Hi Gerv,
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.
Section 5.3.1 and 5.3.2 imply no audit is needed
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.
Doug
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Doug
> Beattie via dev-security-policy
> Sent: Monday, May 8, 2017 12:47 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Email sub-CAs
>
> Hi Gerv,
>
> I wanted to get the latest Mozilla thoughts on the audit requirements for
> TCSCs based on the discussion we started last month. I understand the BR
> requirement if the CA can issue server auth certificates, this was discussed
> here:
>
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ZMUjQ6
> xHrDA/ySofsF_PAgAJ
>
> For TCSCs that can issue secure email certs, what are the requirements in the
> new policy, 2.4? I think they were excluded from audit requirement before,
> but in the latest Mozilla policy these CAs need to have a WT for CA audit even
> if they are Name Constrained.
>
> So here my questions:
>
> Was this an intentional change?
>
> Is the same true for TCSCs that can issue server auth certificates (even NC
> CAs
> need a webtrust for CA audit)?
>
> Are previously issued TCSCs exempt, if not, when would the audit period for
> them start?
>
> Do these CAs need to be publicly disclosed?
>
> Related tickets:
>https://github.com/mozilla/pkipolicy/issues/36
>
>https://github.com/mozilla/pkipolicy/issues/69
>
>
>
>
>
>
>
>
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> > douglas.beattie--- via dev-security-policy
> > Sent: Thursday, April 13, 2017 12:33 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Email sub-CAs
> >
> > On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham
> wrote:
> > > On 13/04/17 14:23, Doug Beattie wrote:
> > > > In 3.2 the term Technically Constrained is not defined to be any
> > > > different than the BRs (or perhaps even less restrictive).
> > >
> > > You mean 2.3, right?
> >
> > Yes, 2.3.
> >
> > > I would say Inclusion section, bullet 9 gives the definition of
> > > technically constrained. For email certs, because of the bug
> > > described in issue #69, it basically just says that it has to have
> > > the id-kp-emailProtection EKU. It should say more, but it doesn't.
> > > That's problematic, because just having an EKU isn't really a
> > > technical constraint in the "TCSC" sense.
> > >
> > > > 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?
> > >
> > > If they did not include id-kp-serverAuth, I would not have faulted a
> > > CA for not disclosing them if they met the exclusion criteria for
> > > email certs as written.
> >
> > OK.
> >
> > > > 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?
> > >
> > > I think this is basically issue #69.
> > > https://github.com/mozilla/pkipolicy/issues/69
> >
> > OK, I look forward to a conclusion on that. I hope that name
> > constraining a secure email CA (either technically in the CA
> > certificate or via business
> > controls) is sufficient to avoid WebTrust Audits. If Public
> > disclosure helps get us there then that would be acceptable.
> >
> > > I don't think it was supposed to be the case that intermediates with
> > > id-kp-emailProtection alone were
