The less new registrations we need to make, the better. If we can drop the draft kty "PQK" for "OKP" we should.
We have a similar issue with "alg" at least for dilithium, where we need "alg" to show up in the JWK as well as the signature, because we don't have any other way to detect the parameter set in the key. For example, in a JWK with crv "P-256" we know to use "ES256" but if we see a dilithium OKP, how do we know the "pset" to use? If we were to register a new "crv" like property, we would want it to work for a family of algs, i don't think we should register "pset" but we had originally planned to. Thanks for the feedback, looking forward to working with you all. OS On Thu, Mar 10, 2022 at 12:30 AM Ilari Liusvaara <[email protected]> wrote: > On Wed, Mar 09, 2022 at 05:55:56PM -0500, Russ Housley wrote: > > > > > > > On Mar 8, 2022, at 2:36 PM, Mike Prorock <[email protected]> wrote: > > > > > > Where the actual "kty" shakes out as we continue to improve the > > > draft is yet to be seen. "PQK" made sense at the time as this > > > is dealing with post quantum keys and signatures - just as > > > easily we could be looking at two key types, probably by family - > > > e.g. one for lattice based, and one for hash based signatures, > > > or could just as easily be "OKP" - we opened an issue to track > > > that here: > > > https://github.com/mesur-io/post-quantum-signatures/issues/48 < > https://github.com/mesur-io/post-quantum-signatures/issues/48> > > > and will discuss on our next call. > > > > > > This is exactly why we wanted the broader input from the COSE WG > > > > https://www.rfc-editor.org/rfc/rfc8778.txt > > > > Is there any reason to do things differently for other hash-based > > signatures? > > IMO, Yes, there is a reason: HSS/LMS are stateful (note that there is > no defined private key format in that RFC), while SPHINCS+ is stateless > (with byte string public and private keys, and a closed set of small > number of variants, which makes it map cleanly into OKP). > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
