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. 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. 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. 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. 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. Thanks again, -- Mike Jim
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
