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

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Mar 2011 11:38:31 +1100

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

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

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

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

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 24 Mar 2011 10:42:18 +0800

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

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 - 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,
> 
> --

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 23 Mar 2011 22:01:56 -0700

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: [email-masked] [mailto:[email-masked]]
> 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).
> 
>  * 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).
> 
>  * [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.
> 
> 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.
> 
> 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).
> 
> 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.
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Mar 2011 16:05:51 +1100

> * 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 mis…

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 tha…

+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,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Mar 2011 16:06:56 +1100

TLS everywhere has its own galaxy of issues (one of which has been recently highlighted!). I think there are enough use cases for this to make it interesting.

Cheers,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 23 Mar 2011 23:47:45 -0700

Sure. But there are enough real world deployment issues (frameworks, proxies, broken servers) which render canonicalization of request/response headers pretty much a lost cause. I think a standard way to sign HTTP messages is important, but there should be clear security reasons for normalizing and signing headers (are there actual attacks based solely on changing the header that cannot be prevented with a slightly more intelligent application logic?).

No matter what the use cases are, most signature algorithm requiring complex canonicalization of data have failed the test of widespread adoption, so before we produce yet another such solutions, we should figure out if this complexity adds real value.

Also, verification of the body should be possible independently from the header (i.e. optional on both sides).

EHL

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Wednesday, March 23, 2011 10:07 PM
> To: Eran Hammer-Lahav
> Cc: Thomson, Martin; Bill Burke; HTTP Working Group
> Subject: Re: Feedback on draft-burke-content-signature-00.txt
> 
> TLS everywhere has its own galaxy of issues (one of which has been recently
> highlighted!). I think there are enough use cases for this to make it
> interesting.
> 
> Cheers,
> 
> 
> > 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
> >
> >> 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).
> >>
> >> * 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.
> >>
> >> 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).
> >>
> >> * [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.
> >>
> >> 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.
> >>
> >>> 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.
> >>>
> >>> * 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.
> >>>
> >>> * 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
> >> 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.
> >>
> >>> Date header, so maybe say something like "this allows signing
> >>> messages before they're actually generated."
> >>>
> >>> 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.
> >>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Mar 2011 17:51:18 +1100

To be clear -- this isn't a WG item, it's a side effort that's using the list for feedback (as many HTTP-related projects do).

So, there's no "we" producing the specification, in an IETF WG sense. If Bill wants to submit a draft, implement it, and take feedback from interested folks, nothing here can (or should) stop him.

That being the case, why not specify it and let the market decide? 

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Mar 2011 04:38:49 +1100

[ sorry for answering a little out of order ]

On 23/03/2011, at 9:53 PM, Bill Burke wrote:

> Question:
> 
> I'm very unfamiliar with the whole IETF process.  How do I submit new draft versions?  Maybe I'm just stupid, but I couldn't figure out a way to do this.

As Chad mentioned, you just resubmit, while incrementing the version. Note that submission isn't allowed this week; the queue is closed right before IETF meetings, so people have a chance to review them beforehand. <https://datatracker.ietf.org/idst/upload.cgi> is the right place.

> Also, where should I ping for feedback on this?  CC [email-masked]?  You also suggested the HTTPbis email list in a prior email.

That's fine.

> IMO, only headers that can be retransmitted as-is should be a default. I want signatures (and the signed content) to be able to be forwarded to multiple parties multiple times.  Correct me if I'm wrong, but Date will change each time the signature/representation is forwarded to a new party?  Same could be said for Cache-Control, etc.

Date definitely does, so it's only useful when the signing is done as part of the serving engine. 

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

> Doesn't the Date header change each time a request is made?

As above, yes. I'm thinking of cases where the serving engine itself signs responses.

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

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

Cheers,

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 25 Mar 2011 10:29:17 -0400

Hi Eran,

--On March 23, 2011 11:47:45 PM -0700 Eran Hammer-Lahav 
<[email-masked]> wrote:

> No matter what the use cases are, most signature algorithm requiring
> complex canonicalization of data have failed the test of widespread
> adoption, so before we produce yet another such solutions, we should
> figure out if this complexity adds real value.

Please take a look at DKIM which does this for email (and reasonably well 
by most accounts). In fact my preference here is to use DKIM for HTTP as 
well. Whilst DKIM is currently used for email it was designed to be 
generally applicable to similar protocols - in fact we are planning on 
using it for iTIP-over-HTTP (iSchedule: 
<http://tools.ietf.org/id/draft-desruisseaux-ischedule-01.txt>). It would 
be good to be able to utilize the existing infrastructure and experience 
from DKIM in HTTP.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Mar 2011 15:39:09 +0100

Cyrus Daboo wrote:

> Please take a look at DKIM which does this for email (and reasonably 
> well by most accounts). In fact my preference here is to use DKIM for 
> HTTP as well. Whilst DKIM is currently used for email it was designed 
> to be generally applicable to similar protocols - in fact we are 
> planning on using it for iTIP-over-HTTP (iSchedule: 
> <http://tools.ietf.org/id/draft-desruisseaux-ischedule-01.txt>). It 
> would be good to be able to utilize the existing infrastructure and 
> experience from DKIM in HTTP.

+1.
Dave Crocker is going to make a presentation on a more generalized DKIM 
in the Apps Area on Monday, March 28th.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Mar 2011 08:21:18 -0700

Reusing an existing (working) mechanism is always a good idea.

Understanding the use cases for signing random headers is important. Email and HTTP are very different when it comes to deployment. Yes, both suffer from similar issues with intermediaries, and HTTP headers are similar to those of SMTP, but DKIM operates in a much friendlier environment, and a much smaller development range.

If this solution can only be fully implemented at a very low level - right above HTTP as even as part of the HTTP layer - most developers will not be able to use it for a long time. I know this group likes to dismiss real-world considerations, and sometimes that's the right approach for making progress, but there is an opportunity here to provide a useful solution that is widely applicable.

Some may say that if the consumer web world (e.g. Twitter, Facebook, Yahoo, Google, etc.) doesn't use this because it too complex or too hard to deploy with all the existing crappy framework used, that's ok. Maybe it is. But it only means that people will continue to come up with yet new ways to accomplish pretty much the same thing. Oh well.

OAuth 1.0 and the 2.0 companion MAC token specs both sign HTTP requests in a limited way that is optimized for deployment. During the three years this has been in development, no use cases for signing random headers were presented.

Recent efforts (which I am strongly opposed to) are trying to define a way to normalize the HTTP request into a JSON object, base64 and sign it, and include the base64 blob with the request. This is part of the JSON token proposal. It basically means using HTTP as a stupid transport and repeating all the important details in the signed blob (including the request URI, HTTP method, etc.). The reason I am mentioning this is to demonstrate what happens when no alternative practical solution is offered.

What would be useful is to list the use cases and requirements the author had in mind when drafting this, why signing headers is necessary, and what is lacking in the MAC token proposal that might make it more appealing.

EHL

> From: Cyrus Daboo [mailto:[email-masked]]
> Sent: Friday, March 25, 2011 7:29 AM
> To: Eran Hammer-Lahav; Mark Nottingham
> Please take a look at DKIM which does this for email (and reasonably well by
> most accounts). In fact my preference here is to use DKIM for HTTP as well.
> Whilst DKIM is currently used for email it was designed to be generally
> applicable to similar protocols - in fact we are planning on using it for iTIP-
> over-HTTP (iSchedule:
> <http://tools.ietf.org/id/draft-desruisseaux-ischedule-01.txt>). It would be
> good to be able to utilize the existing infrastructure and experience from
> DKIM in HTTP.
> 
> --
> Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 25 Mar 2011 16:41:15 -0400

Hi Bill,

--On March 25, 2011 3:33:40 PM -0400 Bill Burke <[email-masked]> wrote:

> The only thing I worry about DKIM is that it imposes a key management
> structure and infrastructure?  The users I deal with will probably want
> to integrate with existing mechanisms to manage keys and look them up and
> to verify identity (which will probably be different per user). Specially
> I want to apply this protocol to enterprise based systems rather than the
> typical Google/Yahoo/Twitter kind of thing.

A DKIM expert will need to speak up to confirm this, but I believe the key 
management piece is extensible. i.e. right now it defines a DNS-based 
mechanism, but I think you can extend it with others. The choice is 
advertised as one of the attributes in the DKIM header.

I have also been told that there will be a presentation at the Apps Area 
meeting next week on how DKIM can be used for general application security 
issues as described in 
<https://datatracker.ietf.org/doc/draft-crocker-dkim-doseta/>. So you might 
want to check that out.

-- 
Cyrus Daboo

---

From: Bill Burke <[email-masked]>
Date: Wed, 23 Mar 2011 10:54:27 +0000

Question:

I'm very unfamiliar with the whole IETF process.  How do I submit new 
draft versions?  Maybe I'm just stupid, but I couldn't figure out a way 
to do this.

Also, where should I ping for feedback on this?  CC [email-masked]? 
  You also suggested the HTTPbis email list in a prior email.

More comments inline.

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

Chad La Joie encouraged me to submit this.  Also, one of my users 
requested a feature like this.  I hope to get some feedback on how it 
works in the wild.

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

Sure.  I'm not married to any name.

> * 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) sa…

IMO, only headers that can be retransmitted as-is should be a default. 
I want signatures (and the signed content) to be able to be forwarded to 
multiple parties multiple times.  Correct me if I'm wrong, but Date will 
change each time the signature/representation is forwarded to a new 
party?  Same could be said for Cache-Control, etc.

Originally I had Content-Type as a default, but changed my mind as I 
didn't see why it mattered or not.

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

Ok.

> * What algorithm is used if the algorithm parameter is missing? Also, at least one algorithm should be pre-defined, to improve interop.

I wanted the option to keep the algorithm secret and understood between 
parties.  Maybe this doesn't matter as a hacker would try all known 
algorithms anyways.

> * 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 algorit…

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.

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

> * NIT - Throughout, you use "entity header." In HTTPbis, we've just moved away from this terminology; it should just be "header" now.

Too bad.  I liked that terminology.

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

---

From: Bill Burke <[email-masked]>
Date: Fri, 25 Mar 2011 19:34:26 +0000

DKIM looks exactly like what I want.  I wish I had found it prior to 
doing all this work to draft my own protocol.  You can have multiple 
signatures and also add arbitrary tags.  The only thing it doesn't seem 
to support is composing signatures from other signatures.  I see this 
being a very useful feature in workflows where somebody needs to verify 
that more than one party saw the same representation.

The only thing I worry about DKIM is that it imposes a key management 
structure and infrastructure?  The users I deal with will probably want 
to integrate with existing mechanisms to manage keys and look them up 
and to verify identity (which will probably be different per user). 
Specially I want to apply this protocol to enterprise based systems 
rather than the typical Google/Yahoo/Twitter kind of thing.

> What would be useful is to list the use cases and requirements the author had in mind when drafting this, why signing headers is necessary, and what is lacking in the MAC token proposal that might…

I did look at MAC, other than being design specifically to work with 
OAuth, it exists specifically to verify the integrity of a message sent 
between one client and server.

The list of use cases and requirements are expressed in a blog I wrote a 
few weeks ago:

http://bill.burkecentral.com/2011/02/21/multiple-uses-for-content-signature/

Bill

---

From: Bill Burke <[email-masked]>
Date: Thu, 24 Mar 2011 16:01:53 +0000

>   * 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 m…

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

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

---

From: Bill Burke <[email-masked]>
Date: Thu, 24 Mar 2011 15:47:00 +0000

Thanks for the feedback.

Digital signatures exchanged by two parties, a client and a server are 
completely uninteresting to me.  I agree TLS is the appropriate 
solution. Applications that are not more complex than simple client and 
server interactions probably would never need or want to use digital 
signatures.

The problems I'm having have to deal with are simple to complex workflow 
scenarios where there are multiple identities involved.  Where a sender 
of a representation might not be the originator of the representation. 
A token based approach combined with TLS just doesn't cut it in these 
scenarios.  Digital signatures seemed like the simplest way to secure 
such environments.

As for signing headers, I also don't find it very interesting either, 
but I can see how it could be useful in certain situations.  I can see 
where the canonicalization of request/response headers might make things 
more complex, but I think the rest of my proposal is pretty straight 
forward.

---

From: Bill Burke <[email-masked]>
Date: Thu, 24 Mar 2011 18:13:01 +0000

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

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

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

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 27 Mar 2011 15:48:44 +0200

On 3/25/2011 8:34 PM, Bill Burke wrote:
>     The only thing it doesn't seem to support is composing
> signatures from other signatures. I see this being a very useful feature in
> workflows where somebody needs to verify that more than one party saw the same
> representation.

Can you clarify the details of the added functionality you are interested in?

By way of guessing, I'm thinking of two possibilities of what you might have in 
mind:

1. A new signature covers an existing signature.  I think the DOSETA model can 
cover this by specifying the existing signature's header field in the list of 
covered fields.

2. Re-using calculations from a first signature for forming a second one.  This 
would be the two hashes (content and content+header).  Something related to this 
idea has occurred to be, but only vaguely and I haven't done any work on it.

> The only thing I worry about DKIM is that it imposes a key management structure
> and infrastructure? The users I deal with will probably want to integrate with
> existing mechanisms to manage keys and look them up and to verify identity
> (which will probably be different per user).

Officially, the DKIM/DOSETA specs permit referring to a different key retrieval 
mechanism.  In practice I haven't heard of that being used.

More generally, it is certainly fundamental to gain clarity and agreement on the 
key management and certification model that is required.

>  Specially I want to apply this
> protocol to enterprise based systems rather than the typical
> Google/Yahoo/Twitter kind of thing.

Well, those large services certainly use DKIM, but I believe there is nothing in 
the design that is specific to large services.  On the other hand, the design 
certainly is biased towards operation across the open (public) Internet and it 
is certainly true that enterprise-based operation can permit a variety of 
alternatives that are not available across the open Internet.

To the extent that these requirements can be characterized and support for 
satisfying them gains rough consensus, I'm more than happy to participate in the 
effort to add the enhancement in Doseta.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 28 Mar 2011 14:48:13 +0800

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

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.
 
> the impl I used did.  I'll use base64 in next draft.

That's a common misconception :) 
 
> https://datatracker.ietf.org/idst/upload.cgi

Yeah, just submit -01.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 29 Mar 2011 09:47:15 +0200

On 3/28/2011 9:23 PM, Bill Burke wrote:
> The header canonicalization algorithm seems a little fragile, but I don't have
> experience deploying the protocol. Its probably sufficient enough for the
> perceived needs I envision.

For DKIM's intended email use, some of us believe there needs to be an 
additional canonicalization algorithm that is more extensively tailored to 
modifications that happen during real-world transit.  The more forgiving of the 
existing two (relaxed) breaks too often.  I'm confident we'll write a spec for 
this soon.

But I said email transit, which of course is not the same as web transit.

I would think it likely that the web environment could also benefit from a 
canonicalization algorithm tailored to the kinds of modifications done during 
web page data migration.

Since this is a modular part of the signing service, this is merely a matter of 
developing the algorithm and registering it in the right DKIM-related table (and 
getting signers and verifiers to implement it...)

> I just wish DKIM was a tiny bit more layered into additional RFCs. Specifically
> keeping key management separate from the canonicalization algorithms and header
> format. While I do so far like the key management structure specified, I do
> worry about it being accepted when I start selling this as a solution other than
> just for managing email integrity.

Just to make sure we have a clear base for discussion:  DOSETA is not DKIM.

DKIM is a fully-integrated email identification scheme.

Although DOSETA documents the same core technology, the specification is 
organized very differently and is intended to be easy to adapt to other 
applications.

The DOSETA documents are also is newer and very much subject to changes 
(improvements).  These documents are only a few weeks old, although of course, 
much of the text was taken from the older and more mature DKIM specifications.

To put things baldly:  I made an initial pass at organizing the DOSETA spec in a 
way that would support much better modularization, to support use in other 
application.  But like any writing I do, it needs others to suggest changes.  By 
"needs" I mean /must/ be obtained.  I'm quite happy with the current version... 
as a start.  It needs other eyes and some testing to provide guidance for how to 
make it better, in terms of organization, technical design, and wording.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 29 Mar 2011 10:19:25 +0200

d/
-- 

   Dave Crocker

---

From: Bill Burke <[email-masked]>
Date: Mon, 28 Mar 2011 19:24:19 +0000

On 3/27/11 9:48 AM, Dave CROCKER wrote:
> By way of guessing, I'm thinking of two possibilities of what you might
> have in mind:
>
> 1. A new signature covers an existing signature. I think the DOSETA
> model can cover this by specifying the existing signature's header field
> in the list of covered fields.
>
> 2. Re-using calculations from a first signature for forming a second
> one. This would be the two hashes (content and content+header).
> Something related to this idea has occurred to be, but only vaguely and
> I haven't done any work on it.
>

The header canonicalization algorithm seems a little fragile, but I 
don't have experience deploying the protocol.  Its probably sufficient 
enough for the perceived needs I envision.

>> structure
> Officially, the DKIM/DOSETA specs permit referring to a different key
> retrieval mechanism. In practice I haven't heard of that being used.
>
> More generally, it is certainly fundamental to gain clarity and
> agreement on the key management and certification model that is required.
>

I just wish DKIM was a tiny bit more layered into additional RFCs. 
Specifically keeping key management separate from the canonicalization 
algorithms and header format.  While I do so far like the key management 
structure specified, I do worry about it being accepted when I start 
selling this as a solution other than just for managing email integrity.

Bill

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 29 Mar 2011 07:41:02 +0000

On 3/23/2011 11:54 AM, Bill Burke wrote:
> Question:
>
> I'm very unfamiliar with the whole IETF process. How do I submit new draft
> versions? Maybe I'm just stupid, but I couldn't figure out a way to do this.

Anyone may submit a new Internet Draft.  I think the web interface for doing 
this is now quite good, although the error messages can sometimes be a bit 
cryptic.  But I'll assume that there are no questions about that level of 
interaction.  If there /are/ questions, they probably should refer to specific 
actions and details of any problems.

One quirk is that the filename must be draft-...-00.txt form.

As for updates, any of the authors listed in the last-issued draft may submit a 
revision.  The process is exactly the same as for initial submission.

The difference is that the tool enforces version control.  The filename that is 
used for getting (uploading) needs to be the same as the previous submission, 
but with the version number being exactly one higher.

(Feel free to contact me offlist if you want to discuss this more, or onlist if 
the rest of the group wants to pursue it.)

> Also, where should I ping for feedback on this? CC [email-masked]? You also
> suggested the HTTPbis email list in a prior email.

Since this exchange came up on that list and since I believe that's the group 
that is interested in this functional enhancement, I assume the answer is yes. 
But then, I am not running that list...

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

If you really mean opaque, how is the verifier on the receiving side supposed to 
know how to use the string?

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 30 Mar 2011 10:05:10 +0200

On 3/29/2011 5:36 PM, Bill Burke wrote:
> Is there a specific mail list you discuss DOSETA on? I'd like to join the
> conversation or at least listen. At a minimum I can provide feedback from
> implementing, integrating, and applying the protocol.

Apologies for not having announced this during the meeting:

    <http://www.trusteddomain.org/mailman/listinfo/doseta-discuss>

d/
-- 

   Dave Crocker

---

From: Bill Burke <[email-masked]>
Date: Tue, 29 Mar 2011 15:37:28 +0000

On 3/29/11 4:19 AM, Dave CROCKER wrote:
> (improvements). These documents are only a few weeks old, although of
> course, much of the text was taken from the older and more mature DKIM
> specifications.
>
> To put things baldly: I made an initial pass at organizing the DOSETA
> spec in a way that would support much better modularization, to support
> use in other application. But like any writing I do, it needs others to
> suggest changes. By "needs" I mean /must/ be obtained. I'm quite happy
> with the current version... as a start. It needs other eyes and some
> testing to provide guidance for how to make it better, in terms of
> organization, technical design, and wording.
>

Is there a specific mail list you discuss DOSETA on?  I'd like to join 
the conversation or at least listen.  At a minimum I can provide 
feedback from implementing, integrating, and applying the protocol.