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:[email protected]]
> Sent: Monday, October 06, 2014 12:54 AM
> To: Ted Lemon; The IESG
> Cc: [email protected]; draft-ietf-jose-json-web-
> [email protected]; [email protected]
> 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:[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
