Hi Doug,

On 18/05/17 12:03, Doug Beattie wrote:
> I'm still looking for audit guidance on subordinate CAs that have EKU
> of Server auth and/or Secure Mail along with name constraints.  Do
> these need to be audited?
> I'm looking at this:
> https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
> Section 1.1, item #2 implies yes, that these CAs are in scope of this
> policy and thus must be audited - correct me if I'm wrong if being in
> the policy means they need to be audited.

Being in scope of the policy means that you need to read the rest of the
policy as applicable. It doesn't necessarily mean they need to be
audited - whether they do or not depends on what the Audit section says
about what needs to be audited. If these certs weren't in the scope of
the policy, then whatever the Audit section said would be irrelevant.

> Section 5.3.1 and 5.3.2 imply no audit is needed

At the moment, if a server-auth intermediate is properly
name-constrained according to the BRs, it's a TCSC and does not require
an audit. As you know, there's a bug in the latest version of the policy
regarding email intermediates, but the intent is that is an email
intermediate is properly rfc822name-constrained, with the constraints
being domain-ownership-validated to be owned by your customer, it also
doesn't require an audit, otherwise it does.

> Prior versions of the policy (at least 1.3 and before), did not
> require audits for technically constrained CAs like the ones
> referenced above.  Further, it used to be OK if the "Name
> Constraints" applied for Secure Mail CAs was done via contractual
> methods, vs. in the CA certificate at a technical NC.  We have one
> remaining customer with a CA like this and we're not sure on how new
> policy requirements apply to this existing customer.  Your guidance
> is appreciated.

Contractual constraints are not considered sufficient under the current
version of the policy.

dev-security-policy mailing list

Reply via email to