Thanks for your review, Jim. I've attempted to address your comments in the -01 version. Responses are inline below.
-----Original Message----- From: jose [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Sunday, August 02, 2015 9:02 PM To: [email protected] Cc: [email protected] Subject: [jose] draft-jones-jose-jws-signing-input-options 00 The following represents my review of the document. * The justification for this document seems to be rather odd. There is a problem with the "compact" form of JWS and the fact that the bodies are too large. This seems to be rather contradictory. Why would having a compact form be the case that is having problems with size This is about both serializations and the motivating problems can occur in both. I've added a JWS JSON Serialization example in -01. * Abstract - second paragraph is a restatement of the first paragraph - this is unnecessary. Thanks - simplified. * There is only one API that I am aware of that does not support an "Initialize, Update and Finalize" API for dealing with hash functions. That is the W3C WebCrypto API. Are there others that have the same issue? Does the W3C have plans to change this so that hashing is not an atomic operation? "sph" is gone by popular demand now, so this is no longer pertinent. * I don't know about Phil, but Anders wants to have clear signed for debugging purposes among other things. He just wants to be able to read the message w/o the base64 decoding issues. Nothing to do with what you are suggested the reasons are. I don't know that either of them are interested in the compact serializations. The fact that you are not removing the base64 encoding on the transmitted protected header means that you are not getting all of his issues solved with this approach. He can do that if he uses "b64":false and "header" rather than "protected" with the JWS JSON Serialization. * You have a major security problem with this proposal SIGN({"sph":false, "b64":false}, "ABC") === SIGN("sph":false, "b64":true"}, "ABC") But I did not sign the same content. There are lots of other ways that you can play games. Consider for example putting all of the message, with periods, in the body and say don't sign the object. It would still have the same signature but totally different meanings. "sph" is gone, so this is no longer pertinent. * If the values of sph and b64 are going to be fixed by the application and are not intended to be changed on a per message basis, why are they even parameters? So that the encodings are explicit. If "b64":false is omitted but assumed, some are sure to use standard JWS libraries without the extension to emit and consume the JWSs, causing interop problems. * Given that a double-quote will be quoted if contained in a string for json serialization, I don't understand the delimiter issue for it. You are signing the in memory representation and not the JSON serialized version. This entire issue needs far better text than it has. The better text is in the new section https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-01#section-5. * How do I go back and forth between compact and non-compact representations if I am signing w/o b64 and there is a period in the message. It does not seem to be possible. The last paragraph of Section 5 addresses this explicitly. * 7.2 para #2- what is the second property? The first is changes in payload transmission The other is restricting the characters used to those that can be successfully parsed. Thanks again, -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
