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

Question:

I'm very unfamiliar with the whole IETF process.  How do I submit new 
draft versions?  Maybe I'm just stupid, but I couldn't figure out a way 
to do this.

Also, where should I ping for feedback on this?  CC ietf-http-wg@w3.org? 
  You also suggested the HTTPbis email list in a prior email.

More comments inline.


On 3/22/11 8:38 PM, Mark Nottingham wrote:
> <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.
>

Chad La Joie encouraged me to submit this.  Also, one of my users 
requested a feature like this.  I hope to get some feedback on how it 
works in the wild.


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

Sure.  I'm not married to any name.

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

IMO, only headers that can be retransmitted as-is should be a default. 
I want signatures (and the signed content) to be able to be forwarded to 
multiple parties multiple times.  Correct me if I'm wrong, but Date will 
change each time the signature/representation is forwarded to a new 
party?  Same could be said for Cache-Control, etc.

Originally I had Content-Type as a default, but changed my mind as I 
didn't see why it mattered or not.


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

Ok.

> * 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."
>

Doesn't the Date header change each time a request is made?

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

I wanted the option to keep the algorithm secret and understood between 
parties.  Maybe this doesn't matter as a hacker would try all known 
algorithms anyways.


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

I'd like to keep the signer field opaque.  That way you can put a URI, 
or just some arbitrary string.  One of the use cases I have for this is 
authentication in a workflow environment, and a URI might not be 
appropriate for these scenarios.

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

I don't understand what you mean here.  Do you mean why not just add all 
metadata to the signature hash calculation?

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

Too bad.  I liked that terminology.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Received on Sunday, 27 March 2011 13:06:17 UTC