Thanks for the review, Kathleen. My responses are inline below, prefixed by "Mike>".
-----Original Message----- From: jose [mailto:[email protected]] On Behalf Of Kathleen Moriarty Sent: Monday, May 19, 2014 6:16 PM To: [email protected] Subject: [jose] AD review of JWS draft Hello, I reviewed the JWS draft and have questions and comments for the editor and working group. There are a few things that I would like clarified or corrected before we progress the document. 1. Section 4.1.7, Why isn't there a SHA-256 'Thumbprint'? XML tools had this functionality 2+ years ago as I used it with the XML editor, Oxygen. It would be better to bake this in now rather than having to rush it at a point later in time. Mike> We haven’t added this, to date, because no implementations of SHA-256 thumbprints of certificates in common development tools had been brought to the working group’s attention. For instance OpenSSL supports SHA-1 but not SHA-256 (see http://www.openssl.org/docs/apps/x509.html). The same is true of Windows and .NET. (Java has no support for certificate thumbprints, but they can be computed by writing code to do so.) In general, the JOSE working group’s features choices have been strongly directed by what features are actually available in common development tools. If something is not commonly implemented in practice, we have tended to leave it out, while providing registries to enable adding new functionality later, should it be desired. I do see that RFC 6594 describes the use of SHA-256 fingerprints in SSHFP Resource Records and I don’t doubt that some tools such as Oxygen implement this for SSH purposes. There wouldn’t have to be a rush to add this later and it doesn’t even have to be done by the JOSE working group. This can be added by a separate specification via the JSON Web Signature and Encryption Header Parameters Registry (defined in Section 9.1) at any time that it’s needed. Also, note that even if SHA-1 were completely cryptographically broken, there wouldn’t be a significant security issue with using SHA-1 thumbprints of certificates, since the certificates are public information, and the thumbprint is just used as a certificate selection hint. No non-public information would be leaked. Yes, it might be possible to create another certificate with the same thumbprint at that point, but when used, the full certificate would be downloaded and evaluated. If not trusted, it would be rejected. What do others in the working group think? Is there a compelling reason to add this now, or shall we leave it to a future specification to add it via the registry, when wanted? 2. Section 8: Is it still the case that you guys aren't using TLS 1.2 widely still? Setting a minimum requirement would be good here and there are implementations now. Is this just older text (I'm guessing that is the case and it just needs to be updated)? The pointer for TLS 1.2 is rfc5246. Wikipedia (http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations) has a list they maintain of TLS implementation state and there is good support for TLS 1.2 now. Can you update this and set a minimum requirement? For the following text, I recommend removing the last clause in the second sentence as the decision will be made with knowledge of current vulnerabilities as opposed to those at the time of this publication. I have some other suggested edits to the sentence as well. Change from: Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. To: Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, will depend on widespread adoption and deployment, as well as known security vulnerabilities. Mike> Agreed. You’re right that the text is old; its origin is http://tools.ietf.org/html/rfc6749#section-1.6. I’ll also drop the phrase “but has very limited actual deployment, and might not be readily available in implementation toolkits”. 3. Section 10.1 This looks like the same text from the start of the security considerations section of JWA. Please make the same updates and ensure the documents are consistent where there is shared text. Mike> Yes, the introductions to all four Security Considerations sections are intentionally the same, and will be kept in sync. The specific threats listed in the four specs differ. *Working Group* – I’m still hoping that a number of you will identify additional threats that we want to describe mitigations for in the four Security Considerations sections. Have at it! 4. Section 10.1 - There is more text here about the SHA-1 thumbprint and state of implementation that would need to get updated with an adjustment to support SHA256 for the thumbprints. Just making a note of this so it is not forgotten. Mike> Thanks – noted. 5. Section 10.2 Could you add a clause to the end of the last sentence to make it specific to the scope of applicability for this sentence? Since this just has an example, the full scope of what should be rejected is not clear and it is different from what is in parsers (according to this paragraph). Here is the current text: Some JSON parsers might not reject input that contains extra significant characters after a valid input. For instance, the input "{"tag":"value"}ABCD" contains a valid JSON object followed by the extra characters "ABCD". Such input MUST be rejected in its entirety. Mike> How about if I change the last sentence to “Any inputs not conforming to the JSON-text syntax defined in RFC 7159 input MUST be rejected in their entirety”? http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ is an example of parsers that would not reject the input. Can you add this as an informational reference and ideally, you would fix the issue to prevent the problem. Mike> The parser cited is parsing sequences of JSON-text objects separated by newlines. Yes, it would accept some such JWS-invalid inputs, because they would be valid JSON-sequence values but not valid JSON-text values. I believe it would be ill advised to use such a parser as it is designed to accept inputs not conforming to the JSON-text syntax, but if it were used, the input would need to be rejected if the JSON-sequence contained more than one JSON-text object. Is your intent in asking for the informative reference to use this as an example of characteristics of a parser that should not be used? I could do that, but it’s not clear to me that this reference would really help most developers quickly grasp the issue. Would it be OK to just change the last sentence to “Any inputs not conforming to the JSON-text syntax defined in RFC 7159 input MUST be rejected in their entirety”, as proposed above, or are you still interested in having us discuss how parsers of JSON-sequence syntax and other extended syntaxes should not be used? If so, I could add something like “Use of parsers that accept syntax beyond JSON-text, such as parsers for JSON-sequence streams, as defined in draft-ietf-json-text-sequence, is ill advised, as without further filtering their outputs, they will accept inputs that are not legal JSON.” Do you also want that, or are you OK just with the first change? 6. Also on issue #26, is there a pointer to discussion on this? It looks like it was closed out, but I'd like to read more on agreement for the decision. Mike> This was discussed on the thread titled “[jose] #26: Allow for signature payload to not be base64 encoded”, which starts at http://www.ietf.org/mail-archive/web/jose/current/msg02645.html. The discussion concluded during the in-person WG meeting at IETF 87, the minutes of which are at http://www.ietf.org/proceedings/87/minutes/minutes-87-jose. These minutes record: * Issue #26 - Allow for signature payload not to be base64 encoded John said that this issue should wait for something like a compact binary serialization. Joe Hildebrand said see CBOR and Richard nodded vigorously. Jim said he could live with deferring the issue until an updated version. Based upon this agreement, Jim closed the issue during IETF 87. 7. In the first paragraph of section 4, couldn't you wind up with different answers because of the text, "use a JSON parser that returns only the lexically last duplicate member name"? Full paragraph included for reference: The members of the JSON object(s) representing the JWS Header describe the digital signature or MAC applied to the JWS Protected Header and the JWS Payload and optionally additional properties of the JWS. The Header Parameter names within the JWS Header MUST be unique; recipients MUST either reject JWSs with duplicate Header Parameter names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. Let's say you have the following: {“alg”:”alg1”, “alg”:”alg2”} {“alg”:”alg2”,”alg”:”alg1”} You could end up with two difference answers about what is the value of the member alg. A parser that reads everything and then re-emits may change the order of the fields or emit only one of the fields and thus change the validity of it. Can it be reworded to avoid this potential issue? Mike> When parsing the input “{“alg”:”alg1”, “alg”:”alg2”}” legal outcomes are either rejecting the input or using “alg”: “alg2” (the ECMAScript 5.1 specified behavior – using the lexically last member with that name). The wording above doesn’t allow the “alg”: “alg1” result, since it is neither unique or the lexically last member name. Likewise, for the input “{“alg”:”alg2”,”alg”:”alg1”}”, only rejecting the input or using “alg”: “alg1” are legal outcomes. These inputs are not at all equivalent (unless the parser rejects them both because they have duplicate member names). ECMAScript doesn’t permit re-emitting the fields in different order, as you suggest in your comment, since it changes the meaning of the object. With that being said, do you still perceive that there’s a potential ambiguity that needs to be clarified? Thanks again for your review. -- Mike -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
