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,
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.
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
