Yes, just for the JWK encoding (so, the Wei25519 curve, IIUC). Moving that IANA registration from the LWIG doc to here would keep us from blocking on that document, yes -- I forgot that it was only in "AD Evaluation" state and thought it was further along.
-Ben On Thu, Feb 06, 2020 at 06:32:04PM +0000, Pascal Thubert (pthubert) wrote: > Oh it’s the JWK encoding, right? > > Would we speed things up if we just imported the IANA section from the LWIG > draft? > > > Regards, > > Pascal > > > Le 6 févr. 2020 à 19:09, Pascal Thubert (pthubert) <[email protected]> a > > écrit : > > > > Hello Benjamin > > > > > >> "backward compatibility with" is easy to misparse, so maybe add a comma, or > >> go with "backward compatibility but adds the capability"? > > > >>> We're getting there. I snipped the places were we appear to have > >>> converged. > >>> > >>> Please let me know if the DISCUSS is now solved (we removed all ambiguity > >> on the crypto-ID and forced that a key is employed uniquely for the > >> purpose of > >> this draft and for one crypto-ID). > >> > >> I think the technical aspects are all resolved and there just remains the > >> tiniest > >> of process nits. Specifically, in order to use some of the algorithms we > >> define > >> in the protocol we define, we rely on the IANA codepoints currently > >> requested > >> to be registered by [CURVE-REPRESENTATIONS]. > >> So we have a normative dependency on those registrations being made, but > >> right now [CURVE-REPRESENTATIONS] is listed as only an informative > >> reference, so there's not anything that will enforce the sequencing of > >> publication. It's probably easiest to promote that reference to being > >> normative > >> and make a note (either near Table 2 or in the IANA > >> considerations) that we rely on the codepoints being registered by [CURVE- > >> REPRESENTATIONS]. > >> > >> Sorry to be so picky! > >> > > > > > > I'm happy to do the changes though it will delay a spec that 802.11 is > > waiting for. > > But I fail to understand why we depend on a COSE or a JOSE registry to > > compute our signature. > > > > What do I miss? > > > > > >>> But I guess it does not hurt to clarify a little bit. Maybe by > >>> changing the first paragraph of section 3 as " > >>> Section 5.3 of [RFC8505] introduces the ROVR that is used to detect > >>> and reject duplicate registrations in the DAD process. The ROVR is a > >>> generic object that is designed for backward compatibility with the > >> > >> "backward compatibility with" is easy to misparse, so maybe add a comma, or > >> go with "backward compatibility but adds the capability"? > > > > I favor the comma over the "but" since it is not antagonistic (maybe my > > French?). > > What about > > > > " > > Section 5.3 of [RFC8505] introduces the ROVR that is used to detect > > and reject duplicate registrations in the DAD process. The ROVR is a > > generic object that is designed for both backward compatibility and > > the capability to introduce new computation methods in the future. > > " > > > > ? > > > > : ) > > > > Pascal > >> > >>> capability to introduce new computation methods in the future. Using > >>> a Crypto-ID per this specification is the RECOMMENDED method. > >>> Section 7.3 discusses collisions when heterogeneous methods to > >>> compute the ROVR field coexist inside a same network. > >>> " > >>> Is that readable? > >>> > >>> I'll publish this with the changes suggested by Roman > >>> > >>> Thanks a million! > >>> > >>> Pascal > >> > >> _______________________________________________ > >> 6lo mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
