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? 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. > 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 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-version-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)? 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? > 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)? > 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. > 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. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
