rfc9711v2.txt   rfc9711.txt 
skipping to change at line 549 skipping to change at line 549
on the protocol carrying the EAT. In some cases, it may be by media on the protocol carrying the EAT. In some cases, it may be by media
type (e.g., in an HTTP Content-Type field). In other cases, it may type (e.g., in an HTTP Content-Type field). In other cases, it may
be through use of CBOR tags. There is no fixed mechanism across all be through use of CBOR tags. There is no fixed mechanism across all
use cases. use cases.
This document also defines another message, the detached EAT bundle This document also defines another message, the detached EAT bundle
(see Section 5), which holds a collection of detached claims sets and (see Section 5), which holds a collection of detached claims sets and
an EAT that provides integrity and authenticity protection for them. an EAT that provides integrity and authenticity protection for them.
Detached EAT bundles can be either CBOR or JSON encoded. Detached EAT bundles can be either CBOR or JSON encoded.
The following CDDL defines the top-level $EAT-CBOR-Tagged-Token, The following CDDL defines the top-level $CBOR-Tagged-Token, $EAT-
$EAT-CBOR-Untagged-Token, and $EAT-JSON-Token-Formats sockets (see CBOR-Untagged-Token, and $EAT-JSON-Token-Formats sockets (see
Section 3.9 of [RFC8610]), enabling future token formats to be Section 3.9 of [RFC8610]), enabling future token formats to be
defined. Any new format that plugs into one or more of these sockets defined. Any new format that plugs into one or more of these sockets
MUST be defined by an IETF Standards Action [RFC8126]. Of particular MUST be defined by an IETF Standards Action [RFC8126]. Of particular
use may be a token type that provides no direct authenticity or use may be a token type that provides no direct authenticity or
integrity protection for use with transport mechanisms that do integrity protection for use with transport mechanisms that do
provide the necessary security services [UCCS]. provide the necessary security services [UCCS].
Nesting of EATs is allowed and defined in Section 4.2.18.3. This Nesting of EATs is allowed and defined in Section 4.2.18.3. This
includes the nesting of an EAT that is in a different format than the includes the nesting of an EAT that is in a different format than the
enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the
skipping to change at line 572 skipping to change at line 572
Nested-Token references the CDDL defined in this section. When new Nested-Token references the CDDL defined in this section. When new
token formats are defined, the means for identification in a nested token formats are defined, the means for identification in a nested
token MUST also be defined. token MUST also be defined.
The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and
for JSON-encoded EATs is EAT-JSON-Token (while CDDL and CDDL tools for JSON-encoded EATs is EAT-JSON-Token (while CDDL and CDDL tools
provide enough support for shared definitions of most items in this provide enough support for shared definitions of most items in this
document, they do not provide enough support for this sharing at the document, they do not provide enough support for this sharing at the
top level). top level).
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token EAT-CBOR-Token = $CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message $CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message $EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message $EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message $EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
EAT-JSON-Token = $EAT-JSON-Token-Formats EAT-JSON-Token = $EAT-JSON-Token-Formats
$EAT-JSON-Token-Formats /= JWT-Message $EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message $EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message
skipping to change at line 1497 skipping to change at line 1497
The Submodule type and Nested-Token type definitions vary with the The Submodule type and Nested-Token type definitions vary with the
type of encoding. The definitions for CBOR-encoded EATs are as type of encoding. The definitions for CBOR-encoded EATs are as
follows: follows:
Nested-Token = CBOR-Nested-Token Nested-Token = CBOR-Nested-Token
CBOR-Nested-Token = CBOR-Nested-Token =
JSON-Token-Inside-CBOR-Token / JSON-Token-Inside-CBOR-Token /
CBOR-Token-Inside-CBOR-Token CBOR-Token-Inside-CBOR-Token
CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token CBOR-Token-Inside-CBOR-Token = bstr .cbor $CBOR-Tagged-Token
JSON-Token-Inside-CBOR-Token = tstr JSON-Token-Inside-CBOR-Token = tstr
$$Claims-Set-Claims //= (submods-label => { + text => Submodule }) $$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / CBOR-Nested-Token / Submodule = Claims-Set / CBOR-Nested-Token /
Detached-Submodule-Digest Detached-Submodule-Digest
The Submodule and Nested-Token definitions for JSON-encoded EATs are The Submodule and Nested-Token definitions for JSON-encoded EATs are
as below. The definitions are necessarily different than CBOR as below. The definitions are necessarily different than CBOR
skipping to change at line 1540 skipping to change at line 1540
Detached-Submodule-Digest = [ Detached-Submodule-Digest = [
hash-algorithm : text / int, hash-algorithm : text / int,
digest : binary-data digest : binary-data
] ]
Nested tokens can be one of three types as defined in this document Nested tokens can be one of three types as defined in this document
or types that are standardized in subsequent documents (e.g., or types that are standardized in subsequent documents (e.g.,
[UCCS]). Nested tokens are the only mechanism by which JSON can be [UCCS]). Nested tokens are the only mechanism by which JSON can be
embedded in CBOR and vice versa. embedded in CBOR and vice versa.
The addition of further types is accomplished by augmenting the $EAT- The addition of further types is accomplished by augmenting the
CBOR-Tagged-Token socket or the $JSON-Selector socket. $CBOR-Tagged-Token socket or the $JSON-Selector socket.
When decoding a JSON-encoded EAT, the type of submodule is determined When decoding a JSON-encoded EAT, the type of submodule is determined
as follows. A JSON object indicates that the submodule is a Claims- as follows. A JSON object indicates that the submodule is a Claims-
Set. In all other cases, it is a JSON-Selector, which is an array of Set. In all other cases, it is a JSON-Selector, which is an array of
two elements that indicates whether the submodule is a nested token two elements that indicates whether the submodule is a nested token
or a Detached-Submodule-Digest. The first element in the array or a Detached-Submodule-Digest. The first element in the array
indicates the type present in the second element. If the value is indicates the type present in the second element. If the value is
"JWT", "CBOR", "BUNDLE", or future-standardized token types, e.g., "JWT", "CBOR", "BUNDLE", or future-standardized token types, e.g.,
see [UCCS], the submodule is a nested token of the indicated type, see [UCCS], the submodule is a nested token of the indicated type,
i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle,
skipping to change at line 1764 skipping to change at line 1764
EAT bundle, they can be very short, perhaps one byte. EAT bundle, they can be very short, perhaps one byte.
BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message
BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message) BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle BUNDLE-Untagged-Message = Detached-EAT-Bundle
Detached-EAT-Bundle = [ Detached-EAT-Bundle = [
main-token : Nested-Token, main-token : Nested-Token,
detached-claims-sets: { detached-claims-sets: {
+ tstr => JC-NEST-SAFE<json-wrapped-claims-set, + tstr => JC<json-wrapped-claims-set,
cbor-wrapped-claims-set> cbor-wrapped-claims-set>
} }
] ]
json-wrapped-claims-set = base64-url-text json-wrapped-claims-set = base64-url-text
cbor-wrapped-claims-set = bstr .cbor Claims-Set cbor-wrapped-claims-set = bstr .cbor Claims-Set
6. Profiles 6. Profiles
EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT, and JWT. EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT, and JWT.
skipping to change at line 2425 skipping to change at line 2425
] ]
BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message
BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message) BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle BUNDLE-Untagged-Message = Detached-EAT-Bundle
Detached-EAT-Bundle = [ Detached-EAT-Bundle = [
main-token : Nested-Token, main-token : Nested-Token,
detached-claims-sets: { detached-claims-sets: {
+ tstr => JC-NEST-SAFE<json-wrapped-claims-set, + tstr => JC<json-wrapped-claims-set,
cbor-wrapped-claims-set> cbor-wrapped-claims-set>
} }
] ]
json-wrapped-claims-set = base64-url-text json-wrapped-claims-set = base64-url-text
cbor-wrapped-claims-set = bstr .cbor Claims-Set cbor-wrapped-claims-set = bstr .cbor Claims-Set
nonce-label = JC< "eat_nonce", 10 > nonce-label = JC< "eat_nonce", 10 >
ueid-label = JC< "ueid", 256 > ueid-label = JC< "ueid", 256 >
sueids-label = JC< "sueids", 257 > sueids-label = JC< "sueids", 257 >
skipping to change at line 2458 skipping to change at line 2458
dloas-label = JC< "dloas", 269 > dloas-label = JC< "dloas", 269 >
sw-name-label = JC< "swname", 270 > sw-name-label = JC< "swname", 270 >
sw-version-label = JC< "swversion", 271 > sw-version-label = JC< "swversion", 271 >
manifests-label = JC< "manifests", 272 > manifests-label = JC< "manifests", 272 >
measurements-label = JC< "measurements", 273 > measurements-label = JC< "measurements", 273 >
measurement-results-label = JC< "measres" , 274 > measurement-results-label = JC< "measres" , 274 >
intended-use-label = JC< "intuse", 275 > intended-use-label = JC< "intuse", 275 >
7.3.2. CBOR-Specific CDDL 7.3.2. CBOR-Specific CDDL
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token EAT-CBOR-Token = $CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message $CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message $CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message $EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message $EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
Nested-Token = CBOR-Nested-Token Nested-Token = CBOR-Nested-Token
CBOR-Nested-Token = CBOR-Nested-Token =
JSON-Token-Inside-CBOR-Token / JSON-Token-Inside-CBOR-Token /
CBOR-Token-Inside-CBOR-Token CBOR-Token-Inside-CBOR-Token
CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token CBOR-Token-Inside-CBOR-Token = bstr .cbor $CBOR-Tagged-Token
JSON-Token-Inside-CBOR-Token = tstr JSON-Token-Inside-CBOR-Token = tstr
$$Claims-Set-Claims //= (submods-label => { + text => Submodule }) $$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / CBOR-Nested-Token / Submodule = Claims-Set / CBOR-Nested-Token /
Detached-Submodule-Digest Detached-Submodule-Digest
7.3.3. JSON-Specific CDDL 7.3.3. JSON-Specific CDDL
skipping to change at line 2974 skipping to change at line 2974
* Each intended use should be distinct from others that are * Each intended use should be distinct from others that are
registered. registered.
* Point squatting is discouraged. * Point squatting is discouraged.
The three columns for the registry are: The three columns for the registry are:
1. Value: This is a unique integer that is used to identify the 1. Value: This is a unique integer that is used to identify the
intended use in CBOR-encoded tokens. intended use in CBOR-encoded tokens.
2. Name: This is unique short descriptive string that is used to 2. Description: This is one or more text paragraphs that
identify the use in JSON-encoded tokens.
3. Description: This is one or more text paragraphs that
sufficiently define what the intended use means. It may also be sufficiently define what the intended use means. It may also be
a reference to another document. a reference to another document.
3. Reference: This field contains a reference to the defining
specification.
The following 5 values represent the initial content of the registry. The following 5 values represent the initial content of the registry.
Note that 0 will be marked as "reserved" for the CBOR value, and the Note that 0 will be marked as "reserved" for the CBOR value, and the
maximum CBOR value for assignment is 255. maximum CBOR value for assignment is 255.
1 -- Generic: Generic attestation describes an application where the 1 -- Generic: Generic attestation describes an application where the
EAT consumer requires the most up-to-date security assessment of EAT consumer requires the most up-to-date security assessment of
the attesting entity. It is expected that this is the most the attesting entity. It is expected that this is the most
commonly used application of EAT. commonly used application of EAT.
2 -- Registration: Entities that are registering for a new service 2 -- Registration: Entities that are registering for a new service
skipping to change at line 3710 skipping to change at line 3710
/ { / / { /
/ 10: h'948F8860D13A463E', / / 10: h'948F8860D13A463E', /
/ 256: h'0198F50A4FF6C05861C8860D13A638EA', / / 256: h'0198F50A4FF6C05861C8860D13A638EA', /
/ 258: 64242, / / 258: 64242, /
/ 262: true, / / 262: true, /
/ 263: 3, / / 263: 3, /
/ 260: ["3.1", 1], / / 260: ["3.1", 1], /
/ 266: { / / 266: { /
/ "TEE": [ / / "TEE": [ /
/ -16, / / -16, /
/ h'8DEF652F47000710D9F466A4C666E209 / / h'ab86f765643aabfd09c84eebe150b7f6 /
/ DD74F927A1CEA352B03143E188838ABE' / / 1bc24804cee75e90c5f99cb850fe808f' /
/ ] / / ] /
/ } / / } /
/ } / / } /
h'D83DD28443A10126A05866A80A48948F8860D13A463E1901 h'D83DD28443A10126A05866A80A48948F8860D13A463E1901
00500198F50A4FF6C05861C8860D13A638EA19010219FAF2 00500198F50A4FF6C05861C8860D13A638EA19010219FAF2
19010504190106F5190107031901048263332E310119010A 19010504190106F5190107031901048263332E310119010A
A163544545822F58208DEF652F47000710D9F466A4C666E2 A163544545822F58208DEF652F47000710D9F466A4C666E2
09DD74F927A1CEA352B03143E188838ABE5840F690CB0388 09DD74F927A1CEA352B03143E188838ABE5840F690CB0388
677FA624A3775FD7CBC4E8409EC9816BE32FA474733B0F98 677FA624A3775FD7CBC4E8409EC9816BE32FA474733B0F98
C27FBAEDBBC9963B9CB5ECC03C3E35B3AFC0B7B35B495DEA C27FBAEDBBC9963B9CB5ECC03C3E35B3AFC0B7B35B495DEA
C0997122EA867F07B8D5EB', C0997122EA867F07B8D5EB',
{ {
/ A CBOR-encoded byte-string-wrapped EAT claims-set. It / / A CBOR-encoded byte-string-wrapped EAT claims-set. /
/ contains claims suitable for a TEE. / / It contains claims for a simple TEE attestation. /
"TEE" : h'a40a48948f8860d13a463e190106f519010702 "TEE" : h'a40a5048df7b172d70b5a18935d0460a73dd7119
190111818218795858a60064336132340c0101 0106f51901070219011081821901025858a60064
6b41636d6520544545204f530d65332e312e34 336132340c01016b41636d6520544545204f530d
0282a2181f6b41636d6520544545204f531821 65332e312e340282a2181f6b41636d6520544545
01a2181f6b41636d6520544545204f53182102 204f53182101a2181f6b41636d6520544545204f
06a111a118186e61636d655f7465655f332e65 5318210206a111a118186e61636d655f7465655f
7865' 332e657865'
} }
]) ])
/ This example contains a submodule that is a detached digest, / / This example contains a submodule that is a detached digest, /
/ which is the hash of a Claims-Set conveyed outside this / / which is the hash of a Claims-Set conveyed outside this /
/ token. Additionally, there is an example of a token from an / / token. Additionally, there is an example of a token from an /
/ attestation HW block. / / attestation HW block. /
{ {
/ eat_nonce / 10: h'3515744961254b41a6cf9c02', / eat_nonce / 10: h'3515744961254b41a6cf9c02',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea', / ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: 64242, / Private Enterprise Number / / oemid / 258: 64242, / Private Enterprise Number /
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 3, / disabled-permanently / / dbgstat / 263: 3, / disabled-permanently /
/ hwversion / 260: [ "3.1", 1 ], / multipartnumeric / / hwversion / 260: [ "3.1", 1 ], / multipartnumeric /
/ submods/ 266: { / submods/ 266: {
"TEE": [ / detached digest submod / "TEE": [ / detached digest submod /
-16, / SHA-256 / -16, / SHA-256 /
h'e5cf95fd24fab7144674 h'ab86f765643aabfd09c8
2dd58d43dae178e55fe2 4eebe150b7f61bc24804
b94291a9291082ffc263 cee75e90c5f99cb850fe
5a0b' 808f'
] ]
} }
} }
A.2.3. JSON-Encoded Detached EAT Bundle A.2.3. JSON-Encoded Detached EAT Bundle
In this bundle, there are two detached Claims-Sets: "Audio Subsystem" In this bundle, there are two detached Claims-Sets: "Audio Subsystem"
and "Graphics Subsystem". The JWT at the start of the bundle has and "Graphics Subsystem". The JWT at the start of the bundle has
detached signature submodules with hashes that cover these two detached signature submodules with hashes that cover these two
Claims-Sets. The JWT itself is protected using the Hashed Message Claims-Sets. The JWT itself is protected using the Hashed Message
skipping to change at line 4116 skipping to change at line 4116
exp-claim-label = JC<"exp", 4> exp-claim-label = JC<"exp", 4>
nbf-claim-label = JC<"nbf", 5> nbf-claim-label = JC<"nbf", 5>
iat-claim-label = JC<"iat", 6> iat-claim-label = JC<"iat", 6>
cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text
JSON-ONLY<J> = J .feature "json" JSON-ONLY<J> = J .feature "json"
CBOR-ONLY<C> = C .feature "cbor" CBOR-ONLY<C> = C .feature "cbor"
JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C> JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>
; Same as JC<> but with unwound generic nesting as it seems to cause JC<J,C> = J .feature "json" / C .feature "cbor"
; problems. Perhaps this is the nesting problem described in RFC
; 8610.
JC-NEST-SAFE<J,C> = J .feature "json" / C .feature "cbor"
; A JWT message is either a JSON Web Signature (JWS) or a JSON Web ; A JWT message is either a JSON Web Signature (JWS) or a JSON Web
; Encryption (JWE) in compact serialization form with the payload ; Encryption (JWE) in compact serialization form with the payload
; as a Claims-Set. Compact serialization is the protected headers, ; as a Claims-Set. Compact serialization is the protected headers,
; payload, and signature that are each b64url-encoded and separated ; payload, and signature that are each b64url-encoded and separated
; by a ".". This CDDL simply matches the top-level syntax of a JWS ; by a ".". This CDDL simply matches the top-level syntax of a JWS
; or JWE as it is not possible to do more in CDDL. ; or JWE as it is not possible to do more in CDDL.
JWT-Message = JWT-Message =
text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+" text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+"
 End of changes. 16 change blocks. 
38 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.48.