Russ, I can't tell from your brief comment if you're supportive of 
non-polymorphic or polymorphic algorithm identifiers.  Can you expand on your 
remarks?

For the record, I also believe the polymorphic algorithm identifiers were a 
mistake.  OAuth, OpenID Connect, FIDO2, W3C WebAuthn, and I believe other 
systems, all count on being able to use a single algorithm identifier to fully 
specify the cryptographic computation.  Polymorphic algorithm identifiers break 
that invariant.  We should introduce no more of them.

That's why, for instance, https://www.rfc-editor.org/rfc/rfc8812 intentionally 
introduced the new algorithm identifier "ES256K" for "ECDSA using secp256k1 
curve and SHA-256"; it requires the use of "ES256K" for signing with the 
secp256k1 curve so that a polymorphic algorithm identifier is never used with 
it.

                           -- Mike (writing as an individual)

From: COSE <[email protected]> On Behalf Of Russ Housley
Sent: Wednesday, March 9, 2022 2:56 PM
To: Mike Prorock <[email protected]>
Cc: Ilari Liusvaara <[email protected]>; [email protected]; Orie 
<[email protected]>; Anders Rundgren <[email protected]>
Subject: Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call 
for COSE Agenda Items for IETF 113 in Vienna]




On Mar 8, 2022, at 2:36 PM, Mike Prorock 
<[email protected]<mailto:[email protected]>> wrote:

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

https://www.rfc-editor.org/rfc/rfc8778.txt

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

Russ
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to