On Sun, May 07, 2023 at 11:10:25AM -0700, Laurence Lundblade wrote: > Below is the near-complete text of what I think should be added to > the COSE-HPKE draft. The text in blue is copied exactly from RFC > 9053 section 6.3.1/6.4.1. The text in black is new. > > The mapping of KEM ID to curve below is trivial and not a big > problem. We’re already doing similar in COSE and HPKE, e.g. KEM ID > to HKDF.
I do not think it is trivial. > I believe real motivation for a new “kty" is what needs to be done > when there’s a new KEM beyond the current ones. This table can’t be > extended, because the new KEM won’t be EC. I don't think that is good assumption. There is a I-D that would register new KEM values that do work with existing EC2 keys. Which would lead into situation where a key works with two different KEMs. > If there’s a new “kty” for HPKE, there’s almost nothing to be done. > It just fits in nicely. If there’s not a new “kty”, then it seems a > new document has to be written. It’s not a difficult document and > we’ve written lots of little docs like this before, but it does seem > like a new one. I hope we’re not expecting lots of new KEMs. We > generally want to use just a few, 1 or 2, thoroughly vetted > algorithms. I really do not want to see documents like that. Problems include: - Processing overhead (even for expert review). - Somebody doing something "smart". - Causes extra work for implementations. - Are for things that don't make any sense outside HPKE. E.g., a X25519 and Kyber768 hybrid key. > When using a COSE key for this algorithm, the following checks are made: > The "kty" field MUST be present, and it MUST be "EC2" or "OKP". This is problematic if there is ever any new kty that can be used. Weither HPKE-KEM kty, or some other kty that happens to be convertable. > if the “alg” field is present and set to HPKE-v1-Base and the “hkc” > field is present, the kem, kdf and aead used must be listed in the > “hkc” field (see definition of “hkc” below”). I think this should be SHOULD and be independent of alg. I think "hkc" is advertisment, not restriction. > The “crv” field must be as in the following table. > KEM Identifier. COSE_Key Elliptic Curve > 0x0010 DHKEM(P-256, HKDF-SHA256) P-256 1 > 0x0011 DHKEM(P-384, HKDF-SHA384) P-384 2 > 0x0012 DHKEM(P-521, HKDF-SHA512) P-521 3 > 0x0020 DHKEM(X25519, HKDF-SHA256) X25519 4 > 0x0021 DHKEM(X448, HKDF-SHA512) X448 6 > > (Note that the text in black is only needed / different from 9053 > because we’re using “hkc” and not using cipher suites; if we were > using cipher suites the text would be exactly the same 6.3.1/6.4.1 > and implementations would be simpler). Implementations would not be simpler, as they would need to deal with the nasty mess of ciphersuites, as opposed to just dumping some values to underlying library. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
