Re: Draft Email - Non-Disclosed SubCAs
I have sent the email to the following CAs. Root Owner | # Certs still to add to Salesforce Actalis 2 Asseco Data Systems S.A. (previously Unizeto Certum)1 Atos3 Autoridad de Certificacion Firmaprofesional 6 Camerfirma 19 certSIGN6 China Internet Network Information Center (CNNIC) 1 Chunghwa Telecom Corporation1 Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) 2 Cybertrust Japan / JCSI 1 Dhimyotis / Certigna24 EDICOM 1 e-tugra 4 Government of Japan, Ministry of Internal Affairs and Communications1 Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)3 Government of Taiwan, Government Root Certification Authority (GRCA)15 Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) 3 Internet Security Research Group (ISRG) 4 Izenpe S.A. 9 Microsec e-Szignó CA4 NetLock Ltd.5 QuoVadis9 RSA the Security Division of EMC20 SECOM Trust Systems Co. Ltd.13 Swisscom (Switzerland) Ltd 8 SwissSign AG20 Trustis 4 TurkTrust 12 Visa2 WISeKey 1 ~~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
On Thursday, October 27, 2016 at 4:14:35 AM UTC-7, Rob Stradling wrote: > So, to ensure that no CA can claim that they didn't know, I'd like to > see the "must keep disclosing intermediates to Salesforce on an ongoing > basis" requirement explicitly stated: > 1. in the next version of the Mozilla CA Policy. Noted here: https://wiki.mozilla.org/CA:CertificatePolicyV2.3#General_Policy_Cleanup > 2. in the next CA Communication. Noted in my list for the next CA Communication to all CAs. This is currently on hold, awaiting for when the New Validation Rules in BRs are all settled. I started the new section in the wiki page: https://wiki.mozilla.org/CA:SalesforceCommunity#CA_Responsibilities Will appreciate feedback on it. Note that the email draft has been updated to point to this section in the wiki page. Here's the updated text for this current email that I will hopefully send out today using the new email capability that we added to the production instance of the CA Community in Salesforce yesterday. ~~ Subject: ACTION REQUIRED: Non-Disclosed non-technically-constrained Intermediate Certs Message: Dear Certification Authority, You are receiving this email because we have become aware 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. The deadline for CAs to disclose their intermediate certificate data in the CA Community in Salesforce was June 2016. Mozilla is going to 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. Please see https://wiki.mozilla.org/CA:SalesforceCommunity#CA_Responsibilities 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. 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. 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
Re: Draft Email - Non-Disclosed SubCAs
On 27/10/16 09:31, Gervase Markham wrote: > On 26/10/16 22:02, Kathleen Wilson wrote: >> Please see >> https://wiki.mozilla.org/CA:SalesforceCommunity#CA_Community_in_Salesforce >> and let me know if you still think we need to add a sentence to the >> wiki page stating that CAs are expected to maintain this data on an >> ongoing basis. > > Well, like I said, it should be obvious to anyone with half a brain but > explicit is always clearer than implicit. Being explicit also allows us > to set expectations about how quickly the info is updated after events, > e.g. how soon must new intermediates be reported. +1 Kathleen, >From previous discussions on this list and from reading... https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F ...and other wiki pages, it's obvious to me that you expect CAs to maintain this data on an ongoing basis. However... It was I who suggested to Gerv (at the CABForum F2F last week) that this point needs to be stated to CAs more explicitly. Yes, https://wiki.mozilla.org/CA:SalesforceCommunity is clear, but is it actually fair to assume that all CAs are aware that that wiki page essentially forms part of Mozilla's CA policy? The March 2016 CA Communication said... "Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016." "Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates...The date that you enter must be on or before June 30, 2016" ...which made it sound like a one-time census, rather than an ongoing requirement. Whilst I think it's obvious to all CAs that your CA Communications essentially form part of your CA Policy, I suspect it's _not_ obvious to all CAs that the same is true of (at least some of) your wiki pages. So, to ensure that no CA can claim that they didn't know, I'd like to see the "must keep disclosing intermediates to Salesforce on an ongoing basis" requirement explicitly stated: 1. in the next version of the Mozilla CA Policy. 2. in the next CA Communication. >> ~~ Subject: ACTION REQUIRED: Non-Disclosed >> non-technically-constrained Intermediate Certs >> >> Dear Certification Authority, >> >> You are receiving this email because our records indicate > > Well, Rob Stradling's records indicate :-) We might instead say that > "because we have become aware" +1 It's great that folks are finding https://crt.sh/mozilla-disclosures useful, but clearly it's not an authoritative Mozilla data source. Trust, but verify. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
To be clear, this particular email will just be going to the CAs listed here: https://crt.sh/mozilla-disclosures#undisclosedsummary The intention of the email is to remind those CAs that they have an overdue action item, that needs to be completed. It is not the intention of this email to clarify policy around intermediate certificate disclosure. > what to do about intermediate CAs which were created since the last audit. > We should work out what to do about that, at least in the short term, I agree that I should add a section about that to https://wiki.mozilla.org/CA:SalesforceCommunity I don't agree that it needs to be resolved before reminding these particular CAs about their overdue action items. If they fall into that category, then they can respond to my email stating that. > Disclosed, but audit and CP/CPS data incomplete To be handled differently... I plan to add automation to Salesforce that will send email to CAs with intermediate cert data that has incomplete or outdated audit/CP/CPS information in Salesforce. (similar to the automated audit reminder emails that get sent to CAs regarding their included root certs.) > uploading intermediates > to the Common CA Database is an ongoing responsibility, not just a > one-off task. This should be kind of obvious, but at least one person at > the CAB Forum suggested it needed making more clear. Please see https://wiki.mozilla.org/CA:SalesforceCommunity#CA_Community_in_Salesforce and let me know if you still think we need to add a sentence to the wiki page stating that CAs are expected to maintain this data on an ongoing basis. > For CA certificates signed or cross signed after the June deadline, > there is an ongoing requirement to enter them within ? calendar days > (?? hours) after signing them, preferably earlier. > > For all the CA certificates entered in SalesForce, there is an ongoing > requirement to keep the information up to date, e.g. when there are > updates to audit reports, policy documents, ownership etc. Generally > within ?? calendar days (??? hours) after these changes occur. In > particular, changes of ownership should be reported as soon as they are > operational facts, even if the legal process of ownership change has > not yet completed. Perhaps I need to add a section called "CA Responsibilities" to https://wiki.mozilla.org/CA:SalesforceCommunity Here's the current draft of the email that I plan to send to the CAs listed in https://crt.sh/mozilla-disclosures#undisclosedsummary ~~ 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. The deadline for CAs to disclose their intermediate certificate data in the CA Community in Salesforce was June 2016. Mozilla is going to 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
Re: Draft Email - Non-Disclosed SubCAs
On 21/10/2016 00:24, Gervase Markham wrote: On 20/10/16 15:05, Kathleen Wilson wrote: 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. I don't think we should set another deadline. We should remind them that the deadline was June, tell them to do it ASAP, and warn them that we could begin discussions about taking action at any time. 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. There is an open question, raised by Peter Bowen in CAB Forum, of what to do about intermediate CAs which were created since the last audit. We should work out what to do about that, at least in the short term, before sending this message. I think this could be covered together with the other issue you mentioned by a text similar to: For CA certificates signed or cross signed after the June deadline, there is an ongoing requirement to enter them within ? calendar days (?? hours) after signing them, preferably earlier. For all the CA certificates entered in SalesForce, there is an ongoing requirement to keep the information up to date, e.g. when there are updates to audit reports, policy documents, ownership etc. Generally within ?? calendar days (??? hours) after these changes occur. In particular, changes of ownership should be reported as soon as they are operational facts, even if the legal process of ownership change has not yet completed. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
Ben, That is a good point, but I was more looking at ones where there link is readily available. For example: https://www.quovadisglobal.nl/Bedrijfsinformatie/Accreditaties.aspx Right now one would have to go through many different possible reports to figure out which cover which Quovadis CAs. Thanks, Peter On Fri, Oct 21, 2016 at 9:33 AM, Ben Wilson <ben.wil...@digicert.com> wrote: > I think a one-click access to a PDF isn't available for some documents > stored in searchable databases. The only way to get to some documents is to > go to the database and conduct a search. > > From: Peter Bowen > Sent: 10/21/2016 10:08 AM > To: Kathleen Wilson > Cc: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Draft Email - Non-Disclosed SubCAs > > On Thu, Oct 20, 2016 at 1:09 PM, Kathleen Wilson <kwil...@mozilla.com> > wrote: >> 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. > > I think it would be good to clarify that "non-disclosed" includes > entries in the database that don't have valid information. For > example, the following entries are found in the Standard Audit field: > Available upon request > ETSI TS 102 042 (Available upon request) > Internal Audit > Revocation Pending, CA retired from use > > Additionally several entries are valid HTTP(S) URLs but either return > an error code when requested via GET or return a web page that does > not seem to be an audit report. > > Should the requirement be updated to state that each field should > contain a HTTP(S) URL for a PDF? > > Thanks, > Peter > ___ > 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
Re: Draft Email - Non-Disclosed SubCAs
On 20/10/16 13:09, Kathleen Wilson wrote: > Next week I expect to have a better capability for sending > notification emails to CAs. The first email I would like to try this > new tool on is regarding the CAs who have not disclosed all of their > non-technically-constrained intermediate certificates in the CA > Community in Salesforce (aka Common CA Database). One thing this email should make clear is that uploading intermediates to the Common CA Database is an ongoing responsibility, not just a one-off task. This should be kind of obvious, but at least one person at the CAB Forum suggested it needed making more clear. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Draft Email - Non-Disclosed SubCAs
I think a one-click access to a PDF isn't available for some documents stored in searchable databases. The only way to get to some documents is to go to the database and conduct a search. From: Peter Bowen<mailto:pzbo...@gmail.com> Sent: 10/21/2016 10:08 AM To: Kathleen Wilson<mailto:kwil...@mozilla.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Draft Email - Non-Disclosed SubCAs On Thu, Oct 20, 2016 at 1:09 PM, Kathleen Wilson <kwil...@mozilla.com> wrote: > 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. I think it would be good to clarify that "non-disclosed" includes entries in the database that don't have valid information. For example, the following entries are found in the Standard Audit field: Available upon request ETSI TS 102 042 (Available upon request) Internal Audit Revocation Pending, CA retired from use Additionally several entries are valid HTTP(S) URLs but either return an error code when requested via GET or return a web page that does not seem to be an audit report. Should the requirement be updated to state that each field should contain a HTTP(S) URL for a PDF? Thanks, Peter ___ 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
Re: Draft Email - Non-Disclosed SubCAs
On 20/10/16 15:05, Kathleen Wilson wrote: > 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. I don't think we should set another deadline. We should remind them that the deadline was June, tell them to do it ASAP, and warn them that we could begin discussions about taking action at any time. > 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. There is an open question, raised by Peter Bowen in CAB Forum, of what to do about intermediate CAs which were created since the last audit. We should work out what to do about that, at least in the short term, before sending this message. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
* Kathleen Wilson: > 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. 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). 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? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Draft Email - Non-Disclosed SubCAs
All, Next week I expect to have a better capability for sending notification emails to CAs. The first email I would like to try this new tool on is regarding the CAs who have not disclosed all of their non-technically-constrained intermediate certificates in the CA Community in Salesforce (aka Common CA Database). Those CAs may be seen in the table here: https://crt.sh/mozilla-disclosures#undisclosedsummary I will appreciate your thoughtful and constructive feedback on the following draft of the email. ~~ 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. Regards, Kathleen Wilson, Mozilla CA Program Manager ~~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
