If I create a new sub CA on a weekly basis, will that mean that I have to republish my CPS every week? That makes absolutely no sense.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On Behalf Of Dimitris Zacharopoulos via dev-security-policy Sent: Thursday, April 5, 2018 12:56 PM To: r...@sleevi.com Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Wayne Thayer <wtha...@mozilla.com> Subject: Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates On 5/4/2018 9:00 μμ, Ryan Sleevi via dev-security-policy wrote: > On Thu, Apr 5, 2018 at 5:20 AM, Dimitris Zacharopoulos via > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > >> On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote: >> >>> In a recent discussion [1] we decided to clarify the audit >>> requirements for new subordinate CA certificates. I’ve drafted a >>> change that requires the new certificate to appear in the next >>> periodic audits and in the CP/CPS prior to issuance: >>> >>> https://clicktime.symantec.com/a/1/uK18WYwZQOQJdKx7xZlajZuBM8yRGOSgy >>> j1SoIDpakw=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv >>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy >>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k >>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG >>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX >>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt >>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c >>> Isp_BE0uutKBEGOnmgO6cd&u=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipol >>> icy%2Fcommit%2F09867ef4a0db3b1c >>> ab162930c0326c84d272ec10 >>> >>> We also discussed requiring root key generation ceremony (RKGC) >>> audit reports, but I have since realized that the BRs (section >>> 6.1.1.1) only require these audit reports for new root certificates. >>> I’m not convinced that we should begin requiring an auditor’s report >>> every time a new subordinate CA certificate is created. >>> >>> I would appreciate everyone's comments on this proposed change. >>> >>> This is: >>> https://clicktime.symantec.com/a/1/H6tO2jUY3sZd2sXgMqg8Ay069QdOne7oi >>> y4J1W4xQsI=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv >>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy >>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k >>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG >>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX >>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt >>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c >>> Isp_BE0uutKBEGOnmgO6cd&u=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipol >>> icy%2Fissues%2F32 >>> >>> [1] >>> https://clicktime.symantec.com/a/1/wkXkHi0pu4wDxDHEw6Kx8SMY_1-Pcpybd >>> w-Yf2WFJ7M=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv >>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy >>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k >>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG >>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX >>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt >>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c >>> Isp_BE0uutKBEGOnmgO6cd&u=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2 >>> Fmozilla.dev.security.policy%2F >>> CAaC2a2HMiQ/IKimeW4NBgAJ >>> ------- >>> >>> This is a proposed update to Mozilla's root store policy for version >>> 2.6. Please keep discussion in this group rather than on GitHub. >>> Silence is consent. >>> >>> Policy 2.5 (current version): >>> https://clicktime.symantec.com/a/1/5agl31kcRVdv5wJIFH5-P76QaiWh638Yf >>> cxtaF8uZWQ=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv >>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy >>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k >>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG >>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX >>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt >>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c >>> Isp_BE0uutKBEGOnmgO6cd&u=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipol >>> icy%2Fblob%2F2.5%2Frootstore%2Fpolicy.md >>> _______________________________________________ >>> dev-security-policy mailing list >>> dev-security-policy@lists.mozilla.org >>> https://clicktime.symantec.com/a/1/p8d7MblLB4xZGE-0GeE31x3kiYA3Sm1js >>> xtAab6FZFU=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv >>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy >>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k >>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG >>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX >>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt >>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c >>> Isp_BE0uutKBEGOnmgO6cd&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo% >>> 2Fdev-security-policy >>> >>> >> I will copy the proposed change here for convenience: >> >> " >> >> 1. MUST be audited in accordance with Mozilla’s Root Store Policy. If >> the subordinate CA has a currently valid audit report at the time of >> creation of the certificate, it MUST appear on the subordinate CA's >> next periodic audit reports. >> 2. MUST be publicly disclosed in the CCADB by the CA that has their >> certificate included in Mozilla’s root program. The CA with a >> certificate included in Mozilla’s root program MUST disclose this >> information within a week of certificate creation, and before any >> such subordinate CA is allowed to issue certificates. All disclosure >> MUST be made freely available and without additional requirements, >> including, but not limited to, registration, legal agreements, or >> restrictions on redistribution of the certificates in whole or in part. >> 3. MUST be added to the relevant CP/CPS before issuing certificates. >> >> " >> >> I kind of disagree with 3. The new Subordinate CA Certificate MUST be >> added to CCADB (per 2.). It MUST be covered by the audit (per 1.) and >> show up in the next report. If a Subordinate CA is operated by the >> Root operator, a change in the CP/CPS could probably be just an >> addition of the Distinguished Name and a SHA fingerprint. However, >> CPS changes require administrative work and several levels of >> approval which IMHO is not worth the effort for such an addition. I don't >> see such a big value for 3. >> compared to 1. and 2. >> > Do you see this as a frequent occurrence such that the overhead of > performing this is greater than the value derived by the community in > having this information? > I will call the specific scenario below "a rollover subCA". I think rollover subCAs are issued frequently, several times per year depending on the size of the CA and their practices. From 2. the community has this information so it seems redundant. >> Consider the case where you have a Subordinate CA Certificate that >> you need to update because you want to change the hashing algorithm >> (SHA1 --> SHA256), or change the key size, or renew. This would lead >> to a new subCA Certificate with CN "My Subordinate CA Certificate >> R2", "My Subordinate CA Certificate R3" and so on. The controls >> would be exactly the same as the previous subCA Certificate. >> > Except how does the community know and verify that those controls are > the same? How does the community know and verify if those controls change > (e.g. > the subordinate CA is immediately sold to a third-party and/or > transferred to them) > I understand the concern, so why don't we write policy language to address this concern rather than making it so broad and cause administrative overhead for not so much value compared to the other points? What you're describing looks like a rare case. Something along the lines of "If a new Subordinate CA Certificate is issued and not included in the currently published CP/CPS, it must be maintained by the Root CA Operator and must appear in the next audit report" might address this concern. >> The 3rd requirement might make more sense for externally operated >> Subordinate CAs. According to BRs 6.1.1.1, Key Pairs that are >> generated for SubCAs not to be used by the Root CA operator or an >> Affiliate (meaning an externally operated Subordinate CA), MUST be >> witnessed by a Qualified Auditor (or record the ceremony and get an >> opinion letter afterwards). It seems that the BRs require some >> special treatment when a SubCA Key Pair is generated for an >> externally operated entity. Is it worth the effort to reflect a similar >> distinction in the Mozilla Policy? >> > That covers the key generation - but if the subCA is first generated > for the CA, and then later transferred to a third-party - which is > something that has happened - it's a loophole in both policies and practices. This loophole seems to exist in the current BRs and we should probably address it at the CA/B Forum venue. It sounds like what you described, defeated the purpose of the 6.1.1.1 differentiation between internal and external subCA. You can't beat the "creativity" of some CAs... Do you think publishing this new subCA in the CP/CPS solves this particular problem? The CA could still sell the certificate and then update its CP/CPS to remove that subCA, which would need to appear in another CP/CPS. I guess what I'm saying is that each subCA, if things are audited properly, should turn up in a CP/CPS somewhere either in the Issuing CA's CP/CPS or in an externally operated subCA's CP/CPS. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/p8d7MblLB4xZGE-0GeE31x3kiYA3Sm1jsxtAab6FZFU=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNvY3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-kTB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREGk0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYXeVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt_Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9cIsp_BE0uutKBEGOnmgO6cd&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
