On Thu, Apr 2, 2015 at 9:41 AM, Gervase Markham <g...@mozilla.org> wrote: > On 02/04/15 12:42, Sebastian Wiesinger wrote: >> the plan would be to continue allowing current certificats (perhaps >> with some sort of whitelist) while not accepting new certificates. >> >> Could you ask Google to share their whitelist? > > Until they announced, we were not aware that Google would be requesting > a whitelist. It is quite possible CNNIC will supply us both with the > same data. > >> As far as I understand it, without an explicit whitelist nothing would >> prevent CNNIC to backdate new certificates so that they would be >> accepted. Is this right or am I missing something? > > Well, if anyone detects them doing this, by e.g. scanning the internet, > the consequences will be serious. I have no reason to believe that they > would backdate certs but if they did, they would need to be very > confident that no-one would notice. If I owned CNNIC, I would not be at > all confident of this.
Organizations are funny things. Facing a choice of coming clean, admitting a mistake and moving on versus a cover up, pretty much every rational CEO will choose the first. Faced with a choice between getting fired for making a mistake and making a pathetic attempt to cover up with a small chance of success, a rational junior manager will choose the second. I think we need to rethink how the principle of least privilege applies here and make sure we are doing everything we can to minimize risk. As a matter of policy, no cert should ever issue for a private key that is not under the direct control of a CA unless one of the following apply to the corresponding cert: 1) The other party has CP, CPS and full audit for operating a CA. 2) There is a name constraint. 3) It is an end entity certificate. Further no private key should ever be in a network accessible device unless the following apply: 1) There is a path length constraint that limits issue to EE certs. 2) It is an end entity certificate. Perhaps we should take this to the IETF right key list. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
