Re: [Acme] ACME signature mechanics

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Dec 17, 2014 at 5:23 PM, Nico Williams <[e-mail]>
wrote:
>
> On Wed, Dec 17, 2014 at 03:28:27PM -0500, Phillip Hallam-Baker wrote:
> > On Wed, Dec 17, 2014 at 12:19 PM, Nico Williams <[e-mail]>
> > wrote:
> > >
> > > On Wed, Dec 17, 2014 at 12:02:10PM -0500, Phillip Hallam-Baker wrote:
> > >
> > > That does leave two open issues to be decided though:
> > > >
> > > > 1 Should the signature header be part of the HTTP header or the
> payload?
> > >
> > > The payload.  And then you've created a new MIME type.
> >
> >
> > *message/rfc822*
>
> I guess that works.
>
> > In fact we could even make both the header and the payload portion JSON
> > encoded and then just use the JSON list spec to put them both in the same
> > wrapper. The only hard part here is that we have a sequence of octets and
> > we need to unambiguously specify exactly where the dividing line is
> between
> > them:
>
> Might as well just have a single JSON value wrapping both (or a JSON
> text sequence!), but whatever.


No, not at all. At every layer in the stack we have a separation of
Header/Payload. And the Payload for one layer contains the Header and
Payload for the one above.

If the architecture was clean we would have this pattern all the way up the
stack. But instead we have rather a lot of places where things are
confused. and intertwingled. HTTP being especially bad as part of the
header is application protocol and part is message content.


Where this becomes a problem is when trying to sign stuff. I want the scope
of the signature to be exactly the scope of the payload. Right now my code
all works on the basis that the payload is the HTTP payload. But I am more
than happy to move to a model where the payload is the message payload.

This has other advantages we could make use of later on. For example, we
could add encryption without problems. Or we could make it a general
metadata prefix for content. Or we could add in slots for content metadata
that tends to get conflated with SMTP or HTTP headers making signature and
encryption harder than needed.


If we try to wrap a JSON object then we are committed to the payload being
JSON and we have two areas of ambiguity in the signature scope, the start
and the end.

Prefixing a signed object with a JSON blob and CRLF is rather simpler.