-04 is a good improvement. Thank you.

The kid parameter is always optional in COSE. It shouldn’t be mandatory in 
3.1.1 and 3.1.2. I think this is a mandatory change for this draft. Section 5.2 
of 9052 even discourages use of kid in and Encrypt0:

The COSE_Encrypt0 encrypted structure does not have the ability to specify 
recipients of the message.  The structure assumes that the recipient of the 
object will already know the identity of the key to be used in order to decrypt 
the message.  If a key needs to be identified to the recipient, the enveloped 
structure ought to be used.

Key identification is something that COSE leaves up to the layers above as far 
as I can see. It should probably have been mentioned as one of the things a 
COSE profile should specify in section 10 of RFC 9052. I have found this a bit 
odd, particularly compared to CMS, but I can see the value in leaving it open.


I’d like for “HPKE” to be in the name of the structure since it is HPKE 
specific — perhaps “HPKE_sender_info”.


I think it’s better to say “plaintext” rather than “detached plaintext” in 
section 5. The plaintext is an input to COSE which may then turn into an inline 
cipher text or a detached cipher text. The plaintext is the same in both cases 
so there’s not really any such things as “detached plaintext”.


Section 4.3 is clear now and well-aligned with what I was thinking it should 
be. A few suggestions:

Say “again as required RFC 9052” rather than "again intentionally aligned with 
COSE by re-using the Enc_structure” in 4.3.1.

Say “The external_aad in the Enc_structrue contains the Externally Supplied 
Data described in 4.3 and 5.3 in RFC 9052”  rather than "The external_aad field 
in the Enc_structure is populated with the API caller provided AAD 
information”. There are several occurrences.

While it is not wrong, the distinct descriptions in 4.3.1 and 4.3.3 are a 
little confusing. The AAD input to SealBase in 4.3.1 is exactly the same as the 
AAD input to the AEAD in 4.3.3. Why not say “An  Enc_structure is create per 
RFC 9052 section 5.3. For Encrypt0 it is passed to SealBase. For Encrypt it is 
passed to the AEAD”.

I also made related comments in the “COSE-HPKE: AAD and Info” thread.


I will comment on the info parameter to SealBase separately.

LL

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to