Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

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 <ilariliusvaara@welho.com>
wrote:

> On Wed, Mar 09, 2022 at 05:55:56PM -0500, Russ Housley wrote:
> >
> >
> > > On Mar 8, 2022, at 2:36 PM, Mike Prorock <mprorock@mesur.io> 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
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>