> -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of Gervase > Markham via dev-security-policy > Sent: Wednesday, April 12, 2017 4:45 AM > To: mozilla-dev-security-pol...@lists.mozilla.org
> > - Under policy 2.3 a CA that is technically constrained with EKU set > > to only secure email but without name constraints was considered out > > of scope of the Mozilla Policy. > > Which parts of policy 2.3 lead you to that conclusion? > https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md In 3.2 the term Technically Constrained is not defined to be any different than the BRs (or perhaps even less restrictive). In 3.2 this is all I can find regarding CAs that are capable of signing secure email certificates, section 9: "If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or mailboxes that the issuing CA has confirmed (via technical and/or business controls) that the subordinate CA is authorized to use." There is no statement back to scope or corresponding audits. Were secure email capable CAs supposed to be disclosed and audited to Mozilla under 2.3? Section 8 implies that if it's technically constrained then it does not need to be disclosed and audited: "All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla's CA Certificate Program, MUST be operated in accordance with Mozilla's CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited." Combine this with the definition, or lack thereof, of TCSC and how it applies to Secure email, I don't see how TCSCs with secure email EKU fall within the scope of the Mozilla Policy 2.3. Can you help clarify? > 2.3 does not have an explicit scope statement, something we fixed in 2.4. > > Policy 2.3, Application section, bullet 9, defines rules for technically > constrained > certificates, including a section giving rules for certs issued by technically > constrained email sub-CAs. How do you then see these as out of scope? The definition of Technically Constrained in this policy does not apply to secure email certificates, as far as I can determine. It just says you need an EKU and is must not be anyExtendedKeyUsage. This is actually less restrictive than the BR definition. > > - Policy 2.4.1 adds a requirement that for the CA to be out of scope > > of the Mozilla policy the CA needs to have name constraints if the CA > > is capable of issuing secure email certificates. > > Which parts of policy 2.4.1 lead you to that conclusion? > https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md > OK, you're right, the number of negatives in that section got me. So, even when EKU permits just secure email, having name constraints does not exempt a CA from the Mozilla policy. It does for BRs since email is not within scope (and discussed on the link you included in the response). When I saw TCSC references I personally didn't realize that this was different than the BR definition of TCSC (maybe should have called this something different). Section 3.1.2.1 specifies that any CA capable of issuing secure email certificates must have a "WebTrust for CAs" audit (or corresponding ETSI audit). This is a huge change from 3.2 and I wonder if all CAs understand this. Even the Blog about this version does not highlight this substantial change: https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/ Obviously there are a lot of technically constrained CAs issued to organizations to run their own CAs for issuing secure email and client auth certificates. In order for them to continue operations they now every organization needs to be publicly reported and audited (a new requirement for 2.4.1 as far as I can tell), is that right? When did (does) this take effect? Is this for new CAs, existing or both? When would the Audit Period for these CAs need to begin? This is a side question, but does the Mozilla policy require that these CAs meet the Network Security Requirements? > Section 1.1.2 of 2.4.1 says that sub-CAs are included in the overall scope > statement. There are two ways to be exempted - not be capable of issuing email > certificates, or be name-constrained. So I assume you are referring to 1.1.2, > bullet 2. But this says that to be exempted, you need to be not issuing any > form > of rfc822Name - in other words, it's a way of turning off email entirely > using a > different technical mechanism. > This bullet is not met if you have name constraints which restrict you to > particular email domains. > > So I would say that an email-only sub-CA which is name-constrained to certain > domains is currently still in scope. And, indeed, section 5.3.1 is the new > analogue of the old Application section, bullet 9 mentioned above, and > contains > the same language governing certs issued by technically constrained email-only > sub-CAs. Section 5.3.2 says that all CAs of the type I'm discussing must be in the CCADB. What's the timeline for CAs to upload them? > Of course, this is all related to: > https://github.com/mozilla/pkipolicy/issues/36 > :-) > > Gerv > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
