From: Mike Jones [mailto:[email protected]] Sent: Friday, June 28, 2013 4:45 PM To: Jim Schaad Cc: [email protected] Subject: RE: Comments on version 11 of draft-ietf-jose-json-web-encryption Responses inline. From: Jim Schaad [mailto:[email protected]] Sent: Friday, June 28, 2013 12:39 PM To: Mike Jones Cc: [email protected] Subject: RE: Comments on version 11 of draft-ietf-jose-json-web-encryption From: Mike Jones [mailto:[email protected]] Sent: Thursday, June 27, 2013 3:50 PM To: Jim Schaad Cc: [email protected] Subject: RE: Comments on version 11 of draft-ietf-jose-json-web-encryption Thanks for the useful review comments, Jim. Replies inline prefixed by "Mike>". -----Original Message----- From: Jim Schaad [mailto:[email protected]] Sent: Saturday, June 15, 2013 2:08 PM To: [email protected] Cc: [email protected] Subject: Comments on version 11 of draft-ietf-jose-json-web-encryption Gentlemen, Here are a few comments for consideration. Note that some of the comments from the JWS review are also applicable to this document as much of the language in places is the same. 1. In Section 4.1.2 - You probably want to say an AEAD algorithm not an AE algorithm Mike> The problem with the "AEAD" terminology is that it implies both algorithm and encoding properties. We want the algorithm properties but not the encoding properties defined by RFC 5116. Thus, a conscious terminology change was made in -08 to longer use the term "AEAD". [JLS] The term AEAD has nothing to do with the encoding properties defined in RFC 5116. AE and AEAD algorithms are very distinct. One offers only authenticated encryption and the other adds the associated data. They are not to be confused. Mike> OK - What's a good reference for the term that's not RFC 5116? [JLS] You don't need one - if you are worried about it rather than just doing an inline abbrev (i.e. Authenticated Encryption with Associated Data (AEAD)) then define it in the terms. 3. In section 4.1.4 - Does the group agree that compression is a required feature to implement? Mike> This feature was discussed at IETF 83 and has been in place in the current form ever since -02. I'd be shocked if people didn't believe this feature was necessary. [JLS] So in your opinion, it is an absolute requirement that my code implement zip, but not that it implement jwk. This makes absolutely no sense to me. I am not asking if there is a requirement that it be present in the document. I am asking if it is a required to implement feature. Mike> The rationale for this is that people (Eric Rescorla, I think) thought that since "zip" processing changes the ciphertext, that not supporting it would give a weapon to attackers, enabling them to substitute one ciphertext for another. Since there are security implications in not implementing it, it's MTI. [JLS] I would have to talk to EKR about this. Given that you compress before you encrypt and we are authenticating either the post encrypted stream or the post compressed stream I don't see where this is a real security issue. 4. Why not reference sections 4.1.5 - 10 by reference with a comment that these refer to the key that was used to encrypt the content? Is there a benefit of having them listed here? Is there a difference in the way they are interpreted other than the recipient/originator thing? Mike> I assume you mean reference them in JWS? There's a complete list here so that it's clear to JWE implementers what the reserved header parameters are without having to reference other specs. And yes, the JWS and JWE key selection parameters are the same other than the JWS sender/JWE receiver difference. [JLS] That does not make sense to me. There are lots of times that referencing other specifications makes a lot of sense. You certainly be that this is true when it comes to security considerations. I believe that it is equally true here. I did not say don't list time, I said that you should reference the sections in the signature draft. Mike> I have no objection to adding a reference saying that related parameter definitions are also contained in JWS 4.1.2 - 4.1.5. [JLS] I have no objection to saying the complete definition is in JWS as the entire text of the section. 5. Why not reference sections 4.1.11-12 from the JWS document? Is there a difference in the way they are interpreted? Mike> (Apparently I didn't understand what you were suggesting in 4, having seen this next question.) In any event, in JWS they reference the key that is used to verify the signature. In JWE they reference the key to which the content was encrypted. That's the difference in all these parameters. Mike> I have no objection to adding a reference saying that the related parameter definitions are also contained in JWS 4.1.8 - 4.1.9. 6. If we are not going with an alphabetic order of names, the I would suggest that apu should be next to exp as they are used in the same context and therefore having them adjacent makes sense. Mike> Actually, Richard had suggested moving "apu" to the key agreement section in JWA, since its use is algorithm-specific. I think I agree with him. [JLS] that's a fine approach as well. 7. Is there a reason not to reference 4.1.14 from JWS? Is there a difference in interpretation? Mike> Stylistically, it seems easier for implementers of JWE to have a complete list of general-purpose parameter definitions than to have some here and some there. The example is also different, because one is a JWS header and the other is a JWE header. Mike> I have no objection to adding a reference saying that the related parameter definition is also contained in JWS 4.1.10. Thanks again, -- Mike Jim
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
