Thanks for your feedback Gerv, On Friday, 2 September 2016 11:19:49 UTC+1, Gervase Markham wrote: > Have you considered what was done for CNNIC? In that case, we distrusted > all certificates issued after a certain time. We used a whitelist for > determining this, but it would be possible to use the notBefore date in > the certificate. A CA could dodge this by backdating, but if the CA were > also committed to putting all its certs in to CT, then the backdating > would be noticeable.
That's a good point, I knew of the CNNIC outcome but didn't add it to my list. It has the obvious GOOD factor that we know Mozilla can successfully do it. I suspect that a whitelist will almost always prove necessary. Even the suspicion of backdating happening undermines the value of this sanction. > > 2. Create "at risk" category for problematic CAs > One issue to consider with this option would be that reputational damage > is harder to quantify and control than a technical measure, which might > be said to increase the risk that the action would be disproportionate. The intention of my "leave the programme" option was to mitigate this risk. If the CA thinks it would be worse to have reputational damage from the "at risk" declaration than be distrusted, they're free to leave Mozilla's trust store programme entirely instead. > > Finally, I would like to mention, though I expect it to be shot down, > > a much more radical way forward. RP audits. Relying Party audits. > Some issues to consider with this approach would be: > > * How does the money to pay for such audits flow from the CA to the > auditor, and through whom? Collected by an arms length contractor on a volume basis, see e.g. how Advertising Standards Agency is funded in UK. This gets easier with CT because volume stops being speculative. The exact funding structure (e.g. logarithmic on certs issued? thresholds for validity months x number of certs?) would be chosen by the arms length contractor to meet an overall funding goal. > * Who chooses the auditors? Major Trust Stores like Mozilla on behalf of their relying party users. You could build a big clumsy bureaucracy around this but I think the big 3-4 could just settle it among themselves e.g. cut the list of CAs up and take some each, or rotate responsibility. > * How do you make sure they remain independent when their funding is > (even indirectly) from the CAs? Pooling effect of funding this way dilutes corrupting influence of money. Reporting to trust stores rather than to CA reminds auditors who they're representing. Keep in mind that today the funding is indirectly from subscribers, but auditors don't usually meet one, so why think about it? > * How do you deal with confidentiality issues? CAs have some things they > legitimately wish to keep confidential. And yet such an auditor would > need full access to all their infra and business processes. It may be necessary to carefully draft a standard agreement for this purpose. I've never seen an auditor be confused about whether it's appropriate to disclose things like passwords, exact locations of secure facilities, identities of key employees etc. This is not their first rodeo. In my experience too often the "legitimate wishes" of an audit subject involve not disclosing the very sort of things the audit is in fact intended to unearth, such as unmitigated risks and poorly conceived processes. So "too bad" has to be the answer in those cases. > * Is it a problem that adding additional costs to becoming a CA > discourages new and possibly innovative companies from entering the market? Ultimately the goal would be that RP audits would be either cost neutral (assuming the eventual elimination of the current less than ideal audit system) or only slightly more expensive (reflecting costs from choosing higher quality auditors or from more thorough conduct of the audits) If we want to make it cheaper, my understanding is that the _utterly_ useless insurance requirement is still there. If one RP audit finds one bug before it bites us in the real world that was already a better investment than all the insurance ever purchased by CAs in the history of the web PKI as far as I know. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
