On Tue, Aug 15, 2017 at 4:01 PM, Kathleen Wilson via dev-security-policy < [email protected]> wrote:
> On Tuesday, August 15, 2017 at 12:46:36 PM UTC-7, Ryan Sleevi wrote: > > > > The requirement for revocation comes from the Baseline Requirements. > > > > Could you clarify your expectations regarding CAs' violation of the > > Baseline Requirements with respect to these issues and Section 4.9.1.1. > > Are you specifically referring to item #9 of Section 4.9.1.1? > Yeah, #9 serves as a catch-all, but based on the reporting from Jonathan and Alex, also #4. For things like internal IPs / domains, there's #6 and #10 Depending on the CP/CPS, #14 applies For some of the encoding issues, I would argue that #15 would/should apply - some of these certificates actively harm interoperability (e.g. they're problematic practices well beyond an acceptable timeframe for them, and fail to work in NSS and other applications) I think, in all of this, it's worth calling out that at least one CA has (1) Proactively reached out to multiple root programs regarding a proposed remediation plan (2) Provided a detailed post-mortem that sufficiently demonstrates an understanding of the issue (3) Provided a reasonable and responsible set of next steps that arguably represent good industry practice that other CAs should consider adopting. And that's PKIoverheid. Also worth calling out is Let's Encrypt, which was able to revoke in a timely fashion, enact a production change, and provide a detailed post-mortem, all within 24 hours. That's an incredible level of responsibility and turn-around that shows a systemic understanding of the risks and challenges. It would be a shame if the excellent work by these two CAs to address community concerns was not met-or-exceeded by the other CAs on the list, as that certainly discourages future post-mortems and encourages incomplete responses. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
