Good to finally get some needed discussion on this to progress the draft. 1. I agree with other commenters that ES256K should be considered to be an exception/historical accident.
2. My preferred solution would be if we do not have to register more code points. Ilari's proposal seems to achieve that. If any new co-factor code points are needed, they should be general and not for a specific curve. The original question from Göran only talks about ECDSA. My understanding is that the current discussion is only about co-factor ECDH, and that nothing special is needed for ECDSA. 3. COSE is a 0.5 round-trip protocol, so I don't think EE makes sense for COSE itself even on a high level. Agree with earlier comments that a use case would have to be motivated. EDHOC uses COSE with EE but only uses ths curve registry. (EDHOC does not use the COSE ECDH-ES points either). Cheers, John -----Original Message----- From: COSE <[email protected]> on behalf of Benjamin Kaduk <[email protected]> Date: Sunday, 31 January 2021 at 21:56 To: Göran Selander <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] IANA COSE assignments Hi Göran, I'm replying late to the thread, so I can refer to all the good discussion that's happened already :) On Thu, Jan 28, 2021 at 09:17:56AM +0000, Göran Selander wrote: > > 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. I agree with other commenters that ES256K should be considered to be an exception/historical accident. A reading of RFC 8812 suggests that perhaps the new signature codepoint was not as much about using the curve for signatures but rather about not using the curve for anything else. This note from 8812 also seems to come into play: Care should be taken that a secp256k1 key is not mistaken for a P-256 [RFC7518] key, given that their representations are the same except for the "crv" value. As described in Section 8.1.1 of [RFC8152], we currently do not have any way to deal with this attack except to restrict the set of curves that can be used. > 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? Another +1 from me on needing to be able to justify the exception. > > 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? For deterministic vs. nondeterministic ECDSA, I think it is clear that the codepoint allows both. For the cofactor, it is not quite so clear-cut: Ilari's proposal seems sound and ought to work, but it may end up requiring us to rely on implementors reading the details carefully in order to get correct operation. I could imagine defining a new codepoint for "ECDSA with non-unity curve cofactor" to call this out, though that is just a brainstorming note and I am not saying (at this time) that I would prefer to do that over Ilari's proposal. > 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? I have some vague recollection that ECDH-EE was challenging due to the lack of a stable key identifier to use. But I'm not even sure how I would go about turning that vague recollection into something concrete from the mailing list/meeting archives. Thanks for bringing all of this to the WG, Ben _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
