Inline (with snips): <snip>
> > And that may work in some contexts but not others. > In some context you have a "generic" ML-DSA key and no restrictions on > which algorithm to use (ML-DSA vs HashML-DSA), now how do you generate > a JWK out of it ? > You would generate the key for ML-DSA, compute its fingerprint and store it as JWK indexed by fingerprint. You would then replace the algorithm in the key, compute a new fingerprint, and store the JWK indexed by fingerprint. In the case that you don't use fingerprints to lookup keys, you could name the keys: http://key.example.keys/42-ml-dsa http://key.example.keys/42-hash-ml-dsa Or whatever you like, and store them indexed by the name you have chosen for them. In the case that you were hoping to generate the same private key handle not exportable in web crypto... That would not work, and you would be forced to make an exportable private key, if you wanted to use the same key for multiple algorithms. Of course internally, web crypto could decide that it would support any signing algorithm that might work with that private key regardless of which algorithm the key was generated for... But that seems not in line with the current APIs for P-256 with ECDSA / ECDH. > If HashML-DSA is specified for JOSE / COSE in the future it would be fine > > to create a HashML-DSA key: > > > > { > > "kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o", > > "kty": "AKP", > > "alg": "HASH-ML-DSA-44", > > "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ", > > "priv": "129kadu...DZgbTP07e7gEWzw4MFRr54" > > } > > This is not helpful on systems that use the same key for both > algorithms, which is a perfectly valid thing to do. > It's not helpful for a (valid) poor security practice, but as I noted above, it's still possible to use AKP with the same key material and different algorithms. AKP does not forbid you from using the same key material with different algorithms. > > > What is the point? > > > A kty of ML-DSA-XX would work just the same and make integration in > > > existing software much easier. > > > > > > > Thanks for this feedback. > > > > Is your proposal to register a new kty for each ML-DSA parameter set? > > > > For example: > > > > { > > "kty": "ML-DSA-44", > > "alg": "ML-DSA-44", > > ... > > } > > ... > > { > > "kty": "ML-DSA-65", > > "alg": "ML-DSA-65", > > ... > > } > > { > > "kty": "ML-DSA-65", > > "alg": "HASH-ML-DSA-65", > > ... > > } > > { > > "kty": "ML-DSA-65", > > "alg": "EXTERNAL-MU-ML-DSA-65", > > ... > > } > > ... > > Only if "alg" is optional, ie you *can* restrict a key to a specific > algorithms but you should not be required to. > Just so I understand, your proposal is that kty should be used to express ML-DSA-44, ML-DSA-65 ... ML-KEM-768 ... X-WING and that alg should remain optional. We should then register these key types and any desired algorithms that are supported for each key type. alg would still be used to restrict algorithms within a given key type, but the fingerprint for a key would not commit to the algorithm. So an ML-DSA-65 and HASH-ML-DSA-65 public key would have the same fingerprint. This is similar to proposals that Ilari and others discussed at the beginning of the work. > > > > > Moreover the use of "alg" sounds misleading as the same ML-DSA-XX keys > > > can be used already with at least 2 algorithms: ML-DSA and HashML-DSA, > > > and potentially soon with a "new one" based on external-mu > > > precomputation ... > > > > > > > Its less misleading in the context of the JWK and COSE RFCs which state: > > > > ``` > > The "alg" (algorithm) parameter identifies the algorithm intended for use > > with the key. > > ``` > > https://datatracker.ietf.org/doc/html/rfc7517#section-4.4 > > > > ``` > > The JWS Signature value is not valid if the "alg" value does not > represent > > a supported algorithm or if there is not a key for use with that > algorithm > > associated with the party that digitally signed or MACed the content. > > ``` > > https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.1 > > > > Keep in mind that in COSE, alg is optional in both headers and keys, > > whereas in JOSE alg is mandatory in headers, and optional in keys. > > > > ``` > > This parameter is used to restrict the algorithm that is used with the > key. > > If this parameter is present in the key structure, the application MUST > > verify that this algorithm matches the algorithm for which the key is > being > > used. > > If the algorithms do not match, then this key object MUST NOT be used to > > perform the cryptographic operation. > > All of the above is know and also intentionally optional. > I don't follow this comment, when an algorithm is present, MUST is not optional? Note that an alg being absent in a key matches any in a message, for both JOSE and COSE, if you accept the algorithm in the message, you can run it to see what happens. With AKP: alg being present in a key matches mandatory alg in JOSE message. alg being present in a key matches optional / absent alg in a COSE message. However, in all cases, it is the holder of the key who decides if they are willing to use an algorithm. If they really wanted to, they could decide to overwrite the algorithm specified for the key with the one specified in the message, and see if it verifies / decrypts. That's basically what is happening when combining supported algorithms external to the key, with a key that has no specified algorithms... it's just the verifier is overwriting an undefined property. > > > *Note that the same key can be in a different key structure with a > > different or no algorithm specified; however, this is considered to be a > > poor security practice.* > > In some contexts it may be, but you can't make a general rule out of > it, yet by forcing a single valued "alg" parameter you are making the > standard un-neccessarily overly restrictive. The outcome of overly > restrictive standards is that implementations then tend to relax and > become incompatible with one another at the edges. This is a fair comment. We want to make sure that JOSE / COSE support for ML-DSA / ML-KEM / X-Wing works well with CMS, WebCrypto, PKIX, SMIME, etc... At the same time, we want to avoid specifying things for JOSE / COSE in a way that makes it easy to make new unsafe decisions, just because we have been comfortable with those decisions historically. For new things, we can be more aggressive about security improvements, under which contexts for JOSE and COSE do we need agility for PQ Signatures and KEMs? Is this really just ML-DSA? or are there others that we specifically want to enable the same key to be used with multiple algorithms? (without the workarounds I noted above). Any context or use cases you have in mind for ML-DSA (or other keys) with multiple algorithms needing to be supported for the same key would be helpful. > > > ``` > > https://datatracker.ietf.org/doc/html/rfc9052#section-7.1-3.4 > > > > Given that 9052 comes after 7517, it would seem that using the same key > > type (with alg remaining optional) for "ML-DSA-65", "HASH-ML-DSA-65" and > > "EXTERNAL-MU-ML-DSA-65" would be encouraging a poor security practice > (same > > key *different algorithms*). > > A recommendation is a fine thing, but you made a construction that > dictates thing, that is quite different. > The construction does put a lot of pressure on aligning both JOSE and COSE, and we did incorporate feedback from several IETFs on "algorithms in keys". It dictates the structure of the key, but it does not (and cannot as you note below) stop people from reusing key material, that's ultimately an implementation decision. > > > > > In the context of JOSE and COSE, one could infer that "in a different key > > structure" could mean JWK, in which case, I could have a COSE Sign1 that > is > > verifying with a JWK. > > If the JWK does not have a mandatory algorithm present for ML-DSA, then > > COSE signatures would have the same security issue as JWS example above, > > but cross protocol: > > A COSE Sign1 ("ML-DSA-65", "HASH-ML-DSA-65" and "EXTERNAL-MU-ML-DSA-65") > > might verify with a JWK that had *no algorithm.* > > > > Tackling the design position head on, I consider it a feature of AKP that > > it cannot easily be used to create keys that work for both "ML-DSA-65" > and > > "HASH-ML-DSA-65". > > Putting on my attacker hat, I would copy the AKP key, update its > algorithm, > > regenerate its fingerprint if it had one, and then exploit the weaker > > algorithm. > > > > This is the reasoning behind the current design at least from my > > perspective, although the draft has passed WGLC and is currently in AD > > Evaluation. > > The reasoning defeats itself as you described. > Nothing prevents a user to use the same key with two algorithms, you > just make it awkward and hidden. > Awkward yes...Hidden? I am less sure. AKP fingerprints are unique to the algorithm specified for the key. You might detect key purpose change, by noting that a fingerprint no longer matches, in some systems, this might lead to failing closed. Then again, you might change the algorithm on a key that has no kid, or which uses a human readable string as its identifier. If you could change the algorithm in such a key, you could also replace the public key. > > > > > > > All keys must include a "pub" public key parameter. Private keys in > > > > addition also include "priv", or "priv_exp", or both where applicable > > > (see > > > > archive) > > > > < > https://mailarchive.ietf.org/arch/msg/cose/-vIaTIvZoSh21_2vqPakAvzzwSw/ > > > > . > > > > > > > > > > If priv is the seed, why not call it just 'seed' ? > I agree, so does Mike... and I have proposed this change here: https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/16 I will leave the PR open until it becomes obvious which path to take, and even then, it's still not official until a new draft version is uploaded. > > > > > > > :) Thanks for this feedback, I will admit that I considered trying to > move > > AKP to SPHINCS-PLUS just to avoid this issue while introducing AKP. > > ... I still prefer not to do that, despite the frustration regarding > seeds > > and external mu. > > > > "priv_exp" is not in > > https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-05 > > > > It's proposed in the branch: > > https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/16 (this > won't be > > merged if there are objections, can I count this as an objection to > > merging?) > > > > Absolutely not, in some cases the expanded key is all that it is > available and need to be possible to be carried. > I added this sentence here: https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/16#discussion_r2017428321 Given your comment at the bottom of the thread, I have to explain the SHOULD. My reasoning is that some systems may lack the resources to expand or validate the ML-DSA private key, even if seed were present. If you have a specific use case that has a different reason, I am happy to consider more text to justify why this is not a MUST. <snip> > This could be seen as still in keeping with what I believe LAMPs has plans > > to do, although the draft is not yet updated: > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-07#appendix-C.1 > > > > I'd like to hear from others if they prefer "seed" + "priv" over "priv" > and > > "priv_exp"... I proposed "priv" as "seed" only to keep with the current > -07 > > framing above. > > > > TBH I do not care *that* much for names, : ) > but it brings confusion when a > name is used for very different things depending on context of very > similar objects. > I very much agree with this, IMO, we got on this track from sticking close to LAMPs, sounds like they may have reversed course just in time for us to catch up. We will make sure we are aligned either way. <snip> > I would note that DJB used the terms "seed" + "expanded", which if we were > > to do that in JWK, we would end with 3 private information classes for > JWKs > > that use kty: AKP ( seed(ml-dsa), expanded(ml-dsa), priv(slh-dsa, x-wing, > > ...) ). > > I do favor seed+expanded, or may be priv_seed + priv_expanded to be > extra clear that does alues need to be kept secret. > I like that priv_seed expresses that this is private... it's a better name than "d". I don't like the idea of "priv_expanded" though... and I am not certain but I believe that in ML-DSA / ML-KEM seeds expands to both priv and pub, so ... priv_seed might not technically always be correct. I'm do not know exactly where this common pattern does or does not hold for new pq algorithms, but ideally we would have: secret_seed -> private_key -> public_key Naming remains difficult, but since we are adding a new name here, I'm happy to be more specific than LAMPs if there is consensus to do that. I would be cautious that this does not scope creep into: - generic methods for expanding a secret key to an arbitrary length seed so that ML-KEM can work with an ML-DSA seed. - constructions for managing hybrid seeds - other stuff I don't want to imagine right now My general feeling is that the less we can say about ML-DSA the better, that includes not specifying HashML-DSA or ExternalMu or anything beyond what we need for representing an exported ML-DSA-65 JWK / COSE Key from an HSM / WebCrypto. > > > > > Note that I asked the pqc-forum, for ML-DSA when "priv_expanded" is > present > > SHOULD / MUST "seed/priv" be present? > > SHOULD, you can't have MUST. > https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/16#discussion_r2017428321 <snip> > -- > Simo Sorce > Distinguished Engineer > RHEL Crypto Team > Red Hat, Inc > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
