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 JWTs built from { alg: 'ECDH-ES+A128KW', enc: 'A128GCM' } The ephemeral public key goes into the protected header, and the encrypted content encryption key goes in to the JWE Encrypted Key. 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. There was confusion about some of the normative statements that are in JWE, and how they apply to HPKE based JWTs. I show how apu / apv can remain supported, however they are secured with aad in my prototype instead of as part of the key agreement info. This is inconsistent with their original purpose, but they are "mandatory to process" when present, so I am not sure how we should be interpreting them in the context of HPKE. Please read: https://datatracker.ietf.org/doc/html/rfc9180#section-8.1 Based on my experience as a developer (not a cryptographer) implementations should not be required to write extra code to process apu / apv. Please read: https://datatracker.ietf.org/doc/html/rfc9180#section-5.1.1 We should provide an example like https://datatracker.ietf.org/doc/html/rfc7518#appendix-C But it should explicitly address the confusion that is present surrounding mandatory processing of "apu" and "apv" when present. My current recommendation would be to write something to the effect of: When "apu" and "apv" are present in headers, they: 1. MUST NOT be used to construct explicit info per section 5.1.1 of RFC 9180. 2. will be secured as AAD, during Seal and Open AEAD operations (this is true of all information in protected headers). 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. 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 also goes against guidance in https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/ The good news is that we do not need to register all combinations of mode, kem, kdf, and aead that are implied by: https://www.iana.org/assignments/hpke/hpke.xhtml Now seems like a great time to talk about use cases for HPKE based JWTs, so we know which algorithms are actually needed. At IETF 119, this draft was presented: https://datatracker.ietf.org/doc/draft-bastian-jose-alg-ecdh-mac/ 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. When creating "tokens" or "credentials", the goal is to convey claims made by an issuer about a subject, to a verifier. JWT and CWT have claim names for these entities, such as: "iss", "sub", "aud". Other claims can be added such as "iat", "exp", or "email", etc... Such claims are secured in several different ways, for example: 1. The claims could be signed with the issuer private key, producing a signed JWT. 2. The claims can be encrypted to the verifier's public key, producing an encrypted JWT. 3. The claims can be retrieved over a secure channel, like HTTPS. This draft shows how to assign media types for each case: https://datatracker.ietf.org/doc/draft-ietf-rats-eat-media-type/ There is growing interest in credentials that are channel bound, and cannot be stolen or sold while remaining verifiable to a high value issuer, for example a government. HPKE Encrypted JWTs with Auth Mode can support this use case, for protocols that support JWT, and that already understand JWT claims that are protected with digital signatures today. I am hopeful that with feedback from stakeholders that have this use case, we can ensure that HPKE JWTs support the algorithms that are necessary to enable government credential use cases where digital signatures are forbidden, or not recommended. Please use know if you would like us to apply any of these prototype implemented changes to the draft. Regards, OS -- 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
