Given RSA as a predecessor, wherein RS256 and PS256 are distinct padding modes
for RSASSA, I'd prefer "kty" be specific configuration of an algorithm; e.g.
Kyber-768-90s should be distinct from Kyber-768 or Kyber-512.
It may be tempting to generalize ("lattice" vs "hash-based") instead of specify
("SPHINCS+SHAKE256" vs "SPHINCS+SHA256"), but being specific is less likely to
encourage implementations to support in-band algorithm
negotiation<https://www.howmanydayssinceajwtalgnonevuln.com/>.
________________________________
From: COSE <[email protected]> on behalf of Orie Steele
<[email protected]>
Sent: Monday, July 11, 2022 6:59 AM
To: Ilari Liusvaara
Cc: cose
Subject: RE: [EXTERNAL][COSE] draft-prorock-cose-post-quantum-signatures [Was:
Re: IETF 114 Call for Agenda Items]
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
There is not a single elliptic curve system I am aware of that is acknowledged
as being post quantum.
We're really just looking for consensus on what to use for `kty` for new post
quantum schemes... it can't be OKP, EC, EC2.
It could be a unique class name for lattice, hash-based, isogeny... etc...
(each a generic family)
But then the actual type would have to be signalled elsewhere, for example:
dilithium, kyber, falcon, sphincs, ntru, etc... (each a specific family)
Based on the existing conventions there is no obvious choice.
https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
The "kty" (key type) parameter identifies the cryptographic algorithm
family used with the key, such as "RSA" or "EC". "kty" values should
either be registered in the IANA "JSON Web Key Types" registry
established by [JWA] or be a value that contains a Collision-
Resistant Name. The "kty" value is a case-sensitive string. This
member MUST be present in a JWK.
A list of defined "kty" values can be found in the IANA "JSON Web Key
Types" registry established by [JWA]; the initial contents of this
registry are the values defined in Section 6.1 of [JWA].
The key type definitions include specification of the members to be
used for those key types. Members used with specific "kty" values
can be found in the IANA "JSON Web Key Parameters" registry
established by Section 8.1.
Given, RSA and EC/EC2 are "families"...
Option 1: (a single post quantium "family")
{ kty: AKP, pset: SPHINCS+-128s }
{ kty: AKP, pset: CRYDI3 }
{ kty: AKP, pset: FALCON-xxx }
Option 2: (specific system for post quantum family)
{ kty: CRYDI, pset: CRYDI3 }
{ kty: FALCON, pset: FALCON-xxx }
{ kty: SPHINCS+, pset: 128s }
Option 3: (generic system for post quantum family)
{ kty: LATTICE, pset: CRYDI3 }
{ kty: LATTICE, pset: FALCON-xxx }
{ kty: HASH, pset: SPHINCS+-128s }
Of these options I still think Option 1 matches most closely the existing
systems...
See this list of "EC" types... that have drastically different security
properties:
- https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve
- https://safecurves.cr.yp.to/index.html
If it's ok to have "secp256k1" and "secp384r1" both use kty: EC....
Then it follows that its ok for dilithium and falcon to both use kty: LATTICE
If it's ok to have "Ed25519" us "OKP" and "secp256r1" use EC....
Then it follows that it's ok for dilithium and falcon to both use kty: CRYDI
and FALCON.
Can we agree to eliminate option 1?
OS
On Sat, Jul 9, 2022 at 3:50 AM Ilari Liusvaara
<[email protected]<mailto:[email protected]>> wrote:
On Fri, Jul 08, 2022 at 10:34:11PM +0200, Anders Rundgren wrote:
> I can only iterate my claim that overloading an existing definition is an
> unusual solution.
>
> However, since even the author of
> https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
> have abandoned [*] the (IMO) most logical interpretation, I guess
> this is it:
>
> All new keys having a "crv" SHOULD have "kty" = "OKP".
Well, if the new key is some prime-field weierstass elliptic curve,
then it should be EC (EC2 in COSE). EC/EC2 was designed for those
things.
BLS is not prime-field, so it does not fit EC/EC2.
-Ilari
_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
--
ORIE STEELE
Chief Technical Officer
www.transmute.industries
[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
