On Thu, Apr 2, 2015 at 10:34 AM, Phillip Hallam-Baker <[email protected] > wrote:
> On Thu, Apr 2, 2015 at 9:41 AM, Gervase Markham <[email protected]> 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. > That's what the Mozilla policy already says! """ 10. ... All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program MUST be audited in accordance with Mozilla’s CA Certificate Policy and MUST be publicly disclosed by the CA that has their certificate included in Mozilla’s CA Certificate Program. The CA with a certificate included in Mozilla’s CA Certificate Program MUST disclose this information before any such subordinate CA is allowed to issue certificates. """ https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Indeed, the lack of disclosure and audit is the core of the concern in this case. --Richard > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
