Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

[Mike Jones <[e-mail]>]

Hi Pete,

Could you take a look at the text changes made and responses your DISCUSS positions in the next few days?  We’re down to a week left to submit new drafts and if we need to make further changes for you, it would be good to know what they are before that.

For JWS:

You’d agreed to withdraw the first DISCUSS on the telechat.

You’d said that you’d review the specific uses of “accept” and “reject” and call out any specific places that you thought that implementers would be confused.

For your suggestion to convert JWSs using the Compact Serialization to the JSON Serialization, given that the reworked steps are now all steps (thanks for your feedback there!) and only necessary steps are included, given that your suggestion is not a necessary step, I would request that you drop it.  It’s an implementation suggestion – not a necessary step.

On your TLS comments, the places actually using TLS are now explicitly called out.

For JWE:

You’d agreed to withdraw this DISCUSS on the telechat.

For JWA:

Stephen said on the telechat that he would enter a DISCUSS if the implementation requirements were removed.

Jim Schaad pushed back on your suggestions that we use ASCII rather than UTF-8 as algorithm IDs and passwords.

====

The proposed resolutions were applied in response to your COMMENT positions too.

                                                            Thanks,
                                                            -- Mike


-----Original Message-----
From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Tuesday, October 14, 2014 5:46 AM
To: Pete Resnick; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

The proposed resolutions below have been applied to the -34 drafts.  Also, the "steps that are not steps" have been reworked or removed.  Can you please confirm that you're willing to consider your DISCUSSes on this draft satisfied on this basis, Pete?

Note that if you supply specific locations where you believe that changes need to be made to uses of "accept" and "reject" because those specific uses may be misleading, as I believe you volunteered to do on the telechat, we can do another round of edits to address them, as needed.

				Thanks again,
				-- Mike

> -----Original Message-----
> From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
> Sent: Saturday, October 04, 2014 6:58 PM
> To: Pete Resnick; The IESG
> Cc: [e-mail]; [e-mail]; 
> draft-ietf-jose-json-web- [e-mail]
> Subject: Re: [jose] Pete Resnick's Discuss on 
> draft-ietf-jose-json-web-signature-
> 33: (with DISCUSS and COMMENT)
> 
> Thanks for your review, Pete.  I've added the working group to the thread.
> Replies are inline below...
> 
> > -----Original Message-----
> > From: Pete Resnick [mailto:[e-mail]]
> > Sent: Wednesday, October 01, 2014 9:14 PM
> > To: The IESG
> > Cc: [e-mail]; draft-ietf-jose-json-web- 
> > [e-mail]
> > Subject: Pete Resnick's Discuss on
> > draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
> >
> > Pete Resnick has entered the following ballot position for
> > draft-ietf-jose-json-web-signature-33: Discuss
> >
> > When responding, please keep the subject line intact and reply to 
> > all email addresses included in the To and CC lines. (Feel free to 
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to
> > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/
> >
> >
> >
> > --------------------------------------------------------------------
> > --
> > DISCUSS:
> > --------------------------------------------------------------------
> > --
> >
> > 3.1: Why can't I use an unprotected header when I'm using the 
> > Compact Serialization? This seems like a real problem, since I can't 
> > convert (in a round- trippable way) between a JWS with an 
> > unprotected header in the JSON Serialization to a Compact Serialization. Why the limitation?
> 
> As Richard explained during the telechat, this was a deliberate choice 
> on the part of the working group to keep the compact form as simple as 
> possible by removing some options.  Do I remember correctly that you 
> said on the telechat that you would be willing to withdraw this DISCUSS on that basis?
> 
> > 5.2:
> >
> > Strike the last sentence of the second paragraph. There's no 
> > requirement here. If none of them validate, I can do what I want 
> > with the JWS. I needn't "reject" it. I might just mark it as "invalid".
> >
> > [Get rid of all talk of "rejecting" throughout this document. Again, 
> > I will note that the signatures are not valid, but rejecting is a 
> > local implementation detail.]
> 
> As discussed during the telechat and on subsequent threads, the terms "accept"
> and "reject" are commonly used in this way, for instance, in RFC 5820.  
> As Kathleen wrote after the call, "For the "reject" language, Pete 
> said on the call that he would go through each one to see where it 
> might be application specific and will suggest changes.  Thanks in advance, Pete.".
> 
> > This section would be greatly simplified if step 1 was: "If the 
> > Compact Serialization is being used, convert it to the JSON Serialization."
> 
> This would be doing a disservice to some implementers, since some 
> implementations (for instance those designed to support JWTs) will 
> only implement the Compact Serialization.  I therefore request that 
> you withdraw this DISCUSS on that basis.
> 
> > Some of these steps are not steps. I could not follow this to figure 
> > out what to do. This section could use a serious rewrite. I'm glad 
> > to work with you on that, but did not have time to provide a rewrite 
> > during my
> review.
> 
> This section has been heavily wordsmithed already by numerous 
> reviewers.  That said, I'd be glad to receive suggestion for specific proposed changes.
> 
> > 8: This section needs to be removed. There is no need for TLS in a 
> > whole host of applications that could implement this protocol.
> 
> As discussed in threads that immediately followed your review, I 
> propose to clarify to which specific features ("jku" and "x5u") this section applies.
> 
> > --------------------------------------------------------------------
> > --
> > COMMENT:
> > --------------------------------------------------------------------
> > --
> >
> > 2. A "JSON Web Signature Signature" is an unfortunate terminology choice.
> > If there is a whole *thing* that is the combination of the header, 
> > the signature, and the payload, perhaps that should have been a 
> > "JOSE Web Object", or better yet a "JOSE Object". Then you could 
> > simply have "JOSE Signature", "JOSE Payload", and "JOSE Header". I'm 
> > also unclear why the word "Web" appears in each of these things -- 
> > except "JOSE Header", which I find equally strange. They should not 
> > just be for use on the Web. This whole "JW*" terminology thing is goofy.
> 
> See my response to your JWT review for the etymology of the "JSON Web ..."
> terminology.  The "JWS" prefixes on some terms are there to indicate 
> that the defined term is being used in specific way (such as "JWS 
> Signature") versus a generic way (such as "signature").
> 
> > 3. "JWS object" is undefined. Do you just mean a JWS?
> 
> Yes, the meaning is the same.  Sometimes the word "object" is included 
> in locations that it seems to improve the readability of the text.
> 
> > Please reverse the order of section 3.1 and 3.2.
> 
> The order is intentional.  The simple serialization is intentionally 
> presented before the more general, more complicated serialization.
> 
> > 3.2:
> >
> >    In the JWS JSON Serialization, a JWS object is represented as the
> >    combination of these four values,
> >       BASE64URL(UTF8(JWS Protected Header)),
> >       JWS Unprotected Header,
> >       BASE64URL(JWS Payload), and
> >       BASE64URL(JWS Signature)
> >
> > Why is the Payload (a) part of the serialization and (b) base64ed? 
> > Are you saying that the only way I can use JWS is to include the 
> > payload as part of the JOSE object? Why can't it be a separate 
> > thing? Also, why does it
> have to be base64ed?
> > It could be a UTF-8 string, or it could be a large binary object 
> > that I'm using in a non-JSON context, neither of which I want to 
> > bloat by base64ing it. This seems bogus.
> 
> It is base64url encoded because JSON has no way of representing 
> arbitrary octet sequences.  This enables the "binary object" case that you're describing to work.
> Also note that this was extensively discussed by the working group in 
> the context of issue #26 http://trac.tools.ietf.org/wg/jose/trac/ticket/26.
> 
> > 3.3:
> >
> > OLD
> >    The following example JWS Protected Header declares that the encoded
> >    object is a JSON Web Token (JWT) [JWT] and the JWS Protected Header
> >    and the JWS Payload are secured using the HMAC SHA-256 [RFC2104, SHS]
> >    algorithm:
> >
> > There's a could of typos in there. I think you meant:
> >
> > NEW (1)
> >    The following example JWS Protected Header declares that the encoded
> >    object is a JSON Web Token (JWT) [JWT] and the JWS Payload is secured
> >    using the HMAC SHA-256 [RFC2104, SHS] algorithm:
> >
> > However, I'm not clear why that's an example of a *Protected* Header.
> > Looks like it could be any old header. So I think better is:
> >
> > NEW (1)
> >    The following example JOSE Header declares that the encoded object is
> >    a JSON Web Token (JWT) [JWT] and the JWS Payload is secured using the
> >    HMAC SHA-256 [RFC2104, SHS] algorithm:
> >
> > Then you would fix:
> >
> > OLD
> >    Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
> >    Header)) gives this value:
> > NEW
> >    If this were a JWS Protected Header, the encoding of
> >    BASE64URL(UTF8(JWS Protected Header)) gives this value:
> >
> > This one:
> >
> >    Encoding this JWS Payload as BASE64URL(JWS Payload) gives this 
> > value
> 
> Both the JWS Payload and the JWS Protected Header *are* 
> integrity-protected, hence the inclusion of the "JWS Protected Header" language in the description.
> 
> > I'll get back to in Section 5. Finally:
> >
> >    Concatenating these values...
> >
> > This section is not about the compact serialization. If you want to 
> > give both example serializations in this section, fine, but if you 
> > are giving a general "Example JWS" as the title of the section 
> > states, don't just give
> the compact.
> 
> The point is to give a simple example to familiarize readers with the 
> idea of a JWS - not for the example section to be a complete tutorial on the possibilities.
> Note, however than an example using the JSON Serialization *is* 
> present in Appendix A.6 and many are present in 
> http://tools.ietf.org/html/draft-ietf-jose-
> cookbook-03.
> 
> > 4.1.1/4.2: Why even bother mentioning that the alg could be a
> > "Collision- Resistant Name" (what a term!)? The alg should be registered.
> > If it's not, you're in private agreement space anyway, so it needn't 
> > be specified in the spec. Same thing for Public Header Parameter
> > Names: If you're going to do this interoperably, you're going to 
> > have to know what the thing means; otherwise, it's out of band 
> > anyway. I say get rid of the whole concept of using non-registered names.
> 
> Per the response to a similar comment in Stephen Kent's secdir review:
> 
> This specification will be used both in open environments, in which 
> multiple organizations will need to have a common understanding of any 
> extensions used, and closed environments, which the producing and 
> consuming organization will always be the same and private values could be safely used.
> IANA registration is definitely the right thing to do for open 
> environments.  It’s probably unnecessary for deployments in closed environments.
> 
> > 4.1.9 (and elsewhere): "Sender" is the wrong term here. (Same with
> > "recipient".) "Generators" and "interpreters" seems much better.
> 
> Thanks.   What about using the terms "producers" and "consumers"?
> 
> > 5.1: s/MUST perform/performs
> 
> I don't think I understand the motivation for this suggested change.  
> All the steps must be performed...
> 
> >   2. Why is BASE64URLing the payload required? If I want to use a 
> > binary payload, or something that I know is a string, why not just use it as-is?
> > The encoding of the payload should be application dependent.
> 
> See my response to your comment on the same issue in Section 3.2.
> 
> >   3. There might not be a Protected Header. Better to say "the JWS 
> > Protected Header and/or the JWS Unprotected Header, as appropriate."
> 
> Thanks
> 
> >   4. Strike the parenthetical "(which can only happen...)". Sounds 
> > like you are discouraging use of the JSON Serialization and the 
> > Unprotected
> Header.
> 
> It's not pejorative - it's intended to be informative to implementers.
> 
> >   5. Again, why BASE64URL the payload? Also, I don't understand the 
> > need for the second sentence. Please explain.
> 
> The same answer applies as to the previous times this question was asked.
> 
> >   7 is not a step that you MUST perform.
> 
> You're right.  I'll consider whether text of this form needs to 
> remain, and if so, how to write it in an actionable fashion.
> 
> >   9. Replace with "Create the desired serialized output, as 
> > described in Section 7." Stop privileging Compact.
> 
> The fact is that the Compact Serialization is (intentionally!) simple 
> enough it can be fully described in the single sentence.  Same cannot 
> be said of JSON Serialization, hence the need for the section reference.
> 
> > 5.2: s/MUST be taken/are performed.
> 
> Same response as to your related comment on 5.1
> 
> > 5.3: I don't understand why this section is necessary.
> 
> String comparison rules are necessary both for interoperability and 
> security.  If comparisons of security-sensitive elements were done 
> differently by different implementations, that would result in an ample attack surface.
> 
> 				Thanks again,
> 				-- Mike
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose