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 <[email protected]>
wrote:
>
>
> 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
>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/cose
