One fine point here: You assert that an ACME setup should not require knowledge of the root certificate because it may change over time, but if we extend that to a complicated trust chain, that logic doesn’t necessarily work.
For example: For ISRG/Let’s Encrypt, the system certainly knows the ICA it’s issuing from (generally Let’s Encrypt X3…) The server produces the certificate and the “full chain” is the certificate plus the issuing CA. But what if Let’s Encrypt's (or any other organization’s) issuing certificate trust chain were more complicated. Imagine that there’s a “Let’s Encrypt BR Compliant WebPKI Server Certificate CA” which is signed by an Identrust Root and this offline CA has further signed two subordinate issuing CAs (X3 and X4). In this instance, the “full chain” returned by the ACME server should include both the issuing ICA certificate AND the parent certificate of that, as it is that parent which chains directly to a trust anchor. So you either have to have the ACME server discern that via explicit config or AIA for any complicated cases. Imagine some branch of the US Government implementing an ACME server inside the massive and complex Federal PKI. Producing that “full chain” less trust anchor is no more or less difficult than producing it with the trust anchor. > On Mar 14, 2018, at 1:11 PM, Hugo Landau <[email protected]> wrote: > > >> I must admit that I'm not very familiar with DANE. >> >> What would be a typical use case where you use ACME but you don't >> already know the root cert? > Where DANE is used, a trust anchor is referenced by a hash of its public > key or certificate, which is placed in a DNSSEC-secured DNS record. This > trust anchor isn't necessarily one already known to the client > connecting to a TLS server, since the whole idea is that DANE/DNSSEC is > the real trust anchor and whatever CA is used for the TLS server > certificate is trusted by virtue of being referenced by hash. > > Because of this, where DANE is used, the trust anchor must be served by > the TLS server in the certificate chain. This is a waste of bandwidth > but otherwise harmless where DANE is not used, but is critical when > supporting DANE. > > An ACME setup shouldn't be expected to know the root certificate because > it may change over time. For example, currently Let's Encrypt serves > certificates using the IdenTrust cross-signed intermediates. It could at > some point switch to using its own ISRG root, once it has sufficient > prevalence in trust stores; if an ACME setup makes assumptions about > what root an ACME server issues using, breakage would result when this > happens. Moreover root certificates do have an eventual expiry date and > need to be swapped out. (Or acquired CAs could desire to switch to a new > root without breaking servers, or so on, and so forth.) > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
