[COSE] Re: [EXT] Re: RFC 9052 clarification on recipient ciphertext

["Sipos, Brian J." <[e-mail]>]

Laurence,

The root of the problem is the question “is the decoder-processor supposed to treat null value any differently?”

 

If the intent is that this field is a “do not care” that the algorithm never sees and doesn’t use, then there is a cascade effect:

1.	There is no functional difference between null and empty bstr for verification (or in fact any bstr at all)
2.	The decoder can handle both of these values the same way internally (e.g. decode both to an empty byte string)
3.	The choice of which encoding to use is arbitrary because the value itself is “do not care”
4.	The encoder can choose one preferred value (e.g. always treat as byte string, never output null value)

As far as I can tell, it seems like the answer is: no, the field is “do not care” from the algorithm perspective and the errata is to add a statement that the null value is purely aesthetic and in fact any value MAY be present when the recipient ciphertext is not needed by the algorithm.

 

Brian S.

 

From: Laurence Lundblade <[e-mail]> 
Sent: Monday, July 13, 2026 11:36 PM
To: Sipos, Brian J. <[e-mail]>
Cc: [e-mail]
Subject: [EXT] Re: [COSE] RFC 9052 clarification on recipient ciphertext

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

This text in 5.1 would seem to require nil:

 

ciphertext:

This field contains the encrypted key, encoded as a bstr. All encoded keys are symmetric keys; the binary value of the key is the content. If there is not an encrypted key, then this field is encoded as a nil value.

 

But examples C.3.1 and C.3.2, which don’t have an encrypted key, show:

 

        / ciphertext / h''

 

Probably if we look at Jim Schaad’s code that generated the examples we’ll find h’’. 

 

This is the problem, right? Seems like a problem to me.

 

LL

 





On Jul 8, 2026, at 8:53 AM, Sipos, Brian J. <[e-mail] <mailto:[e-mail]> > wrote:

 

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.

_______________________________________________
COSE mailing list --  <mailto:[e-mail]> [e-mail]
To unsubscribe send an email to  <mailto:[e-mail]> [e-mail]