On Sat, Nov 02, 2024 at 05:27:12PM -0700, [email protected] wrote: > Internet-Draft draft-ietf-jose-hpke-encrypt-02.txt is now available. It is a > work item of the Javascript Object Signing and Encryption (JOSE) WG of the > IETF. > > Title: Use of Hybrid Public Key Encryption (HPKE) with JSON Object > Signing and Encryption (JOSE) > Authors: Tirumaleswar Reddy > Hannes Tschofenig > Aritra Banerjee > Orie Steele > Michael B. Jones > Name: draft-ietf-jose-hpke-encrypt-02.txt > Pages: 19 > Dates: 2024-11-02
Quickly reviewing the diff: 1) 'The protected header parameters "ek" MUST NOT be present.' This should presumably be 'The protected header parameter "ek" MUST NOT be present.' (There is exactly one parameter.) 2) 'The "iv", "tag" and "aad" members MUST NOT be present.' The second example seems to have "aad" member. 3) 'The HPKE Setup info parameter MAY be used, and its values are not constrained by this specification. By default, it is empty unless apu or apv are present, in which case it will carry the JOSE context-specific data as defined in Section 4.6.2 of [RFC7518].' There seems to be multiple issues here: - The structure defined in JWE/4.6.2 does not seem suitable for the info parameter. It contains meaningless-looking things like Z and keydatalen. - Some HPKE implementations don't like having both aad and info. - Many HPKE implementations limit size of info to quite low values (spec only guarantees 64 bytes). This could exceed those limits. - Copying information from protected headers is useless. To be actually useful for security, the information copied must come from outside the message (that is, related to context the message is in). IMO, apu and apv in JOSE are unnecessary and completely misdesigned. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
