This discussion seems kind of out of scope for 7525-bis, which is about how to use TLS, but doesn't seem to say much of anything in terms of how to operate a CA.
The current draft seems not to say anything about what clients ought to do and to say that servers SHOULD support OCSP and OCSP stapling (though the citation to 6961 is weird because it seems to be referred to twice). My sense is that it probably ought to say: - Clients should have some mechanism for dealing with revocation, at least in high value cases - For the reasons rsleevi indicates it may be desirable that it not be totally unfiltered - None of the standardized mechanisms are acceptable here, OCSP for privacy and performance reasons, and stapling for deployment reasons - Servers SHOULD (MAY?) support stapling for clients which don't have another mechanism, but shouldn't expect a lot of use. This last seems a bit 6919ish, tbh. -Ekr On Fri, Jan 21, 2022 at 10:31 AM Ryan Sleevi <ryan-ietf...@sleevi.com> wrote: > > > On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > >> > Do you think that DNSSEC should be soft-fail for CAA checks, or should >> > we urge the CAs to be more strict here? Perhaps that would be another >> > recommendation. >> >> CAA lookups must not softfail. This needs to be the case whether the >> domain is signed or not. For signed domains this means that validation >> of the response (positive or denial of existence) must succeed. Bogus >> replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all >> be hard errors (for signed and unsigned domains alike). >> > > Yes, and OCSP lookups must not softfail either, in order for them to be > useful. > > Unfortunately, the real world is messy and complex, and the incentives for > getting to such a system for CAA are, unfortunately, greatly misaligned - > for CAs, but also for server operators and all the intermediaries along the > line. > _______________________________________________ > Uta mailing list > u...@ietf.org > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
