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

[Russ Housley <[e-mail]>]

In certificates using ECDSA [RFC5480], we see the subject public key identified with id-ecPublicKey, and then you learn the curve in the parameters.  For PQC, there is a desire to identify the algorithm and the parameters from the top-level object identifier and omit the parameters altogether.  This is essentially what COSE has done for ECDSA with "ES256".

It would be good for COSE and certificates (which are being done in LAMPS) take the same approach.

Russ


> On Mar 10, 2022, at 8:41 AM, Orie Steele <[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> On Wed, Mar 09, 2022 at 05:55:56PM -0500, Russ Housley wrote:
> > 
> > 
> > > On Mar 8, 2022, at 2:36 PM, Mike Prorock <[e-mail] <mailto:[e-mail]>> 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> <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 <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
> 
> 
> 
> -- 
> ORIE STEELE
> Chief Technical Officer
> www.transmute.industries
>