Matthew, That’s a good summary. It seems we have 2 methods that can be used only if the CAs using the methods have the design and risk mitigation factors reviewed and approved. It’s basically the old “any other method”, except before you can use it, the Root programs must review the design/implementation and can approve/reject them on a case by case basis. Is that where we are with these methods – Not approved unless disclosed and reviewed?
Given this discussion, there must be no other CAs using method 9 or 10, else they would have come forward by now with disclosures and have demonstrated their compliance.. Maybe we need to post this on the CABF public list? Based on this, do we need a ballot to remove them from the BRs, or put in a statement in them to the effect that they can be used only if approved by Google on this list? I’m not picking on Ryan, but he’s the only root program representative that has expressed strong views on what is permitted and what is not (else you have your CA revoked or root pulled from the program). Doug From: Matthew Hardeman [mailto:mharde...@gmail.com] Sent: Friday, January 19, 2018 1:45 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: r...@sleevi.com; Alex Gaynor <agay...@mozilla.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: TLS-SNI-01 and compliance with BRs One opinion I'd like to add to the discussion... In as far as that at this point, it looks like it's time for guidance from the root programs officially on whether or not and under what circumstances TLS-SNI-01 and/or any other mechanism based on method #10 are allowable moving forward.... I'd like to point out that both Let's Encrypt recognized an issue and voluntarily disclosed and took measures in the direction of securing the WebPKI above and beyond any demands made of them. Additionally, GlobalSign was obviously diligent in their responsibility to monitor this mailing list and others and actively discern whether any ongoing discussion may pertain to their operations. As evidenced by their preemptive disclosure and shut down of their method #10 validation mechanism, they've shown strong adherence to the best practices espoused by this community -- actively monitoring the broad discussions and concerns and actively considering the impact of the issues surfaced in terms of their own CA operations. Ultimately, if it should arise that other CAs who rely on mechanisms implementing or claiming to implement method #10 have similar risk and vulnerabilities, those CAs should be called to task for not having timely disclosed and remediated. Further, perhaps those CAs should suffer the burden of mandatory revalidation under a different mechanism, as the vulnerability category has now been acknowledged in the community for some time and the recent press has been significant. In contrast, I think any remediation plan should reward Let's Encrypt and GlobalSign for their diligence and compliance to best practice. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
