Thanks for your review, Ted. I'm adding the working group to the thread so they're aware of your comment.
> -----Original Message----- > From: Ted Lemon [mailto:[email protected]] > Sent: Thursday, October 02, 2014 4:14 AM > To: The IESG > Cc: [email protected]; draft-ietf-jose-json-web- > [email protected] > Subject: Ted Lemon's No Objection on draft-ietf-jose-json-web-encryption-33: > (with COMMENT) > > Ted Lemon has entered the following ballot position for > draft-ietf-jose-json-web-encryption-33: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This question is almost certainly due to my thick-headedness with respect to > authentication algorithms, but: > > 16. Let the Additional Authenticated Data encryption parameter be > ASCII(Encoded Protected Header). However if a JWE AAD value is > present (which can only be the case when using the JWE JSON > Serialization), instead let the Additional Authenticated Data > encryption parameter be ASCII(Encoded Protected Header || '.' || > BASE64URL(JWE AAD)). > > 17. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization > Vector, the Additional Authenticated Data value, and the JWE > Authentication Tag (which is the Authentication Tag input to the > calculation) using the specified content encryption algorithm, > returning the decrypted plaintext and validating the JWE > Authentication Tag in the manner specified for the algorithm, > rejecting the input without emitting any decrypted output if the > JWE Authentication Tag is incorrect. > > How does it make sense for the AAD encryption parameter to consist of > ASCII and BASE64 text? How would a decryption algorithm use this? I > know nothing about AAD parameters in encryption algorithms, so I realize this > is > probably a very naive question. When doing authenticated encryption, an Additional Authenticated Data parameter can be included that will be integrity-protected as part of the authenticated encryption operation. This means that if it is tampered with, the decryption will fail. JWE uses this authenticated encryption feature to integrity-protect some header fields. It also makes this feature available to applications using the JWE JSON Serialization. Answering your specific question, all of these three values are strings consisting of ASCII characters, so their concatenation is also a string consisting of ASCII characters: ASCII(Encoded Protected Header) '.' BASE64URL(JWE AAD)) The "ASCII(...)" around the string denotes that the string is to be represented in a sequence of ASCII octets (rather than, for instance, a series of UTF-32 octets, which would be four times as long). Best wishes, -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
