Response to your option 1:
https://datatracker.ietf.org/doc/html/rfc7518#section-6.2.1.1
The "crv" (curve) parameter identifies the cryptographic curve used
with the key.
> crv: SPHINCS+-128s
> crv: CRYDI3
This does not make sense, neither of these systems are based on elliptic
curves.
Response to your option 2:
> { kty: AKP, alg: CRYDI3, d: ..., x:... }
> { kty: AKP, alg: SPHINCS+-128s, d: ..., x:... }
This makes sense to me, but unfortunately it's incompatible with the
current normative requirements since `alg` is OPTIONAL.
https://datatracker.ietf.org/doc/html/rfc7517#section-4.4
The "alg" (algorithm) parameter identifies the algorithm intended for
use with the key. The values used should either be registered in the
IANA "JSON Web Signature and Encryption Algorithms" registry
established by [JWA] or be a value that contains a Collision-
Resistant Name. The "alg" value is a case-sensitive ASCII string.
Use of this member is OPTIONAL.
Last time I floated the idea of making `alg` required (to align with the
recommendations from NIST) it got shot down here, so I am not going to try
that again.
So far... My Option 2 seems to be winning.
Regards,
OS
On Fri, Jul 8, 2022 at 1:05 PM Ilari Liusvaara <[email protected]>
wrote:
> On Fri, Jul 08, 2022 at 12:37:44PM -0500, Orie Steele wrote:
> > I wonder if we might propose a concrete serialization for SPHINCS+ given
> > this commentary...
> >
> > Please hold the bikeshed for "pset"... it's a placeholder for
> > parameterization.
> >
> > Option 1: { kty: OKP, pset: SPHINCS+-128s }
> > Option 2: { kty: SPHINCS+, pset: 128s }
> >
> > Consider also the similar options for Dilithium:
> >
> > Option 1: { kty: OKP, pset: CRYDI3 }
> > Option 2: { kty: CRYDI, pset: CRYDI3 }
> >
> > Which do you prefer: Option 1 or Option 2?
>
>
> Well, I think the most sensible options are (with "AKP" being a
> placeholder for a new keyshape, and AKP/d and AKP/x also being
> placeholders for its private/public keys, the alg is the JOSE alg
> parameter).
>
>
> Option1: { kty: OKP, crv: SPHINCS+-128s, d: ..., x:... }
> Option2: { kty: AKP, alg: SPHINCS+-128s, d: ..., x:... }
>
>
> (For Dilithium:
>
> Option1: { kty: OKP, crv: CRYDI3, d: ..., x:... }
> Option2: { kty: AKP, alg: CRYDI3, d: ..., x:... }
>
> )
>
> And this generalizes to COSE in the obvious way (AKP becomes some int,
> the alg becomes 3, the d and x become some ints, and their values are
> raw bstr's instead of base64url-encoded strings).
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
