Re: [jose] AD review of JWK draft

[Mike Jones <[e-mail]>]

The changes we’d agreed to wording approaches for below have all been incorporated in the -28 drafts.  Specifically, the new wording for the “goals” statement in the introduction is in place, and explanations of when applications would and wouldn’t use “typ” and “cty” are now present.

                                                            -- Mike

From: Kathleen Moriarty [mailto:[e-mail]]
Sent: Monday, June 16, 2014 2:42 PM
To: Mike Jones
Cc: [e-mail]
Subject: Re: [jose] AD review of JWK draft

Thanks again, Mike.

On Fri, Jun 13, 2014 at 9:27 PM, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:
Thanks for working through the details.  Replies inline…

From: Kathleen Moriarty [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, June 13, 2014 2:05 PM
To: Mike Jones
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] AD review of JWK draft

Hi Mike,

Thanks for the quick response and update to the draft!  I'll respond in-line and will follow up and read the draft to confirm later.

On Wed, Jun 11, 2014 at 3:33 AM, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:
Hi Kathleen,

I believe that the -27 drafts address all your outstanding issues on the JWK draft, 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 reply below.  In short, if a change is to be made to this already heavily discussed phrase, I’d like to see proposed alternate wording that means the same thing but is even clearer.
I believe Jim had some additional guidance, maybe he can assist with alternate language.

•        Discussion on “typ” and “cty” wording.  Status:  Please see my reply below.  In short, if a change is to be made to this even more heavily discussed and wordsmithed wording, I’d like to see proposed alternate wording that means the same thing but is even clearer.
This should come from the WG and my concern is two-fold.
1. There isn't much text on what this is actually used for, but rather more on processing.  I'm fine with the clarity on the processing language.

Mike> OK, that’s a useful clarification.  I’ll review the “what it’s used for” text in JWS and propose updates.
Thanks.

2. There is a bunch of overlap and then some varying guidance (lower case vs. capital letters) between drafts.  Can this be streamlined rather than repeated and then stated a bit differently between drafts?  These will be processed as a set, so we can treat them that way.

Mike> Sounds good.  I’ll see what duplication and inconsistencies can be avoided.  Also, it’s good to hear that they’ll be processed as a set, because I think that will help everyone.
Yes.  If you can reduce redundant text, it will be helpful, especially as a set where people otherwise would need to read the same thing multiple times.  If errata is found later, even editorial, it would be in lots of places too.

Does that help more in terms of what I am looking to see?  I believe the text is below, so I'll highlight my #1 there to help.

                                                            Thanks again,
                                                            -- Mike

From: Mike Jones
Sent: Saturday, June 07, 2014 1:29 PM
To: 'Kathleen Moriarty'; [e-mail]<mailto:[e-mail]>
Subject: RE: [jose] AD review of JWK draft

Thanks once again for the review, Kathleen.  Responses inline…

From: jose [mailto:[e-mail]] On Behalf Of Kathleen Moriarty
Sent: Saturday, June 07, 2014 9:14 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [jose] AD review of JWK draft

Thanks again for your hard work on this draft.  I do have some comments and questions listed below.  I know we still have at least one or two outstanding issues from the last review, so hopefully they can get addressed soon.

1. Introduction, 2nd paragraph:
   Goals for this specification do not include representing certificate
   chains, representing certified keys, and replacing X.509
   certificates.

I see that you actually do address this is section 3.6.  Could you clear up the text int he introduction and add something to say that the appropriate references will be provided?  It seems like a wording mis-match that is easy enough to address and make clear from the start.  Here is the text from 3.6 (bottom of p6):
   The identified resource MUST provide a representation of
   the certificate or certificate chain that conforms to RFC 5280
   [RFC5280] in PEM encoded form [RFC1421].

Mike> Good catch.  The text in the introduction dates back to a time when there were no X.509 representations in JWK.  The real point was that we were not trying to create an alternative key attestation format – just dealing with bare keys.  I’ve tried to reword this in my mind a few different ways, given the presence of the X.509 representations that were added, and all the rewordings I’ve thought of could be subject to misinterpretation.  I’m thinking of just deleting the sentence at this point.  Would that work for you?

You have the reference included later in the draft, so something simple would make the intent clear from the start.  How about:

1. Introduction, 2nd paragraph:
   Goals for this specification do not include representing certificate
   chains, representing certified keys, and replacing X.509
   certificates.  References to existing standards will be provided.

Mike> The problem with the wording above is that, in fact, there *are* representation of X.509 certificate chains in the spec now (“x5c” and “x5u”), so what’s in the normative text actually contradicts this text in the introduction.  How about this instead?  (It doesn’t read as well, but it’s at least correct.)

Goals for this specification do not include representing new kinds of certificate chains, representing new kinds of certified keys, or replacing X.509 certificates.
That's fine, thanks.

2. Terminology:
The definitions for JWK and JWK set are not clear in this section alone.  It seems to be explained at the start of section 3, so could you clean up the definition a bit for each and reduce the redundancy?  For instance the JWK represents a cryptographic key and contains the properties and value of the key.  The JWK Set definition doesn't explain the use of "keys" here to make the definition clear.  Maybe just stating it more basically would help, where the term member is understood as an object member when you describe the array of JWK values.

This should be an easy enough fix that will assist with readability and understanding before diving deeper.  The start of section 4 reads better with this explanation once again in the draft.

Mike> OK

3. Section 3.
Paragraph 3 also appears in the JWS document and I am noting it here as there is an ongoing discussion.  Adjustments to language may be needed here as well.
   The member names within a JWK MUST be unique; recipients MUST either
   reject JWKs with duplicate member 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].

Mike> Do you have a specific suggested text change you’re looking for?  I may be too close to this, but I don’t find any ambiguity in the current language:
    “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]”.
In particular, the phrase “returns only the lexically last duplicate member name” already allows implementers to understand the properties that the parser needs to have without having to actually look at the ECMAScript spec at all.

I should also add some of the background on the current text.  It used to be that the spec said that the member names MUST be unique – period.  Jim Schaad and Tim Bray (the JSON spec editor), among others, pointed out that, based on the then-current discussions in the JSON working group, the new JSON spec (now RFC 7159) was not going to mandate that parsers reject inputs with duplicate member names.  So the old text would have meant that most implementations would have to write their own, more-restrictive JSON parsers.  What to do about this was extensively discussed by the working group in response to issue #27, in the thread beginning with http://www.ietf.org/mail-archive/web/jose/current/msg02647.html.  I count 32 messages in that thread.  The outcome was the current language, which uses MUST language about producers but allows consumers to be laxer so as to be able to use existing parsers, while still having well-defined behavior, should an illegal input with duplicate member names be parsed.

Given how extensively this was discussed the working group, I’m reluctant to change this already highly wordsmithed text unless the replacement text means the same thing and is even clearer.

The ticket underscores the interoperability issues that could occur in a pretty clear way, I see the current text tries to address the cited issues.  I'll plan to respond to this in the JWS thread as I believe Jim also chimed in to that discussion and I'd like to go through that before responding and keep the discussion in one place if possible with context of recent discussions.

Mike> OK
I need to do this still...


4. Section 3.6
COuld you include an example of a common representation and what would be required if PKI X.509 certificates are not used?  It could help interoperability to spell out what is required rather than just saying include what is required.  I suspect developers may come up with very different representations left to their own devices.
   For instance, if the "use"
   member is present, then it needs to allow for only a subset of the
   usages that are permitted by the certificate.  Similarly, if the
   "alg" member is present, it should represent an algorithm that the
   certificate allows.

Mike> Such an example is present in http://tools.ietf.org/html/draft-ietf-jose-json-web-key-26#appendix-A.1.  However, you’re not the first person to make a comment of this form.  Part of the problem is that what is required for each key type is defined in the JWA spec – not here.  Another practical problem is that many developers implement against the examples – not solely from the normative text.  Having the example come late in the draft may thus be problematic.  I therefore propose to add a simple example early in the draft, much as was done in http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-26#section-3.1, so developers have something to wrap their heads around early in the draft, before trying to read the rest of it.
A simple solution would be to reference the guidance in JWA in the second paragraph so developers know where to go (prevent interop issues) as well as the example within section 3.6 (now 4.6) from the appendix that shows a representation of an alternate type (guidance in JWA to example in appendix so the mapping is clear) to address this concern.


Mike> I like having the early JWK example, just like there are in the JWS and JWE drafts.  In practice, I think seeing it when skimming is significantly better than being told in running text where to find it, since that’s easy to miss.  I also did add the forward reference “Additional example JWK values can be found in Appendix A<http://tools.ietf.org/html/draft-ietf-jose-json-web-key-27#appendix-A>.”.
Great, thanks!  If this sort of thing shows up elsewhere, proving a pointer to the examples would be good.

 5. Section 3.8
You should add another one for SHA-2 if this will be used by the XMPP community since they are trying to drop the use of SHA-1. (2nd paragraph changes somehow depending on how you do this.)

Mike> Will do.
Thanks for adding in 4.9

6. Section 4
If the text from the following paragraph is updated from the discussion resulting from the JWS review, it should get updated here as well.  Included so it's not forgotten.
   The member names within a JWK Set MUST be unique; recipients MUST
   either reject JWK Sets with duplicate member 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].

Mike> Thanks – noted.

7. Section 6, first sentence.
Not sure "contexts" is the right word here:
   JWKs containing non-public key material will need to be encrypted in
   some contexts to prevent the disclosure of private or symmetric key
   values to unintended parties.
If the goal is to prevent disclosure (if you don't care about that, you don't do it), shouldn't this read:
   JWKs containing non-public key material will need to be encrypted
   to prevent the disclosure of private or symmetric key
   values to unintended parties.

Mike> How about this language instead?
“JWKs containing non-public key material will need to be encrypted when potentially observable by parties without legitimate access to the non-public information to prevent the disclosure of private or symmetric key values to unintended parties.”

(Your proposed language, while simpler, is overly restrictive, because they don’t need to be encrypted when only observable by parties with legitimate access to the non-public information.)

Let me understand your argument here.   Why would you want the materials observable at all if intended parties have access?  Doesn't this open the door unnecessarily to attackers who observe the traffic, even if they appear as the intended parties just observing (on the network, for instance).  Is there a case where it is helpful for intended parties to observe this?

Mike> I’m sure we both have the same understanding of the requirements but I think finding the best words may be tripping us up.  It needs to be observable by the intended parties and not be observable by unintended parties.  Thus, unencrypted representations have to be available to the intended parties for the keys to be useful.  Conversely, if it’s possible for any unintended party to observe a representation, it must be encrypted in a way that can only be decrypted by intended parties.

That being said, I agree that the new first sentence of http://tools.ietf.org/html/draft-ietf-jose-json-web-key-27#section-7 is clunky.  I’ll think about ways to improve it.
Thanks!


8. Section 6
This question really starts from the JWS draft, but I am mentioning it here as I am not sure how a developer would know how/when to use "cty" and "typ".  I find the language a little confusing and then how the possibilities are spread throughout various drafts rather than in one place (JWS 4.1.8 & 4.1.9, JWK 6) and Oauth (JWT 5.1 and 5.2), and maybe more?  The initial description in 4.1.8 and 4.1.9 could be crisper and how it refers to the IANA MIME Media Type registry.  They are also optional, so the point of using them isn't clear enough to me.  Can you fix the language in the drafts to address this?
   A "cty" (content type)
   Header Parameter value of "jwk+json" MUST be used to indicate that
   the content of the JWE is a JWK, unless the application knows that
   the encrypted content is a JWK by another means or convention.

From "cty" 4.1.9 of JWS:
   This parameter has
   no effect upon the JWS processing.  Use of this Header Parameter is
   OPTIONAL.

I'm not sure why you would use it then and if it is there, why would you process it?  The language in these drafts may need to be cleaned up a bit, otherwise, It's not clear why this is defined.  If you know it is a JWK – do you ignore the value of cty if present or should you still check it and fail if it is not “jwk+json”


Mike> If you know from the application context that it is a JWK, there’s no need to use a media type.  The options to use media types in JWS, etc. are there for polymorphic application cases – where the data type can legally vary.  In those use cases, an application can use the media type to determine the type of the content being referred to.  Whereas if you know the type, there’s no need to declare it dynamically at runtime.  That’s why the definitions of “typ” and “cty” say “in contexts where this is useful to the application”.  It’s up to the application whether to use these fields or not.  JOSE libraries will ignore them – leaving processing of them to the applications, if wanted.
OK, the purpose for typ and cty is never stated.   Can you add in (to JWS) the purpose and why one would process it if there is no effect on JWS processing?  Why would one bother, that is not clear in the current text.  You description helps, can you turn that into something that makes sense in the JWS draft?  The processing requirements only need to be in one draft, then referred to by the other drafts.  If something varies from the first draft, then you just need to state that to streamline.  Since these will go through as a set, it's helpful to treat the drafts that way.

Mike> Yes
Thank you!


Then in JWT (I know t is Oauth and not this WG), they have you use upper case instead of lower case letters to represent the value.  How does a developer track this if it is not in one place?  Section 5.1
   While
   media type names are not case-sensitive, it is RECOMMENDED that "JWT"
   always be spelled using uppercase characters for compatibility with
   legacy implementations.

I guess it is all in the media type definitions, but seems odd that the recommendations switch from upper to lower case depending on what tag is used.  I'm guessing that there is some history here that explains it and probably can't be changed without causing issues… but it could cause confusion.

Mike> Yes, there’s history here.  “typ” and “cty” didn’t use to be MIME Types – they used to be fields with their own registry and defined values.  Those values were case sensitive.  James Manger, among others, convinced the working group that it was better to use MIME Types, since then we weren’t defining new type namespaces.  However, because of existing JWT deployments that counted on the strings “typ”:“JWT” and “cty”:“JWT”, the JWT spec includes the recommendation that the application/jwt media type be represented with the uppercase value “JWT” in JWTs, so as to not break those deployments.

OK, thanks for the background!


This is another area that’s been (even more) extensively discussed and heavily wordsmithed by the working group.  The specific issue of whether these fields should be MIME Types or not was issue #50, discussed in the threads http://www.ietf.org/mail-archive/web/jose/current/msg02967.html (7 messages) and http://www.ietf.org/mail-archive/web/jose/current/msg03470.html (10 messages), on the 9/16/13 working group call http://www.ietf.org/proceedings/interim/2013/09/16/jose/agenda/agenda-interim-2013-jose-7, http://www.ietf.org/mail-archive/web/jose/current/msg03464.html and the 10/7/13 working group call, after which Jim resolved the issue.  But also see the closely related threads http://www.ietf.org/mail-archive/web/jose/current/msg02364.html (92 messages), http://www.ietf.org/mail-archive/web/jose/current/msg02589.html (52 messages), and http://www.ietf.org/mail-archive/web/jose/current/msg02974.html (5 messages) which discuss the purpose and use of the “typ” and “cty” fields.

Given how extensively this was discussed the working group, I’m reluctant to change this already highly wordsmithed text unless the replacement text means the same thing and is even clearer.  Do you have a specific suggested text change you’re looking for?

No, my response above and fixing that is the main issue, not that these are MIME types.

Mike> Good – Then I’ll work on the “what it’s for” text in JWS, while leaving the “how it works” text alone.  And I’ll see if there’s duplication that I can remove.
Thanks!


9. Security Considerations
I know you are aware, but this should be updated similar to the other drafts, addressing additional concerns specific to this draft.  If this should just reference the security considerations of one, that's fine and just add what's needed for this draft.  People don't mind reading something only once when reviewing a set of drafts :-)

Mike> What additional specific additional security considerations would you like to see added?  (Working group, that question goes to you too!)  For JWA, I plan to add text about timing attacks but I don’t know what to add here.

If the working group doesn’t come up with specific security considerations that they’d like to have added soon to the drafts (they’ve been silent thus far despite multiple requests for input!), might a path forward be to submit the drafts for IETF review, specifically asking people to review the security considerations and suggest additions that they believe should be covered?

I had given some word smithing recommendations, that would be a good start.  The second sentence needs to be corrected.

Mike> Per my response to the JWA review thread, I think at this point that the second sentence should just be removed, since it doesn’t add any value.
Ah, it's kind of a good way to introduce what is coming.  I just thing some edits would be helpful.   If you add in asymmetric, that would be good.  It should be obvious, but a lot of things should be obvious ;-)

Thanks,
Kathleen


--

Best regards,
Kathleen

Mike> I plan to submit updated drafts in the next few days covering the outstanding discussion issues that I believe we’ve reached resolutions on, so as to keep things moving forward.  I look forward to hearing your thoughts on my responses above.

Thanks & sorry for the delay.  The telechats occur on Thursdays and I was very busy with the numerous reviews.

Mike> No problem.  When I was a researcher, I used to be on a lot of conference program committees, so I have some sense of what it might be like. ☺

Best regards,
Kathleen

                                                            Best wishes,
                                                            -- Mike




--

Best regards,
Kathleen

                                                            Later,
                                                            -- Mike



--

Best regards,
Kathleen