We seem to still be talking past each other, so I'm going to try one more time and then probably give up.
On Wed, Oct 24, 2018 at 3:50 PM Kas <[email protected]> wrote: > 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 > What out of scope means here is: the ACME WG should not be working on this. If you want to work on it, you will need a recharter or to start some other wG. 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. > I honestly don't understand how you think this is going to work. In this scenario, the clients have no interaction with the ACME server at all. They may not even be on a network connected to it. > > 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. > It would really help if you were able to explain what your concern is. It's certainly true that an WebPKI-capable CA can (modulo CT, pinning, etc.) impersonate another WebPKI CA to an ACME client, but this doesn't seem like a very interesting threat given that said CA can impersonate *any* site to *any* client, which is a much more serious type of attack in general. The IETF has already standardized a set of techniques (including ones based on DNS) for preventing this type of attack, and ACME clients are free to use those. But there's nothing required in ACME 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. > > 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. > I don't understand what you think this would accomplish. As I said, there are two cases: - In the case of system-installed trust anchors, there is already an existing way to configure them, and the vendors don't want to outsource that to DNS - In the case of user-installed (or typically systems-manager installed) trust anchors, there are also existing ways to configure them via enterprise policy, and DNS wouldn't be a good choice there either. Note that neither of these cases involves any kind of connection to the ACME server. > 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. > I'm sorry, I am totally unable to determine what use cases you think you are trying to solve, and therefore I don't see how to design a protocol to address them. Again, it would really help if you would describe a concrete attack. Failing that, I don't think this is a productive interaction. -Ekr
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
