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

[Richard Barnes <[e-mail]>]

On Thu, Oct 2, 2014 at 2:25 PM, Jim Schaad <[e-mail]> wrote:

>
>
> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]]
> Sent: Wednesday, October 01, 2014 9:22 PM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33:
> (with DISCUSS and COMMENT)
>
> Richard Barnes 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:
> ----------------------------------------------------------------------
>
> Overall, this document is in much more solid shape than when it began.
> Thanks to the WG for a lot of hard work.  I only have two remaining
> concerns, which should hopefully be easy to address.
>
> Section 7.2.
> I've had several implementors trying to use JWS in the JSON serialization
> ask why it was necessary to include a "signatures" array in cases where
> there's only one signer.  It seems like this is going to be a major barrier
> to deployment and re-use, so I would propose including the following text:
>
> """
> In cases where the JWS has been signed by only a single signer, the
> "signatures" array will contain a single object.  In such cases, the
> elements of the single "signatures" object MAY be included at the top level
> of the JWS object.  A JSON-formatted JWS that contains a "signatures" field
> MUST NOT contain a "protected", "header", or "signature" field, and vice
> versa.
> """
>
> This may also require some other changes where "signatures" is relied on,
> e.g., in Section 9 of the JWE spec.
>
>
> Section 6.
> """
> These Header Parameters MUST be integrity protected if the information
> that they convey is to be utilized in a trust decision.
> """
> This smells really fishy to me.  What's your attack scenario?  I'm pretty
> certain that there's no way any of these fields can be altered in such a
> way that (1) the signature will validate, and (2) the recipient will accept
> a key it shouldn't.  By way of contrast, CMS doesn't sign the certificate
> fields, and the Certificate payload in TLS is only signed as a side effect
> of the protocol's verification that the remote end has been the same
> through the whole handshake (which doesn't apply here).
>
> [JLS] There were a couple of attacks that were created for CMS based on
> using the SKI as the identifier in CMS.  There now exists a signed
> attribute for CMS to deal with this problem.   IMO the pointer the
> certificate probably should be a required signing field in CMS
>

Citation?



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 2.
> In the definition of "Unsecured JWS", it would be good to note that this
> requires "alg" == "none".
>
> Section 3.3.
> Why doesn't this section have a JSON-encoded form as well?
>
> Appendix A.5.
> I would prefer if this example could be removed.  JWT is the only use case
> for Unsecured JWS right now, and there's already an example in that
> document.
>
> Thanks for Appendix C.  FWIW, it has been implemented:
>
> http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoBuffer.cpp#85
>
>
>