OK so there is policy. But what about enforcement. At the moment we only have accountability controls. Can we turn them into access controls?
On Thu, Apr 2, 2015 at 10:45 AM, Richard Barnes <[email protected]> wrote: > > > 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
