Since the last thread had a lot of details, I am starting a new one to summarize the changes that need to be documented in the JOSE HPKE draft.
I was able to get JSON Serialized JWE with "HPKE-Base-P256-SHA256-AES128GCM" and "ECDH-ES+A128KW" to work with https://github.com/panva/jose (decryption only, given it does not yet support HPKE). To do this, I had to pull a bunch of the internals out, so the code is a bit gross, and that's because of me, not panva. "encapsulated_key" should be "ek", I just have not shortened the name yet, since the short name is harder to communicate with. { "protected": "eyJlbmMiOiJBMTI4R0NNIn0", "ciphertext": "t7XOvW1SZgf-3fz7ZNSDiEEUKRdI9MdblC-8wLysN49ov0erROQDieZ-EFn0QnDFZw5RcGPMLWvO8ZkHfOsgzSld", "iv": "Sl0fLuINvzicEgzQ", "aad": "8J-SgCBhYWQ", "tag": "xy3xYOfBM5ObzNXdeppkyw", "recipients": [ { "encrypted_key": "tURMb3-zPMhHoHZUGlnVUyQhscrpQenjrRKorM2DoDo", "header": { "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:RLaSa8XtodlM3fLoS7IGBL21lgXOP-nVg7obhAf8AVs", "alg": "HPKE-Base-P256-SHA256-AES128GCM", "encapsulated_key": "BESPDLvUeBwkSsQhrZpY4lS-fFE_3LcQCh8TuUsphvrSd1oapl6SNg-Hs0poV8rn-KCbyWGuY6IAABpRlNUiH3g" } }, { "encrypted_key": "zuVnoUXttYnMW9FtxXPkSD_rF__Udixs", "header": { "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:2M7TcrbAuR5riiLzxwWN_NR6Js8fMFtu-tVLakgqoAo", "alg": "ECDH-ES+A128KW", "epk": { "kty": "EC", "crv": "P-256", "x": "H5jZ_QhKH8XfqvKT6lqWO0yGSMLA8VukIDmdHzQnca4", "y": "BmWr4pxMoQI_BJaachjhP_YfMKXNmStHiQGkKFDXdaE" } } } ] } 1. The AAD for the content encryption MUST be "protected" + "." + "aad", where protected and aad are both base64url encoded. When no JWE aad exists, the aad MUST be "protected" (no trailing period). 2. The tag for AEAD needs to be exported and base64url encoded and MUST be included in the JSON Serialization JWE. 3. The AAD for HPKE Seal and Open MUST be the same as the AAD used with AEAD for content encryption ("protected" + "." + "aad" or just "protected" in case there is no "jwe aad"). So if we are just looking at AADs used in HPKE JWEs, this is what they look like decoded: COMPACT: base64url ( JSON ( { alg, ... } ) ) aka the protected header. - enc MUST NOT be in the protected header of COMPACT serialized HPKE JWEs. JSON: base64url ( JSON ( { enc, ... } ) ) + "." + base64url ( aad ) aka the protected header with or without aad per https://datatracker.ietf.org/doc/html/rfc7516#section-5.1 - alg MUST NOT be in the protected header of JSON serialized HPKE JWEs. We could set the aad for HPKE "seal and open" to nothing for the JSON serialization (was suggested in the other thread), then HPKE would use aad for seal and open in compact serialization, and not use it for JSON serialization. It seems safer to use the same aad for both the encrypting the content encryption key, and using the content encryption key to encrypt the plaintext... I assume there is a negligible performance impact. I think we should add lots of text clearing distinguishing all these places where AAD shows up, and hopefully developers will read all of it, but if they don't we should consider what will happen when there is an aad mismatch in all the places where you can have one. OS -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
