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

[Mike Jones <[e-mail]>]

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