1575530 - Camerfirma: Govern d'Andorra audits

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Juan Angel Martin]

Attachment: govern_andorra_serials.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

As a result of the annual audit performed to the intermediate certificate of the Government of Andorra to cover all the certificates issued by this intermediate certificate. This intermediate certificate does not issue SSL certificates only SMIME certificates.

This audit was carried out by the external provider Auren.

We were aware of the situation for the first time when we received the negative report that contained relevant deficiencies on July 29th, 2019.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

   1.- Perform the audit to the intermediate certificate of the Government of Andorra (July 17th, 2019)
   2.- Receive and review the negative report (July 29st, 2019),
   3.- Stop issuing certificates through the Government of Andorra Registration Authority which has the qualified audit report (July 31st, 2019)

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

After reaching an agreement with the Government of Andorra, they stopped issuing certificates on July 31st, 2019.

A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

7.373 certificates were identified (see below).
The first cert was issued: July 31, 2013
The last cert was issued: July 22, 2019

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

See the attached file

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

We had not performed any external audits before because this intermediate CA does not issue SSL certificates and for that reason, we did not include this intermediate CA in our scope for 2018.

Mainly audit has found issues in the RA procedures about technical environment. We depend on the annual audit to control the SubCA procedures and check the technical environment.List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

Firstly, we elaborated the first plan, which included on the following steps:

1. Stop issuing certificates (already done)
2. Ask the Government of Andorra for solving all non-conformities reported by the audits. By the end of September.
3. Schedule a Point in Time audit in order to prove that these non-conformities have been solved. By the end of October depending on auditor availability.
4. In the case that all non-conformities found have been resolved, issuance of a new intermediate CA certificate (also issued by ’Global Chambersign Root – 2008’). October 2019.
5. Revocation of the old intermediate CA certificate. October 2019.
6. Begin the issuance of new certificates for Andorra Government. November 2019
7. Three months after the beginning of issuing certificates with the new intermediate CA, the Government of Andorra must pass a Period of Time audit. February 2020.

When we informed the Government of Andorra about this plan, they stated that the fact of not being able to issue certificates to citizens, companies and public workers for three months would have a huge impact, due to the fact that Andorra has a very high level of implementation of eGovernment, so, they asked us for a grace period in order to reduce this impact.

Most of the non-conformities detected, which made auditors issue a qualified report were related to the Registration Authority.

In this case, the grace period we are proposing would only have impact over the first point of the initial plan, which would remain like that:

1. Stop issuing certificates through the Government of Andorra Registration Authority which has the qualified audit report (already done) and issue the certificates through a Camerfirma Registration Authority (August 26th).
2. Ask the Government of Andorra for solving all non-conformities reported by the audits. By the end of September.
3. Schedule a Point in Time audit in order to prove that these non-conformities have been solved. Before end October depending on auditor availability.
4. In the case that all non-conformities found have been resolved, issuance of a new subCA certificate (also issued by ’Global Chambersign Root – 2008’). October 2019.
5. Revocation of the old subCA certificate. October 2019.
6. Begin the issuance of new certificates for Andorra Government. November 2019
7. Three months after the beginning of issuing certificates with the new subCA, the Government of Andorra must pass a Period of Time audit. February 2020.

Comment 1

[Ryan Sleevi]

• The attached set of certificates does not meet the requirements set forth in https://wiki.mozilla.org/CA/Responding_To_An_Incident , namely:

  The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

• The intermediate certificate is not identified here
• It appears to be a report that, from the period 2013 - 2019, Camerfirma maintained a non-technically constrained sub-CA that was not disclosed and publicly audited. Without knowing which intermediate, it's unclear whether this was for SSL/TLS (required to be disclosed as communicated in May 2014 ) or for S/MIME (required to be disclosed and as communicated November 2017 ). Can you clarify?

Comment 2

[Juan Angel Martin]

(In reply to Ryan Sleevi from comment #1)

• The attached set of certificates does not meet the requirements set forth in https://wiki.mozilla.org/CA/Responding_To_An_Incident , namely:

  The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

See attached file. 6.935 certificates (we’ve withdrawn the expired certificates)

• The intermediate certificate is not identified here

Intermediate certificate: CN=Entitat de Certificació de l'Administració Pública Andorrana. Subject Key Identifier: A6:B0:51:FD:9B:A0:46:48:2D:45:74:14:95:F7:D6:E2:9B:EF:F9:1E

• It appears to be a report that, from the period 2013 - 2019, Camerfirma maintained a non-technically constrained sub-CA that was not disclosed and publicly audited. Without knowing which intermediate, it's unclear whether this was for SSL/TLS (required to be disclosed as communicated in May 2014 ) or for S/MIME (required to be disclosed and as communicated November 2017 ). Can you clarify?

This intermediate CA is disclosed with the name ‘Entitat de Certificació de l'Administració Pública Andorrana’, and it has been included on the CCADB within the given deadline. You can find the information about the certificate and the root CA in the attached files.

Referring to the audits, we had not externally audited the intermediate CA until this year because this intermediate CA had not been included in the scope for the review performed in 2018, due to the fact that the interpretation we applied was to include only SSL certificates in that scope.

This year we were conscious about the need to include these type of certificates for the first time and that is why we included them in the scope and performed the audit.

Comment 3

[Juan Angel Martin]

Attachment: certs_govern_andorra.zip

Comment 4

[Juan Angel Martin]

Attachment: Entitat de Certificació de l'Administració Pública Andorrana.pem

Comment 5

[Juan Angel Martin]

Attachment: Global Chambersign Root - 2008.pem

Comment 6

[Ryan Sleevi]

Wayne: I'm greatly concerned by this plan, and would recommend immediate revocation.

My understanding, at present is:

• Camerfirma has, since 2013, maintained an unaudited, unconstrained, publicly trusted CAs
• Since 2014, Mozilla has required such certificates be audited, constrained, or revoked
• Camerfirma has, to date, evaded detection of this issue by misleading Mozilla about the nature and scope of disclosure, by incorrectly reporting within CCADB that this certificate has been disclosed in scope of audit, despite the audit report listing this, and 5 other certificates, as out of scope (specifically, d.2.b, d.3, d.4, d.5, e.6, e.7 of said report)
• Camerfirma has known about this issue since 2019-07 (although clearly, from such reports, known about it longer), and is requesting until 2019-10 to do anything about it.
• Camerfirma acknowledges in Comment #2 that, despite communications in September 2018, January 2018, November 2017, April 2017 and May 2014

Comment 7

[Wayne Thayer]

Juan: this is a very serious issue. At a minimum, I would like to know:

• What issues were identified by the audit report? If an attestation statement was issued, please attach it here
• On what date does Camerfirma plan to revoke the existing certificate? Is that the soonest date possible?
• Is there any reason that this certificate can't be added to OneCRL, effectively preventing its use to sign TLS certificates?
• Please confirm that Camerfirma has reviewed all subordinate CAs and there are no other missing or late audits, as described in bug #1502957 and bug #1549861

Comment 8

[Eusebio Herrera]

Hi Wayne,

First of all, let us give you an introduction about the situation.

We are conscious about the problem occurred with the SubCA of Andorra.

Due to the special characteristics of the SubCA because it is for a Government of a Nation and the fact that it has never issued TLS certificates, this can have taken us to not consider it in the scope by mistake until this last audit cycle.

We are working to solve the situation in the best way possible, taking into account the criticality and the impact that would have any action made on the certificates issued.

The action plan raised tries to pay attention to the special situation of the client as well as the protection of the community of users.

You can find the response to your questions below:

1. We already asked the auditors for the report and we are waiting to receive it. We will attach the file to this bug as soon as we receive it.

2. As you can see in the information included in the description of the plan that we detailed on August, 22nd 2019, the soonest date we will be able to revoke the existing certificates is October due to the fact that it is extremely important for the Govern of Andorra to have the certificates non revoked until we can create the new SubCA and start issuing the new certificates through it.

In the meantime, the SubCA is blocked and no certificate can be issued through it.

3. Referring to the prevention of the issuing of TLS certificates that you mentioned. This SubCA has never issued TLS certificates and from July 31st, 2019 the SubCA is blocked, so it cannot issue any kind of certificates, neither TLS nor other types.

These certificates have not been added to OneCRL because we could not revoke them yet. It is extremely important for the Govern of Andorra to have their certificates non revoked until we have the new CA ready to operate with all the necessary guarantees, nevertheless, we stopped issuing certificates through the SubCA on July 31st, 2019.

4. We are performing an exhausting review for each case to be assured that there are not any cases as Ryan mentioned in his comment.

We hope we can provide you with the information tomorrow

Comment 9

[Wayne Thayer]

(In reply to Eusebio Herrera from comment #8)

3. Referring to the prevention of the issuing of TLS certificates that you mentioned. This SubCA has never issued TLS certificates and from July 31st, 2019 the SubCA is blocked, so it cannot issue any kind of certificates, neither TLS nor other types.

These certificates have not been added to OneCRL because we could not revoke them yet. It is extremely important for the Govern of Andorra to have their certificates non revoked until we have the new CA ready to operate with all the necessary guarantees, nevertheless, we stopped issuing certificates through the SubCA on July 31st, 2019.

Eusebio: we can add subCA certificates to OneCRL even if the CA has not revoked them. This causes the certificate to no longer be trusted for TLS in Firefox, which I understand will not be a problem because in this case the subCA never issued TLS certificates - is that correct?

Comment 10

[Ryan Sleevi]

(In reply to Wayne Thayer [:wayne] from comment #9)

Eusebio: we can add subCA certificates to OneCRL even if the CA has not revoked them. This causes the certificate to no longer be trusted for TLS in Firefox, which I understand will not be a problem because in this case the subCA never issued TLS certificates - is that correct?

Wayne: It may be useful when offering solutions like this to also remind CAs that this doesn’t address any BR compliance issues, and that other root programs may expect CAs to have clearly defined paths towards remediation of the compliance issue. OneCRL remains a useful tool for mitigating the risk to Mozilla users, but I’m concerned it may be misinterpreted as addressing the BR compliance issue.

Comment 11

[Eusebio Herrera]

Hi Wayne,

we just applied for inclusion in OneCRL.

We will inform you when the inclusion has been made.

Best regards.

Comment 12

[Kathleen Wilson]

Per email from Eusebio, I have indicated that the following certificate is "Ready to Add" to OneCRL, so that it will be added in the next batch of updates.

Subject: CN=Entitat de Certificació de l'Administració Pública Andorrana; O=M.I. Govern d'Andorra; C=AD
Issuer: CN=Global Chambersign Root - 2008; O=AC Camerfirma S.A.; C=EU
Certificate Serial Number: 00BBBBEEEE341353B9
SHA-256 Fingerprint: 62FDD1DD4DBD26940066AA030FCDA451B2BC2143FECE65A8AA03FC0BD311F0FD

Comments: CA plans to revoked this subCA cert in October 2019, and has requested that it be added to OneCRL now.

Comment 13

[Juan Angel Martin]

Attachment: Informe Sello Webtrust CA Andorra 2018-2019_QUALIFIED-Period Of Time

(In reply to Wayne Thayer [:wayne] from comment #7)

• What issues were identified by the audit report? If an attestation statement was issued, please attach it here

Comment 14

[Wayne Thayer]

(In reply to Eusebio Herrera from comment #8)

4. We are performing an exhausting review for each case to be assured that there are not any cases as Ryan mentioned in his comment.

We hope we can provide you with the information tomorrow

Eusebio: have you provided this information?

Comment 15

[Eusebio Herrera]

Hi Wayne,

During the review, we found another problem with OMC.

We asked them for a report, and they provided us with a draft version.

We have been waiting for the formal report from them, but it is taking them more time that we expected to get it, so we have decided not to wait more to update the information in this bug.

Regarding Andorra's SubCA, we already generated the new subCA (17-October-2019) based on the audit report (PIT) to make sure that the detected incidents have been solved.

The Government of Andorra has asked to postpone the revocation until they have all the certificates transferred to the new subCA so we calculate we will be able to revoke it by 20-November-2019.

Best regards

Comment 16

[Juan Angel Martin]

The Government of Andorra has asked to postpone the revocation until they have all the certificates transferred to the new subCA so we calculate we will be able to revoke it by 20-November-2019.

The Government of Andorra has just asked us for an extension as it has been impossible for them to carry out this task by 20-11-2019. The new revocation date is 30-11-2019.

Comment 17

[Wayne Thayer]

Juan: thank you for the update. Will you please explain why it has become "impossible" to meet the original revocation date that was provided, and what is being done to ensure that future commitments, such as the 30-11-2019 date, will be kept?

Comment 18

[Juan Angel Martin]

It has been impossible to meet the original revocation date because of the special situation of the Govern of Andorra and the big number of citizens that would be affected because of the lack of service.

For future commitments we have made our clients sign an addendum to accept the revocation for all non-compliance occasions like this.

In this case, in the end, the intermediate certificate will be revoked on 4 December due to difficulties in replacing the old certificate with the new one on the platform responsible for issuing certificates and the systems working with it (i.e. OCSP). This date is final.

Comment 19

[Eusebio Herrera]

Today the intermeditate certificate of the "Entitat de Certificació de l'Administració Pública Andorrana" was revoked.

Comment 20

[Ryan Sleevi]

Eusebio: Thanks for the update.

In terms of making sure we prevent situations like this in the future, Comment #0 omitted part of the incident report template, which is understanding what sort of operational changes the CA is making to ensure situations like this don't arise.

There's a few issues here that we want to unpack and ensure appropriate preventative measures, as well as try to share as an industry best practices here:

• Certificates explicitly disclosed as out of scope in the audit report, but listed in-scope by the CA in CCADB
• A lack of compliance with Mozilla policies, despite both Mozilla Policy and the BRs clarifying the expectations
• The delay in revocation, which likely speaks to more systemic design of how Camerfirma designs its PKI going forward

Comment 21

[Ana Lopes]

Hi Ryan,

Please, find below the information about the measures established to prevent situations like this in the future:

• Certificates explicitly disclosed as out of scope in the audit report, but listed in-scope by the CA in CCADB

Due to the fact that this error took place due to a human error, we appointed one more person to work on these tasks. Additionally, we have performed a review of all the scopes as we described in the following two bugs reported in the past: bug #1502957 and bug #1549861

• A lack of compliance with Mozilla policies, despite both Mozilla Policy and the BRs clarifying the expectations.

Additionally to the hiring of a new internal employee for the department, we count with ta legal department specialised in this kind of requirements and legislation and, in case of additional questions that we cannot clarify internally, we also count with the support of external experts who collaborated with us.

• The delay in revocation, which likely speaks to more systemic design of how Camerfirma designs its PKI going forward

As we explained on comment 18, we have made our clients sign an addendum to accept the revocation for all non-compliance occasions like this. Additionally, our purpose is to make the client conscious about the situation and incorporate new substitution processes that impact the least possible over the client operations. We will work with the clients to facilitate those operations where possible.

Comment 22

[Ben Wilson]

Hello Ana,

Could you please answer these additional follow up questions?

• Certificates explicitly disclosed as out of scope in the audit report, but listed in-scope by the CA in CCADB

Due to the fact that this error took place due to a human error, we appointed one more person to work on these tasks. Additionally, we have performed a review of all the scopes as we described in the following two bugs reported in the past: bug #1502957 and bug #1549861

Besides adding an additional person to work on audit reports, scopes, and CCADB data entry, please tell us what additional controls (e.g. processes and procedures) have you implemented to ensure compliance so that future audit information will be accurate?

We also look forward to reviewing your upcoming audit report.

• A lack of compliance with Mozilla policies, despite both Mozilla Policy and the BRs clarifying the expectations.

Additionally to the hiring of a new internal employee for the department, we count with ta legal department specialised in this kind of requirements and legislation and, in case of additional questions that we cannot clarify internally, we also count with the support of external experts who collaborated with us.

When will the next version of your CPS be available for me to review?

The one I have is v.3.3.4 (in English), and it is from 2018 and v.3.3.5 (in Castellano) is from 2019. I would like to review the CPS to see if Mozilla and CA/Browser Forum requirements are being properly incorporated into your CPS. For example, the CA/Browser's Baseline Requirements require revocation within certain time frames under certain conditions (see BR 4.9.1.1 and BR 4.9.1.2).

• The delay in revocation, which likely speaks to more systemic design of how Camerfirma designs its PKI going forward

As we explained on comment 18, we have made our clients sign an addendum to accept the revocation for all non-compliance occasions like this. Additionally, our purpose is to make the client conscious about the situation and incorporate new substitution processes that impact the least possible over the client operations. We will work with the clients to facilitate those operations where possible.

Please, could you provide me with an excerpt from the addendum that shows the language now giving you the legal right to revoke your client's CA for non-compliance?

I would like to review it and possibly provide feedback.

Also, could you please describe the new substitution processes you have adopted? Do those processes help ensure timely revocation of subordinate CAs in the future?

Thank you.

Ben

Comment 23

[Juan Angel Martin]

Hello Ben,

The delay in revocation, which likely speaks to more systemic design of how Camerfirma designs its PKI going forward

As we explained on comment 18, we have made our clients sign an addendum to accept the revocation for all non-compliance occasions like this. Additionally, our purpose is to make the client conscious about the situation and incorporate new substitution processes that impact the least possible over the client operations. We will work with the clients to facilitate those operations where possible.

Please, could you provide me with an excerpt from the addendum that shows the language now giving you the legal right to revoke your client's CA for non-compliance?

"...
In the event of regulatory changes or new technical requirements imposed on CAMERFIRMA by the States, the European Union, CA/Browser Forum, ETSI or any other standardisation body, which require the CA Root to change their practices (CPS), internal procedures, these Terms and Conditions, the Agreement, or any standard or reference heretofore applicable to its relationship with the SubCA, this will be passed on to the SubCA for implementation and the SubCA will be required to incorporate the necessary changes to their services as quickly as possible. CAMERFIRMA may ask the SubCA to issue statements of compliance confirming that the legal and technical regulatory changes have been duly applied. Should these changes or requirements fail to be duly implemented by the SubCA within the time frame required by the corresponding standard, and after having been formally required to do so, CAMERFIRMA may revoke the SubCA certificate if the Root CA were to be at risk of losing the trust of the CA/Browser Forum community or the competent national or international institutions, without compensating or indemnifying the owner of the SubCA or its affected customers.
…
"

We will add information on the other questions as soon as possible.

Thank you very much
Juan Ángel

Comment 24

[Ana Lopes]

Hi Ben,

In response to your question "When will the next version of your CPS be available for me to review?", we already published the last version 3.3.5 in English and Spanish and you can find it here: https://www.camerfirma.com/publico/DocumentosWeb/politicas/CPS_EN_v.3.3.5.pdf

We are also preparing the documentation concerning to the massive substitution process that we would use in case os revocation of one our SubCAs and we will update that information here for you to review it and give us your feedback as soon as possible.

Comment 25

[Ana Lopes]

Hi Ben,

Here you are a summary of the revocation process for our SubCAs with problems.

This summary is based on the diagram that we included in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1623384a and will be aplicable for all future revocations.

REVOCATION PROCESS AND MASSIVE SUBSTITUTION PHASES

1. Detection of the affected SubCA: When a problem with a SubCA belonged to Camerfirma is detected internally or notified externally (through the e-mail address [e-mail], incorporated to CCADB as entry point for notifications related to incidents with our CAs).

2.  Analysis and deteccion of all the affected certificates: PKI Expertise department verifies if the communication received is correct and an error exists and determines the scope by checking the certificates affected. 
   

3.  Extraction of the ID list associated to the certificates: A list is elaborated with the IDs of the identified certificates and is passed to the Operations department so that they can manage the communication with the clients and the applications for substitution. 
   

4.  Inclusion of the fingerprints on the list of certificates 
   

5.  The Operations department extracts the contact list: Once they receive the certificate information, the operations department locates the information of the affected client who must be notified about the situation. 
   

6.  The Operations department sends a communicate to the affected clients indicating the situation and planned date for revocation and substitution if possible. 
   

Depending on the date there will exist the possibility to substitute the certificate before revoking or not, taking into account that the deadline can be 24 hours or 7 days depending on the criticality of the incident detected.

In case of possible substitution:

Option A: Using an existing CA:
6A1: Operations department sed a e-mail to the clients with the URL to substitute the certificate before its revocation
6A2: PKI plans a ceremony to revoke the problematic certificate
6A3: PKI Expertise department+ Internal Auditor+Systems Administrator + Operators participate in the ceremony to revoke the problematic SubCA

Option B: Using a new CA:
6B1: PKI plans a ceremony to create the new SubCA
6B2: PKI Expertise department+ Internal Auditor+Systems Administrator + Operators participate in the ceremony to create the new SubCA
6B3: Operations department send an e-mail to the clients with the URL to substitute the certificate before its revocation
6B4: PKI plans a ceremony to revoke the problematic certificates
6B5: PKI Expertise department+ Internal Auditor+Systems Administrator + Operators participate in the ceremony to revoke the problematic SubCA

In case of no substitution of certificates
6C1: PKI plans a ceremony to revoke the problematic certificates
6C2: PKI Expertise department+ Internal Auditor+Systems Administrator +Operators participate in the ceremony to revoke the problematic SubCA

Comment 26

[Ryan Sleevi]

Ben: I think this goes to you. In the past, CAs have been distrusted for issues as serious as this, and so I think as a systemic issue it raises a lot of concerns. For example, the language in Comment #23 doesn't give much hope for new Mozilla requirements, or for the CAs' violation of existing requirements (i.e. it's worded as to only apply to new requirements from the CABF)

At the same time, I don't have further questions here.

Comment 27

[Juan Angel Martin]

Hi Ben and Ryan,

We would like to add some information related to Ryan’s comment 26 (thanks Ryan for your comment) because we have realized that we need to update the following information contained in our CPS.

Our current version indicates that:

"These practices are aligned with the requirements established in the Baseline Requirements for the Issue and Management of Publicly-Trusted Certificates from the CA/B Forum http://www.cabforum.org in its version 1.6.7.

These practices are aligned with the requirements established in the Guidelines For The Issuance And Management Of Extended Validation Certificates from the CA/B Forum http://www.cabforum.org in its version 1.7.1..

If there is any inconsistency between this document and the Baseline Requirements, the Baseline Requirements will have priority over this document."

So, we have started the process to substitute that text for the following:

"These practices comforms the requirements established in the current version of "Baseline Requirements for the Issue and Management of Publicly-Trusted Certificates" from the CA/B Forum published at http://www.cabforum.org

These practices comforms the requirements established in the current version of "Guidelines For The Issuance And Management Of Extended Validation Certificates" from the CA/B Forum http://www.cabforum.org published at http://www.cabforum.org

These practices comforms the requirements established in the current version of "Mozilla Root Store Policy" from Mozilla published at https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

If there is any inconsistency between this document and the requirements referenced above, those requirements will have priority over this document."

We hope that you will find that information useful.

Comment 28

[Ben Wilson]

I am concerned that the language in comment 23 is too weak. It says, "Should these changes or requirements fail to be duly implemented by the SubCA within the time frame required by the corresponding standard, and after having been formally required to do so, CAMERFIRMA may revoke the SubCA certificate if the Root CA were to be at risk of losing the trust of the CA/Browser Forum community or the competent national or international institutions, without compensating or indemnifying the owner of the SubCA or its affected customers."

However, there are too many loopholes and subjective judgment decisions. SubCAs should already be aware of all CA requirements, so the language "having been formally required" is unnecessary. The Root CA is already at risk of losing trust with Mozilla, so that language is also unnecessary. So instead of "may revoke" it should say something more like, "Should these changes or requirements fail to be duly implemented by the SubCA within the time frame required by the corresponding standard, CAMERFIRMA will revoke the SubCA certificate without compensating or indemnifying the owner of the SubCA or its affected customers."

Comment 29

[Eusebio Herrera]

Hi Ben,

Thank you for your comments.

We are going to change the text in the addendum.

We are going to put "CAMERFIRMA will revoke the SubCA certificate" instead of "may revoke".

Comment 30

[Juan Angel Martin]

Hello,

We've updated the addendum as Eusebio told and passed it to our intermediate CAs.

Kind Regards

Comment 31

[Ben Wilson]

I will close this bug on or about 9-October-2020 unless there are other issues or questions to be raised.