Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

[Mike Prorock <[e-mail]>]

Orie,
I think other alternative would be:
kty: PQL        // post quantum - lattice based
alg: CRYDI3  // crystals dilithium, parameter set 3
x: public
d: private

and
kty: PQH       // post quantum - hash based
alg: SP-SHAKE256-[n]-[w]-[h]-[d]-[k]-[t]  // SPHINCS+, shake256, parameter
set as noted
x: public
d: private

Mike Prorock
CTO, Founder
https://mesur.io/



On Tue, Mar 15, 2022 at 10:32 AM Orie Steele <[e-mail]>
wrote:

> The goal in registering new JWK and JWS compatible terms for the family of
> post quantum crypto systems is to register only what is needed to identify
> the key and the signature.
>
> We are not trying to add any additional parameters, in the abstract, we
> want to convey "key type", "public key" and "private key", while following
> the conventions that came before us.
>
> So far, we think the OKP style Ed25519 keys are the model to follow, here
> is a reminder:
>
>       "kty": "OKP",
>       "crv": "Ed25519",
>       "x": "3ygWe2mas7ZvquJ2E_aNh3wJEcLPsHp_8r0UXoyhBwQ",
>       "d": "EKCZgwCYoasDC61z5aWR6LqvPbpxWPKFY1PexeW5WSw"
>
> https://www.rfc-editor.org/rfc/rfc8037.html#section-2 (reminder that crv
> is required... so sadly it seems we will need a new key type).
>
> this would mean something like this:
>
> kty: PQK
> pset: CRYD3 // handled like "crv" was for kty: OKP, with a new value for
> every new key type from lattice, hash or isogeny based systems
> alg: CRYD3 // optional
> x: pub
> d: priv
>
> another alternative would be:
>
> kty: CRYD3 // with a new value for every new key type from lattice, hash
> or isogeny based systems
> alg: CRYD3 // optional
> x: pub
> d: priv
>
> OS
>
>
> On Tue, Mar 15, 2022 at 1:48 AM David Waite <[e-mail]>
> wrote:
>
>>
>>
>> On Mar 14, 2022, at 2:19 PM, Orie Steele <[e-mail]>
>> wrote:
>>
>> <snip>
>>
>> So for a dilithium example:
>>
>> kty: PQK (required)
>> pset: CRYD3 (required)
>> x: ... (required)
>> alg: CRYD3 (optional)
>>
>>
>> Would you expect additional parameters (say “s1” and “s2”) for private
>> keys?
>>
>> Is X consistent within a parameter set, or is there variability (such as
>> the algorithm to generate the matrix from a seed value, or the option to
>> include a full matrix)
>>
>> Obviously JWK thumbprint will need to be aware of all required fields,
>> and will need to drop all optional fields in order to be useful.
>>
>>
>> And if those rules aren’t generic and simple, it is possible we have
>> rolled multiple key types into one “kty”. The “EC” key type allowed just
>> “X” coordinates for other curves, but my interpretation is that “OKP” was
>> still created because the public value for Edwards curves was defined with
>> a different packed binary format.
>>
>> I posit it is better to have experimental key types for experimental key
>> formats, vs the potential for a complex set of key forms in future
>> production deployments. That is not to say that I have an informed opinion
>> on stability of any proposal.
>>
>> If we don't define something like "pset" and we don't make "alg" required
>> for "kty:PQK"... the only optional will be to explode based on mismatched
>> keys / signatures... unless I am missing something... we have the same
>> problem with P-256 keys today... when "alg" is not present, you can't tell
>> if the key is for "signing" or "key agreement"... which means that any JWE
>> / JWS can target that key, and the key representation won't catch what the
>> key was intended for... unless "alg" and "use" are present... which nobody
>> can rely on, because they are marked optional.
>>
>>
>> Parameter set seems appropriate, as long as it is the term of art for the
>> category of key type, and (for a given parameter set name) is in a
>> non-extensible format.
>>
>> WRT the usage of “alg” - there can be multiple algorithms that leverage
>> the same underlying key object, which means a subtype is a different level
>> of restrictiveness/specificity than specifying an algorithm. A single
>> instantiated key of a subtype can be used with multiple algorithms (“RS”
>> and “PS” families), and a single algorithm can be used with multiple key
>> subtypes - such as “ECDH-ES” and “EdDSA”.
>>
>> This would make the subtype of a key and its algorithmic usage
>> restrictions orthogonal.
>>
>> Take a look at:
>> https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties
>>
>> Notice that they include "alg" and "use"... if both are optional, why
>> include them in such an example?
>>
>>
>> FWIW I think making "alg" required is the best thing to do for new key
>> types moving forward (it addresses future ambiguity / explicit over
>> implicit makes me feel safer).
>>
>>
>> The “alg” and “use” parameters are restrictions on key object usage,
>> rather than specifying the key object cryptographic properties themselves.
>> IMHO, one needs an underlying PKI or just blanket immutability which
>> restricts a party from changing such parameters over time for them to have
>> value.
>>
>> Historically these have not been “self asserted”, but rather asserted by
>> an authority in a PKI system who has made an integrity protected statement
>> about the key (e.g. a public certificate). In this case they may not be
>> self-imposed restrictions, but restrictions by the trust broker, such as
>> “they can’t act as a sub-CA” or “check here to see if the authority marked
>> this key as revoked”.
>>
>> Likewise, key usage restrictions are systems-specific. An example would
>> be key operations (also specified in the JWK RFC, distinct from “use”).
>> Verification relationships in decentralized identifier documents are
>> arguably another example of operational restrictions, albeit in a graph
>> rather than a simple broker hierarchy.
>>
>> -DW
>>
>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>