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

On 3/23/11 10: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 :)
>

I'm not familiar with trailer processing, but its something I would look 
into.

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

IMO, this should be left up to the application.  How the signing 
principal is defined and recognized.

>   * 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).
>
>   * Base64 encoding saves a few more bytes over hex.
>

For some reason I thought base64 used cr\lf after 76 bytes.  At least 
the impl I used did.  I'll use base64 in next draft.


Speaking of a next draft, do I just resubmit through:

https://datatracker.ietf.org/idst/upload.cgi

Or is there some other process?

Thanks,

Bill

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

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