On Mon, Feb 12, 2024 at 05:17:28PM -0600, Orie Steele wrote: > I tried to capture some of the comments from Ilari on KEMs here: > https://github.com/selfissued/draft-ietf-jose-fully-specified-algorithms/pull/4 > > Before the registry experts get flooded with Kems, Hybrid Kems, and Hybrid > Composites, we should at least get some guidance in place on what makes a > KEM "fully specified".
I think that: "Fully specified" KEM <=> KEM with all parameters fixed. > I think the KDF part is the main piece, in other words a KEM algorithm is > fully specified, if it implies the use of a single KDF. ML-KEM-1024 fixes all parameters, but does not imply any KDF. The only hit in FIPS 203 for "key derivation" makes it very clear that key derivation is something external to the KEM. Now, some KDFs might be easier to implement as some code gets shared with ML-KEM. > But we have a similar situation with ECDH-ES, and it seems the convention > at least from HPKE is to name the KEM after the curve and KDF, for example > "DHKEM(P-384, HKDF-SHA384)"... > https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids With ECDH-ES, the algorithms are shared between different key subtypes. I.e., there is no seprate: - ECDH-ES-P256 - ECDH-ES-P256+A128KW - ECDH-ES-P384 - ECDH-ES-P384+A192KW - ECDH-ES-P521 - ECDH-ES-P521-A256KW - ECDH-ES-X25519 - ECDH-ES-X25519+A128KW - ECDH-ES-X448 - ECDH-ES-X448+A256KW But instead there are just: - ECDH-ES - ECDH-ES+A128KW - ECDH-ES+A192KW - ECDH-ES+A256KW HPKE defines two-parameter (elliptic curve, KDF) KEM called "DHKEM", and most of KEMs used in HPKE are instances of that (currnently only X25519Kyber768Draft00 is an exception). "DHKEM(P-384, HKDF-SHA384)" => DHKEM with P-384 curve and HKDF-SHA384 KDF. Taking https://github.com/lamps-wg/draft-composite-kem/pull/11 again, it defines 11 KEMs. If all used different "alg" values, that would be 22 (including KW variants). That is more algorithms than currently exist in JWE (18). And it would be duplication of information, which is always risky. What if the two places disagree? Sometimes the answer is "critical vulnerability". > I assume RSA Kem would look sorta similar if it were added to the HPKE > registry... It is surprising we don't see RSA KEM including some indication > of strength in the algorithm identifier, in the examples we see "RSA-KEM > with a 3072-bit key and KDF3 with SHA-256;" ... and I see ASN.1 with > "CMS-RSA-KEM-2023". > > What would a "fully specified RSA Kem algorithm ID" look like? > > I'd imagine something like "RSA-KEM-3072-KDF3-SHA-256" ? RSA-KEM is parameterized by KDF and output length. However, some places seem to parametrize using hash instead, so something like "RSA-KEM(SHA256)". -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
