> On May 31, 2023, at 9:15 AM, Christopher Wood <[email protected]> wrote: > > The convention established by RFC8152 and updated in RFC9052 says the > following about the "alg" header parameter: > > alg: 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. 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. > > My interpretation of this is that "alg" fully specifies the algorithm that is > to be used for the object. For HPKE, the algorithm consists of the mode and > ciphersuite parameters (KEM, KDF, and AEAD). On that basis, Orie's suggestion > to use a single identifier or label that maps to an HPKE mode and ciphersuite > seems best. It also matches the very high level abstraction that alg seems to > target, being a very generic identifier for a "security thing." > > Beyond matters of consistency and abstraction alignment, I'll note that > splitting up algorithm "negotiation" across parameters runs counter to the > trend I've seen in higher-level security protocols lately, which is roughly > "versions define ciphersuite/algorithm parameters." This lets implementations > check precisely one thing, a version, label, or, in this case, the "alg" > parameter, and determine how to process the rest. It does not introduce > additional processing complexity. (I understand that the alternative proposal > with the "hkc" parameters may not seem overly difficult, but it does > effectively break from the mold of '"alg" fully defines the algorithm'.) > > As a final note, the contents of the registry do matter. I consider HPKE to > be a fairly low-level primitive, whereas I (perhaps naively) view COSE as a > higher-level application protocol. We have the expertise to be opinionated > about what goes into that registry for applications to use, and we should > exercise that opinion to provide folks with a very limited set of options, > ideally target precisely one. The > "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" label seems like a > perfectly fine candidate for that. > > I hope this helps. > > Best, > Chris
+1 to all of this LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
