Re: [COSE] IANA COSE assignments

[Russ Housley <[e-mail]>]

Göran:

> 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?

I like the principle that a new algorithm does not need to be defined for each of the curves.  That leads to a huge number of code points.  So, I think you are right that exceptions should come with a rationale,

> 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?

My reading of draft-ietf-cose-rfc8152bis-algs-12 is that implementations SHOULD use a deterministic version of ECDSA.  This means that other ECDSA implementations are still consistent with the use of these code points.  I think that Section 2.1.1 further supports this interpretation.

> 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?

If someone has a use case for ECDH-EE, then the should write a document to get the code point(s).

Russ