No issues. Assuming the receiver can detect and avoid “too many levels of encapsulation”.
From: Orie Steele <[email protected]> Sent: Monday, January 22, 2024 5:05 PM To: Ilari Liusvaara <[email protected]> Cc: [email protected] Subject: Re: [jose] Fwd: New Version Notification for draft-rha-jose-hpke-encrypt-02.txt Here is the JSON approach you suggested: https://github.com/OR13/draft-jose-hpke-test-vectors/blob/main/src/json.ts The JSON approach has no protected headers, and makes no use of aad. It seems like it should behave the same as the compact approach. Why not treat the protected header as aad for seal in the JSON approach? Seems that would be safer, and it would commit the JOSE ciphertext for encrypted_key to the "alg" used in the HPKE suite. Regards, OS On Mon, Jan 22, 2024 at 3:29 PM Orie Steele <[email protected]<mailto:[email protected]>> wrote: Here is an implementation of the compact serialization: https://github.com/OR13/draft-jose-hpke-test-vectors/blob/main/src/compact.ts I will look at the JSON serialization next. OS On Mon, Jan 22, 2024 at 11:07 AM Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote: On Mon, Jan 22, 2024 at 09:27:31AM -0600, Orie Steele wrote: > Thank you for these comments! > > Would you mind filling in the HPKE Operations for this part of your > proposal: > > HPKE ciphertext = Seal(key, nonce, aad, pt) > HPKE plaintext = Open(key, nonce, aad, ct) > > But using the variables you defined below: The HPKE variables are obtained/transported as follows, in compact/JSON serialization: pkR: The public key, converted to kem indicated by alg used skR: The private key, converted to kem indicated by alg used kdf: Determined by alg used aead: Determined by alg used info: Empty octet string aad: * Compact: BASE64URL(UTF8(JWE Protected Header)) (Note: This is the 1st part of compact serialization as-is) * JSON: Empty octet string pt: * Compact: message (if "zip" is present, compressed) * JSON: CEK enc: * Compact: Transported as JWE Encrypted Key (Note: implicit base64url by JWE) * JSON: Base64url encoding transported as per-recipient encapsulated_key header. ct: * Compact: Transported as JWE Ciphertext (Note: implicit base64url by JWE) * JSON: Transported as per-recipient JWE Encrypted Key. (Note: implicit base64url by JWE) The compact serialization does not use the 3rd and 5th parts (JWE Initialization Vector and JWE Authentication Tag) of the serialization. Both are set to empty octet strings. One can compare to COSE-HPKE: (pkR, skR, kdf, aead and info are the same) aad: CDE(Enc_structure) pt: * Layer0: message * Layer1: CEK enc: Transported as layer unprotected encapsulated_key. ct: Transported as layer ciphertext. -Ilari _______________________________________________ jose mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose -- ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries> [cid:[email protected]]<https://transmute.industries/> -- ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries> [cid:[email protected]]<https://transmute.industries/> THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
