Thanks Kathleen, I realize these questions are delayed and apologize for not raising them sooner. As mentioned, I do not believe DigiCert has a concern meeting these policies (which is why they weren't a concern before). However, I figure we should address the issues now rather than later since there will be some CAs who, operating purely under the BRs, will be (very) surprised to find that the Mozilla policy is out of alignment with what the Forum's disclosure requirements. Announcing a map of customers is a scary prospect for a CA who believed they were following best practices and naming their intermediates accurately.
Also, the technical constraint of serverAuth won't work properly since anyEKU (or a lack of EKU) is required in some grid, EU, and fed space certs. Unfortunately, their policies conflict with the technical constraints Mozilla hopes to implement. Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson Sent: Monday, May 12, 2014 6:26 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DRAFT: May CA Communication On 5/12/14, 5:06 PM, Jeremy Rowley wrote: >>From what I can tell, the new Mozilla policy covers both SSL and >>client cert > issuing intermediates. There are some interesting complications with > client certs that some CAs may experience since client certs are often > used only for access control and not easily discoverable. Plus, many > enterprises use the intermediate solely with private networks, making > even the SSL certs issued from the intermediate fairly > non-discoverable. A policy to publicly disclose this info will result > in more ambiguous names and, possibly, a lot of hurried key ceremonies > to try and mask the name of the networks protected by intermediates. The "new Mozilla policy" was published in February 2013. https://blog.mozilla.org/security/2013/02/15/announcing-version-2-1-of-mozil la-ca-certificate-policy/ https://wiki.mozilla.org/CA:Communications#January_10.2C_2013 https://wiki.mozilla.org/CA:CertificatePolicyV2.1 So why are these questions coming up now at the end of the grace period? The technical constraints for intermediates that issue client certs are very easy. Basically, any intermediate cert that will not be issuing SSL certs that need to be recognized by Firefox, just needs to include the EKU extension and *not* include the id-kp-serverAuth (the SGC EKU for now). > > May 30th is an awfully short date to review this information, make the > necessary changes to intermediate names (to avoid potentially > violating confidentiality clauses), and report back to Mozilla. I > assume that is the purpose of the legacy system exemption. Can any CA > claim "legacy system" to freely buy themselves more time to rename intermediates? Again, this was announced in early 2013. The purpose of the current communication is to find out how CAs have done with this. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Technical_Constraints_or_A uditing.2FDisclosure_of_Intermediate_Certificates -- Items #8, 9, and 10 of Mozilla's CA Certificate Inclusion Policy describe how intermediate certificates must either be technically constrained or be audited and publicly disclosed. All subordinate CA certificates that are issued after May 15, 2013 must comply with version 2.1 or later of Mozilla's CA Certificate Inclusion Policy All pre-existing subordinate CA certificates must be updated to comply with version 2.1 or later of Mozilla's CA Certificate Inclusion Policy for new certificate issuance by May 15, 2014. A pre-existing externally-operated subordinate CA certificate that expires before May 15, 2014 may be re-issued in order to extend the validity period of the currently-valid intermediate CA certificate until May 15, 2014. That is, the replacement certificate's notAfter date would be May 15, 2014 or earlier. All certificates that are capable of being used to issue new certificates must comply with version 2.1 or later of Mozilla's CA Certificate Inclusion Policy for new certificate issuance by May 15, 2014. -- > What if the legacy >> system needs to be private for another 15 years? Should a timeline >> be given about when the phase-out should occur? Or is that subject to >> private negotiations between Mozilla and the CA? The requested time frames will be published in the tabulated CA Responses. A few months would probably be acceptable, depending on the reasons, which I would only briefly summarize in the tabulated CA responses. Kathleen _______________________________________________ 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
