Hi Doug,

Kathleen is unavailable this week, so I'll try and answer. (This might
have been better as a new top-level post, though...)

On 11/04/17 21:14, Doug Beattie wrote:
> This is my understanding: 
> - 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?

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?

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

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.

Of course, this is all related to:

dev-security-policy mailing list

Reply via email to