On Thu, Jul 20, 2023 at 05:44:40PM -0500, Orie Steele wrote: > On Thu, Jul 20, 2023, 5:01 PM AJITOMI Daisuke <[email protected]> wrote: > > > It's *extremely* unfortunate naming choices, because that's not how JOSE > >> works: > > > > > > ...Regarding the KEM/key agreement thing about which we are talking, > > *that's > > how JOSE works*. > > > > In JOSE, the primary "alg" value for key agreement is "ECDH-ES". > > Not only "crv" but also "kty" cannot be determined by the "ECDH-ES". > > > > This is true... Partially... You still see crv and kty in epk. ( Which is > similar to how you see x and y in enc, for dh kems )... You can't do ecdh > cross curves... Afaik. > > Are we sure we haven't learned how to do this better since JOSE was > standardized?
I see the crv and kty in epk as duplicate information, and duplicating information is not a good idea to put it mildly. > > In the first place, "alg" is just an optional value in JWK/COSE_Key and > > cannot be relied upon. There are plenty of examples of JWKS endpoints > > without "alg" values. > > > > For example, Azure-AD JWKS endpoints like this... > > https://login.microsoftonline.com/common/discovery/keys > > > > Example JWKs in MDN web docs don't use "alg" ... > > > > https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/importKey#json_web_key_import > > > > Yes, alg is optional in both COSE Key and JWK. > > It's not optional in JWS headers, or JWE headers. > > It is optional in COSE Encrypt, and there are good reasons for it to remain > optional everywhere... The most obvious is that a protocol might only > support 1 configuration, an example of this is Apple's wallet protocol. It is actually only optional on Layer 0. All recipient structures are required to have alg info. And even then, it seems pretty bad idea to leave it out, except maybe in the most constrained uses of COSE_Encrypt0. > Just because it's optional, does not mean that when it's present it should > be ambiguous, or invite negotiation. Well, the disaggregation of alg already either requires profiling or negotiation. And this is even worse than with current COSE-HPKE design, because one can just support everything in current COSE-HPKE design (I have done that), but full COSE design (before COSE-HPKE) is far too complex for any implementation. > > > And this is "better" than iterating one list of "advertised algorithms" > > in the sense that it is "more compact" and "safer" ? > > > > I think the "hkc" approach is better. > > - Since it does not rely on "alg", it will work with many existing > > implementations and it can be used not only JOSE/COSE but also many other > > applications. > > > > It's just another optional field.... You could make them equivalent by > calling stringify on it, and using that for alg. In COSE, I presume equivalent would be deriving the alg value from KEM/KDF/AEAD by some formula (string alg values are bit too complicated, even if allowed)? There was a concern that there are not enough bits for that sort of thing. There are enough. > - If the recipient(server) wants to support multiple KDF/AEADs for one KEM > > algorithm, the "alg" approach should provide multiple KEM keys. > > - etc... > > > > I'm sure its possible... But is it a good idea? Well, if the protocol is capable of both AES and Chacha20, yes. > Which vendors have said they really want to advertise capabilities this > way, by exposing a full list of HPKE parameters they support? > > Do the folks who implemented HPKE for TLS do this today? Yes. And also for HTTP. MLS does not, but I think what that protocol does is flawed. > What evidence from implementations supports standardizing this kind of > parameterization? > > Even if people show up saying it is being done outside COSE... That's not > necessarily a reason to do the same thing in COSE. I think the reasons are pretty similar. > We didn't invent the wheel (HPKE) but we can improve it. > > Reducing the parameterization burden to use it, is one of the few things we > can do to improve the experience for developers. One way to improve HPKE would be Locking KEM and KDF together. Sadly, that is not possible from outside HPKE. > And it doesn't impact what HPKE can do. Unfortunately, that may or may not be true. > It impacts what you need to know to use HPKE. In subtle ways. E.g., sender still needs to force strong enough encryption. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
