Actually I forgot about this:
https://www.rfc-editor.org/rfc/rfc8037#section-2
The parameter "crv" MUST be present and contain the subtype of the
key (from the "JSON Web Elliptic Curve" registry).
So I revise my Options to account for your new kty name:
Option 1: { kty: AKP, pset: SPHINCS+-128s }
Option 1: { kty: AKP, pset: CRYDI3 }
Option 2: { kty: CRYDI, pset: CRYDI3 }
Option 2: { kty: SPHINCS+, pset: 128s }
So far, I prefer these:
Option 1: { kty: AKP, pset: SPHINCS+-128s }
Option 1: { kty: AKP, pset: CRYDI3 }
Regards,
OS
On Fri, Jul 8, 2022 at 1:27 PM Orie Steele <[email protected]>
wrote:
> 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>
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
