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 supposed to be considered TCSCs. > > > After all, certs with id-kp-serverAuth alone are not TCSCs; they > > > need to have Name Constraints as well. But you are right, that's > > > what the policy > > says. > > > > > > > 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-vers > > > > io > > > > n-2-4-ca-certificate-policy/ > > > > > > I didn't realise it _was_ a substantial change. Are you saying that > > > you used to think it was fine for email-only sub-CAs to have no > > > audits at all? Is this because you considered all such CAs to be > > > TCSCs (by the Mozilla definition)? > > > > Yes, we've been working hard to technically constrain all CAs and > > especially those operated outside of our infrastructure. We've been > > following the BR > > definition: Include EKUs in all CAs, and for those that include server > > auth or secure email, include name constraints. > > > > > Even if we didn't require it in our policy, I'm very surprised that > > > no-one else does. Which other root store policies have requirements > > > on email-only sub-CAs? > > > > Not that I know of. > > > > > > 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? > > > > > > This is issue #36 :-) > > > https://github.com/mozilla/pkipolicy/issues/36 > > > > > > Do the CAs you are thinking of in this category have name > > > constraints, or not (either actually in the cert, or via business > > > controls)? > > > > Yes - they are all either name constrained either via the certificate > > name constraints or via business controls. > > > > > > 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? > > > > > > https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment. > > > > OK > > > > > > 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? > > > > > > Well, let's figure out what the right thing to do is first. If it > > > turns out we've created new normative requirements accidentally, the > > > first thing to do is to decide whether that's what we meant. Only > > > then will we set some sort of sane implementation timeline. > > > > Thanks Gerv. > > > > > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
