Re: [Acme] ACME signature mechanics

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

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 have a marginal preference for making the signature header part of the
> > HTTP header because that is how most Web servers and support libraries
> are
> > designed to work. They make it really easy to pull data out of a header.
> On
> > many platforms the RFC822 tag value pairs are automatically mapped to
> > corresponding data structures.
>
> I'd rather it be in the payload because then you have less dependence on
> the transport.  E.g., if you're using an IPC mechanism in your server
> implementation, with a less-privileged front-end passing validated
> payloads to a more-privileged back-end.


Well so long as the payload is divided into a header portion and a payload
portion, I am fine.

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:

{ <header JSON> } CR LF CR LF { <payload JSON> }

I am perfectly happy with any one of the following, or with additional
control characters thrown in to season the pot if you really must. But I am
really insistent that there be exactly one choice:

Header = [ { <header JSON> } ]
Payload = [ CR LF CR LF { <payload JSON> } ]

Header = [ { <header JSON> } CR LF ]
Payload = [  CR LF { <payload JSON> } ]

Header = [ { <header JSON> } CR LF CR LF ]
Payload = [ { <payload JSON> } ]

Header = [ { <header JSON> } WS* ]
Payload = [ { <payload JSON> } ]


The third is consistent with the approach for HTTP, the last is probably
the easiest to implement and is a superset of the third. The only problem
is that then this approach only works for JSON payloads.



> > There is an argument for making the signature part of the payload though.
> > It is not a HTTP protocol header, it is content metadata and these should
> > have always been kept separate.
>
> Exactly.