On Fri, Jan 19, 2018 at 2:58 PM, Doug Beattie <[email protected]> wrote:
> 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? > > I wouldn't necessarily go that far as yet. The only ones who can speak to that are the root programs. The limited guidance available so far suggests that they won't tolerate perverse consequences to continue even if the method is BR compliant. Certainly, there would be no shortage of supporters for removal of the #9 and #10 methods as written. > > > 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? > One would think there must be no others. In the alternative, someone is dilatory. > > > 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). > > > Therein is the real question. If we go with the assumption that the vulnerable methods are in fact BR compliant, someone should probably fix the BRs. More urgently, perhaps the root programs should all issue guidance on acceptability of these methods or mitigations over the methods. The obvious safe leap of logic to make is to assume in the most securely constrained light: that all the root programs reject the mechanism underlying a method which has significant demonstrable holes when applied in the real world. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
