All,
In the examples of RFC 8152 [1] the COSE_Mac0 and COSE_Encrypt0 examples don't
include a key identifier ("kid" parameter) in the top-level unprotected
headers, and there is no example of COSE_Sign1 message. The informative text
implies that there should not be a kid parameter, but I don't see this in any
normative statement of RFC 8152 or in the errata [2]. I also don't see any
difference in the upcoming 8152bis document [3].
I thought that the algorithm itself determined which protected/unprotected
headers were acceptable within a particular layer, while the message type
determined the top-level structure and whether there are sub-layers.
Is there a fundamental reason why the single-signer example (from C.1.1) of:
98(
[
/ protected / h'',
/ unprotected / {},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 /
} >>,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'...'
]
]
]
)
could not be rewritten as a COSE_Sign1 message of:
18(
[
/ protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 /
} >>,
/ unprotected / {
/ kid / 4:'11'
},
/ payload / 'This is the content.',
/ signature / h'...'
]
)
I thought that the point of the COSE_Mac0, COSE_Sign1, COSE_Encrypt0 messages
were just to reduce the framing overhead of allowing multiple signatures.
Thanks for any clarification,
Brian S.
[1] https://tools.ietf.org/html/rfc8152#appendix-C
[2] https://www.rfc-editor.org/errata_search.php?rfc=8152
[3] https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-14
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
