I decided to purchase a domain and make a demo. https://hpke.dev
The demo shows how JWK can be valuable for working with HPKE even when JWE is not used. The demo compares the current experience *using the exact same P-256 key* with *ECDH-ES+A128KW* to HPKE with *APPLE-HPKE-v1 *aka* ... *DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM Based on: https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests?language=objc The demo code hand waves over a number of important issues in how HPKE might look in JOSE, Ilari has pointed a few of them out before, but I will repeat them here just in case: 1. My "json hpke envelope" is made up (so is Apple's), but looks similar to a flattened JWE from JOSE. 2. The "alg" value used in the JWK is not a registered "alg" for use with EC or OKP curves... This seems fixable, see https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms 3. JWE "enc" vs HPKE "enc" and related issues... https://github.com/transmute-industries/hpke.dev/blob/main/components/demo-old-way.tsx#L12 4. No example of "multiple recipients" is provided. 5. Technically "alg" is optional in my "made up JSON HPKE envelope", since the recipient key contains an alg, and the assumption is that the sender possesses the recipient's key ( and I mean JWK with a restricted alg, not opaque bytes and key type). How the sender obtained the recipient key is irrelevant but you can imagine "kid" may or may not have been involved. I realize bringing a partially-JOSE demo to a COSE key representation debate might seem odd, but COSE has similar APIs as JOSE, despite having less overall adoption (thanks mostly to OAuth), and per the discussion we had earlier, a JWK can mitigate the need to transmute "alg" or "sender info" in the case the recipient key is restricted. I don't have plans to implement support for 100% of the HPKE registry, and I would guess that neither does Apple based on their current SDK. @Ilari Liusvaara <[email protected]> send me your COSE HPKE implementation and I will add it to the implementation list. Regards, OS On Sun, Apr 16, 2023 at 2:28 PM Laurence Lundblade <[email protected]> wrote: > > > On Apr 15, 2023, at 10:12 PM, Ilari Liusvaara <[email protected]> > wrote: > > On Fri, Apr 14, 2023 at 4:00 PM Laurence Lundblade <[email protected]> > wrote: > > 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. > > > Well, in store-and-forward system like COSE or JOSE, there are really > only two ways: > > - negotiation. > - assume based on application. > > And when it comes to COSE and JOSE, there are no usable negotation > capabilties, so it is the latter: assuming based on application. > > > Hi Ilari, > > Want to clarify your point here. > > I think you mean that we can’t design and standardize a negotation > protocol that COSE use case will use (if we did it would be a bad TLS). > Instead, each COSE use case, each COSE application, will come up with its > own way of determining the algorithm(s) used. Right? I think this is right. > > When I used the word “negotiation” in framing I was using it in a very > broad general sense to cover every means that sender and receiver come to > know what algorithm to use. I think you used the word negotiation the > narrow sense of a round trip protocol. > > I am little unsure about your wording “assume based on application”. We > could rip out CMS and replace it with COSE for S/MIME and still use X.509 > and the sender could know that the recipients algorithm from the X.509 > cert. That doesn’t seem like “assuming” to me. > > Modern web protocols can be pretty complex and powerful and do a lot with > a lot of round trips. One of those round trips might allow algorithm > agreement for some use of COSE in another part of the protocol. > > When you use the word “assume” I think of more of a simple thing like > minimum-to-implement, a general specification that a use case uses only one > algorithm, or allowing the sender to pick one of three and requiring the > receiver to support all three. These are fine, but there’s also a > proprietary round-trip agreement, certificate-based agreement and probably > a lot more. > > It might be good to see what JWT and CWT do. They certainly have this > problem and have real world deployments. > > 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>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
