On Mon, 14 Nov 2016 06:00:24 -0800 Peter Bowen <[email protected]> wrote:
> > CT is getting to be very useful as a way of surveying the certificate > > ecosystem. This is helpful to assess the impact of proposed policy > > changes or positions, e.g. "how many certs don't have an EKU", or "how > > many certs use a certain type of crypto". If certs under TCSCs are > > exempt and this becomes popular, CT would become less useful for that. > > > > One possible answer is just to say: "Mozilla will not accept 'but we > > have a lot of certs under TCSCs which will be affected by this' as a > > valid reason not to do something. In other words, if you hide stuff and > > it breaks, you get to keep both pieces. But in practice, such a line > > might not hold. > > I think this is the right answer. Yes, CT has helped provide a better > view into galaxy of CAs that is WebPKI, that was not its stated > purpose. CT was created to help domain registrants have visibility > into what is issued for their domain names. I disagree with your characterization of CT. The first sentences of RFC6962 say: "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates. The logs are publicly auditable so that it is possible for anyone to verify the correctness of each log and to monitor when new certificates are added to it. The logs do not themselves prevent misissue, but they ensure that interested parties (particularly those named in certificates) can detect such misissuance." Although issuing a certificate without the authorization of the domain registrant is the most serious type of misissuance, it is not the only type. Apart from audits, TCSCs are subject to the Baseline Requirements, and failure to comply is a type of misissuance that is of interest to the Internet community, particularly to root store operators and certificate validation implementers like Mozilla. In any case, standards can provide unexpected benefits. It would be self-defeating to discount a benefit just because it wasn't originally stated as a goal of the standard. > If domain holders want to keep their certificates semi-private, then > they need to be aware that security is a moving target and their > input on data-driven decisions may be diminished. Unfortunately, domain holders do not act rationally. Just look at all the domain holders who requested redacted franken-certificates from Symantec for publicly-accessible websites even when it was immediately apparent that such certificates do not work in Chrome. Domain holders would likewise fail to take heed that certificates issued from TCSCs might stop working at some point in the future, and probably in greater numbers since the consequences of their actions would be more abstract and less proximate. Meanwhile, end users have no say over what certificate a site uses and just want their browser to work. No browser maker wants to break sites for users. The rule about ignoring TCSCs when making decisions will surely be reverted the first time it causes widespread breakage. Then we'll be back in the same situation we are in now, where the lack of complete information makes it difficult to make changes that improve the security and robustness of the Web PKI. I appreciate the need for domain name privacy, but it must be balanced against the needs of the public. I find the label redaction approach in draft-strad-trans-redaction-00 to be more balanced, as it hides only the minimum amount of information needed to provide domain name privacy. Regards, Andrew _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
