> On Apr 12, 2023, at 10:31 AM, Orie Steele <[email protected]> wrote: > > I don't see how you can use HPKE without knowing what a recipient supports, > and I don't think it is smart to do that work in a separate document from > where it is used.
That is true of all of COSE, not just HPKE. It is discussed in the profiles section in RFC 9052. This mentions minimum to implement, advertising in (x.509) certificates. No negotiation mechanism is specified in COSE because it is highly variable by application domain (IMO). Some use cases may succeed with specification of one single algorithm (perhaps relying excellent SW update that happens to be available in the particular ecosystem). Others, like S/MIME (certificate-based encrypted email) may rely on directory services with X.509 certificates to advertise the algorithm. Another might have a round-trip negotiation protocol. What’s new here is that COSE-HPKE requires the “hkc” structure in addition to the integer cipher suite. The rest of COSE requires only the integer. That means the “hkc” structure needs to be incorporated into minimum-to-implement definitions, as protocol items in advertisement in a certificate and so on for each negotiation scheme used with COSE. Also, I see the purpose of a COSE_Key as representing and holding a COSE_Key, not as a negotiation mechanism. Holding a key and end-end algorithm negotiation may end up both using the “hkc” structure, but that is because the data structure is a common solution to two different problems, not because they are the same problem. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
