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/ZMUjQ6xHrDA/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-versio > > > 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
