The usage model I think we should aim for is where chains are used as-is. For instance, the chain is fed straight to the HTTPS server. There is reasonably strong advice against sending trust anchor certificates over the wire, and most software simply spools out everything it is given.
I thought that we already had this discussion and concluded that roots wouldn't be included. That's consistent with the above. Obviously that would leave this open to some discretion, but that's OK. For instance, during the period that a new CA has a cross-signature on their root, they might include their own anchor for maximum compatibility, but they might phase that out over time. But the CA is in a reasonable position to know when to move, and it isn't as though this would prevent clients from adding or removing as they see fit. On Mon, Mar 12, 2018 at 3:14 PM, Jörn Heissler <[email protected]> wrote: > On Mon, Mar 12, 2018 at 16:01:24 +0100, Philipp Junghannß wrote: >> But isn't the point of this proposal that the client CANNOT be expected >> knowing the root like with DANE/TLSA'd servers with a custom root or >> whatever? > > 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? > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
