Subject: Re: [COSE] Call for COSE Agenda Items for IETF 113 in Vienna

From: Mike Prorock <[email-masked]>
Date: Tue, 8 Mar 2022 09:07:30 -0500

Mike Jones, et al.,
I would like to request 10 minutes of agenda time to discuss a new
cose-related draft that we are working on to provide support for post
quantum signature schemes with JOSE and COSE.

The draft is here:
https://datatracker.ietf.org/doc/draft-prorock-cose-post-quantum-signatures/

Title would be: JSON Encoding for Post Quantum Signatures:
draft-prorock-cose-post-quantum-signatures-00 - Presenter would be Mike
Prorock (remotely), 10 minutes of time

We have had some great engagement and support on this work item from the
community, and the work relates well to the pq key information draft here:
https://datatracker.ietf.org/doc/draft-uni-qsckeys/

Thanks so much for the consideration.

Mike Prorock
CTO, Founder
https://mesur.io/

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 8 Mar 2022 20:16:01 +0200

> https://datatracker.ietf.org/doc/draft-prorock-cose-post-quantum-signatures/

Some quick feedback:

Looking at the draft, why it is not using OKP key type? 

AFAIK, All of Dilithium, Falcon and SPHINCS+ already use byte strings
for keys with good encoding. Any sort of re-encoding would massively
increase complexity for likely negative gain.

And there are only a few parameter sets (IIRC, 3 for Dilithium, 2 for
Falcon and 6 for SPHINCS+), so folding these to the (misnamed) crv
parameter should nto be difficult.

And with regards to using one or different values of alg (differentiated
by key), that is more complicated question. IIRC FIDO incorrectly
assumes that alg values do not get reused, which causes problems with
EdDSA which does reuse alg values (Ed25519 and Ed448 both use alg=-8 in
COSE). On the other side, not reusing algorithm opens possibility for
key-algorithm mismatches, which caused an infamous vulernabities in
JOSE.

-Ilari

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 8 Mar 2022 19:42:37 +0100

On 2022-03-08 19:16, Ilari Liusvaara wrote:
<snip>
> key-algorithm mismatches, which caused an infamous vulernabities in

I believe most people (in retrospect) have rather come to the conclusion that polymorphic algorithms were a mistake.

Anders

> 
> 
> -Ilari
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Mike Prorock <[email-masked]>
Date: Tue, 8 Mar 2022 14:36:57 -0500

>
> I believe most people (in retrospect) have rather come to the conclusion
> that polymorphic algorithms were a mistake.
>

+1 - that seems to be something that folks are finding out

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
and will discuss on our next call.

This is exactly why we wanted the broader input from the COSE WG

---

From: Russ Housley <[email-masked]>
Date: Wed, 9 Mar 2022 17:55:56 -0500

> On Mar 8, 2022, at 2:36 PM, Mike Prorock <[email-masked]> 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://www.rfc-editor.org/rfc/rfc8778.txt

Is there any reason to do things differently for other hash-based signatures?

Russ

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 10 Mar 2022 08:30:13 +0200

On Wed, Mar 09, 2022 at 05:55:56PM -0500, Russ Housley 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: 

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

---

From: Orie Steele <[email-masked]>
Date: Thu, 10 Mar 2022 07:41:13 -0600

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-masked]>
wrote:

> > > https://github.com/mesur-io/post-quantum-signatures/issues/48 <
> https://github.com/mesur-io/post-quantum-signatures/issues/48>

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

<https://www.transmute.industries>

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Mar 2022 11:33:08 -0500

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 <[email-masked]> wrote:
> 
> 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.
> 
> On Thu, Mar 10, 2022 at 12:30 AM Ilari Liusvaara <[email-masked] <mailto:[email-masked]>> wrote:
> > > On Mar 8, 2022, at 2:36 PM, Mike Prorock <[email-masked] <mailto:[email-masked]>> wrote:
> > > 
> > > 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>> 
> > https://www.rfc-editor.org/rfc/rfc8778.txt <https://www.rfc-editor.org/rfc/rfc8778.txt>
> > 
> ORIE STEELE