Feedback on draft-burke-content-signature-00.txt

<http://www.ietf.org/internet-drafts/draft-burke-content-signature-00.txt>

Bill,

First of all, I'm very excited that somebody has finally picked up the ball on this; it's been discussed for a long time.

Some thoughts, in no particular order:

* The Content-Signature header field-name, along with the various parameter names in its value, are quite lengthy. Can I suggest just "Sig" for the field-name, and correspondingly shorter parameter names? Saving bytes will help deployment.

* I'd argue that there are some HTTP headers which, if present, should always form part of the signature, both because they're an intrinsic part of the message, and because doing so will (again) save bytes in these common cases. Content-Type is the most important, but Date, Expires, Cache-Control, ETag, Last-Modified, P3P, and Warning may also be suitable.

The important thing here is to figure out a reasonable default that works for most cases, so that they can save the bytes and verbosity. If necessary, maybe an opt-out for these common headers could be defined.

* It'd be good to have a way to include the request-target (i.e., the result of combining the host header and the request-line) in a request's signature, and the status code in a response signature. 

* I can think of a few cases where it's important to NOT sign the body, but still sign some headers, etc.

* The timestamp parameter's purpose is defined as "this gives the receiver the option to refuse old signed messages." In some implementations, that purpose could be better served by signing the Date header, so maybe say something like "this allows signing messages before they're actually generated."

BTW, one cool use case is that signing the Date, Cache-Control and Expires headers enables clients to verify that the caching policy has been honoured by intermediaries.

* A little bit more needs to be said about header canonicalisation; at a minimum, an algorithm for stripping whitespace and combining multiple header field-values needs to be defined, taking into account that intermediaries can modify message headers in certain ways.

* What algorithm is used if the algorithm parameter is missing? Also, at least one algorithm should be pre-defined, to improve interop.

* There currently isn't any structure to the signer field. What about putting a URI there, or specifying a parameter for one, so that the public key can be discovered? I know this is highly algorithm-specific, but IMO most / all algorithms should have a way to discover the key, so as to encourage decoupling.

* Can you speak to why you included the ability to put non-signature metadata in the field-value, rather than just signing it as the payload of other headers? 

* It would be friendly to include a warning that hop-by-hop headers should not be included in a signature, and to remind people that headers which are allowed to be modified by an intermediary (e.g., Age) are also probably not wise.

* NIT - Throughout, you use "entity header." In HTTPbis, we've just moved away from this terminology; it should just be "header" now.

* NIT - In a few places, you say "server" where "recipient" would be more appropriate.

* NIT - It's important to clearly specify that the payload body is being signed, not the bytes on the wire. See <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13#section-3.3>.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 23 March 2011 00:39:03 UTC