On Thursday, October 20, 2016 at 2:24:19 PM UTC-7, Florian Weimer wrote: > > Does this requirement apply transitively sub-CAs of sub-CAs? > > It may make sense to stress explicitly that the “technically > constrained” refers to properties visible in the certificates > themselves, not technical measures in the certificate issuance process > (which I would consider organizational constraints, but opinions > probably differ).
Good points. Updated draft... ~~ Subject: ACTION REQUIRED: Non-Disclosed non-technically-constrained Intermediate Certs Dear Certification Authority, You are receiving this email because our records indicate that there are non-technically-constrained intermediate certificates that chain up to your root certificates that are included in Mozilla’s program that have not been entered into the CA Community in Salesforce. Please complete this requirement by November 14, 2016. Soon after that date, Mozilla will begin discussions in the mozilla.dev.security.policy forum about action to take for any remaining non-disclosed non-technically-constrained intermediate certificates and the CAs who are responsible for those CA hierarchies. The following was stated in Mozilla’s March 2016 CA Communication (https://wiki.mozilla.org/CA:Communications#March_2016): Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please see https://wiki.mozilla.org/CA:SalesforceCommunity for information about which intermediate certificate data you are expected to enter into the CA Community in Salesforce, and instructions on how to do so. In particular, CAs must add records to the CA Community in Salesforce for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program that are not Technically Constrained via Extended Key Usage and Name Constraint settings. Intermediate certificates are considered to be technically constrained, and do not need to be added to the CA Community in Salesforce if: - The intermediate certificate has the Extended Key Usage (EKU) extension and the EKU does not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth; or - The EKU extension in the intermediate certificate includes the anyExtendedKeyUsage or id-kp-serverAuth KeyPurposeIds, and the intermediate certificate includes the Name Constraints extension as described in section 7.1.5 of the CA/Browser Forum's Baseline Requirements; or - The root certificate is not enabled with the Websites trust bit. Records should also be added to the CA Community in Salesforce for revoked certificates that were capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program and were not Technically Constrained via Extended Key Usage and Name Constraint settings. Regards, Kathleen Wilson, Mozilla CA Program Manager ~~ > > What about sub-CAs with outdated published policies which do not meet > Mozilla's requirements, but where the CA actually issues certificates > according to an unpublished policy which is likely conforming to > Mozilla's requirements? I'm not sure what that question means. Thanks, Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
