On Thu, Jan 04, 2024 at 01:37:34PM -0600, Orie Steele wrote: > Thanks for your comments Neil! > > On Thu, Jan 4, 2024 at 12:47 PM Neil Madden <[email protected]> wrote: > > I am sure there are other references, but one I often find myself referring > to is: > > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf > > > A major thrust from Part 1 of this Recommendation is that, in general, > > keys shall not be used for multiple cryptographic purposes
That document seems to define purpose as things like key derivation, encryption, signing, etc... not what algorithm it (and especially any derived keys) is used for. And not that it is good idea to use the keys in question with multiple signature algorithms: - For P-256 or secp256k1 keys, the only sensible algorithm is ES256. - For P-384 keys, the only sensible algorithm is ES384. - For P-521 keys, the only sensible algorithm is ES512. - For Ed25519 keys, the only sensible algorithm is Ed25519 - For Ed448 keys, the only sensible algorithm is Ed448. Mixing key and hash sizes in ECDSA is not a good idea. And using SHA-3 is even worse idea (that thing is just FUBAR). JOSE has "use". COSE has no equivalent. "key_ops" is FUBAR. > It would be more work to change the requirements for "alg" in key > representations, or to add crypto periods to key representations. Alg in COSE/JOSE is not quite the same as use of the key. Especially annoying case is ECDH-ES in JOSE (and JOSE-HPKE would have the exact same issue). > > * Does the usage of “enc” count as not being fully specified? I can well > > imagine that there are some clients that support, say, RSA-OAEP, but only > > support 128-bit content encryption algorithms, or only support GCM. So the > > same issue with not specifying the curve also applies when not specifying > > the content encryption algorithm. > > > > Excellent question. > > See the recent discussion here: > > https://datatracker.ietf.org/meeting/118/materials/slides-118-lamps-attack-against-aead-in-cms-00 > > In an ideal world, the crypto is "key AND algorithm" committing, in our > current world, we may only be able to signal things in a way that easily > enables that kind of commitment, not enforce that it actually happens in > all the places it should. > > Addressing what "fully specified" means for HPKE, ECDH-* + AEAD... is > harder than addressing signatures... There are principles that are hard to > achieve without an ability to fully specify and commit to keys, this is an > area where more discussion is probably needed. The algorithm one would want to commit to is the first algorithm. Unfortunately, "alg" does not cut it because there are different alg that all have the same first algorithm. And in JOSE, those algorithms are not even interchangeable! E.g., one would need to specify in JOSE: ECDH-ES or ECDH-ES+<some_key_wrap>. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
