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