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

["Richard Barnes" <[e-mail]>]

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).


----------------------------------------------------------------------
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