Re: [Acme] ACME signature mechanics

[Nico Williams <[e-mail]>]

On Wed, Dec 17, 2014 at 12:02:10PM -0500, Phillip Hallam-Baker wrote:
> On Tue, Dec 16, 2014 at 11:27 AM, Richard Barnes <[e-mail]> wrote:
> > That said, if your concern is really human readability, I don't think it's
> > a tragedy to make someone copy/paste into a base64 decoder.
> 
> I do. If we are going to write protocols that can't be easily interpreted
> in wireline form then why not go binary with JSON-B, CBOR or what have you.

Well, it does mean having to implement one of those...

> I don't see any value in the 'protected' or 'header' slots. They just
> confuse the issue. We should have ONE JSON blob that has all the data that
> we need and sigh that. All the data that is the case shall be signed and
> any data that is not signed shall be ignored.

I'd rather have the signature in a JSON text and the signed text encoded
as a string in the same text as bears the signature.

> The only objection I can see to this approach is that it makes JOSE pretty
> much redundant.

And that it uses new headers.

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

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

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

Nico
--