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

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

Explicit rules (enumeration) makes for less mistakes in implementation, 
but maybe saving transmition bytes is more desirable.

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

signer principal is orthogonal to algorithm.  Again, I think it should 
be opaque, or, have a separately defined field named "public-key-uri" or 
something like that.

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

It would be either or both signature specific or general.  The spec is 
flexible enough to leave these things up to the application.

I also see the scenario where the application wants to associate 
metadata with a specific signer/principal.  A Content-Header could have 
multiple signatures each with their own values for the same type of 
metadata.  If a representation is hopping multiple times, like in a 
workflow, different principals can attach their own specific metadata to 
the request and guarentee integrity (and identity) through a signature. 
  I hope I'm making sense here.


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

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