On Thu, Oct 2, 2014 at 2:25 PM, Jim Schaad <[email protected]> wrote:
> > > -----Original Message----- > From: Richard Barnes [mailto:[email protected]] > Sent: Wednesday, October 01, 2014 9:22 PM > To: The IESG > Cc: [email protected]; [email protected]; > [email protected] > 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 > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
