On Mon, Nov 14, 2016 at 9:00 AM, Peter Bowen <[email protected]> wrote:
> On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham <[email protected]> wrote: > > > > 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. CT's original purpose is useful to know, but not as important as what benefit Mozilla wishes to gain from CT as a root program and browser. Right now, there aren't a lot of TCSCs, and so the impact to ecosystem visibility is small. Once they're made easy to mint (which seems like a good thing) an exemption from CT could, over time, drastically impact the ecosystem visibility benefits that CT has demonstrated (which seems like a bad thing). Chrome's been really clear that, CT spec or not, the use of a TCSC isn't enough to get out of SCT requirements. At least until the community does more work at identifying name redaction use cases and how to best address them over the next few months, I would recommend Mozilla stick with Chrome's position. -- Eric > 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. > > Thanks, > Peter > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
