Would you mind replying with hypothetical JWK representations and a label
to refer to them, so we can work towards consensus on draft revisions?
I am hearing a preference for more specific, which aligns with my option 2,
but you go even further to include parameters in the `kty`...
Option 4:
{ kty: CRYDI-2, ...}
{ kty: CRYDI-3, ....}
{ kty: CRYDI-5, ....}
{ kty: Kyber-512, }
{ kty: Kyber-512-09s, }
{ kty: Kyber-768 }
{ kty: Kyber-768-90s, }
{ kty: FALCON-xx, ....}
{ kty: SPHINCS+-128s, ....}
To me, this is starting to contradict the original RFC text... because the
`kty` no longer refers to a "family" it refers to an "individual".
Nobody switches on `kty` alone today, so this would likely not help
implementations...
Folks do switch on `kty` + `crv` or `alg` today...
But I prefer to address `kty` before considering `alg`... since `alg` is
currently optional... see this poll:
https://twitter.com/OR13b/status/1545483227439046656
Regards,
OS
On Mon, Jul 11, 2022 at 10:04 AM Blumenthal, Uri - 0553 - MITLL <
[email protected]> wrote:
> 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.
>
>
>
> I support this position. Let’s be specific.
>
>
> ------------------------------
>
> *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]
>
>
>
>
>
> 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]>
> 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
>
>
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
