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
