Re: [jose] Ted Lemon's No Objection on draft-ietf-jose-json-web-signature-33: (with COMMENT)

[Mike Jones <[e-mail]>]

The resolutions proposed below have been incorporated in the -34 draft.

				Thanks again,
				-- Mike

> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Monday, October 06, 2014 12:54 AM
> To: Ted Lemon; The IESG
> Cc: [e-mail]; draft-ietf-jose-json-web-
> [e-mail]; [e-mail]
> Subject: RE: Ted Lemon's No Objection on draft-ietf-jose-json-web-signature-
> 33: (with COMMENT)
> 
> Thanks for the review, Ted.  I've added the working group to the thread so
> they're aware of your comments.
> 
> > -----Original Message-----
> > From: Ted Lemon [mailto:[e-mail]]
> > Sent: Thursday, October 02, 2014 6:36 AM
> > To: The IESG
> > Cc: [e-mail]; draft-ietf-jose-json-web-
> > [e-mail]
> > Subject: Ted Lemon's No Objection on draft-ietf-jose-json-web-signature-33:
> > (with COMMENT)
> >
> > Ted Lemon has entered the following ballot position for
> > draft-ietf-jose-json-web-signature-33: No Objection
> >
> > 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/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > The following sample text is encoded assuming a CR+LF line terminator:
> >
> > {"typ":"JWT",
> >   "alg":"HS256"}
> >
> > I think it would be better to just encode it as a single line, as was
> > done in the JWE spec, so as to avoid confusing people who use operating
> > systems that use the single-character line ending ("newline").   I
> > suspect this applies to other examples as well.   If you have to go
> > multiline, you could also address this by just saying "line separators
> > in examples are CR+LF ([13, 10])".
> 
> Quoting your response to your own message so the working group will also see
> it:
> "This is actually covered in the Appendix, so I don't think it's necessary to make
> the change I suggest here.   Sorry for the confusion."
> 
> > This looks like an attack surface:
> >
> >    The Header Parameter names within the JOSE
> >    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].
> >
> > Is this really safe?
> 
> Quoting Kathleen's response on the thread so the working group will see it:
> "I pointed to a thread on this in the ballot text, so thanks for weighing in.  This
> has been a hot discussion in the WG and is unresolved as to how it should be
> handled.  This discussion seems to be happening on Pete's Abstain, so let's see if
> we can keep it there for now and this as a placeholder.  It comes down to
> implementation issues and a decision as to how we should best handle it.
> Thanks."
> 
> > I believe you mean "base64 padding characters" here:
> >
> >   2.   The encoded representation of the JWS Protected Header MUST be
> >         successfully base64url decoded following the restriction that no
> >         padding characters have been used.
> >
> > I mention this because I don't think you require that no whitespace
> > characters be present in the encoded JWS protected header, and someone
> > might read this text that way.   This concern exists in several other
> > paragraphs in this document, and also in the JWE document.   I don't know
> > if it's worth dealing with, but it seems like it might make peoples'
> > lives easier if you stated explicitly that you are talking about /base64/ padding.
> 
> Thanks for pointing this out.  I believe that it's referring both to base64 padding
> characters and whitespace.  I'll plan to reword this to make the intent clear.
> 
> > Why not just make this a requirement of JWE:
> >
> >    o  Require that the "alg" Header Parameter be carried in the
> >       protected header.  (This is always the case when using the JWS
> >       Compact Serialization and is the approach taken by CMS
> > [RFC6211].)
> >
> > Relying on the application to get this right seems chancy.
> 
> This point was raised in Tero Kivinen's secdir review as well.  Richard Barnes led
> a thorough discussion of the topic.  The result was the inclusion of the Security
> Considerations text in Section 10.7 (Algorithm Protection).
> 
> > This document has a really great security considerations section.
> > Thanks for being so thorough and clear.
> 
> Thanks.  A lot of smart and knowledgeable people have contributed to it.
> Thanks for your contributions as well.
> 
> 				-- Mike
>