Skip to content

Commit

Permalink
Script updating gh-pages from 5f5c0b1. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed May 24, 2024
1 parent 1a2673e commit aa95691
Show file tree
Hide file tree
Showing 3 changed files with 1,215 additions and 1,175 deletions.
42 changes: 27 additions & 15 deletions draft-ietf-rats-eat.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1909,7 +1909,7 @@ <h2 id="name-top-level-token-definition">
This includes the nesting of an EAT that is a different format than the enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT encoded using JSON or vice versa.
The definition of Nested-Token references the CDDL defined in this section.
When new token formats are defined, the means for identification in a nested token <span class="bcp14">MUST</span> also be defined.<a href="#section-3-7" class="pilcrow"></a></p>
<p id="section-3-8">The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for shared definitions of most items in this document, they don’t provide enough support for this sharing at the top level).<a href="#section-3-8" class="pilcrow"></a></p>
<p id="section-3-8">The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for shared definitions of most items in this document, they don't provide enough support for this sharing at the top level).<a href="#section-3-8" class="pilcrow"></a></p>
<div class="lang-CDDL sourcecode" id="section-3-9">
<pre>
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
Expand Down Expand Up @@ -3125,7 +3125,7 @@ <h3 id="name-full-and-partial-profiles">
<p id="section-6.2-2">For example, a profile that allows the use of signing algorithms by the sender that the receiver is not required to support is a partial profile.
The sender might choose a signing algorithm that some receivers don't support.<a href="#section-6.2-2" class="pilcrow"></a></p>
<p id="section-6.2-3">Full profiles <span class="bcp14">MUST</span> be complete such that a complying receiver can decode, verify and check for freshness every EAT created by a complying sender.
A full profile <span class="bcp14">MAY</span> or <span class="bcp14">MAY</span> NOT require the receiver to fully handle every claim in an EAT from a complying sender.
Full profiles do not need to require the receiver fully handle every claim in an EAT from a complying sender.
Profile specifications may assume the receiver has access to the necessary verification keys or may go into specific detail on the means to access verification keys.<a href="#section-6.2-3" class="pilcrow"></a></p>
<p id="section-6.2-4">The "eat_profile" claim <span class="bcp14">MUST NOT</span> be used to identify partial profiles.<a href="#section-6.2-4" class="pilcrow"></a></p>
<p id="section-6.2-5">While fewer profiles are preferrable, sometimes several may be needed for a use case.
Expand Down Expand Up @@ -3341,7 +3341,7 @@ <h3 id="name-the-constrained-device-stan">
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">Detached EAT Bundle Usage</td>
<td class="text-left" rowspan="1" colspan="1">Detached EAT bundles <span class="bcp14">MUST</span> not be sent with this profile</td>
<td class="text-left" rowspan="1" colspan="1">Detached EAT bundles <span class="bcp14">MUST NOT</span> be sent with this profile</td>
</tr>
<tr>
<td class="text-left" rowspan="1" colspan="1">Verification Key Identification</td>
Expand Down Expand Up @@ -3458,7 +3458,7 @@ <h4 id="name-json-interoperability">
<p id="section-7.2.2-2.4.1">uri -- <span class="bcp14">MUST</span> be a URI <span>[<a href="#RFC3986" class="cite xref">RFC3986</a>]</span>.<a href="#section-7.2.2-2.4.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-7.2.2-2.5">
<p id="section-7.2.2-2.5.1">oid -- <span class="bcp14">MUST</span> be encoded as a string using the well established dotted-decimal notation (e.g., the text "1.2.250.1") <span>[<a href="#RFC2252" class="cite xref">RFC2252</a>]</span>.<a href="#section-7.2.2-2.5.1" class="pilcrow"></a></p>
<p id="section-7.2.2-2.5.1">oid -- <span class="bcp14">MUST</span> be encoded as a string using the well established dotted-decimal notation (e.g., the text "1.2.250.1") <span>[<a href="#RFC4517" class="cite xref">RFC4517</a>]</span>.<a href="#section-7.2.2-2.5.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-7.2.2-3">The CDDL generic "JC&lt;&gt;" is used in most places where there is a variance between CBOR and JSON.
Expand Down Expand Up @@ -4634,7 +4634,7 @@ <h3 id="name-ueid-urn-registered-by-this">
<div class="alignLeft art-text artwork" id="section-10.3-4">
<pre>
body =/ ueidbody
ueidbody = %s”ueid:” b64ueid
ueidbody = %s"ueid:" b64ueid
</pre><a href="#section-10.3-4" class="pilcrow"></a>
</div>
</section>
Expand Down Expand Up @@ -4712,14 +4712,14 @@ <h3 id="name-normative-references">
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2252">[RFC2252]</dt>
<dd>
<span class="refAuthor">Wahl, M.</span>, <span class="refAuthor">Coulbeck, A.</span>, <span class="refAuthor">Howes, T.</span>, and <span class="refAuthor">S. Kille</span>, <span class="refTitle">"Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions"</span>, <span class="seriesInfo">RFC 2252</span>, <span class="seriesInfo">DOI 10.17487/RFC2252</span>, <time datetime="1997-12" class="refDate">December 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc2252">https://www.rfc-editor.org/rfc/rfc2252</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
<dd>
<span class="refAuthor">Berners-Lee, T.</span>, <span class="refAuthor">Fielding, R.</span>, and <span class="refAuthor">L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc3986">https://www.rfc-editor.org/rfc/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4517">[RFC4517]</dt>
<dd>
<span class="refAuthor">Legg, S., Ed.</span>, <span class="refTitle">"Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"</span>, <span class="seriesInfo">RFC 4517</span>, <span class="seriesInfo">DOI 10.17487/RFC4517</span>, <time datetime="2006-06" class="refDate">June 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc4517">https://www.rfc-editor.org/rfc/rfc4517</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4648">[RFC4648]</dt>
<dd>
<span class="refAuthor">Josefsson, S.</span>, <span class="refTitle">"The Base16, Base32, and Base64 Data Encodings"</span>, <span class="seriesInfo">RFC 4648</span>, <span class="seriesInfo">DOI 10.17487/RFC4648</span>, <time datetime="2006-10" class="refDate">October 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc4648">https://www.rfc-editor.org/rfc/rfc4648</a>&gt;</span>. </dd>
Expand Down Expand Up @@ -4837,10 +4837,6 @@ <h3 id="name-informative-references">
<dd>
<span class="refTitle">"IEEE Registration Authority Assignments"</span>, <span>&lt;<a href="https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries">https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4122">[RFC4122]</dt>
<dd>
<span class="refAuthor">Leach, P.</span>, <span class="refAuthor">Mealling, M.</span>, and <span class="refAuthor">R. Salz</span>, <span class="refTitle">"A Universally Unique IDentifier (UUID) URN Namespace"</span>, <span class="seriesInfo">RFC 4122</span>, <span class="seriesInfo">DOI 10.17487/RFC4122</span>, <time datetime="2005-07" class="refDate">July 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc4122">https://www.rfc-editor.org/rfc/rfc4122</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4949">[RFC4949]</dt>
<dd>
<span class="refAuthor">Shirey, R.</span>, <span class="refTitle">"Internet Security Glossary, Version 2"</span>, <span class="seriesInfo">FYI 36</span>, <span class="seriesInfo">RFC 4949</span>, <span class="seriesInfo">DOI 10.17487/RFC4949</span>, <time datetime="2007-08" class="refDate">August 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc4949">https://www.rfc-editor.org/rfc/rfc4949</a>&gt;</span>. </dd>
Expand All @@ -4849,6 +4845,10 @@ <h3 id="name-informative-references">
<dd>
<span class="refAuthor">Arkko, J.</span>, <span class="refAuthor">Jennings, C.</span>, and <span class="refAuthor">Z. Shelby</span>, <span class="refTitle">"Uniform Resource Names for Device Identifiers"</span>, <span class="seriesInfo">RFC 9039</span>, <span class="seriesInfo">DOI 10.17487/RFC9039</span>, <time datetime="2021-06" class="refDate">June 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9039">https://www.rfc-editor.org/rfc/rfc9039</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9562">[RFC9562]</dt>
<dd>
<span class="refAuthor">Davis, K.</span>, <span class="refAuthor">Peabody, B.</span>, and <span class="refAuthor">P. Leach</span>, <span class="refTitle">"Universally Unique IDentifiers (UUIDs)"</span>, <span class="seriesInfo">RFC 9562</span>, <span class="seriesInfo">DOI 10.17487/RFC9562</span>, <time datetime="2024-05" class="refDate">May 2024</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9562">https://www.rfc-editor.org/rfc/rfc9562</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="UCCS">[UCCS]</dt>
<dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">O'Donoghue, J.</span>, <span class="refAuthor">Cam-Winget, N.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"A CBOR Tag for Unprotected CWT Claims Sets"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rats-uccs-09</span>, <time datetime="2024-03-04" class="refDate">4 March 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-rats-uccs-09">https://datatracker.ietf.org/doc/html/draft-ietf-rats-uccs-09</a>&gt;</span>. </dd>
Expand Down Expand Up @@ -4896,7 +4896,7 @@ <h4 id="name-simple-tee-attestation">
/ This is byte-string wrapped /
/ payload CoSWID. It gives the TEE /
/ software name, the version and /
/ the name of the file it is in. /
/ the name of the file it is in. /
/ {0: "3a24", /
/ 12: 1, /
/ 1: "Acme TEE OS", /
Expand Down Expand Up @@ -5689,7 +5689,7 @@ <h3 id="name-collision-probability">
<h3 id="name-no-use-of-uuid">
<a href="#appendix-B.2" class="section-number selfRef">B.2. </a><a href="#name-no-use-of-uuid" class="section-name selfRef">No Use of UUID</a>
</h3>
<p id="appendix-B.2-1">A UEID is not a Universally Unique Identifier (UUID) <span>[<a href="#RFC4122" class="cite xref">RFC4122</a>]</span> by conscious choice for the following reasons.<a href="#appendix-B.2-1" class="pilcrow"></a></p>
<p id="appendix-B.2-1">A UEID is not a Universally Unique Identifier (UUID) <span>[<a href="#RFC9562" class="cite xref">RFC9562</a>]</span> by conscious choice for the following reasons.<a href="#appendix-B.2-1" class="pilcrow"></a></p>
<p id="appendix-B.2-2">UUIDs are limited to 128 bits which may not be enough for some future
use cases.<a href="#appendix-B.2-2" class="pilcrow"></a></p>
<p id="appendix-B.2-3">Today, cryptographic-quality random numbers are available from common
Expand Down Expand Up @@ -6047,6 +6047,18 @@ <h3 id="name-from-draft-ietf-rats-eat-24">
</li>
<li class="normal" id="appendix-G.1-2.2">
<p id="appendix-G.1-2.2.1">Remove all dependence on SUIT Manifest to break schedule interlock with RFC Editor. Use of SUIT-Manifest is peripheral to the core of EAT. It was mostly a content type pre-registration. The modification consisted of the removal of one sentence, a few more words and two lines of CDDL.<a href="#appendix-G.1-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-G.1-2.3">
<p id="appendix-G.1-2.3.1">Reworded full profiles description to convey intent without using "may not"<a href="#appendix-G.1-2.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-G.1-2.4">
<p id="appendix-G.1-2.4.1">Upated references for UUIDs and LDAP to non-obsolete documents.<a href="#appendix-G.1-2.4.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-G.1-2.5">
<p id="appendix-G.1-2.5.1">Removed some non-ascii quote marks<a href="#appendix-G.1-2.5.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-G.1-2.6">
<p id="appendix-G.1-2.6.1">"<span class="bcp14">MAY</span> not" -&gt; "<span class="bcp14">MAY</span> NOT"<a href="#appendix-G.1-2.6.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
Expand Down
50 changes: 29 additions & 21 deletions draft-ietf-rats-eat.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -565,7 +565,7 @@ Table of Contents
The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and
for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough
support for shared definitions of most items in this document, they
don’t provide enough support for this sharing at the top level).
don't provide enough support for this sharing at the top level).

EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token

Expand Down Expand Up @@ -1863,11 +1863,11 @@ Table of Contents

Full profiles MUST be complete such that a complying receiver can
decode, verify and check for freshness every EAT created by a
complying sender. A full profile MAY or MAY NOT require the receiver
to fully handle every claim in an EAT from a complying sender.
Profile specifications may assume the receiver has access to the
necessary verification keys or may go into specific detail on the
means to access verification keys.
complying sender. Full profiles do not need to require the receiver
fully handle every claim in an EAT from a complying sender. Profile
specifications may assume the receiver has access to the necessary
verification keys or may go into specific detail on the means to
access verification keys.

The "eat_profile" claim MUST NOT be used to identify partial
profiles.
Expand Down Expand Up @@ -2094,7 +2094,7 @@ Table of Contents
| Algorithms | The receiver MUST accept ES256, ES384 and |
| | ES512; the sender MUST send one of these |
+----------------+---------------------------------------------+
| Detached EAT | Detached EAT bundles MUST not be sent with |
| Detached EAT | Detached EAT bundles MUST NOT be sent with |
| Bundle Usage | this profile |
+----------------+---------------------------------------------+
| Verification | Either the COSE kid or the UEID MUST be |
Expand Down Expand Up @@ -2217,7 +2217,7 @@ Table of Contents
* uri -- MUST be a URI [RFC3986].

* oid -- MUST be encoded as a string using the well established
dotted-decimal notation (e.g., the text "1.2.250.1") [RFC2252].
dotted-decimal notation (e.g., the text "1.2.250.1") [RFC4517].

The CDDL generic "JC<>" is used in most places where there is a
variance between CBOR and JSON. The first argument is the CDDL for
Expand Down Expand Up @@ -3145,7 +3145,7 @@ Table of Contents
encoded binary byte-string for the UEID or SUEID:

body =/ ueidbody
ueidbody = %s”ueid:” b64ueid
ueidbody = %s"ueid:" b64ueid

10.4. CBOR Tag for Detached EAT Bundle Registered by this Document

Expand Down Expand Up @@ -3193,16 +3193,16 @@ Table of Contents
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, DOI 10.17487/RFC2252,
December 1997, <https://www.rfc-editor.org/rfc/rfc2252>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.

[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517,
DOI 10.17487/RFC4517, June 2006,
<https://www.rfc-editor.org/rfc/rfc4517>.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
Expand Down Expand Up @@ -3347,11 +3347,6 @@ Table of Contents
<https://regauth.standards.ieee.org/standards-ra-web/pub/
view.html#registries>.

[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/rfc/rfc4122>.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>.
Expand All @@ -3361,6 +3356,10 @@ Table of Contents
DOI 10.17487/RFC9039, June 2021,
<https://www.rfc-editor.org/rfc/rfc9039>.

[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>.

[UCCS] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-09,
Expand Down Expand Up @@ -3406,7 +3405,7 @@ A.1.1. Simple TEE Attestation
/ This is byte-string wrapped /
/ payload CoSWID. It gives the TEE /
/ software name, the version and /
/ the name of the file it is in. /
/ the name of the file it is in. /
/ {0: "3a24", /
/ 12: 1, /
/ 1: "Acme TEE OS", /
Expand Down Expand Up @@ -4042,7 +4041,7 @@ B.1. Collision Probability

B.2. No Use of UUID

A UEID is not a Universally Unique Identifier (UUID) [RFC4122] by
A UEID is not a Universally Unique Identifier (UUID) [RFC9562] by
conscious choice for the following reasons.

UUIDs are limited to 128 bits which may not be enough for some future
Expand Down Expand Up @@ -4472,6 +4471,15 @@ G.1. From draft-ietf-rats-eat-24
modification consisted of the removal of one sentence, a few more
words and two lines of CDDL.

* Reworded full profiles description to convey intent without using
"may not"

* Upated references for UUIDs and LDAP to non-obsolete documents.

* Removed some non-ascii quote marks

* "MAY not" -> "MAY NOT"

Contributors

Many thanks to the following contributors to draft versions of this
Expand Down

0 comments on commit aa95691

Please sign in to comment.