Hi Ilari, Please see inline
On Tue, 18 Feb 2025 at 12:47, Ilari Liusvaara <[email protected]> wrote: > On Mon, Feb 17, 2025 at 12:21:09PM +0530, tirumal reddy wrote: > > > > On Tue, 11 Feb 2025 at 23:26, Ilari Liusvaara <[email protected]> > > wrote: > > > > > On Tue, Feb 11, 2025 at 12:22:48PM +0530, tirumal reddy wrote: > > > > Hi all, > > > > > > > > We have published a new draft > > > > https://datatracker.ietf.org/doc/draft-reddy-jose-detached-aad/ that > > > > introduces a mechanism to support detached AAD in JWE. This allows > the > > > AAD > > > > to be derived from context-specific information instead of being > > > > transmitted in-band. The mechanism is particularly useful in > scenarios > > > such > > > > as OpenID for Verifiable Credentials (OID4VC), where a verifier must > > > > validate context information without relying on in-band AAD. > > > > > > > > Comments and suggestions are welcome. > > > > > > Some quick comments: > > > > > > - Remove stuff about JWE serialization. This should work in terms of > > > abstract JWE messages. > > > > > > > "Abstract JWE messages" is not a well-defined term in the context of JWE > as > > specified in RFC 7516. > > What I meant the mechanism should be independent of serialization. > > And RFC 7516 does implicitly have concept of abstract message: Section 7 > is about serialization, and other sections are about messages in > abstract sense. > > IOW, the serialization does not change the meaning of the message. > I believe that keeping serialization details is important. The two JWE serialization formats (Compact and JSON) have different implications for how the message is processed. We would like to provide clarity on how the mechanism works in practice and ensure interoperability across implementations. > > > > > - Remove the "detached_aad" parameter. It only seems useful for > attacks. > > > > > > > "detached_aad" is in the JWE protected header, please elaborate on the > > attack. > > Stuff like receiving application specifying implicit/detached/external > AAD and then library overriding that from message. Such decryption MUST > fail. > > The easiest way to implement this is to just attempt the decryption with > given implicit AAD anyway, as the message will fail authentication. > The inclusion of the detached_aad parameter in the JWE protected header is useful for helping the decryptor identify whether detached AAD is being used. Without this explicit indicator, the decryptor would be unable to distinguish between messages with and without detached AAD, potentially leading to incorrect assumptions and decryption errors. > > > > > - Change the implicit-only AEP construction. Right now it can collide > > > with stock JWE AEP construction, which is unsound. > > > > > > > I don't get the comment, please clarify. > > Messages with: > > - Protected header X, JWE AAD Y, and empty detached AAD. > - Protected header X, empty JWE AAD, and detached AAD Y. > > Both give the same Additional Authenticated Data (AAD) > encryption parameter. Which is bad. > Good point, I will update the message as follows: ASCII(Encoded Protected Header || '.' || 'EMPTY_AAD' || '.' || BASE64URL(Detached AAD)) Cheers, -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]
