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

[Mike Prorock <[e-mail]>]

note, with sphincs+ we may wind up with a simplified set of alg definitions
based on known and tested configs, eg something like the following (based
on the reference implementation here: https://github.com/sphincs/sphincsplus
):

SPHINCS+-SHAKE256-128s
SPHINCS+-SHAKE256-128f
SPHINCS+-SHAKE256-192s
SPHINCS+-SHAKE256-192f
SPHINCS+-SHAKE256-256s
SPHINCS+-SHAKE256-256f

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



On Tue, Mar 15, 2022 at 11:16 AM Mike Prorock <[e-mail]> wrote:

> 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
>>
>