[COSE] IANA COSE assignments

[Göran Selander <[e-mail]>]

 
Hi all,

I'm one of the designated experts for the IANA registry of COSE algorithms and I need some guidance from the WG.

1. Current IANA assignments and instructions for COSE algorithms [1] intentionally bundles certain parameters whereas others are not bundled. 

For example, all COSE registrations of ECDH include key derivation, but ECDH algorithm and elliptic curve are not bundled. Section 6.3.1. states:
 
 ”The math used to obtain the computed secret is based on the curve selected and not on the ECDH algorithm.  For this reason, a new algorithm does not need to be defined for each of the curves.”

As another example, ECDSA is bundled with a hash function (see table 1) but not  with the elliptic curve, see Section 2.1:

”This document defines ECDSA to work only with the curves P-256,
P-384, and P-521. Future documents may define
it to work with other curves and points in the future.”

But then there are exceptions, like ES256K [2] which bundles signature algorithm, hash function and elliptic curve. 

It isn't clear to me when to follow the guidance in [1] and when to make an exception. Just because there is one exception doesn't seem like reason enough to register bespoke bundlings. 

There are different principles in action here. Security is one, where a bundling is made to ensure suitable combinations.  Structure and economy of code points seems to be another, where it may become an issue managing the numbers if every potential bundling of parameters can get a unique assignment.

As I see it,  there should be a good reason to not assign according to the the intentions of [1], and if we deviate from those then we should preferably be able to explain according to what principle that assignment was made so that the new principle can be followed (until potentially other examples requires us to reconsider).

Any views on that?


2. Another point relates to how specifications use COSE code points. For example, [1] recommends the use of deterministic ECDSA. If that is not used, is that reason to register another ECDSA code point? Or, if the cofactor of the curve is not equal to 1, is that reason to register another ECDSA code point? In other words, to what extent is the IANA number registration bundled with certain properties for which there is no register? 

An alternative to make new assignments is that the referencing document re-uses existing code points and specifies how they are used, including why and how deviations are made from the math or the recommendations. 

Opinions?


3. ECDH-EE is not specified in [1], whereas ECDH-ES and ECDH-SS are carefully distinguished in the registries. I would be hesitant to register ECDH-EE algorithms without any supporting specification describing how it is expected to be used in general. What does the WG think?



Chairs: Unless sorted out before, could we have some time at the next interim?

Thanks
Göran

[1] https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-12