> On Feb 27, 2018, at 16:47, Wayne Thayer via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jonat...@titanous.com> > wrote: > >> >>> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> >>>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>>> >>>> This request has been in public discussion for more than 6 months, so I >>>> would like to make a decision soon. If you have comments or concerns >> with >>>> this request, please post them here by 6-March 2018. >>> >>> Given the misissued certificates in CT under the existing root, I >> believe this request should be rejected, and a new clean root with audits >> should be required before moving forward. >>> >> > This course of action doesn't seem consistent with our treatment of the > many included CAs that have experienced these problems.
Given that revocation checking doesn’t work, and CT doesn’t provide a complete picture, especially without browser enforcement, accepting this root would have the result of exposing Mozilla's users to certificates that are known to be misissued. I realize that some inclusion requests have been accepted in the past despite existing misissued certificates, but I don’t think that is sufficient justification for continuing to do so. Why shouldn’t we require CAs to cut a new root when the data indicates that accepting the existing root will put users at risk? Jonathan _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
