Re: [Acme] ACME signature mechanics

[Anders Rundgren <[e-mail]>]

On 2014-12-18 19:50, Trevor Freeman wrote:
>
> *From:*Acme [mailto:[e-mail]] *On Behalf Of *Phillip Hallam-Baker
> *Sent:* Thursday, December 18, 2014 4:34 AM
> *To:* Anders Rundgren
> *Cc:* Richard Barnes; Martin Thomson; [e-mail]; Trevor Freeman
> *Subject:* Re: [Acme] ACME signature mechanics
>
> On Thu, Dec 18, 2014 at 2:54 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
>
> 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.
>
> */[TF] Strange, I have worked with similar constraints with cloud based services and this model worked just fine./*
>

It is possibly that I didn't completely understood the scenario you described but
you also need a trust anchor in the proxy end, don't you?  This seems to not work
with a CSR unless you already have a certificate.

What am I missing here?


> *//*
>
> *//*
>
> +1
>
> Part of the objective here should be to put the end customer in control by running their own issue point that is a proxy to a CA or another proxy. Binding the authentication to the transport means that the proof of possession can only be verified by the proxy which breaks the model.
>
> */[TF] If you trust the proxy enough to terminal the TLS then you trust it enough to pass a flag to indicate authentication succeeded/*
>
> */Have you considered what value the POP on a pkcs#10 actually delivers? It does not show the subject submitting the request is the same as the one in control of the key pair. It just proves to the CA the key pair is functional. /*
>

I agree that the PoP provided by PKCS #10 is essentially useless.
I got the impression that AMCE relies on other data to authenticate the request.

In the proxy systems I have worked with messages were checked for sanity before transferred to the secure world.

Related question:
http://www.ietf.org/mail-archive/web/acme/current/msg00143.html

Anders


> On top of which, it is really yucky to implement. The less time spent traveling unimplemented, unexplored and un-debugged code paths, the better.
>
> Minimal TLS stacks for embedded devices don't typically do client auth. See 'minimal'.
>