> On Apr 12, 2023, at 4:06 PM, Orie Steele <[email protected]> wrote: > > Inline: > > On Wed, Apr 12, 2023 at 3:06 PM Laurence Lundblade <[email protected] > <mailto:[email protected]>> wrote: > >> On Apr 12, 2023, at 10:31 AM, Orie Steele <[email protected] >> <mailto:[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 > <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...
Don’t think so. A COSE_Key is a data structure for holding a key (and supports key use restriction). Some applications may use COSE_Key, some may not. When they use it they might transmit it or they might not. They might have a database of millions of COSE_Keys or they might have a few hard coded keys. We probably need something like a PEM file format for COSE_Key (and we can use PEM-stored keys with COSE and COSE_HPKE). An application is an end-end scheme with lots of things specific to it. Examples: - Encrypted email — a new version of S/MIME? Algorithm selection is peer-peer by (X.509?) certificate. - SUIT Firmware encryption — Device manufacturers keep a device database that has the algorithm for each device - Some other firmware encryption - Encrypted attestation tokens for privacy (and even EAT is only a framework, not a locked down end-end spec) - Some proprietary content encryption (video) — - Photo encryption for spy satellites — Satellites have a fixed alg, decrypting receiver supports lots of algs. - Sensor data encryption over super low bandwidth radio — The protocol version implies the algorithm ID because every bytes costs Many applications will not use COSE_Key at all. The algorithm negotiation schemes will vary widely. > Is there really a burning desire to use the same key with multiple kdf and > aeads? > > Which application use cases really need this feature? We write security considerations to say that is bad, but I don’t think we get to categorically exclude this from all COSE use. > > > 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. It is a should, not a must. > > 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. Right. The alg parameter in a COSE_Key is defined in COSE only for key use restriction for that particular key. I suppose it could be part of a negotiation scheme, but that’s not what it’s defined for. So the new “hkc” parameter in AJITOMI’s draft is then an extension to the alg parameter and its purpose is key use restriction. It is definitely a step beyond anything in COSE so far which has used only single integer ciphersuites here. > ... > > > 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? All sorts of designs are possible and allowed. Use of the kid is optional and when it is used, it’s meaning is application-specific. > > 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? Some negotiation examples: If you are writing a minimum to implement document for COSE before HPKE, you make a list of integer ciphersuite and you are done. With COSE HPKE, you make a list of KEM-HKDF-AEAD triples. If you designed an accept-select negotiation protocol for COSE before HPKE, the accept list is just a list of integers. Now it’s a list of integers plus a list of triples and the processing is more complex. A key use restriction examples: To implement key use restriction in COSE before HPKE, you just see that the COSE algorithm ID that you are about to use the key for is in the COSE_Key alg parameter. This works for every algorithm in COSE until “hkc”. Now you have to do something more complex. (Part of the beauty of COSE’s design for highly constrained devices is the simplicity of the single integer algorithm identification. It has made t_cose internals much cleaner than previous work I’d done with OIDs. If I’d realized all this a few months ago, I’d have argued for ciphersuites a lot harder). > 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 > <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. I think key use restriction by algorithm in COSE_Key is a solvable problem. I do not think COSE algorithm negotiation is solvable in a general way. The problem space is too vast and varied. That’s why COSE didn’t solve it. To give one example — we redesign S/MIME to use COSE, but we want it to work with X.509 certificates because there are millions of them out there and there is huge expensive HW infrastructure and process to support them (HSMs). There’s no COSE_Key in that, so it wouldn’t be part of the solution. And, that is not to exclude the use of COSE_Key for negotiation when it works out in a specific application. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
