Algorithm ID should be optional

[laurencelundblade]

Section 3.1.1 says the algorithm ID must be set.

COSE doesn't require this. COSE allows the algorithm ID to be known from context some sort of negotiation scheme or other means outside of the COSE message itself.

I don't think COSE-HPKE has any characteristic that changes this set up here.

The line that says "The sender MUST set the alg parameter" can just be deleted.

Same in 3.1.2. It is allows that all algorithms IDs are omitted and the algorithm known only by context, even with multiple recipients.

[dajiaji]

Regarding the alg as a COSE_Key parameter, it should be optional and shouldn't be required. However, to my understanding, the alg as a COSE header parameter can be required.

For example, all of the COSE key distibution methods (including direct key agreement and key agreement with key wrap) defined in RFC9052 require the alg as a COSE header parameter as follows:

The "alg" header parameter MUST be present. (Section 8.5.1, RFC9052)

I think the COSE-HPKE should also require it. In particular, since we decided to include the HPKE ciphersuites information to the alg, I think we cannot omit the alg from the COSE header.

[hannestschofenig]

Given the discussion about the "KDF for Content Encryption" from the LAMPS meeting @ IETF#118 (see https://www.youtube.com/watch?v=Iwq3FlqIbtE) I feel that this issue has been resolved.

The conclusion of that discussion was that we need to provide the algorithm id as input to the KDF. Not sending the algorithm id and to infer it from the context makes it more error prone for implementers.

So, are you still of the opinion that the algorithm id used for content encryption should be optional? (The algorithm id for the recipient structure is mandatory anyway).

[selfissued]

I agree that alg should be required, as in the rest of COSE, and that this issue should be closed on that basis.

[dajiaji]

I agree to close this PR.

[laurencelundblade]

Ajitomi-san is right that 9052 requires the algorithm ID for COSE_Recipient types it specifies, but this is only for specific COSE_Recipient types, not for the main body and not a blanket COSE requirement. Algorithm IDs are NOT universally required in COSE.

To line up COSE-HPKE with what 9052 does, retain the requirement text in 3.1.2, but remove the requirement in 3.1.1.

Hannes, we haven't settled how we provide the algorithm ID(s) to the KDF Context. It can just be in the Context Info Structure in which case there's no need for it in a header parameter.

Note that an algorithm ID is always known to the COSE library. It is sometimes specified by a header parameter and other times it comes from context outside of COSE and there's no header parameter.

The main reason I can think of for leaving it out is to reduce COSE message size. Maybe there's some weird single recipient COSE+HPKE API use case where it helps too.

I'd still like to see it optional in the main body (remove requirement text in 3.1.1) for maximal alignment with 9052, but algorithm IDs are very small, so I won't insist past this comment.

[selfissued]

All the Content Key Distribution Methods in Section 8.5 of RFC 9052 require the "alg" header parameter to be present. I see no reason that HPKE should do things different.

Unless someone can point me to text in 9052 that explicitly describes situations in which "alg" is optional, I oppose making this change.

[laurencelundblade]

Mike, yes, you are right about section 8 in 9052, but that is only for COSE_Recipients, not the bulk encryption algorithm at the top level of the COSE message.

Here's the CDDL from 9052 that shows the alg ID is optional:

Generic_Headers = ( ? 1 => int / tstr, ; algorithm identifier ? 2 => [+label], ; criticality ? 3 => tstr / int, ; content type ? 4 => bstr, ; key identifier ? ( 5 => bstr // ; IV 6 => bstr ) ; Partial IV )

As far as I can see, there is no text in 9052 that says in a general way that alg id is mandatory. What is in section 8 of 9052 is that all the key distribution mechanisms individually require it.

This is not a big deal for me either way. I think leaving the alg ID out is only a small size optimization and not much more.

[dajiaji]

Okay. If we have to follow the convention of RFC9052, it seams appropriate for the alg id should be OPTIONAL as Laurence mentioned.

Actually, the ciphersuite (the combination of KEM, KDF and AEAD) information is bound to the encapsulated_key, so there should be no security issues. It seams that it is a reasonable use case in COSE to pre-determine a specific ciphersuite between the sender and the recipient and reduce the message size.

I think the alg value should be specified, but I agree that it should not be mandated.