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. 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. 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. 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. 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. 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. 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. 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? -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
