Maybe the way to say it is that COSE used ciphersuites where it makes sense. The place it makes sense is for a COSE_Recipient. Seems like the COSE algorithm IDs defined for COSE_Recipients in 6.3 and 6.4 are mostly cipher suites as they combine key agreement, KDF and sometimes key wrap.
For example in 6.4.1 ECDH-ES + A128KW -29 HKDF -- SHA-256 yes A128KW ECDH ES w/ HKDF and AES Key Wrap w/ 128-bit key To use a different KDF (or key wrap) you’d have to define a whole new suite. This is different from HPKE where the KDF is identified indecently. There is no place in COSE where the KDF is identified independently. (It would probably have been a bad design to insist that all recipients of a multi-recipient message use exactly that same crypto or that the main body plaintext be encrypted separately for each recipient, so that means it doesn’t make sense to define a ciphersuite for the whole message, just for the COSE_Recipient.) I’m not to win any big argument here, just have some framing to be helpful for the discussion. Appreciate your detailed responses, Ilari. LL > On Nov 16, 2022, at 9:21 AM, Ilari Liusvaara <[email protected]> wrote: > > On Wed, Nov 16, 2022 at 08:47:57AM -0800, Laurence Lundblade wrote: >> >> I want to offer a frame up of what seems different different >> philosophies on algorithm ID in COSE compared to HPKE. >> >> It seems pretty clear that HPKE is ala carte. There are separate id’s >> for the AEAD, KEM and KDF and you can choose any combo you want. It’s >> very flexible because you can make any combo you want. >> >> It seems that COSE went for cipher suites were only the major and most >> useful combinations are defined (which doesn’t prevent other combos >> that turn out to be useful from being defined). The benefit of this >> approach is easier and fewer choices for non-expert users of COSE. I >> think it is probably easier on implementors and possibly results in >> libraries being more interoperable. It also eliminates some silly >> combinations. > > Actually, COSE does not have ciphersuites. > > Consider you want to asymmetrically encrypt a message in (pre-HPKE) > COSE to a single recipient using some ECDH-class key. > > The algs you use for this do not actually depend on the exact type of > the ECDH-class key (e.g., P-256 or X25519)! And the algorithms used in > different layers do not depend on each other, as long as the algorithms > are of the correct type. > > This can wind up there being four independent cryptographic primitives > (bulk AEAD, key wrapping, KDF and ECDH), and COSE has at least four > bulk AEADs, at least 7 key wraps, two KDFs and five ECDHs. > > And if there are multiple recipients, the last three are independent for > every recipient. > > >> I’m looking for answers on how we will handle one message with >> multiple recipients, particularly where some recipients are HPKE >> and some are not (e.g. AES key wrap in RFC 9053 6.2) as the next >> step in figuring out what to do. > > The way multi-recipient messages are handled is performing bulk > encryption with random key, and then encrypting that key N times, > and placing the results as recipients. > > This allows to mix-and-match different recipient types (e.g., > symmetric key, direct ECDH, indirect ECDH, HPKE) in the same > message. And in the future there might be even more recipient > types (e.g., direct/indirect KEM). > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
