I just noticed the responses were not sent to Gen-art, IETF, or [email protected]. Forwarded thread for transparency on review.
On Tue, Aug 26, 2014 at 6:00 PM, Mike Jones <[email protected]> wrote: > So that there are no surprises, I’m also annotating the proposed > resolutions below to say which of them will also result in parallel changes > other drafts. > > > > *From:* Jim Schaad [mailto:[email protected]] > *Sent:* Monday, August 25, 2014 9:13 PM > *To:* Mike Jones; 'Russ Housley' > *Cc:* [email protected] > *Subject:* RE: [jose] Gen-ART review of > draft-ietf-jose-json-web-signature-31 > > > > > > > > *From:* jose [mailto:[email protected] <[email protected]>] *On > Behalf Of *Mike Jones > *Sent:* Monday, August 25, 2014 6:22 PM > *To:* Russ Housley > *Cc:* [email protected] > *Subject:* Re: [jose] Gen-ART review of > draft-ietf-jose-json-web-signature-31 > > > > Thanks for the useful review, Russ. Proposed resolutions to your comments > follow inline. Please let me know if you agree. Also, working group > members, please follow this discussion, as these comments will likely > result in changes to the current drafts. > > > > -----Original Message----- > From: ietf [mailto:[email protected] <[email protected]>] On > Behalf Of Russ Housley > Sent: Sunday, August 24, 2014 12:23 PM > To: [email protected] > Cc: IETF Gen-ART; IETF > Subject: Gen-ART review of draft-ietf-jose-json-web-signature-31 > > > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at < > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > > > Please resolve these comments along with any other Last Call comments you > may receive. > > > > Document: draft-ietf-jose-json-web-signature-31 > > Reviewer: Russ Housley > > Review Date: 2014-08-24 > > IETF LC End Date: 2014-09-03 > > IESG Telechat date: unknown > > > > Summary: Not quite ready. Some issues to resolve. > > > > Major Concerns: > > > > - At first reading, I thought that Sections 2 and 3 were defining the > > same terms. On the second or third reading, I figured it out. > > I think it would be more clear in Section 3 to state that a JWS is > > constructed from a sequence of the things that are already defined > > in Section 2. > > > > I understand that there is some repetition between the Terminology section > and the JWS Overview section. I will plan to eliminate this duplication in > the manner you suggested – by simply using, rather restating the > definitions of, the terms, and saying that they are defined above. (Jim > Schaad – note that this will condense some of the text that you’d requested > be added to Section 3 to explicitly spell out the parts of a JWS, and will > result in a parallel change to JWE. Is that OK with you?) > > > > Given that I would expect the text to be in section 2, this is not an > issue for me. > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > - In Section 5.2, it says that in some cases, all must successfully > > validate, but in other cases, only a specific signature, MAC, or > > plaintext value needs to be successfully validated. How does the > > recipient know which case applies? > > > > The recipient knows what application it is part of, and so knows the > application decisions described in 5.2, paragraph 2 about whether all or > some signatures must validate. > > > > I do agree that the text in step 9 (signature validation) could be read as > being in conflict with paragraph 2. I’ll plan to modify this to say that > the step records whether the signature validated, rather than saying that > it must validate. Then I’ll add a step 11 saying to reject the input if no > signature validated and a step 12 saying to return a result indicating > which signatures were successfully validated, so that the application can > determine whether to accept the input and which signatures to trust. Will > that work for you? > > > > It’s more complicated a description, but a more general description of the > things that can happen in the multiple signatures case, in which some > signatures validate and some don’t and you may need to tell the application > which ones were good and which were bad. (It’s much simpler in the single > signature case, in which you can make a simple accept/reject decision.) > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > - In Section 8, why not say that TLS 1.2 or later MUST be supported? > > > > This text is modelled after http://tools.ietf.org/html/rfc6749#section-1.6, > but updated to remove the reference to TLS 1.0. I don’t believe the > working group felt that it had sufficient data on TLS 1.2 deployment to > understand whether it could now safely mandate 1.2 or whether this would > effectively mean that many deployments would be non-conformant. Is there > data saying that greater than N% of devices in common use now support TLS > 1.2 – where N% is preferably over 90%? It would be good have such data > about commonly used platforms such OS X, iOS, Android, Linux, and Windows > to help inform this decision. > > > > - Section 10 says, "The entire list of security considerations is > > beyond the scope of this document..." This reads like a red flag to > > me. While it is not possible to discuss every possible implementation > > consideration that impacts security, the document should cover the > > topics discussed in RFC 3552. At a minimum, I think the following > > need to be discussed: > > -- the consequences of compromise of the signer's private key > > -- the consequences of compromise of the MAC key > > -- the consequences of poor random numbers, which are needed for > > more than just key entropy with some algorithms like ECDSA > > -- awareness that cryptographic algorithms become weaker with time > > > > I agree that the phrase “The entire list of security considerations is > beyond the scope of this document...” adds no or negative value. I’ll > remove it. > > > > I’ll also plan to explicitly make sure that we address the topics in your > list above and go through RFC 3552 looking for others that we need to cover. > > > > Note that this proposed resolution will also result in parallel changes to > the JWE, JWK, JWA, and JWT specs. > > > > Minor Concerns: > > > > - Section 1, 1st paragraph says: "The JWS cryptographic mechanisms > > provide integrity protection for an arbitrary sequence of octets." > > This is true, but this is not the whole story. A sentence or two > > should be added about when a signature mechanism is appropriate > > and when a MAC mechanism is appropriate. Alternatively, a pointer > > to Section 10.4 could be included. > > > > I will plan to add the pointer to Section 10.4. > > > > - In Section 4.1.4, should the value match the subject key identifier > > if an X.509 certificate is used? > > > > That was not an intended usage of this field, although nothing precludes > particular applications from specifying its use in that manner. Its > intended usage is to match JWK “kid” values, as described. I don’t plan to > make a change to the document in response to this comment unless you > believe that one is truly necessary. > > > > - In Section 4.1.5, why is TLS required to fetch digitally signed > > X.509 certificates? > > > > This question was explicitly discussed by the working group at IETF 87. > The discussion is recorded in the minutes > <http://www.ietf.org/proceedings/87/minutes/minutes-87-jose> as follows: > > If there is an x5u pointing to a certification issued by a major CA, is > TLS required for the HTTP query used to retrieve this certificate? TLS > shouldn't be needed since the certificate is a signed object. Therefore, > the "MUST" use TLS for cert retrieval should be changed to "SHOULD". This > is an application decision. Mike Jones doesn't want removal of TLS in the > case where there's no external means to verify the retrieved key. Matt > Miller: agrees with the jku case, but argues that for x5u, there is a class > of applications where it isn't known if the retrieved object is > self-protecting (like a certificate) until after it is retrieved. Even if > the object appears to be self-protecting, if the retriever doesn't have a > trusted root for that object, it might not be able to verify the protection > anyhow. So it use of TLS might still be preferable instead of having to > potentially retrieve an object twice, once over HTTP and then over HTTPS. > Joe Hildebrand wanted to know what the upside of this proposal is. Richard > says it saves on TLS handshakes; Hildebrand envisions a world where TLS is > ubiquitous. Paul Hoffman said that a similar issue in DANE ended up being > dropped after a couple of months of discussion. Richard agreed to drop the > TLS MUST to SHOULD proposal. > > > > - Section 10.2 talks about chosen plaintext attacks. However, there > > are much worse things than chosen plaintext attacks that will result > > if a third party can get a signer to sign a content of its choosing. > > > > What’s there now is about attackers getting to choose part of the > plaintext. I think you’re talking about attacks in which the attacker gets > to choose the whole plaintext, which is clearly far worse. At that point, > the signature of the signer obviously becomes pretty worthless. Is that > your point here? If so, I could take a stab at writing something about > this, or you could suggest some text if you’d like. > > > > Other Comments: > > > > - I suggest a rewording for a part of Section 2: > > > > OLD: > > > > JOSE Header > > JSON object containing the parameters describing the cryptographic > > operations and parameters employed. The members of the JOSE > > Header are Header Parameters. > > > > NEW: > > > > JOSE Header > > JSON object containing the parameters describing the cryptographic > > operations and parameters employed. The JOSE Header is composed > > of a set of Header Parameters. > > > > OK > > > > - I think that Section 3.1 would be more clear by saying: > > > > In the JWS Compact Serialization, a JWS object is represented as: > > > > BASE64URL(UTF8(JWS Protected Header)) || "." || > > BASE64URL(JWS Payload) || "." || > > BASE64URL(JWS Signature) > > > > OK > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > - I think that Section 3.1 would be more clear by saying: > > > > In the JWS JSON Serialization, a JWS object is represented as: > > > > BASE64URL(UTF8(JWS Protected Header)) || "." || > > JWS Unprotected Header || "." || > > BASE64URL(JWS Payload) || "." || > > BASE64URL(JWS Signature) > > > > This isn’t accurate. Assuming you’re talking about 3.2, the > representation isn’t the concatenation above – it’s a JSON object > containing some or all of the values above. Nonetheless, I can try to > revise the text to be more direct here as well. > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > Then, the text needs to say that whitespace may appear anywhere. > > > > OK > > > > Note that this proposed resolution will also result in parallel changes to > the JWE spec. > > > > - Some additional whitespace would make Section 7.2 easier to read. > > > > OK > > > > - The IANA Considerations section requires the establishment of a new > > mail list: [email protected]. The process for setting up the > > list is described at the bottom of this web page: > > http://www.ietf.org/list/nonwg.html. > > > > This text was taken from RFC 6749 and the list is modelled after the > [email protected] list described therein. It’s not clear to me > whether you want a change to the draft (if so please specify) or whether > you were just being helpful (which is appreciated). > > > > Thanks > again, > > -- Mike > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > -- Best regards, Kathleen
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
