On Wed, Oct 24, 2018 at 2:36 PM Kas <kas=40lightc....@dmarc.ietf.org> wrote:
> > On 10/24/2018 11:33 PM, Eric Rescorla wrote: > > I don't understand what this means. The client doesn't take its root >> certificates >> from the ACME server. In fact, in the most common use cases for ACME, >> issuance of WebPKI server certs, the server doesn't need to know >> anything about trust anchors at all (the ACME *client* does, but >> those are preinstalled and don't need to interact with the ACME server >> other than doing ordinary WebPKI validation). >> >> Client doesn't take its root certificates from ACME server that is true, >> but when a client utilize ACME protocol to get a certificate from ACME >> server, this implies that this server is already CA trusted in the eyes of >> the client, and in both cases if the CA cert used by acme server to issue >> the certificate leads or not to a trusted root certificate on client side, >> the client want that certificate and want the full chain and has the power >> trust it or not, >> > > This is pretty hard to follow but If I'm understanding you correctly, then > I don't think this is correct. There's just no connection at all between > the trust anchors in the ACME client and the trust anchor associated with > the CA part of the ACME server. > > Consider the case where I am operating an Enterprise CA for my own > servers. This CA has a self-signed certificate X that needs to be installed > in every Web client in my network. The CA itself runs ACME and has a > certificate that's signed by a WebPKI valid anchor T. The ACME client > component of my Web server connects to my own ACME server and has trust > anchor T installed, and is therefore able to validate the ACME server's > identity at the TLS level. However, because it does not have trust anchor X > installed, the ACME server cannot issue a certificate which would be > acceptable to the ACME client [0]. Contrariwise, my Web clients have trust > anchor X (and likely T) installed, and so will accept certificates from > both the ordinary WebPKI and from my Enterprise CA. > > You seem to have some concern about this, but I can't really figure out > what it is. Given that a number of people have engaged with you and seem to > also be confused, I would suggest that the problem is that you aren't being > clear. I would suggest you draw a diagram of the various states, including > the initial state, the state you would consider secure, and the state you > are concerned about. > > -Ekr > > [0] Note that the ACME client might have a copy of X in order to validate > the cert chain provided by the ACME server as a means of sanity checking > but this has nothing to do with the TLS portion. > > > You said "trust anchors in the ACME client and the trust anchor associated > with the CA part of the ACME server" and in your example "This CA has a > self-signed certificate X that needs to be installed in every Web client in > my network." > there is connection and there will always connection between those, > Yes, there is a connection between the Web clients (e.g., browsers) and the trust anchor in the enterprise CA, but it has nothing to do with ACME. Generally, the way this works is that when you set up the enterprise CA, you'd generate the trust anchor which you put into whatever system you use to manage those clients. But ACME isn't involved at all, because the web servers that talk to the CA are also not involved. > There is no need for example as your example will do : > My point is about "installed" from your example as word and as process, > ACME is Automatic Certificate Management Environment and thus if this > "installed" can be automated then it better be, and it can be supplied > online without preinstalled certificates, all your clients can only need > the DNS root key and utilize DNSSEC to obtain your X, please correct me if > i am wrong, on top of that there is RFC 5011 "Automated Updates of DNS > Security (DNSSEC) Trust Anchors" can update that key in secure way, and you > can revoke your CA certificate and issue another one to ACME server and all > your client will be updated automatically, so in my opinion using DNSSEC is > way more secure than depending on client store. > I would say three things about this: 1. This has nothing to do with ACME, which is entirely about the interaction between the cert-holder and the CA. Speaking as AD (the rest of this message is as an individual) I can tell you that anything having to do with populating the client key store would be out of scope for ACME. 2. I actually don't agree that it would be better to have the client trust anchor store updated via DNS, at least for one of the large well-managed clients (e.g., Firefox, Chrome, etc.) Because of the nature of the WebPKI, the question of whether a trust anchor is one that the client should trust is to a great extent a policy question. and the clients (or the operating systems that they are hosted on) operate root programs which evaluate those policy issues (for instance, determining whether a given CA should be distrusted). So, the relevant question is how that information gets communicated to the user's machine. There's no particular reason why the DNS is a good choice for that. 3. In the particular case of enterprise trust anchors (as opposed to preconfigured ones) there are already mechanisms for remotely managing machines, and so again. DNS is not a particularly good mechanism for this. -Ekr
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
