Thank you for this wonderful breakdown! On Fri, Apr 14, 2023 at 4:00 PM Laurence Lundblade <[email protected]> wrote:
> So three distinct uses of algorithm ID out on the table here: > > *1) Header Parameter* > > - Alg used to sign or encrypt and thus what to use to verify and > decrypt > - Used in COSE_Sign, COSE_Encrypt…, COSE_Signature, COSE_Recipient > - Header Parameter label == 1 > - Not the same as alg COSE_Key (parameter label == 3) > > Important point, when both are present, are there any examples of them being different (aside from the tag) ? AFAIK they are meant to be matched against, and so, they are meant to be the *same* when both are present. > > - Seems to be optional. I can’t find anything making it mandatory in > RFC 9052. Here’s the CDDL "Generic_Headers = ( ? 1 => int / tstr, ; > algorithm identifier”. It would be a bad idea to leave it out, but that > seems to be allowed, perhaps to accommodate extremely low bandwidth uses > where the algorithm is known by other means. > - > > https://www.rfc-editor.org/rfc/rfc9052.html#name-common-cose-header-paramete > > > I agree it is optional, for comparison, here is the JWE reference: https://www.rfc-editor.org/rfc/rfc7516#section-4.1.1 > *The encrypted content is not usable if the "alg" value does not represent a supported* * algorithm, or if the recipient does not have a key that can be used with that algorithm*. Similar to the examples discussed in: https://datatracker.ietf.org/doc/html/rfc9052#appendix-A A sender could omit the "alg" from the JWE header, and receiver could discover alg from "kid" in keys they hold already or via negotiation, but perhaps that is a better question for the JOSE WG. I will add them here, since we are discussing JWE / JWK as they might be impacted by decisions made about HPKE Public Key structure and algorithm naming / conventions. *2) COSE_Key Parameter* > > - Alg used to restrict key use of a particular COSE_Key > - Used only on COSE_Key > - The required purpose of this is restriction of key use > > Yes! > > - COSE_Key Parameter label == 3 > - Definitely optional. "If this parameter is present…” CDDL: > "COSE_Key = {... ? 3 => tstr / int, ; alg > > Agreed ( I still think unrestricted keys are a bad idea ). > > - > https://www.rfc-editor.org/rfc/rfc9052.html#name-cose-key-common-parameters > > > Another note on "sender" vs "recipient" framing, per https://www.rfc-editor.org/rfc/rfc9052.html#section-5.1 > Examples of header parameters about the recipient are the *recipient's key identifier* and the *recipient's encryption algorithm*. In the current COSE HPKE, by the naming of "hkc algorithm parameters" / "sender info", we are positioning them as originating from the sender's preferences, but the COSE RFC frames them as meeting the "recipients preferences"... and notes that there are security considerations with sender and receiver agreement. And per the current HPKE COSE security considerations: > HPKE assumes the sender is in possession of the public key of the recipient and HPKE COSE makes the same assumptions. Hence, some form of public key distribution mechanism is assumed to exist. Combined with the following from RFC9180: > HPKE assumes that the sender and recipient agree on what algorithms to use. - https://www.rfc-editor.org/rfc/rfc9180.html#section-9.7.2 When we say "public key" in a CRFG document, I think it is reasonable to assume no specific representation (JWK, COSE Key, PGP, etc...) As a side note, HPKE requires more than just having a recipient public key, it also requires knowledge of the recipient supported algorithms... (this is extremely obvious per the security considerations). It is natural to assume this will be solved differently in COSE, PGP, etc... Maybe it is in the key representation, maybe it is via negotiation, as you mentioned earlier... But it has to actually be solved for, or the sender is just guessing that the recipient will be able to process their messages. When we say "public key" in a COSE WG document, folks will want to be sure if we are talking about the "abstract concept of a public key" or a concrete serialization conforming to normative requirements (JWK Public Key or COSE Public Key). Holding a JWK or COSE "public key" with an algorithm, 🔥 has historically meant 🔥 holding a recipient's encryption preferences. - https://datatracker.ietf.org/doc/html/rfc9052#appendix-B - https://www.iana.org/assignments/cose/cose.xhtml see (-27). There is no precedent for COSE Key or JWK containing "preferences for parameterization" in addition to a "restriction of key use". You can imagine COSE HPKE asking IANA to update the COSE registry to communicate that "hkc" is bound to a specific value of "alg", similar to how -27 is bound to "kty". (! 🔥 kty and alg confusion intensifies... ) ... I prefer to imagine requesting registration of a few good choices for HPKE COSE (to start), and not importing every option under the sun by default from the CFRG established registries here: https://www.iana.org/assignments/hpke/hpke.xhtml For example, we could register Apple's preference like in https://www.iana.org/assignments/cose/cose.xhtml, just like this: APPLE-HPKE-v1 <https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests#4036918> (really TBD) | -27 (really TBD) | DHKEM(P-256, HKDF-SHA256) + HKDF-SHA256 + AES-128-GCM <https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests#4036908>... (0x0010, 0x0001, 0x0001) <https://www.iana.org/assignments/hpke/hpke.xhtml> [kty] | [draft...HPKE-COSE <https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/>] | Yes Later, if DHKems are broken by quantum computers, we change the "Yes" to a "No"... How many other preferences would we need to register? Only the ones people actually want to use, and *they* need to do *some* work to justify why this is a good idea... we don't just hand out a blank check, and leave COSE implementers on the hook for an ever expanding bill of CFRG registered algorithms. Obviously Apple is just an example here... But I suspect people will end up referring to HPKE configuration by names sooner or later, "APPLE-HPKE-v1" is already easier to pronounce than "HPKE-v1-BASE + ( 0x0010, 0x0001, 0x0001) <https://www.iana.org/assignments/hpke/hpke.xhtml>" . If we make this harder, people will just call it what Apple calls it... Since Apple is already following a best practice here, and it is easier to understand what is supported from their simple and effective choice of a name... for what is supported. HPKE is not actually usable in COSE without some work from this working group, we should not defer our responsibility to the (first ever, IIRC) CFRG established registry, it is not going to feel good for developers, if we try to start a 5 guy revolution while the world is trying to upgrade to post quantum encryption. *3) Algorithm negotiation* > > - RFC 9052 defines no protocol message for negotiation > - It doesn’t even require that items in the COSE algorithm registry be > used for negotiation, though that seems like a very good and obvious thing > to do > - > > https://www.rfc-editor.org/rfc/rfc9052.html#name-application-profiling-consi > > > As you noted, there will be cases when you want to use COSE HPKE, without holding a JWK or a COSE Key... or via some negotiation for one... The good news is that you can still do that with a named algorithm, Apple provides an example of this today. I suspect we will see more examples if COSE HPKE becomes an RFC. > Up until COSE_HPKE, 1) and 2) are a single integer ciphersuite. Probably > anyone doing 3) up to until COSE_HPKE would also use the single integer too. > Agreed. > > draft-ietf-cose-hpke has addressed 1) with the new HPKE_sender_info header > parameter. Now the algorithm used is a special ciphersuite identifier that > indicates further details in an additional parameter. > > Agreed, there are "proposals for revolution", which I am all for, if they are coming from enough reviewers / implementers. I am happy to withdraw my objection if overwhelmed by counter arguments, I don't find the current arguments from Ilari compelling, but I appreciate his consistent engagement. > draft-ajitomi-cose-cose-key-jwk-hpke-kem is a proposal for 2) COSE_Key > using the same approach as draft-ietf-cose-hpke, but a slightly different > structure. It uses HPKE_Key_Configuration which different > from HPKE_sender_info by not having the enc item. > > draft-ajitomi-cose-cose-key-jwk-hpke-kem is also a proposal for 3). > > Take-away is: > - Algorithm ID is always optional in COSE and should always be optional in > COSE_HPKE. We can write tons of security considerations to say why that is > bad, but we shouldn’t change COSE fundamentals. > > 💯 This has been my consistent argument. > - In COSE_HPKE we’re requiring algorithm identification be made up of a > special ciphersuite and a triple. This will/should apply in all contexts > where COSE algorithm IDs are used. Maybe we should try to unify the > definition of this in draft-ietf-cose-hpke > and draft-ajitomi-cose-cose-key-jwk-hpke-kem? > > I don't think we need another document. I think we should bend the knee to convention in COSE HPKE, even over the objections of Ilari and Daisuke... (assuming they persist in advocating for parameterization of alg). UNLESS, we have clear consensus on proceeding with a revolution, for that I would want to see a lot more engagement :) > > My opinions on 3) are: > - The use cases are too widely varying for anyone to define an actual > protocol > - draft-ajitomi-cose-cose-key-jwk-hpke-kem can only work for a small > fraction of negotiation use cases — those that use COSE_Key for negotiation > - We might generalize the HPKE COSE algorithm identifier definition so the > same thing can be used for 1), 2) and 3). That is probably splitting > HPKE_sender_info > into two, one structure that is the algorithm ID and one is the enc info. > We still wouldn’t define actual protocol for 3) but we would have a clear > common method for COSE HPKE algorithm identification that anyone could use > for their use-case specific negotiation protocol. > > I agree with you on 3. > LL > > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
