So three distinct uses of algorithm ID out on the table here:
1) Header Parameter
Alg used to sign or encrypt and thus what to use to verify and decrypt
Used in COSE_Sign, COSE_Encrypt…, COSE_Signature, COSE_Recipient
Header Parameter label == 1
Not the same as alg COSE_Key (parameter label == 3)
Seems to be optional. I can’t find anything making it mandatory in RFC 9052.
Here’s the CDDL "Generic_Headers = ( ? 1 => int / tstr, ; algorithm
identifier”. It would be a bad idea to leave it out, but that seems to be
allowed, perhaps to accommodate extremely low bandwidth uses where the
algorithm is known by other means.
https://www.rfc-editor.org/rfc/rfc9052.html#name-common-cose-header-paramete
2) COSE_Key Parameter
Alg used to restrict key use of a particular COSE_Key
Used only on COSE_Key
The required purpose of this is restriction of key use
COSE_Key Parameter label == 3
Definitely optional. "If this parameter is present…” CDDL: "COSE_Key = {... ?
3 => tstr / int, ; alg
https://www.rfc-editor.org/rfc/rfc9052.html#name-cose-key-common-parameters
3) Algorithm negotiation
RFC 9052 defines no protocol message for negotiation
It doesn’t even require that items in the COSE algorithm registry be used for
negotiation, though that seems like a very good and obvious thing to do
https://www.rfc-editor.org/rfc/rfc9052.html#name-application-profiling-consi
Up until COSE_HPKE, 1) and 2) are a single integer ciphersuite. Probably anyone
doing 3) up to until COSE_HPKE would also use the single integer too.
draft-ietf-cose-hpke has addressed 1) with the new HPKE_sender_info header
parameter. Now the algorithm used is a special ciphersuite identifier that
indicates further details in an additional parameter.
draft-ajitomi-cose-cose-key-jwk-hpke-kem is a proposal for 2) COSE_Key using
the same approach as draft-ietf-cose-hpke, but a slightly different structure.
It uses HPKE_Key_Configuration which different from HPKE_sender_info by not
having the enc item.
draft-ajitomi-cose-cose-key-jwk-hpke-kem is also a proposal for 3).
Take-away is:
- Algorithm ID is always optional in COSE and should always be optional in
COSE_HPKE. We can write tons of security considerations to say why that is bad,
but we shouldn’t change COSE fundamentals.
- In COSE_HPKE we’re requiring algorithm identification be made up of a special
ciphersuite and a triple. This will/should apply in all contexts where COSE
algorithm IDs are used. Maybe we should try to unify the definition of this in
draft-ietf-cose-hpke and draft-ajitomi-cose-cose-key-jwk-hpke-kem?
My opinions on 3) are:
- The use cases are too widely varying for anyone to define an actual protocol
- draft-ajitomi-cose-cose-key-jwk-hpke-kem can only work for a small fraction
of negotiation use cases — those that use COSE_Key for negotiation
- We might generalize the HPKE COSE algorithm identifier definition so the same
thing can be used for 1), 2) and 3). That is probably splitting
HPKE_sender_info into two, one structure that is the algorithm ID and one is
the enc info. We still wouldn’t define actual protocol for 3) but we would have
a clear common method for COSE HPKE algorithm identification that anyone could
use for their use-case specific negotiation protocol.
LL
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
