On Wed, Oct 24, 2018 at 1:21 PM Kas <[email protected]> wrote: > > On Wed, Oct 24, 2018 at 12:04 PM Kas <[email protected]> > wrote: > > I don't think I agree with this claim. The client's expectations about the > intended > server are set by its domain name and it verifies that it is talking to > the server in > question via the WebPKI. > > Acme protocol doesn't mention anything about verifying domain name, if you > mean when on TLS connection layer then my replay to Ilari applies here. >
I don't understand that response. You seem to be assuming that the WebPKI isn't secure, but htat's not the operational assumption here. 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.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
