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

On 24/03/2011, at 1:42 PM, Thomson, Martin wrote:

> I'm similarly pleased by the effort.  More people are looking for this functionality recently (I'd go spruiking in the ALTO working group, for one).
> 
> Just adding a few comments of my own:
> 
> * Signatures in trailers are a distinct (and useful) option, particularly for sizeable or dynamic streamed content.  (That came from ALTO :)

+10 -- many of my use cases would benefit from that. AFAICT nothing in the draft precludes it.

> * How you identify the signing principal is a critical aspect of the document that is only given superficial treatment.  I'd go a good deal beyond Mark's comments and say that you have a lot of missing detail in this area.  For instance, does a relying party need to be able to determine who they expect a signer to be for a given resource?  There's a lot of existing PKI infrastructure that is already in use for HTTPS that I'd imagine people would be happy to use in many cases, but that might be too restrictive for others.  How a client principal is identified is an even more challenging prospect.

I was thinking that this *could* be linked to the algorithm definition. Not sure if that's a good idea, but it could.

> * Your concatenation method for signing should include delimiters for values.  Concatenating "abc" and "def" is otherwise identical to "a", "b", "c", and "def".  Set up a concatenation operator that handles this case (and be aware that some delimiters could appear in headers...and any delimiter can appear in a body).

+1 

> * [NIT] Header syntax is defined using RFC 5234 syntax in the HTTPbis drafts.  Have a look at that syntax (it doesn't use #, for instance)

People are using the 2616 syntax until bis goes through, so it's OK either way, I think.


Cheers,



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

Received on Thursday, 24 March 2011 05:06:23 UTC