> -----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 

> 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 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 

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

Reply via email to