> On Mar 14, 2022, at 2:19 PM, Orie Steele <[email protected]> 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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
