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

[David Waite <[e-mail]>]

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