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.
Because this is qualified as “when using a COSE_Key”, other key serializations like DER-serialized keys are not excluded. The COSE_Key’s used here might not be transmitted in a protocol, might be in files, might be in a private database and so on. Because of that I don’t see this as a big global MUST that is necessary for interop, but rather something an individual application or end-end system can make a choice to use. It is also kind of unenforceable as any pan-Internet requirement. 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 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. 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. No matter whether there’s a new “kty” or not, the text below is required. We want to accommodate use of EC2 and OKP keys in COSE-HPKE, not exclude them. So the question is whether it is really worth creating a new “kty” in addition to the text below? LL 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". If the "key_ops" field is present, it MUST include "derive key" or "derive bits" for the private key. If the "key_ops" field is present, it MUST be empty for the public key. If the "alg" field is present, it MUST match be HPKE-v1-Base 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”). 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).
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
