Hi, Thanks for the extensive document and information, it has been a throughly interesting read.
On Tuesday, 27 September 2016 00:21:13 UTC+10, Gervase Markham wrote: > > Because this document is extensive and contains embedded images, links > and formatting, I have published it on Google Docs instead of as an > email message here: > > https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit > > However, this forum is the appropriate place for discussing it. Please > feel free to cut and paste any parts you wish to quote and comment on. Thoughts: > no longer accept audits carried out by Ernst & Young (Hong Kong). I think that punishing the auditor here but geographically constraining it is the wrong message to send. Why not simply distrust all audits carried out by Ernst & Young? Either someone at Ernst & Young HQ (london) signed-off of this kind deception (if it was known), or they signed-off on an audit when it was improperly conducted, or they signed-off on an audit when the sub-ordinate company was unable to obtain all the infomration required. Or, worse, they have no control at all over their sub-ordinate company. > How much lead time does the ecosystem need before we take this action? I think that this should be a standard security update > Should StartCom/WoSign be permitted to re-apply using the same roots, or > would they need new roots? They should be required to use new roots. I think another set of sanctions you (Mozilla) could also apply are: - anyone issuing certificates for .cn, .hk or .mo domain *MUST* submit those certificate to the CT server set (with similar constraints as you require for WoSign/StartCom) - constrain certificates issued to .cn, .hk, .mo domains to be valid for (at most) 2 years. The rationale for those additional suggestions is that this might preclude any organisation from being pressured into issuing certificates with fraudulent information within them and, even if that were to occur - and not be detected for a while - you have also constrained the maximum exposure window. Regards, Anand _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
