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?
Am 12.03.2018 15:57 schrieb "Jörn Heissler" <[email protected]>: > On Mon, Mar 12, 2018 at 12:25:14 +0000, Hugo Landau wrote: > > 1. Clarify the specification to state that the root certificate must > > always appear in the chain at the end. Clients should be advised to > > pop the root certificate if they are procuring certificate chains > > for non-DANE applications only. Failure to do so will result in > > unnecessary but harmless transmission of the root certificate > > during TLS handshakes. > > > > 2. Don't include the root certificate but provide a way to retrieve it, > > e.g. via a Link header. > > > > 3. Clarify the specification to state that the root certificate must > > not appear in the chain, and that roots must be retrieved using the > > AIA URL inside the final certificate in the chain if it is needed. > > This minimises the chance of clients for non-DANE applications > > messing up and provides a viable method for discovery of the root > > CA for applications which need it. > > > > I'd support option 1 or option 3 equally. Either way, I think this > > should be clarified. > > > > Thoughts? > > There's one more option which I'd actually prefer. > > 4. Root certificate does not appear in the chain but it's expected > that clients already know it. E.g. look in /etc/ssl/certs/. > > Rationale is that the client shouldn't blindly trust that the chain > received by the acme server is valid. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
