Subject: Re: [jose] AD review of JWS draft

From: Mike Jones <[email-masked]>
Date: Wed, 11 Jun 2014 07:28:57 +0000

Hi Kathleen,

I believe that the -27 drafts address all your outstanding comments on JWS, other than the following:

·        Discussion on wording “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]”.  Status:  Please see my latest reply in the thread “[jose] AD review of JWK draft”, sent on Saturday, June 7th.  In short, if a change is to be made to this already heavily discussed phase, I’d like to see proposed alternate wording that means the same thing but is even clearer.

                                                            Thanks again,
                                                            -- Mike

From: Kathleen Moriarty [mailto:[email-masked]]
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-masked]<mailto:[email-masked]>> wrote:

Thanks for the review, Kathleen.  My responses are inline below, prefixed by "Mike>".

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Monday, May 19, 2014 6:16 PM
To: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/jose