On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham <[email protected]> wrote: > If this is the only privacy mechanism available for 6962bis, I suspect > we will see a lot more TCSCs about, particularly if CAs figure out ways > to mint them at scale within the letter of the BRs and other requirements.
This is the only privacy mechanism that will be in -bis, it sounds like. There was not consensus to remove it, since that would force it to go back through WGLC. Instead, it will likely largely be ignored by one major CT implementor (Chrome), but will exist in a documented state that simply documents 'how' you could do it, not whether you should. That is, the RFC documents technology, *not* policy. While this is unfortunate, it's pragmatic - it allows 6962-bis to carry on as-is, without having to restart discussion, even if it contains technology that is unimplemented and will likely remain unimplemented indefinitely. That's just SDOs as usual. I think it'd be useful to resolve the questions I asked on this thread - https://groups.google.com/d/msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ - to figure out what Mozilla expects/wants of TCSCs with respect to the BRs, as that seems like it would significantly affect how you want CT to play or not play in that role. As Andrew Ayer points out, currently, CAs are required to ensure TCSCs comply with the BRs. Non-compliance is misissuance. Does Mozilla share that view? And is Mozilla willing to surrender the ability to detect misissuance, in favor of something which clearly doesn't address the use cases for redaction identified in the CA/Browser Forum and in the IETF? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
