Adding the WG... Thanks. Sent from my iPhone
> On May 21, 2014, at 8:20 AM, Mike Jones <[email protected]> wrote: > > Did you mean to also send this to WG? You just sent it to me. > > From: Kathleen Moriarty [mailto:[email protected]] > Sent: Wednesday, May 21, 2014 5:17 AM > To: Mike Jones > Subject: Re: [jose] AD review of JWS draft > > Thanks, Mike. Responses are inline as well and we are down to just a few > items where WG input could be helpful. I will be off for a couple of days, > so I may be slow to respond, but will do my best. > > > Sent from my iPhone > > On May 20, 2014, at 8:57 AM, Mike Jones <[email protected]> wrote: > > 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? > > I'd like to hear others chime in as well. > > > 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”. > > Thanks. > > > 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! > > > Thanks & I look forward to seeing the updated 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. > > 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? > > My bigger concern on this one was to see crisper guidance. I like the first > sentence, as just saying something is ill advised may not be strong enough. > I'd like to avoid interoperability issues if possible. Thanks. > > > 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. > > I'll have to read the threads, thank you. The issue tracker statement wasn't > clear enough for me on any consensus, etc. > > > 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? > > Ok, then the language may need to be adjusted so that is clear. > > Thank you, > Kathleen > > > Thanks again for your review. > > -- Mike > > -- > > Best regards, > Kathleen > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
