Hi Illari, Thanks for the review. Please see inline
On Sun, 3 Nov 2024 at 14:56, Ilari Liusvaara <[email protected]> wrote: > 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.) > Thanks, fixed. > > > 2) 'The "iv", "tag" and "aad" members MUST NOT be present.' > > The second example seems to have "aad" member. > The second example is for multiple recipients. In this mode, a) The "iv", "tag" JWE members MUST be present b) The "aad" JWE member MAY be present. > > > 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. > Yes, updated the draft to exclude Z and keydatalen. The context-specific data is concatenation of AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo. > - 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 It seems like an implementation bug, for example TLS ECH uses both aad and info, and the size of info is much larger than 64 bytes. TLS ECH is supported by browsers. > . > - 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. > It is a separate issue and requires an update to RFC7518. -Tiru > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
