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

FWIW, my experience from developing and implementing HTTP request signatures in OAuth 1.0 [1] and HTTP MAC authentication [2] is that canonicalization of header fields is most likely doomed.

At least on the consumer web front, developers are moving away from having anything to do with signatures and simply relying on TLS. My HTTP MAC authentication draft represents the most the OAuth community is willing to swallow, and even that unenthusiastically.

EHL

[1] http://tools.ietf.org/html/rfc5849
[2] http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02


> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
> On Behalf Of Thomson, Martin
> Sent: Wednesday, March 23, 2011 7:42 PM
> To: Mark Nottingham; Bill Burke
> Cc: HTTP Working Group
> Subject: RE: Feedback on draft-burke-content-signature-00.txt
> 
> 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 :)
> 
>  * 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.
> 
>  * 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.
> 
>  * [NIT] I would not have seen this draft if it weren't for Mark's email.  I'd
> suggest adding a -http- to the name.
> 
>  * [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)
> 
>  * [NIT] Take a look at an existing IANA registry for signature method
> identifiers and use that.  TLS [1] or DKIM [2] might be a little too abstract, but
> keynote [3] looks promising, though it has an unfortunate encoding
> component bound to each identifier.
> 
> I'm going to agree with the bulk of what Mark says.  More inline...
> 
> Cheers,
> Martin
> 
> [1] http://www.iana.org/assignments/tls-parameters/tls-parameters.xml
> [2] http://www.iana.org/assignments/dkim-parameters/dkim-
> parameters.xml
> [3] http://www.iana.org/assignments/keynote/keynote.xml
> 
> On 2011-03-23 at 11:38:31, Mark Nottingham wrote:
> > <http://www.ietf.org/internet-drafts/draft-burke-content-signature-
> > 00.txt>
> >
> > Bill,
> >
> > First of all, I'm very excited that somebody has finally picked up the
> > ball on this; it's been discussed for a long time.
> >
> > Some thoughts, in no particular order:
> >
> > * The Content-Signature header field-name, along with the various
> > parameter names in its value, are quite lengthy. Can I suggest just
> > "Sig" for the field-name, and correspondingly shorter parameter names?
> > Saving bytes will help deployment.
> >
> > * 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.
> >
> > The important thing here is to figure out a reasonable default that
> > works for most cases, so that they can save the bytes and verbosity.
> > If necessary, maybe an opt-out for these common headers could be
> defined.
> 
> Hmm:
>    Content-Sig: header=Host;-Content-Type
> 
> > * It'd be good to have a way to include the request-target (i.e., the
> > result of combining the host header and the request-line) in a
> > request's signature, and the status code in a response signature.
> >
> > * I can think of a few cases where it's important to NOT sign the
> > body, but still sign some headers, etc.
> 
> Another possible use is an intermediary that inserts, then signs an X-
> Forwarded-For header to limit spoofing.  This can be done on a clear-text
> bearer.
> 
> > * 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."
> >
> > BTW, one cool use case is that signing the Date, Cache-Control and
> > Expires headers enables clients to verify that the caching policy has
> > been honoured by intermediaries.
> >
> > * A little bit more needs to be said about header canonicalisation; at
> > a minimum, an algorithm for stripping whitespace and combining
> > multiple header field-values needs to be defined, taking into account
> > that intermediaries can modify message headers in certain ways.
> 
> Some guidance on this last part is probably useful.  Identifying the headers
> that intermediaries invariably change is probably important (see Mark's hop-
> by-hop comment below).
> 
> > * What algorithm is used if the algorithm parameter is missing? Also,
> > at least one algorithm should be pre-defined, to improve interop.
> >
> > * 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.
> 
> To expand on this, there should be one baseline with a clearly defined
> mechanism for discovering the key.  Without that, this becomes little more
> than a curiosity.
> 
> > * 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?
> >
> > * It would be friendly to include a warning that hop-by-hop headers
> > should not be included in a signature, and to remind people that
> > headers which are allowed to be modified by an intermediary (e.g.,
> > Age) are also probably not wise.
> >
> > * NIT - Throughout, you use "entity header." In HTTPbis, we've just
> > moved away from this terminology; it should just be "header" now.
> >
> > * NIT - In a few places, you say "server" where "recipient" would be
> > more appropriate.
> >
> > * NIT - It's important to clearly specify that the payload body is
> > being signed, not the bytes on the wire. See
> > <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13#section
> > -
> > 3.3>.
> >
> > Cheers,
> >
> > --
> > Mark Nottingham   http://www.mnot.net/
> >
> >
> >
> 
> 
>

Received on Thursday, 24 March 2011 05:02:42 UTC