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

[ sorry for answering a little out of order ]

On 23/03/2011, at 9:53 PM, Bill Burke wrote:

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

As Chad mentioned, you just resubmit, while incrementing the version. Note that submission isn't allowed this week; the queue is closed right before IETF meetings, so people have a chance to review them beforehand. <https://datatracker.ietf.org/idst/upload.cgi> is the right place.


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

That's fine.


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

Date definitely does, so it's only useful when the signing is done as part of the serving engine. 

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

Content-Type is intrinsic to the interpretation of the payload; e.g., without it, privilege escalation can take place.

Maybe it would make sense to define a common suite of headers to sign and allow it to be indicted with a flag, rather than enumerating them.


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

As above, yes. I'm thinking of cases where the serving engine itself signs responses.


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

Doing that makes the message less self-describing; you need external information to correctly interpret it. 

What about tying the interpretation of the signer field to the algorithm in use, so it specifies how do the lookup?


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

No. What I mean is that in well-behaved HTTP applications, metadata is in a header, and if it stands on its own, it gets its own header.

What I should have asked is whether you see the extra metadata that the signature format allows as specific to the signature, or general (i.e., applicable to the whole message). If it's the latter, it should probably just be a header.

Cheers,


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

Received on Thursday, 24 March 2011 17:39:25 UTC