All,
Thank you for pointing me in the right direction for all of this. I suppose 
that all of the necessary requirements are present _somewhere_ just in slightly 
different forms and phrasing.

The RFC 9052 definition in Section 3 does include the statement under 
"protected:" that "This bucket MUST be empty if it is not going to be included 
in a cryptographic computation." Leaving some details to the reader/implementer 
about when that situation occurs, meaning it can never occur for a MAC or 
signing layer but can potentially occur for an encrypt or key-wrap layer 
depending upon whether the alg used supports AAD.

If an errata were to be written, I am not sure what the subject or replacement 
text would be. But it seems like it would apply to Section 3 of RFC 9052. The 
two situations considered by implementations are: The protected bucket can be 
non-empty if and only if used with an encryption/key-wrap layer and the alg 
does not support AAD. Because of requirements about the alg and crit header 
parameters, and because of the required handling of MAC, signature, key 
encapsulation and key derivation, in all other cases the protected bucket will 
be non-empty.

Brian S.

> -----Original Message-----
> From: Carsten Bormann <[email protected]>
> Sent: Friday, July 4, 2025 12:51 PM
> To: Sipos, Brian J. <[email protected]>
> Cc: [email protected]; [email protected]
> Subject: Re: [COSE] [EXT] Re: Requirement for protected header to actually be
> protected
> 
> APL external email warning: Verify sender [email protected] before clicking links 
> or
> attachments
> 
> On 2025-07-03, at 21:35, Sipos, Brian J. <[email protected]> wrote:
> >
> > But the direct (-6) algorithm makes no such statement
> 
> RFC 9053:
> 6.1.1.  Direct Key
> […]
>    When this algorithm is used, the "protected" field MUST be zero
>    length.  The key type MUST be "Symmetric".
> 
> I’m certainly unhappy about the way the various mandates are spread over
> different documents, but this one appears to be there.
> 
> Grüße, Carsten

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to