Re: [jose] Ted Lemon's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)

[Mike Jones <[e-mail]>]

No changes have been made as a result of these comments in the -34 draft.  If you believe that I've missed something, please feel free to point it out!

				Thanks again,
				-- Mike

> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Monday, October 06, 2014 12:54 AM
> To: Ted Lemon; The IESG
> Cc: [e-mail]; draft-ietf-jose-json-web-
> [e-mail]; [e-mail]
> Subject: RE: Ted Lemon's No Objection on draft-ietf-jose-json-web-encryption-
> 33: (with COMMENT)
> 
> 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:[e-mail]]
> > Sent: Thursday, October 02, 2014 4:14 AM
> > To: The IESG
> > Cc: [e-mail]; draft-ietf-jose-json-web-
> > [e-mail]
> > 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