COSE WG, Within the COSE_Sign/COSE_Sign1 messages the "payload" is optionally nil-valued and within COSE_Encrypt/COSE_Encrypt0 messages the "ciphertext" is optionally nil-valued, in both cases these nil values convey that the payload or ciphertext is "detached" and held elsewhere.
There is a similar type union for COSE_recipient structure "ciphertext" field, but less explanation about the semantics or uses of the nil value here. All of the examples in RFC 9052 make use of empty-bstr recipient ciphertext when the algorithm doesn't make use of one, search for "/ ciphertext / h''" to see these examples. This seems a little backward to me (the KDF-based recipient algs do not have ciphertext) but these already exist. So for the question of the semantics of this recipient field: 1. Is there a meaningful distinction between empty-bstr and nil value? 2. Is there a reason why a generator-encoder would use one over the other? 3. Should a decoder-processor treat them differently? 4. Is it okay for a general purpose codec to treat them as equivalent and normalize to one form? Finally, it seems like this deserves some errata discussion for Section 5.1. I can write one if there is some consensus about what the "right" answers are. Thoughts on this are welcome, Brian S.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
