Re: [Acme] ACME signature mechanics

[Anders Rundgren <[e-mail]>]

Having worked with Europe's EAC (e-passport biometric data protection PKI),
which works as described below, I would strongly recommend NOT using HTTPS
client-certificate authentication because it doesn't fit a normal installation
with an external security-proxy.

Anders

On 2014-12-18 08:29, Trevor Freeman wrote:
> The pkcs#10 is a product of the disconnected state we are trying to fix and was designed to be transport independent.
> It works of HTTP, in Windows we used it over RPC and DCOM as well so it achieved its objective such as they were back then.
>
> If we are designing something to run over TLS then we can take advantage of features in the transport such as client auth. PKCS#10 is an input into the request process but it's not the only game in town. In Windows we also use X.509 as an input to the signing process. We could convert a root certificate into a subordinate certificate which freaked a whole bunch of folks out. We use the X.509 certificate to create a degenerate pkcs#10 then signed that with an RA certificate. We could take root certificates like Comodo and Verisign and subordinate them.  All you really need to make this work is a way to encode the public key and parameters using a format which is widely supported and X.509 does just that. The TLS protocol provides the POP for the leaf certificate. If you want to sign the leaf certificate with an authorizing certificate, that too is possible.
>
> -----Original Message-----
> From: Acme [mailto:[e-mail]] On Behalf Of Martin Thomson
> Sent: Wednesday, December 17, 2014 12:00 PM
> To: Trevor Freeman
> Cc: Richard Barnes; Phillip Hallam-Baker; [e-mail]; Anders Rundgren
> Subject: Re: [Acme] ACME signature mechanics
>
> I think that there is the kernel of an idea here.  Richard might not like this, but it does have a certain ring to it:
>
> See:
> https://tools.ietf.org/html/draft-thomson-httpbis-cant
>
> Maybe the whole signing thing isn't needed.
>
> The part about the CSR I get.  This isn't just a matter of ensuring that the right pieces of information traverse the network in the protocol, it's also about dealing with the toolchain that exists for generating the certificates.  The CSR is valuable in the sense that it is input to what is probably an existing process.
>
> On 17 December 2014 at 11:53, Trevor Freeman <[e-mail]> wrote:
>> 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.
>>
>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>