The resolutions proposed below have been incorporated in the -34 draft.
Thanks again,
-- Mike
> -----Original Message-----
> From: Mike Jones [mailto:[email protected]]
> Sent: Monday, October 06, 2014 12:54 AM
> To: Ted Lemon; The IESG
> Cc: [email protected]; draft-ietf-jose-json-web-
> [email protected]; [email protected]
> 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:[email protected]]
> > Sent: Thursday, October 02, 2014 6:36 AM
> > To: The IESG
> > Cc: [email protected]; draft-ietf-jose-json-web-
> > [email protected]
> > 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
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
