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 <[email protected]> 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 <[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
