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 MUST also be defined.¶
-
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).¶
+
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).¶
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.¶
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.
+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.¶
While fewer profiles are preferrable, sometimes several may be needed for a use case.
@@ -3341,7 +3341,7 @@
Detached EAT Bundle Usage
-
Detached EAT bundles MUST not be sent with this profile
+
Detached EAT bundles MUST NOT be sent with this profile
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc4517>.
-Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, , <https://www.rfc-editor.org/rfc/rfc4122>.
Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Names for Device Identifiers", RFC 9039, DOI 10.17487/RFC9039, , <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, , <https://www.rfc-editor.org/rfc/rfc9562>.
/ 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", /
@@ -5689,7 +5689,7 @@
A UEID is not a Universally Unique Identifier (UUID) [RFC4122] by conscious choice for the following reasons.¶
+
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
use cases.¶
Today, cryptographic-quality random numbers are available from common
@@ -6047,6 +6047,18 @@
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.¶
+
+
+
Reworded full profiles description to convey intent without using "may not"¶
+
+
+
Upated references for UUIDs and LDAP to non-obsolete documents.¶
diff --git a/draft-ietf-rats-eat.txt b/draft-ietf-rats-eat.txt
index 954dc06a..e8164edc 100644
--- a/draft-ietf-rats-eat.txt
+++ b/draft-ietf-rats-eat.txt
@@ -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
@@ -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.
@@ -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 |
@@ -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
@@ -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
@@ -3193,16 +3193,16 @@ Table of Contents
DOI 10.17487/RFC2119, March 1997,
.
- [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, .
-
[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,
.
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517,
+ DOI 10.17487/RFC4517, June 2006,
+ .
+
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
.
@@ -3347,11 +3347,6 @@ Table of Contents
.
- [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
- Unique IDentifier (UUID) URN Namespace", RFC 4122,
- DOI 10.17487/RFC4122, July 2005,
- .
-
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
.
@@ -3361,6 +3356,10 @@ Table of Contents
DOI 10.17487/RFC9039, June 2021,
.
+ [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
+ IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
+ 2024, .
+
[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,
@@ -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", /
@@ -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
@@ -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
diff --git a/draft-ietf-rats-eat.xml b/draft-ietf-rats-eat.xml
index 53838cdd..ff2b5546 100644
--- a/draft-ietf-rats-eat.xml
+++ b/draft-ietf-rats-eat.xml
@@ -339,7 +339,7 @@ Of particular use may be a token type that provides no direct authenticity or in
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 MUST also be defined.
- 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).
+ 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).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.
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.
+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.While fewer profiles are preferrable, sometimes several may be needed for a use case.
@@ -1474,7 +1474,7 @@ This section gives a normative definition of one profile that is good for many c
Detached EAT Bundle Usage
-
Detached EAT bundles MUST not be sent with this profile
+
Detached EAT bundles MUST NOT be sent with this profile
Verification Key Identification
@@ -1569,7 +1569,7 @@ following CDDL types are encoded in JSON as follows:
uri -- MUST be a URI .
- oid -- MUST be encoded as a string using the well established dotted-decimal notation (e.g., the text "1.2.250.1") .
+ oid -- MUST be encoded as a string using the well established dotted-decimal notation (e.g., the text "1.2.250.1") .
The CDDL generic "JC<>" is used in most places where there is a variance between CBOR and JSON.
@@ -2640,7 +2640,7 @@ Claim 262 should be renamed from "secboot" to "oemboot" in the JWT registry and
ABNF for these two URNs is as follows where b64ueid is the base64url-encoded binary byte-string for the UEID or SUEID:
@@ -2856,20 +2856,17 @@ specification reference.
-
+
- Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
-
-
-
-
-
+ Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
+
+
- This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]
+ Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. [STANDARDS-TRACK]
-
-
+
+
@@ -2999,20 +2996,29 @@ specification reference.
Informative References
-
+
- A Universally Unique IDentifier (UUID) URN Namespace
+ Universally Unique IDentifiers (UUIDs)
+
+
-
-
-
+
- This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.
- This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]
+ This specification defines UUIDs (Universally Unique IDentifiers) --
+also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
+Resource Name namespace for UUIDs. A UUID is 128 bits long and is
+intended to guarantee uniqueness across space and time. UUIDs were
+originally used in the Apollo Network Computing System (NCS), later
+in the Open Software Foundation's (OSF's) Distributed Computing
+Environment (DCE), and then in Microsoft Windows platforms.
+ This specification is derived from the OSF DCE specification with the
+kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have
+been incorporated into this document. This document obsoletes RFC
+4122.
-
-
+
+
@@ -3255,7 +3261,7 @@ Some examples of signed tokens are also given.
/ 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", /
@@ -3947,7 +3953,7 @@ implementations be able to receive 256-bit UEIDs.
No Use of UUID
- A UEID is not a Universally Unique Identifier (UUID) by conscious choice for the following reasons.
+ A UEID is not a Universally Unique Identifier (UUID) by conscious choice for the following reasons.UUIDs are limited to 128 bits which may not be enough for some future
use cases.Today, cryptographic-quality random numbers are available from common
@@ -4220,12 +4226,24 @@ differences. A comprehensive history is available via the IETF Datatracker's rec
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.
+
+ 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
document:
@@ -4276,1118 +4294,1120 @@ document: