Draft Email - Non-Disclosed SubCAs

[Kathleen Wilson]

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

[Florian Weimer]

* 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?

[Kathleen Wilson]

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

[Gervase Markham]

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

[Peter Bowen]

On Thu, Oct 20, 2016 at 1:09 PM, Kathleen Wilson <kwi...@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

[Ben Wilson]

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:pzb...@gmail.com>
Sent: ‎10/‎21/‎2016 10:08 AM
To: Kathleen Wilson<mailto:kwi...@mozilla.com>
Cc: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Draft Email - Non-Disclosed SubCAs

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

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

[Peter Bowen]

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.w...@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-s...@lists.mozilla.org

[Jakob Bohm]

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

[Kathleen Wilson]

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 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.

If you are still unclear about which intermediate certificates your CA still needs to disclose in the CA Community in Salesforce, you may view the data here: https://crt.sh/mozilla-disclosures#undisclosed

[Gervase Markham]

On 26/10/16 22:02, Kathleen Wilson wrote:
> 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.

But isn't there a field in Salesforce for "audit PDF URL" which they
need to fill in? So we need to tell them what to write. Do we want them
to leave it blank? Or put "not available"? Or something else?

> 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.

> ~~ 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"

Gerv

[Rob Stradling]

On 27/10/16 09:31, Gervase Markham wrote:
> On 26/10/16 22:02, Kathleen Wilson wrote:

<snip>

>> 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

[Kathleen Wilson]

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 Technically Constrained via Extended Key Usage and Name Constraint settings.

If you are still unclear about which intermediate certificates your CA still needs to disclose in the CA Community in Salesforce, one resource for identifying such intermediate certificates is here: https://crt.sh/mozilla-disclosures#undisclosed

[Kathleen Wilson]

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
Atos 3
Autoridad de Certificacion Firmaprofesional 6
Camerfirma 19
certSIGN 6
China Internet Network Information Center (CNNIC) 1
Chunghwa Telecom Corporation 1
Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) 2
Cybertrust Japan / JCSI 1
Dhimyotis / Certigna 24
EDICOM 1
e-tugra 4
Government of Japan, Ministry of Internal Affairs and Communications 1
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ó CA 4
NetLock Ltd. 5
QuoVadis 9
RSA the Security Division of EMC 20
SECOM Trust Systems Co. Ltd. 13
Swisscom (Switzerland) Ltd 8
SwissSign AG 20
Trustis 4
TurkTrust 12
Visa 2
WISeKey 1
~~

Thanks,
Kathleen