Inline: On Wed, Apr 12, 2023 at 3:06 PM Laurence Lundblade <[email protected]> wrote:
> > 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. > Indeed: https://datatracker.ietf.org/doc/html/rfc9052#appendix-A > Applications may need to provide some type of negotiation or discovery method *if multiple algorithms or message structures are permitted*. But is a "key" an application? ... when you generate a key, you control what is permitted... Is there really a burning desire to use the same key with multiple kdf and aeads? Which application use cases really need this feature? > Applications need to define the set of information that is to be considered to be part of a context when omitting algorithm identifiers. At a minimum, this would be the key identifier (if needed), the key, the algorithm, and the COSE structure it is used with. *Applications should restrict the use of a single key to a single algorithm.* As noted for some of the algorithms in [RFC9053], the use of the same key in different, related algorithms can lead to leakage of information about the key, leakage about the data, or the ability to perform forgeries. Is it still considered a single algorithm if it supports a family of parameters like "hkc", or is each unique combination actually a "single algorithm" ? I can imagine needing to check both alg and hkc, in order to build safe APIs for "alg" aware COSE Key. I can imagine different interpretations of this, impacting security considerations. ... > The second case is having multiple implicit algorithm identifiers specified for a multiple-layer COSE object. An example of how this would work is the encryption context that an application specifies, which contains a content encryption algorithm, a key wrap algorithm, a key identifier, and a shared secret. The *sender omits sending the algorithm identifier for both the content layer and the recipient layer, leaving only the key identifier*. The *receiver then uses the key identifier to get the implicit algorithm identifiers*. This implies "sender info" could be discoverable from "kid"? But this would only work if the recipient key had only 1 supported kem, kdf and aead? Does this signal any design decisions around "hkc" ? Imagine sending a single integer for "kid" and storing only a single integer in the COSE Key for the 3 integers (recipient info) needed by HPKE. 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. > > Can you elaborate on this? > Also, I see the purpose of a COSE_Key as representing and holding a > COSE_Key, not as a negotiation mechanism. > I agree, and this also follows from key management best practices, if you generate a key for a specific and single purpose, and you embed that purpose in the "alg" / "key_ops", there is nothing to negotiate. > 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.* - https://datatracker.ietf.org/doc/html/rfc9052#section-7.1 > 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. > > This is very well said. I think it was briefly mentioned at IETF 116, can we perhaps make "sender info" useful for COSE Key / JWK... or can we replace "sender info" with some version of "hkc". I don't think we need 2 different solutions here, even if the problems are different. > LL > > > > > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
