On 10/25/2018 12:49 AM, Eric Rescorla wrote:
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.
Sure it is out of scope but supplying the chain as CA and root certificate doesn't conflict and will only secure the protocol, it is as i said you know better but adding the ability to obtain such small store from acme server is not bad practice.


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.
DNS is running on different servers and will add extra layer of security, even letsencrypt as fully trusted ACME service provider by every store, if wanted to impersonate example.com and act as acme server running on example.com will fail unless it can control DNS records of that domain.


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.
DNS can be used to deliver a pair of encoded data one url and a hash to a certificate to establish secure connection and obtain the chain of acme server, or the store from acme server contain all the root and CA certificates being used by that ACME server, on other hand if only one RFC or protocol has defined such request or protocol, then there will be a chance to configure Windows to use the store provided by Mozilla. Every email been sent trigger DNS lookup to check DKIM and SPF and DNS servers doing amazing and fast job.


I think you got my suggestion and i don't think there will be such a chance to standardize such protocols/functionality in near future if ACME passed on it, i mean something the online certificate revocation process, it is ready to be used. And i am not saying it should be DNS, i think you can figure well suited approach to enhance this protocol.


That is it and thank you for your time
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to