I replied to Ilari offlist by accident, but I hope he will clarify some of the comments he made regardless.
I just stumbled across this: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/200#issuecomment-2183701761 Which seems relevant to his comment about HPKE AuthMode at the end. Regards, OS On Sat, Jun 22, 2024 at 3:42 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Sat, Jun 22, 2024 at 12:32:42PM -0500, Orie Steele wrote: > > Hello, > > > > I've created yet another prototype HPKE implementation to consider > feedback > > we got from the adoption call. > > I know folks are struggling to follow along with HPKE details, but I'm > > going to address several points of feedback in this email to avoid > creating > > separate threads for each topic. > > To make this bearable (bearer token joke), I have focused only on compact > > JWEs for use as JWTs. > > > > As you can see from: > > > https://github.com/transmute-industries/hpke/blob/main/tests/jwt.test.ts#L26 > > > > In the prototype, JWTs are built from { alg: > > 'HPKE-Base-P256-SHA256-A128GCM', enc: 'A128GCM' } > > The encapsulated key goes into the JWE Encrypted Key. > > This is a change from the draft-ietf-jose-hpke-encrypt-00 where the "ek" > > was placed in the protected header. > > It eliminates double base64url encoding. > > The enc value is set to `A128GCM`, this is a change from > > draft-ietf-jose-hpke-encrypt-00. > > Redefining what enc: 'A128GCM' means in JWE is not acceptable. > > Any extensions to JWE itself must encode to currently invalid things > (but compact and JSON serialization may still be used). > > And then alg: 'HPKE-Base-P256-SHA256-A128GCM' sounds like Key > Encryption... And JWE is pretty explicit on how that works. > > > > Another exciting topic has been AuthMode and PSK support. > > > > draft-ietf-jose-hpke-encrypt-00 requests psk_id and auth_kid headers to > > support this use case, but does not request algorithms. > > For PSK, easiest would be to have presence of psk_id header to select > PSK mode. > > - Senders have to be explicitly configured about PSK to use anyway. > - Receiver not supporting PSK will get decryption failure anyway. > > Auth is rather nasty can of worms. It is trivially insecure in > presence of multiple recipients, and still has security issues > even with one recipient (because HPKE fails Insider-Auth). > > > > I've now done a first attempt here: > > > https://github.com/transmute-industries/hpke/blob/main/tests/jwt-auth-psk.test.ts > > > > The headers "psk_id" and "auth_kid" should be optional, but I believe it > > is important to distinguish "auth mode psk" from "base" mode: > > > > - HPKE-Base-P256-SHA256-A128GCM > > - HPKE-Auth-P256-SHA256-A128GCM > > - HPKE-AuthPSK-P256-SHA256-A128GCM > > - HPKE-PSK-P256-SHA256-A128GCM > > > > This is sad, because it will result in registry bloat per mode. > > > > We could consider making the "mode" a dependent parameter of the > algorithm, > > but then we lose the ability to distinguish keys which support auth mode > > from those that do not. > > This sounds bit similar to ECDH-SS. While JOSE does not have that, COSE > does. What does COSE do with ECDH-SS sender keys? > > And then one might want to restrict keys to HPKE, but no further. > > > > Now seems like a great time to talk about use cases for HPKE based JWTs, > so > > we know which algorithms are actually needed. > > For base mode, the only algorithms that JWE has no substitute for is > the post-quantum stuff. > > Yes, HPKE might be a bit more compact, but I doubt people seriously > golfing bytes are using JWTs. > > > > As you can see, the latest editors copy includes some guidance on use of > > HPKE: > > > > > https://paulbastian.github.io/draft-bastian-dvs-jose/draft-bastian-dvs-jose.html#name-designated-verifier-signatur > > > > If this document were to register algorithms there would be substantial > > overlap with HPKE Encrypted JWT use cases. > > > > I believe that draft-ietf-jose-hpke-encrypt based JWTs can support the > use > > case that draft-bastian-jose-alg-ecdh-mac is targeting. > > > HPKE auth mode has property that compromising receiver key allows > unlimited forgery. > > And looks like to enable unlimited forgeries from a single sender, it > requires leaking just a single DH result (receiver private key times > sender public key). > > > > > > -Ilari > > _______________________________________________ > jose mailing list -- jose@ietf.org > To unsubscribe send an email to jose-le...@ietf.org > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
