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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
