Re: [Acme] ACME signature mechanics

[Trevor Freeman <[e-mail]>]

Hi Richard,

 

There is an alternative to using PKCS#10 as the CSR structure. The ACME request is using TLS as a transport. You could use the client certificate portion of TLS to send an X.509 certificate containing the ACME client public key to the ACME server. All the data the ACME server needs is in the X.509 structure. You can sign the X.509 certificate containing the leaf certificate with the authorization public key in the normal X.509 way.  There is just as much X.509 certificate creation code out there as pkcs#10 creation code so I don’t see that as a big issue. An upside to this is you also get a meaningful POP in that the ACME client submitting the request has to use the private key as part of the TLS negotiation which is a better proof they actually have the private key. Also all of the ASN.1 structures and the signatures for the request would be part of the TLS protocol. 

 

Trevor

 

From: Acme [mailto:[e-mail]] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, December 17, 2014 9:02 AM
To: Richard Barnes
Cc: [e-mail]; Anders Rundgren
Subject: Re: [Acme] ACME signature mechanics

 

 

 

On Tue, Dec 16, 2014 at 11:27 AM, Richard Barnes <[e-mail]> wrote:

I think there might be a middle way here.  I've been musing about making a "Content-Signature" header that just carries a JWS signature over the payload (no HTTP headers).  Since HTTP has to carry the payload bit-exact, there's no c14n nonsense, so this could be much simpler than other HTTP signing proposals.  It's sort of like JCS, except that there is actually a guarantee that the payload stays the same ;)

 

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.

 

I like the idea of using a header like container for the signature. It makes good architectural sense and it is easy to code. A signature is logically meta-data and so it should be expressed as a header.

 

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.

 

So the running example would be written thus:

 

 

Signature: alg=RS256; nonce=h5aYpWVkq-xlJh6cpR-3cw; sig=KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ; KeyID=???TBS

 

 { "certificateRequest" : {

     "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P",
  }  }  

 

The "certificateRequest" object contains exactly the sequence of octets that is signed. No moving bits round, no splicing, no complications at all. What is in the signature scope and what is not is clear and unambiguous.

 

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

 

 

That does leave two open issues to be decided though:

 

1 Should the signature header be part of the HTTP header or the payload?

2 How to encode the KeyID?

 

 

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.

 

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.

 

 

The second one is a little bit more subtle as we definitely need a way to identify which key is used and I don't like the way it is done in the example because we end up specifying the key twice and relying on some party to check they are the same. There lies the path to tears, weeping and gnashing of teeth.

 

I would rather make the KeyID implicit in the case and require the application to ferret it out from whatever CSR type object it is using. It would be perfectly OK in my view to define a parallel JSON structure to allow an all-JSON certificate issue path as an alternative to PKCS#10. It would also be OK to use a combination of both to allow additional information to be provided. But presenting security critical information through redundant paths without a means of forcing cross checking is a bad plan.