W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

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

From: Thomson, Martin <Martin.Thomson@commscope.com>
Date: Mon, 28 Mar 2011 14:48:13 +0800
To: Bill Burke <bburke@redhat.com>
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B925B@SISPE7MB1.commscope.com>
On 2011-03-24 at 17:01:53, Bill Burke wrote:
> >   * 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.

That's going to make the extension less useful on the whole, but I can understand why you might like to avoid that - it's a headache.
 
> >   * 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.

That's a common misconception :) 
 
> Speaking of a next draft, do I just resubmit through:
> 
> https://datatracker.ietf.org/idst/upload.cgi

Yeah, just submit -01.
Received on Monday, 28 March 2011 06:48:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:37 GMT