Open Bug 1890896 Opened 3 months ago Updated 6 days ago

Entrust: CPS typographical (text placement) error

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: bruce.morton, Assigned: bruce.morton)

Details

(Whiteboard: [ca-compliance] [policy-failure])

Attachments

(2 files)

20240409-OV-TLS-Certificates-typo-finalcerts.txt
522.18 KB, text/plain
Details
cps-erratum.jpg
261.30 KB, image/jpeg
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Incident Report

Summary

Entrust issued CPS version 3.18 dated 22 March 2024 to require the policyQualifier for the EV certificate profile, but inadvertently added the requirement for the OV certificate profile. OV certificates were not issued with the policyQualifier per design. The error was corrected with CPS version 3.20 dated 26 March 2024.

We will file an incident report detailing the exceptional circumstances that led to our decision not to revoke the affected certificates, see bug https://bugzilla.mozilla.org/show_bug.cgi?id=1890898.

Since his incident is posted late, we will also file an incident report detailing reasons for the delayed incident post, see bug https://bugzilla.mozilla.org/show_bug.cgi?id=1890901.

Impact

This incident involves 6,008 OV TLS certificates that were issued between March 22, 2024, 15:02 UTC and March 26, 2024, 17:07 UTC.

These certificates were issued in accordance with the TLS Baseline Requirements and with the certificate profile intended by Entrust; however, there was a typographical error in the CPS statement linked to these certificates.

These certificates are considered mis-issued in accordance with the CCADB policy

Timeline

All times are UTC.

2024-03-21:

2024-03-22:

  • 15:02 CPS version 3.18 was posted to introduce a new clientAuth only certificate profile and other improvements. In making the change, the policyIdentifier for the SSL Certificate profile was mistakenly updated with the requirement “and must contain policyQualifier with cPSuri.” This requirement was supposed to be added to the EV SSL certificate profile only and not to the OV SSL certificate profile.

2024-03-26:

  • 15:28 We discovered that there was a typographical error included in the CPS. The CPS was updated to correct the error.
  • 17:07 CPS version 3.20 was posted.

Root Cause Analysis

1. Why was there a problem?

A change that was supposed to be made to the “EV SSL certificate” profile was inadvertently added to the “SSL certificate” (OV) profile as well.

2. Why was the wrong certificate profile updated in the CPS?

The CPS was updated several times over a few days to ensure transparency to relying parties and subscribers. During one of these updates, we applied the changes to the incorrect profile due to the generic naming of our OV SSL certificate profile which is called “SSL certificate profile”.

3. Why was the CPS updated several times in a row?

We were addressing concurrent incidents that required rapid certificate replacement and revocation.

4. Why was this error not detected in the review process?

While a second person on the compliance team reviewed and approved the changes, the review focused on the redlined change. Use of a generic name for the certificate profile also contributed to the oversight.

5. Why was there no distinctive name used for the certificate profile?

This comes from the time where the only SSL certificates we issued were OV SSL certificates. When we added EV certificates many years later, we did not change this name as we thought it would be clear enough to have an SSL certificate and an EV SSL certificate.

Lessons Learned

  • Certificates profiles will be given distinctive names so that they are less likely to get confused.

What went well

  • The SSL certificates were issued with the correct certificate profile, as such, no technical change is required.

What didn't go well

  • Amid concurrent incidents, a typographical a change was made to the incorrect certificate profile.
  • This error was not noticed during review, so an incorrect CPS was published.
  • While the issue was identified and remediated on March 26, this incident report was published 15 days later. We have filed a separate incident report for the delayed publication here: bug #1890901.

Where we got lucky

  • CPS error was detected and resolved in 4 days.

Action Items

Action Item Kind Due Date
File an incident report for not revoking the affected certificates Transparency Done
Add errata to CPS version 3.18 and 3.19 to advise readers of the changes Transparency Done
Inform subscribers of the CPS error Transparency 2024-04-12
Review CPS update procedure Prevent 2024-06-30
Rename “SSL certificate profile” to “OV TLS certificate profile” Prevent 2024-08-31

Appendix

Details of affected certificates

Attached is the list of impacted certificates.

Assignee: nobody → bruce.morton
Status: RESOLVED → UNCONFIRMED
Type: defect → task
Component: General → CA Certificate Compliance
Product: Invalid Bugs → CA Program
Resolution: INVALID → ---
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [policy-failure]

Regarding the action, today subscribers were informed of the CPS changes.

Entrust isn't revoking these certificates because re-issuance would result in the exact same certificate? Do I have that correct?

I'm looking for clarity here. Entrust states that there iss no intention to revoke but cite no authority overriding their obligations.

The issue was noted internally at Entrust on 2024-03-26, but it took 16 days before any public notice appeared. We're still lacking any real information on what happened internally.

I will also note that several of the certificates listed have been revoked (superseded):
https://crt.sh/?sha256=34DF91A45C4BF0D54A5879A241C763DB6969002E7739572C6C322E075136AEB7 (2024-03-26 17:08:49 UTC)
https://crt.sh/?sha256=3260F0A3FD4D68674686F6C4A8C2BDB642F2D2E4A8E02D0F0EF93CC0F9711C28 (2024-03-26 17:13:03 UTC)
https://crt.sh/?sha256=75CA61256BF5B55FC6B0B89EEA34F709FA1002350E31513AB6E11350D175F0D1 (2024-03-26 19:19:08 UTC)
https://crt.sh/?sha256=1E190D5B285DFD5A01781132707B4E54F20A4DF31C1F2E82A465E48B3C4DB4D5 (2024-03-26 19:35:29 UTC)
https://crt.sh/?sha256=CE480E4CC20F38C8860C79BE6ECE3583626CA3829AE1D08ADB650E8C3B2FD318 (2024-03-27 18:10:22 UTC)

I don't need to fully explain that the sample above does not paint a good light on Entrust's internal consistency and transparency to the public.

Q1) Can you document what caused Entrust to start revocation for a day, and then stop?

Q2) Can Entrust provide us with a breakdown of outstanding mis-issued certificates, expired certificates, revoked certificates, and a timeframe for each revocation batch (time issued to team, time taken to revoke)?

Q3) What internal discussions occurred at Entrust to change this approach?

Q4) Did Entrust privately inform any Root Programs of this incident prior to this public report?

Q5) Will there be any additional revocations as required?

Q6) Can Entrust please explain why they feel they feel they are under no obligation to abide by their own CPS for certificate mis-issuance revocation? The report does not explain what authorities they are relying on.

Q7) Having read Entrust's CPS I can see no mechanism for 'exceptional circumstances' to avoid revocation. Could Entrust clarify where this is as it has been a common theme throughout these incidents?

Q8) If there will be an update to Entrust's CPS to carve out exceptional circumstances, I trust that there is an understanding that this is not applied retroactively?

Q9) Given the issues in the past month, can Entrust confirm that they are technically capable of mass revocation and reissuance within 24 hours?

Q10) Given the issues in the past month, can Entrust confirm that they are organizationally capable of approving a mass revocation and reissuance event within 24 hours?

Flags: needinfo?(bruce.morton)

Comment 3 states: "Regarding the action, today subscribers were informed of the CPS changes."

Question 1) Can you share more about this, specifically describing what was communicated to subscribers and how?

It's possible to interpret "Regarding the action, today subscribers were informed of the CPS changes." (i.e., "Today, we told subscribers that we updated our CPS.") differently than "Inform subscribers of the CPS error" ("i.e., "We made a mistake.") as described in the Actions table.

Question 2) Can you please correct the Actions table? "Transparency" is not one of the described Action categories listed on https://www.ccadb.org/cas/incident-report.

Question 3) Looking at one of the CPS documents with an errata (example), I'm having a hard time understanding what is being communicated. Other than the (non-text searchable) phrase "This CPS contains an errata, please see version 3.20" it's not clear what the errata was, what changes were made, or what issues were being addressed.

Can you share how this approach meets the intent of "Add errata to CPS version 3.18 and 3.19 to advise readers of the changes?" as described in the Actions table? Also, was adding the errata notice using an image that is not text-searchable intended? The combination of the non-text searchable phrase and the lack of detail make it challenging to understand what the errata has changed or intends to highlight - which does not clearly convey the intended goal of "Transparency" as presently described in the Actions list.

The ease of detecting changes across policy versions was a motivating factor for encouraging the use of Markdown as described in the latest version of the Chrome Root Program policy (i.e., "To promote simplicity and clarity, these CA policy documents SHOULD be available in Markdown.")

(In reply to Jeremy Rowley from comment #4)

Entrust isn't revoking these certificates because re-issuance would result in the exact same certificate? Do I have that correct?

Yes. Please see bug #1890898, referenced in the summary above, where we describe why we are not revoking these certificates.

Flags: needinfo?(bruce.morton)

We are reviewing the open comments in this bug and will come back with a reply next week.

Flags: needinfo?(bruce.morton)

(In reply to Wayne from comment #5)

I'm looking for clarity here. Entrust states that there is no intention to revoke but cite no authority overriding their obligations.

The issue was noted internally at Entrust on 2024-03-26, but it took 16 days before any public notice appeared. We're still lacking any real information on what happened internally.

Please see bug #1890901 in which we filed for this delayed incident report.

I will also note that several of the certificates listed have been revoked (superseded):
https://crt.sh/?sha256=34DF91A45C4BF0D54A5879A241C763DB6969002E7739572C6C322E075136AEB7 (2024-03-26 17:08:49 UTC)
https://crt.sh/?sha256=3260F0A3FD4D68674686F6C4A8C2BDB642F2D2E4A8E02D0F0EF93CC0F9711C28 (2024-03-26 17:13:03 UTC)
https://crt.sh/?sha256=75CA61256BF5B55FC6B0B89EEA34F709FA1002350E31513AB6E11350D175F0D1 (2024-03-26 19:19:08 UTC)
https://crt.sh/?sha256=1E190D5B285DFD5A01781132707B4E54F20A4DF31C1F2E82A465E48B3C4DB4D5 (2024-03-26 19:35:29 UTC)
https://crt.sh/?sha256=CE480E4CC20F38C8860C79BE6ECE3583626CA3829AE1D08ADB650E8C3B2FD318 (2024-03-27 18:10:22 UTC)

I don't need to fully explain that the sample above does not paint a good light on Entrust's internal consistency and transparency to the public.

We uphold a commitment to full transparency with the public, and we appreciate your inquiry regarding any uncertainties in this regard. Please feel free to express any concerns or questions you may have, as we strive to ensure clarity and openness in all our communications.

Q1) Can you document what caused Entrust to start revocation for a day, and then stop?

We have never started or requested customers to revoke certificates in relation to this incident, but certificates are sometimes revoked by customers for other reasons. Except for one, all certificates you listed above belong to one customer. This customer was also impacted by our other incident, and they might have decided to revoke these certificates as well.

Q2) Can Entrust provide us with a breakdown of outstanding mis-issued certificates, expired certificates, revoked certificates, and a timeframe for each revocation batch (time issued to team, time taken to revoke)?

As stated above, in the impact section of this incident report, this incident involves 6,008 OV TLS certificates that were issued between March 22, 2024, 15:02 UTC and March 26, 2024, 17:07 UTC, a list with links to the certificates has been attached to this bug. In the summary above, we describe why we are not revoking these certificates.

Q3) What internal discussions occurred at Entrust to change this approach?

Per our response to Q1, we have not changed our approach to revocation in relation to this incident.

Q4) Did Entrust privately inform any Root Programs of this incident prior to this public report?

While we have spoken with some root programs about the delayed CPS publication, this specific incident has not been discussed.

Q5) Will there be any additional revocations as required?

We do not intend to revoke these certificates, see also bug #1890898.

Q6) Can Entrust please explain why they feel they feel they are under no obligation to abide by their own CPS for certificate mis-issuance revocation? The report does not explain what authorities they are relying on.

Please see bug #1890898.

Q7) Having read Entrust's CPS I can see no mechanism for 'exceptional circumstances' to avoid revocation. Could Entrust clarify where this is as it has been a common theme throughout these incidents?

The Mozilla Wiki describes that there are some exceptional circumstances where revoking the affected certificates within the prescribed deadline may cause significant harm and that the CA is ultimately responsible for deciding if the harm caused by not following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI.

Neither delayed revocation nor non-revocation is described in the TLS Baseline Requirements.

Q8) If there will be an update to Entrust's CPS to carve out exceptional circumstances, I trust that there is an understanding that this is not applied retroactively?

We share this understanding.

Q9) Given the issues in the past month, can Entrust confirm that they are technically capable of mass revocation and reissuance within 24 hours?

Yes.

Q10) Given the issues in the past month, can Entrust confirm that they are organizationally capable of approving a mass revocation and reissuance event within 24 hours?

Yes, we are.

Flags: needinfo?(bruce.morton)

(In reply to Ryan Dickson from comment #6)

Comment 3 states: "Regarding the action, today subscribers were informed of the CPS changes."

Question 1) Can you share more about this, specifically describing what was communicated to subscribers and how?

The following message was sent to our subscribers through the Entrust message center:

Subject: A new ECS CPS is now available, including errata for version 3.16, 3.18 and 3.19

Please be advised that the ECS Public Trust Certificate Practices Statement (CPS) has been revised and errata have been added to CPS releases 3.16, 3.18 and 3.19. These errata have no impact on your certificate and are clearly marked in the respective CPS versions on our website at: https://www.entrust.com/legal-compliance/entrust-certificate-services-repository/archive.

Should you wish to view the updated document, go to our website under >Resources > Legal and Compliance > Entrust Certificates Services Repository > Certification Practice Statements > Certification Practice Statements.

You can also view the new document directly at: https://www.entrust.com/-/media/documentation/licensingandagreements/entrust-certificate-services-cps-3-20.pdf

It's possible to interpret "Regarding the action, today subscribers were informed of the CPS changes." (i.e., "Today, we told subscribers that we updated our CPS.") differently than "Inform subscribers of the CPS error" ("i.e., "We made a mistake.") as described in the Actions table.

We think that the message “errata have been added to CPS releases 3.16, 3.18 and 3.19” is a clear indication that there was an error in these versions.

Question 2) Can you please correct the Actions table? "Transparency" is not one of the described Action categories listed on https://www.ccadb.org/cas/incident-report.

It was not clear that we were limited to the categories included in the following paragraph.

A classification of whether the action will help Prevent future incidents, Mitigate the impact of future incidents, or Detect future incidents. CA Owners are encouraged to propose action items in all three categories, with an emphasis on prevention and mitigation.

We think that the Transparency action items we included do not fit in any of the listed categories, can you let us know if you want us to post an updated table with these action items or categories removed?

Question 3) Looking at one of the CPS documents with an errata (example), I'm having a hard time understanding what is being communicated. Other than the (non-text searchable) phrase "This CPS contains an errata, please see version 3.20" it's not clear what the errata was, what changes were made, or what issues were being addressed.

We included the errata as a PDF comment so that we do not change the original published CPS version. The text “and must contain policyQualifier with cPSuri” on page 85 has been formatted with a red strikethrough, to clearly indicate that this was included as an error.

Can you share how this approach meets the intent of "Add errata to CPS version 3.18 and 3.19 to advise readers of the changes?" as described in the Actions table? Also, was adding the errata notice using an image that is not text-searchable intended? The combination of the non-text searchable phrase and the lack of detail make it challenging to understand what the errata has changed or intends to highlight - which does not clearly convey the intended goal of "Transparency" as presently described in the Actions list.

As stated above, the errata were added as a PDF comment, not as an image but as text, so that everyone can verify that we did not modify anything else in the CPS. In Acrobat Reader the comments are searchable and hyperlinked through a list. That stated, we are open to further improvements if you or the community think that would help subscribers and relying parties.

The ease of detecting changes across policy versions was a motivating factor for encouraging the use of Markdown as described in the latest version of the Chrome Root Program policy (i.e., "To promote simplicity and clarity, these CA policy documents SHOULD be available in Markdown.")

We are aware of the recent Chrome root program desire to use Markdown for CPS documents. This is something we would like to move forward with in the future but is not a small undertaking.

The Mozilla Wiki describes that there are some exceptional circumstances where revoking the affected certificates within the prescribed deadline may cause significant harm and that the CA is ultimately responsible for deciding if the harm caused by not following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI.

I don't think you're reading the link you're posting here? Specifically (emphasis mine):

The decision and rationale for delaying revocation will be disclosed in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include detailed and substantiated explanations for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.

Also, that link is JUST the Mozilla Root Program. Is there anything in the Chrome/Apple/Microsoft Root Programs that carves out exceptions for revocation?

(In reply to Bruce Morton from comment #9)

We uphold a commitment to full transparency with the public, and we appreciate your inquiry regarding any uncertainties in this regard. Please feel free to express any concerns or questions you may have, as we strive to ensure clarity and openness in all our communications.

Q1) Can you document what caused Entrust to start revocation for a day, and then stop?

We have never started or requested customers to revoke certificates in relation to this incident, but certificates are sometimes revoked by customers for other reasons. Except for one, all certificates you listed above belong to one customer. This customer was also impacted by our other incident, and they might have decided to revoke these certificates as well.

Q2) Can Entrust provide us with a breakdown of outstanding mis-issued certificates, expired certificates, revoked certificates, and a timeframe for each revocation batch (time issued to team, time taken to revoke)?

As stated above, in the impact section of this incident report, this incident involves 6,008 OV TLS certificates that were issued between March 22, 2024, 15:02 UTC and March 26, 2024, 17:07 UTC, a list with links to the certificates has been attached to this bug. In the summary above, we describe why we are not revoking these certificates.

In the interest of openness and transparency this was based on a brief sampling of certificates and a more thorough report was produced and posted to the dev-security-policy mailing list (pending approval). I apologize for misunderstanding this as Entrust complying with the Baseline Requirements if but for only a brief period of time.

However in short: You have not answered my question at all. I am well aware of the 6,008 OV TLS certificates mentioned. Are Entrust willing to be transparent and provide a breakdown on: "'outstanding mis-issued certificates', 'expired certificates', 'revoked certificates'" in respect to this issue?

Q6) Can Entrust please explain why they feel they feel they are under no obligation to abide by their own CPS for certificate mis-issuance revocation? The report does not explain what authorities they are relying on.

Please see bug #1890898.

I am not seeing an answer to my question in that bug.

Q7) Having read Entrust's CPS I can see no mechanism for 'exceptional circumstances' to avoid revocation. Could Entrust clarify where this is as it has been a common theme throughout these incidents?

The Mozilla Wiki describes that there are some exceptional circumstances where revoking the affected certificates within the prescribed deadline may cause significant harm and that the CA is ultimately responsible for deciding if the harm caused by not following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI.

Neither delayed revocation nor non-revocation is described in the TLS Baseline Requirements.

Unfortunately as amir has pointed out that is not what the Mozilla Root Program states. Additionally you are correct, delayed revocation nor non-revocation are not described in the TLS Baseline Requirements. To that end, what authorities are you relying on to reach your current understanding that such possibilities exist while being compliant?

Q9) Given the issues in the past month, can Entrust confirm that they are technically capable of mass revocation and reissuance within 24 hours?

Yes.

Q10) Given the issues in the past month, can Entrust confirm that they are organizationally capable of approving a mass revocation and reissuance event within 24 hours?

Yes, we are.

I will note that this does not add up to the current pace at which Entrust is handling incidents. Please see the dev-security-policy mailing list for further detail shortly.

(In reply to amir from comment #11)

The Mozilla Wiki describes that there are some exceptional circumstances where revoking the affected certificates within the prescribed deadline may cause significant harm and that the CA is ultimately responsible for deciding if the harm caused by not following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI.

I don't think you're reading the link you're posting here? Specifically (emphasis mine):

The decision and rationale for delaying revocation will be disclosed in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include detailed and substantiated explanations for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.

We did not decide to delay revocation, but we provided a bug #1890898 to not revoke.

Also, that link is JUST the Mozilla Root Program. Is there anything in the Chrome/Apple/Microsoft Root Programs that carves out exceptions for revocation?

We are not aware of any programs providing exceptions for revocation; however Apple and Chrome refer to the Mozilla policy for revocation.

(In reply to Wayne from comment #12)

(In reply to Bruce Morton from comment #9)

However in short: You have not answered my question at all. I am well aware of the 6,008 OV TLS certificates mentioned. Are Entrust willing to be transparent and provide a breakdown on: "'outstanding mis-issued certificates', 'expired certificates', 'revoked certificates'" in respect to this issue?

This incident provides a crt.sh link for each certificate, so the certificate status can be found. Note, the 14 missing certificates per https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/J3aX8OKIT_A were posted to CT.

Q6) Can Entrust please explain why they feel they feel they are under no obligation to abide by their own CPS for certificate mis-issuance revocation? The report does not explain what authorities they are relying on.

Please see bug #1890898.

I am not seeing an answer to my question in that bug.

We were transparent by providing the issue with the CPS error in this incident and our reason for not revoking in bug #1890898. We are using the incident process to provide justification and our rational.

Q7) Having read Entrust's CPS I can see no mechanism for 'exceptional circumstances' to avoid revocation. Could Entrust clarify where this is as it has been a common theme throughout these incidents?

The Mozilla Wiki describes that there are some exceptional circumstances where revoking the affected certificates within the prescribed deadline may cause significant harm and that the CA is ultimately responsible for deciding if the harm caused by not following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI.

Neither delayed revocation nor non-revocation is described in the TLS Baseline Requirements.

Unfortunately as amir has pointed out that is not what the Mozilla Root Program states. Additionally you are correct, delayed revocation nor non-revocation are not described in the TLS Baseline Requirements. To that end, what authorities are you relying on to reach your current understanding that such possibilities exist while being compliant?

We are not relying on any authorities; however, we have opened bug #1890898 to address this incident and to allow the open community to review this issue.

Q9) Given the issues in the past month, can Entrust confirm that they are technically capable of mass revocation and reissuance within 24 hours?

Yes.

Q10) Given the issues in the past month, can Entrust confirm that they are organizationally capable of approving a mass revocation and reissuance event within 24 hours?

Yes, we are.

I will note that this does not add up to the current pace at which Entrust is handling incidents. Please see the dev-security-policy mailing list for further detail shortly.

We will follow the discussion on the dev-security-policy mailing list.

We are not aware of any programs providing exceptions for revocation; however Apple and Chrome refer to the Mozilla policy for revocation.

Bruce, can you please clarify where Chrome refers to the Mozilla policy for revocation? Did you mean to say the CCADB Policy (which shares management and oversight responsibilities from the members of the CCADB Steering Committee)?

Flags: needinfo?(bruce.morton)

Hi Ryan, apologies for the miss-statement. Yes, I should have stated CCADB Policy. As such, we are not aware that Chrome, Apple or Microsoft root programs provide any exceptions for revocation.

We greatly value everyone’s input because it enables us to engage in informed decision-making. We are considering whether these certificates should be revoked. Are there additional insights and opinions regarding that question? It appears that the certificates complied with industry standards and that the replacement certificates would be nearly identical, except for serial numbers and validity periods. In stating your position, please consider and explain both the potential benefits and drawbacks to the Mozilla root program and the security of the internet. Thanks.

We greatly value everyone’s input because it enables us to engage in informed decision-making. We are considering whether these certificates should be revoked. Are there additional insights and opinions regarding that question? It appears that the certificates complied with industry standards and that the replacement certificates would be nearly identical, except for serial numbers and validity periods. In stating your position, please consider and explain both the potential benefits and drawbacks to the Mozilla root program and the security of the internet. Thanks.

Actually, I think the onus is on the Root Program and CAs to do the security analysis of why following the rules would be too difficult and how these misissued certificates "are nearly identical" and "okay".

Mozilla Root Program, can you answer these questions:

  1. Has Entrust reached out to you in a non-public manner regarding any of their current 15 incidents?
  2. Are these certificates misissued?
  3. Do the baseline requirements allow misissued certificates being left unrevoked? If so, where?
  4. If not, does the Mozilla Root Program consider this a "special circumstance"? If so, where is the procedure regarding "special circumstances" documented?
  5. What are the other Mozilla Root Program rules that don't matter? For example, can ${CA} maliciously issue a certificate and reject revocation, claiming that these certificates will be nearly identical, just that the entity holding the private key is different?
  6. If there are other parts of the BRs that the Mozilla Root Program doesn't consider important, can you please list those out with their sections?
Flags: needinfo?(bwilson)

I also would like to add that, since this issue is now multiple bugs. If there is a desire to get information from the community regarding these incidents, we should move that discussion to MDSP rather than it be on the individual incident level.

(In reply to Bruce Morton from comment #14)

This incident provides a crt.sh link for each certificate, so the certificate status can be found. Note, the 14 missing certificates per https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/J3aX8OKIT_A were posted to CT.

Thank you for following up and making sure those certificates are included after public notification.

I'll provide my comments in the other bug report to make this easier to follow for everyone.

(In reply to Bruce Morton from comment #13, though already addressed by Bruce further in comment #16)

We are not aware of any programs providing exceptions for revocation; however Apple and Chrome refer to the Mozilla policy for revocation.

To be clear, the Apple Root Program Policy makes no reference to the Mozilla policy -- for revocation or any other matter. It does allow for CAs to provide incident reports in Bugzilla, avoiding the need to duplicate in full each incident report.
Aside from that, the Apple Root Program Policy states nothing specific to revocation requirements, stipulating that the CA must adhere to their own CP/CPS disclosed in the CCADB, the CCADB Policy, and to the relevant CA/BF Guideline(s) associated with the type(s) of certificate being issued.

(In reply to Ben Wilson from comment #17)

We greatly value everyone’s input because it enables us to engage in informed decision-making. We are considering whether these certificates should be revoked. Are there additional insights and opinions regarding that question? It appears that the certificates complied with industry standards and that the replacement certificates would be nearly identical, except for serial numbers and validity periods. In stating your position, please consider and explain both the potential benefits and drawbacks to the Mozilla root program and the security of the internet. Thanks.

I know this has been split up over multiple issues now, but my response is at https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c21.

Personally, I'd like to hear input from other CAs. I can't imagine they're too happy about Entrust being given a free pass while they have to follow the rules. It makes Entrust appear untouchable and gives them an unfair advantage over competing CAs.

(In reply to Ben Wilson from comment #17)

the replacement certificates would be nearly identical, except for serial numbers and validity periods. In stating your position, please consider and explain both the potential benefits and drawbacks to the Mozilla root program and the security of the internet. Thanks.

Without attempting to assert an opinion on whether or not Mozilla should require these certificates to be revoked, there is an important point in this dialog that deserves clarification, which is that any replacement certificate would not be identical to its original, and that difference is meaningful.

As you rightly mention, Ben, little is different in this scenario between a replacement certificate and the one it replaces. However, one difference you do allude to, the notBefore date, is important.

Each CA publishes its practices in a Certificate Practices Statement, or CPS. The CPS exists so that any member of the public with sufficient interest, time, and knowledge can examine that CA’s practices to help inform important judgements like whether or not we feel this CA is a reliable steward of the public trust model. While most Relying Parties will never go to this length, some may, and if there are concerns about a CA, surely some will. These can easily include the likes of academics, journalists, security researchers, technology firms, and others who have the resources, knowledge, and ability to use this information in productive ways.

This is why it is considered misissuance for a CA to deviate from its CPS. If a concerned individual seeks to validate the trustworthiness of a given certificate, the CPS must reflect what actually occurred at issuance time, or the investigator is misled. For a CA that legitimately requires this level of scrutiny (or really any CA), providing incorrect information about a CA’s practices at a specific time lowers the security and trustworthiness of the WebPKI.

CAs maintain histories of CPS versions stamped by date. This makes it possible for the concerned citizen to zero in on the actual practices used at the time of issuance for any given certificate, and it yokes known practices to the certificates in question. In a way, the entire CPS that was in force at time of issuance is part of the certificate.

Let’s examine what happens in the case of a CPS misalignment issue. The CA has a body of certificates in production which appear to have been issued according to a specific set of rules, as clarified by the appropriately dated CPS. If the CA failed to follow those rules, this conveys false information about some set of certificates, which undermines the capabilities described in the preceding paragraphs.

How do we mitigate this problem? We ensure each active certificate matches the published CPS for its issuance time. That is readily accomplished by revoking the certificates affected by CPS/practices mismatch and replacing them with new certificates that have notBefore dates corresponding to a published CPS that the CA correctly followed. True alignment of issuance and published practices is restored for all active certificates.

With that context, do the certificates in this incident require revocation? The argument in favor is to achieve the alignment described above, with the benefits explained in this comment.

One possible argument against would be that a given deviation is too minor to justify the revocation and reissuance of these certificates, with the disruption to Subscribers and possibly Relying Parties that may result. Had Entrust made such an argument, we might right now be debating whether or not the mismatches in this bug and bug 1890685 were severe enough to get over that bar.

That is not, however, the contention we’ve seen. In either case, Entrust has used similar rhetoric to maintain that the new certificates would be for all practical purposes the same as those to be replaced and therefore that replacement would change nothing.

This bug’s comment #2 and bug 1890685, comment 1, for example, offer identical wording:

If the certificates were re-issued, they would be re-issued with the identical certificate profile.

I believe this contention is provably false for the reasons given above and should not be in the consideration set when discussing if Mozilla should require revocation of these certificates. If an observer of this bug or bug 1890685 would like to make a different argument about why these certificates should be exempt from revocation rules (such as that the changes are too minor to justify the action), then I encourage them to make that case and the community to discuss it actively.

It is clear to me, however, that the argument that the new certificates would be identical in all meaningful ways to the old certificates is simply untrue and does not in itself justify choosing not to revoke these certificates.

From my experience at large enterprises supporting thousands of applications, Web PKI (E.g., CAB Forum, Bugzilla, etc.) does not effectively represent the enterprise. Enterprises often restrict public speaking, and our voice is primarily through our partner certificate authorities.

Enterprises are both subscribers and relying parties, as well as represent our customers as relying parties and through partners.

Web PKI is governed primarily by certificate authorities and browsers, yet the scope and impact of Web PKI is well beyond the browser and certificate authorities.

Despite having certificate lifecycle management platforms, complexity, scale, and legacy platforms still cause enterprises to manually manage too many certificates which is time consuming and error prone. Parts of the Enterprise are well modernized, but a sizable portion has limited or no automation.

Managing trust stores is another challenge. More work needs to be done on standardization, transparency, and automation of trust stores, particularly across partner ecosystems. This makes hierarchy changes difficult and high risk. In many cases you don’t know in advance if using a new hierarchy will break connections.

There is certainly more Enterprises need to do to move away from Web PKI managed hierarchies for non-browser and internal use cases, drive automation and continue modernization - but today Enterprises have legacy environments where certificate rotations and hierarchy changes are often manual, non-trivial and error prone.

CAs must be held to a high standard, but unfortunately the impact of a potential action is borne largely by subscribers and relying parties. While I appreciate the merits of the technical conversation, from a business perspective, it would be hard to explain a potential revocation action which would have an Enterprise perception of disproportioned cost and risk.

It would be worthwhile to continue the conversation on how to improve Enterprise representation and trying to solve for the problems above.

(In reply to Tim Callan from comment #23)

Let’s examine what happens in the case of a CPS misalignment issue. The CA has a body of certificates in production which appear to have been issued according to a specific set of rules, as clarified by the appropriately dated CPS. If the CA failed to follow those rules, this conveys false information about some set of certificates, which undermines the capabilities described in the preceding paragraphs.

Tim, we would like to clarify that we have updated the applicable CPS with an erratum in red (as a PDF comment, to make it clear that we did not change the CPS itself) to ensure that those who check the appropriately dated CPS for the certificate will see the correct(ed) information. See also the attached screenshot.

Flags: needinfo?(bruce.morton)
Attached image cps-erratum.jpg —

(In reply to David Seferiadis from comment #24)

CAs must be held to a high standard, but unfortunately the impact of a potential action is borne largely by subscribers and relying parties. While I appreciate the merits of the technical conversation, from a business perspective, it would be hard to explain a potential revocation action which would have an Enterprise perception of disproportioned cost and risk.

It would be worthwhile to continue the conversation on how to improve Enterprise representation and trying to solve for the problems above.

It would be worth remembering that the Web PKI ecosystem only survives out of self-regulation. Any perception of a lack of enforcement of internal rules only speeds up the process for a governmental body to wrest control of the model. In a way that in itself is a major security risk, where non-compliance forces regulation practices to dramatically shift.

If your thoughts are primarily Enterprise focused, then surely avoiding an upheaval and adding uncertainty would be your priority? Healthy self-regulation and enforcing the rules consistently for all parties is a basic part of the process. Enterprises are not lacking in opportunity to put resources into encouraging this self-regulation to their benefit, nevermind re-tooling for automation - they just need the correct incentives.

Honestly, if an Enterprise does not feel comfortable speaking in public then that is an internal issue. There isn't a shortage of Subscribers posting on issues here asking questions.

When selecting a CA partner, an Enterprise that would experience substantial disruption from a revocation would perhaps do well to investigate how well the CA in question has adhered to the policies that the CA has agreed to in order to be a CA, and how promptly and thoroughly they respond when they are discovered to be in breach of those commitments. Not only would that help understand the risk posed by revocation due to CA misbehaviour, but I think it would also give insight into the general operational health of the CA in question. That in turn reads on their ability to perform all the responsibilities of a CA—many of which could have very substantial security consequences for an Enterprise. Many Enterprises require and review audit reports from their vendors, and CAs are fortunately required to be very public about their record and commitments, so a 3rd-party auditor isn't even necessarily required for that dimension.

Enterprises who rely on issuer continuity protections would be especially well served to consider this, because misissuance by their selected CA becomes a much more material concern than does misissuance by an unrelated CA.

E: Absent such an investigation, though, the mere fact that a CA has a root present in a major root program should be sufficient assurance that the CA abides by the policies of those root programs consistently, which include not only adherence to the agreed-upon rules, but also a commitment to systematically address cases in which those rules are broken. If that is not a consistent property of the roots in those programs, then relying parties will increasingly need to make their own decisions about root trust in order to determine if a root actually complies, or simply promises to comply or gives excuses for why they can't comply. The vast majority of relying parties are not equipped to make that decision effectively, which is why the root program—and the integrity it derives from the consistent behaviour of the CAs in it—are so important to web security.

It is clear to me, however, that the argument that the new certificates would be identical in all meaningful ways to the old certificates is simply untrue and does not in itself justify choosing not to revoke these certificates.

Absolutely. I'm shocked that the assertion that these will be "nearly identical" is actually the discourse that is happening here. We should know better. This is clearly the overton window in action. These statements would've been unimaginable to hear from a root program just a few years ago.

While this discussion is helpful, I do not think it has any bearing on whether or not Mozilla, Microsoft, Google, and Apple root programs should enforce the existing set of rules by the BRs.

Realistically what this comes down to is: "Are these certificates misissued?" If the answer to this is yes, then what the CA should do about that is clear.

I think it is inappropriate to try to change the rules while an incident is happening. Root programs are claiming that this is a self-regulated space, but there are no actions taken when rules are broken.

There is certainly more Enterprises need to do to move away from Web PKI managed hierarchies for non-browser and internal use cases, drive automation and continue modernization - but today Enterprises have legacy environments where certificate rotations and hierarchy changes are often manual, non-trivial and error prone.

This is irrelevant here. Enterprise is one stakeholder here, and their views are represented even stronger than the average internet user. Despite that, the rules on revocation were set, as strict as they are, over 4 years ago. Have we regressed so much from 2018, that we're having these problems today?

These discussions have happened in publicly accessible mailing lists:

Here's some interesting pieces from this mailing list:
https://lists.cabforum.org/pipermail/servercert-wg/2018-August/000146.html

I'm not sure if this has been discussed before (sorry if I missed did),
but I would like to bring up the fact that there might be Subscribers
who suffer a Key Compromise (like the ones distributed with their own
software or embedded within customer devices), who would be willing to
leave the compromised Certificate/Key out there until they find a way to
replace it (that might take more than 24 hours or 5 days). This is a
case where the Subscriber weighs the impact of Availability in the
security properties of the offered service more than Confidentiality.

I don't agree that the Subscriber's wishes should trump the Relying
Parties. Otherwise, we never would have deprecated SHA-1 or RSA-1024.

https://lists.cabforum.org/pipermail/servercert-wg/2018-September/000166.html

The only reason I am following-up on this is because there will certainly
be CAs in the future that will be tempted to violate the 5-day rule if they
come across a dilemma like the one SHECA is facing. The public would
benefit from a disclosure requirement for revocation cases where the
revocation time must extended the 5 days requirement. CAs will have no
excuse if they do not revoke mis-issued certificates within the 5-day rule
and not use the disclosure provision to extend the 5-day rule and share the
particular revocation case with the public. IMO, it is better for CAs to
share pro-actively, rather than getting caught and share the information
anyway, under worse conditions.

I do not believe there is any justifiable or defensible reason to extend
the 5 days requirement, nor do I believe the CA should be expected to have
a 'clean' audit should they chose to do so.
CAs facing challenges of their own creation should not be exploring "How do
I keep these certs working", but "How do I make sure I don't issue
violating certs to begin with". Anything less is gross negligence, and not
the system we should be striving to build.

https://lists.cabforum.org/pipermail/servercert-wg/2018-September/000170.html

However, let's further expand this thought experiment, and think about what
the consequences are of having the CA make such a determination
(Availability > Competent and Correct operation). A CA is naturally
incentivized to optimize for Availability - the CA who never revokes their
Subscriber certs is the CA to pick, the same as the CA that always picks
the maximum validity period rather than the minimum. This is something
we've seen time and time again - the worse a CA is, for the ecosystem, the
more popular it becomes relative to its competitors. But equally, a CA that
issues such invalid certificates, but encourages non-revocation, equally
encourages the rest of the ecosystem to do so, such that it becomes the
norm - a de facto standard of incompatibility.

https://lists.cabforum.org/pipermail/servercert-wg/2018-September/000171.html

This is really the key point to me. I don't see any way to create a
"hardship exception" to the 5-day rule that won't be abused given the
incentives of both CAs and Subscribers. I would go further and state that
we already have something close to this. A number of CAs have decided to
accept a (theoretical) audit qualification rather than follow the existing
BR revocation rules. My hope is that the extension to a 5-day revocation
window will reduce this abuse and that auditors will hold CAs accountable
when they choose to violate the BRs.

So, do we have anything to add that hasn't already been fully hashed out in the CABF mailing list?

Both Auditors, and Root Programs are failing their mission here by not enforcing the rules set in the BRs.

Disclaimer: The following is my private opinion and not in any way a statement from or endorsed (or even reviewed) by my employer (SwissSign)!

I understand both sides of this argument: On the one hand, rules are here to be followed and enforced. On the other side, rules don't exist in a vacuum and need to be acceptable and useful. Hence rules need to evolve over time to keep up with changes in technology, usage of that technology, changes in behaviour and expectations and many more aspects.

Ideally, rules are changed before something happens that show that they need to be changed. The CA/B IMHO does a good job in this respect. Sometimes however, we only realize that certain circumstances exist where blind enforcment of the rules isn't making anybody more secure or has a deterrent effect for future behaviour. In such cases, I personally prefer pragmatic solutions, sometimes granting a posthum exception without setting a precedence and then re-examining whether the rule needs to be changed or the offender put on a "watchlist" or something. - In my experience, blind enforcement of rules where the benefit of the rule is no longer seen, only leads to chilling, less open reporting and fear of exposure. If we want to foster transparency and openness, then we also have to accept that mistakes happen and react appropriately.

Rgds
Roman

[This is a bit off-topic but I wanted to comment on some quoted posts from the past].

Reading specific email posts from past and complex conversations is useful if one reads the entire thread to capture the full context, otherwise it can be misleading.

I would like to clarify that my intent for bringing up the extension to the 5-day rule back in 2018 was to create a consistent way for CAs to present cases of delayed revocation into the Baseline Requirements, which was already happening in practice, at the time. That process was later created by the Mozilla Root Program for good reasons (Check the change history) and, in my understanding, the goal was to make CAs disclose more information about any special circumstances that prevent them from revoking certificates within the BR-required timelines. Based on that disclosure, further Policy adjustments (within the CA/B Forum) could be made to prevent common cases that cause delayed revocation. People can follow-up the discussions in m.d.s.p. but the main gist for this proposal can be found in this post.

Like with any controversial topic, there were arguments for and against that proposal which was nothing more than bringing an existing practice into the BRs. There was no consensus at the time but that doesn't mean that the CA/B Forum will not re-open such a topic for discussion in search for an improved version that could achieve the necessary consensus. In any case, I think this community has already collected a large number of delayed revocation incidents that need to be analyzed for commonalities. Hopefully this will lead to targeted policy changes that will minimize the chance of delayed revocation for specific problematic subscriber use cases.

(In reply to amir from comment #18)

We greatly value everyone’s input because it enables us to engage in informed decision-making. We are considering whether these certificates should be revoked. Are there additional insights and opinions regarding that question? It appears that the certificates complied with industry standards and that the replacement certificates would be nearly identical, except for serial numbers and validity periods. In stating your position, please consider and explain both the potential benefits and drawbacks to the Mozilla root program and the security of the internet. Thanks.

Actually, I think the onus is on the Root Program and CAs to do the security analysis of why following the rules would be too difficult and how these misissued certificates "are nearly identical" and "okay".

I appreciate your engagement and these thoughtful questions regarding the operation of the Mozilla Root Program. Your questions highlight the importance of transparency and accountability in how we manage our root store. While I welcome open discussions on these topics, it is important to approach them with a constructive and respectful dialogue rather than to put the root program on the defensive. Our discussions are most productive when we collectively explore these complex issues, bringing together diverse viewpoints and expertise.

Mozilla Root Program, can you answer these questions:

  1. Has Entrust reached out to you in a non-public manner regarding any of their current 15 incidents?

We are committed to maintaining the highest standards of transparency, but there are reasons why we engage in private communications with CAs, including: to provide constructive feedback and encourage and guide CAs toward compliance and improvement (while CAs help root programs understand practical challenges, which is essential when we develop and improve policies that are secure and can be implemented); to mitigate risk (e.g., https://wiki.mozilla.org/CA/Vulnerability_Disclosure); to provide support and assistance (e.g. questions related to the CCADB and the root inclusion process), and CAs sometimes require technical or policy assistance when implementing requirements within their infrastructure or processes; to collaborate on industry standards (this environment is still rapidly evolving and close collaboration with CAs through private discussions helps root programs gain insights into evolving industry standards and practices, ensuring that standards and policies are relevant and effective); for responsiveness and efficiency--private discussions allow root programs to respond swiftly and efficiently to CA inquiries or issues, enabling more flexible problem-solving than in a public forum; and to build trust (collaborative environment where CAs can express concerns or challenges candidly).

In summary, private discussions are not just about confidentiality or security; they help cultivate an open, constructive relationship between root programs and CAs. This ensures that both parties work collaboratively to maintain high standards of security and trust across the internet.

  1. Are these certificates misissued?

Certificate misissuances are taken seriously and are required to be reported, triaged, and addressed according to the documented procedures and compliance rules of the Mozilla Root Program. This ensures a rigorous and fair handling of any issues that arise.

  1. Do the baseline requirements allow misissued certificates being left unrevoked? If so, where?

The CABF’s Baseline Requirements are meant to set standards for the issuance and management of certificates. Our goal is to uphold these standards rigorously and to address any deviations swiftly and effectively. Regarding revocation, our position is stated here: https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation. For a more specific answer to your question about the Baseline Requirements, they are available for review at: https://cabforum.org/working-groups/server/baseline-requirements/requirements/.

  1. If not, does the Mozilla Root Program consider this a "special circumstance"? If so, where is the procedure regarding "special circumstances" documented?

From time to time, situations arise that not only require added scrutiny and due process, but also flexibility, in ensuring the security and trustworthiness of the internet. The implementation of these exceptions occurs openly here on Bugzilla and in the Mozilla dev-security-policy forum.

  1. What are the other Mozilla Root Program rules that don't matter? For example, can ${CA} maliciously issue a certificate and reject revocation, claiming that these certificates will be nearly identical, just that the entity holding the private key is different?

No rule within the Mozilla Root Program is considered unimportant. We believe that each requirement is important for the integrity and security of internet communications. Allegations of malicious actions by CAs are treated with the highest level of seriousness and investigated thoroughly.

  1. If there are other parts of the BRs that the Mozilla Root Program doesn't consider important, can you please list those out with their sections?

We encourage open discussions and questions about our processes. However, it is equally important to ensure that these inquiries are aimed at constructive feedback and a deeper understanding of our mutual goals for a secure and reliable internet. We remain committed to engaging with our community in ways that foster trust and respect among all stakeholders.

Thank you for your attention and continued participation in our community. We value your contributions and look forward to further discussions.

Flags: needinfo?(bwilson)

Thank you for the response Ben! I appreciate the transparency in the matter, so I want to follow up with a few other questions & comments:

Regarding if Entrust has reached out to you privately. I think that discussions about requirements, changes to the ecosystem, etc would benefit from happening out in the open. I think the dev-security-policy mailing list would be a perfect place for these discussions since:

  1. CAs are required to follow the discussions there. And discussions about the ecosystem in general is probably useful for more than just the one CA reaching out.

  2. It helps independent researchers understand what the conversations going on are about.

  3. It helps CAs improve their operations based on the discussions in those mailing lists. It also serves as a litmus test for other CAs that may not actually be following Bugzilla and the mailing lists. Causing them to have repeat of similar incidents in the community.

I understand that some discussions may be sensitive, and may need to be kept hidden until that issue is mitigated.

Regarding revocation, our position is stated here: https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation.

It is unclear if this is a policy document that comes into effect over the existing BRs, or as a supplementation to it. Could you please clarify in the case of revocation, what is the hierarchy these documents are read through?

Beyond that, that section in the wiki specifies specific requirements that I've not seen 1) enforced, 2) actually done by most CAs. So it raises the question of 1) does the enforcement strategy of Mozilla need to be updated 2) does that wiki page need to be updated to remove those requirements.

For example, incidents that delayed revocation, and never did the requirements listed in that wiki end up getting closed. For example, an improvement in this area can be that a delayed revocation incident can't be closed without:

  1. Providing a weekly summary of when the certificates are going to expire naturally. For example, the CAA incident from Let's Encrypt can be used as an example of a very effective way of doing this.
  2. Providing a per-subscriber reasoning for why their certificates can't be revoked/are delayed in revocation.
  3. Action items that prevent the occurrence of another delayed revocation.

Throughout these incidents, we've seen that Entrust simply doesn't do the second or third. Every single time I've asked them to provide reasonable action items for what they're doing to prevent delayed revocations, they toe around that and never commit to anything.

No rule within the Mozilla Root Program is considered unimportant.

I really want this to be true, but even in this incident we're seeing that it isn't actually the case. My feedback here is that, while discussions around new rules and requirements are helpful, I do not think that they should be retroactively applied. Doing so creates a mal-incentive for CAs to lobby/talk/discuss instead of take the expected actions of them at the time.

Once the required actions have been taken, a discussion surrounding if those rules make sense or not would be a huge benefit for the ecosystem. In some form, this could look like an "Incident & Rules postmortem." A clear separation of discussion about the active incident and the rules that turned that event into an incident would create a healthy platform to discuss these.

Given the reputation and broken promises by some CAs, when these incidents turn into discussions about "does this requirement make sense?", it's hard to see them for anything other than yet another broken promise from a CA.

From the bottom of my heart, thank you for all your hard work and dedication. It has ensured that the public trust in WebPKI strengthens day by day.

Thank you for your follow-up and detailed input. I understand your concerns and appreciate these suggestions on how we might improve. Let me attempt to respond to them as follows:

1. Public Discussions and Transparency
I agree that many discussions about requirements and ecosystem changes would be beneficial if conducted publicly. In addition to discussing important issues with a broader audience on Mozilla dev-security-policy, maybe we should create an online forum specifically aimed at addressing minor issues, which would ensure that CAs, independent researchers, and other stakeholders are better informed. There is also the CCADB Public list, but maybe an additional resource is still needed.

2. Revocation
Regarding your query about the language on the wiki page and its relation to the Baseline Requirements, the wiki page has served as a supplemental guide to the BRs and has stated Mozilla’s balanced approach to handling revocation. However, as you and others have pointed out, more work needs to be done to update both the Baseline Requirements and the wiki page to provide clearer statements of policy, requirements, and expectations concerning revocation.

3. Consistent Enforcement of Policy
You’ve raised valid points about the need for consistent enforcement of policy, and it is important that all requirements are enforced consistently. Your feedback suggests a need to review our strategies and documentation beyond just revocation. We agree that rules need to be applied fairly and consistently across all incidents, and that policy be written so that enforcement is appropriate for all anticipated circumstances. I use GitHub to track issues with the Mozilla Root Store Policy - https://github.com/mozilla/pkipolicy/issues. Note, however, that policies, requirements, and practices in this area continue to evolve rapidly based on ongoing feedback and changing circumstances, and so we need some flexibility to adapt our approaches as necessary to meet the challenges we face.

4. CA Commitments
The issue with CAs not fulfilling their commitments, particularly regarding action items for preventing future occurrences, is concerning. Entrust and other CAs must be held accountable to their promises and commitments, and we continue and strive to follow-through on all CA commitments and CA action items prior to closing each bug.

Again, thank you for your engagement and your detailed suggestions, which will help us improve as we move forward.

We have no updates for this week and will continue to monitor the bug.

Setting Next Update to 2024-06-17 based on Comment #1.

Whiteboard: [ca-compliance] [policy-failure] → [ca-compliance] [policy-failure] Next update 2024-06-17

(In reply to Bruce Morton from comment #13)

We are not aware of any programs providing exceptions for revocation; however Apple and Chrome refer to the Mozilla policy for revocation.

Bruce, could you help me find where Chrome and Apple refer to the Mozilla policy for revocation?

I do not see any such references in https://www.chromium.org/Home/chromium-security/root-ca-policy/ , only that incident reports should be filed in Bugzilla, in accordance with the CCADB incident report format and timelines.

Similarly, in https://www.apple.com/certificateauthority/ca_program.html I only see indication that incidents may be submitted to Apple in the form to a link to a Bugzilla report. There are no references to the Mozilla revocation or incident response policy.

Flags: needinfo?(bruce.morton)

We have no updates for this week but will have an update on "Review CPS update procedure" by 6/30 per our posted due date in comment #1
https://bugzilla.mozilla.org/show_bug.cgi?id=1890896#c1

We will continue to monitor the bug.

(In reply to Mike Shaver (:shaver emeritus) from comment #37)

(In reply to Bruce Morton from comment #13)

We are not aware of any programs providing exceptions for revocation; however Apple and Chrome refer to the Mozilla policy for revocation.

Bruce, could you help me find where Chrome and Apple refer to the Mozilla policy for revocation?

I do not see any such references in https://www.chromium.org/Home/chromium-security/root-ca-policy/ , only that incident reports should be filed in Bugzilla, in accordance with the CCADB incident report format and timelines.

Similarly, in https://www.apple.com/certificateauthority/ca_program.html I only see indication that incidents may be submitted to Apple in the form to a link to a Bugzilla report. There are no references to the Mozilla revocation or incident response policy.

The comment was retracted in comment 16 which said this “Hi Ryan, apologies for the miss-statement. Yes, I should have stated CCADB Policy. As such, we are not aware that Chrome, Apple or Microsoft root programs provide any exceptions for revocation.”
See https://bugzilla.mozilla.org/show_bug.cgi?id=1890896#c16

Note that the original statement was made based on the understanding that Google and Apple respected the Mozilla delayed revocation procedure.

(In reply to ngook.kong from comment #39)

The comment was retracted in comment 16 which said this “Hi Ryan, apologies for the miss-statement. Yes, I should have stated CCADB Policy. As such, we are not aware that Chrome, Apple or Microsoft root programs provide any exceptions for revocation.”
See https://bugzilla.mozilla.org/show_bug.cgi?id=1890896#c16

Note that the original statement was made based on the understanding that Google and Apple respected the Mozilla delayed revocation procedure.

Apologies for missing that, and thank you for the clarification.

Whiteboard: [ca-compliance] [policy-failure] Next update 2024-06-17 → [ca-compliance] [policy-failure]

We have no updates, but plan to update action status this week.

Flags: needinfo?(bruce.morton)

Action Items

Action Item Kind Due Date
File an incident report for not revoking the affected certificates Transparency Done
Add errata to CPS version 3.18 and 3.19 to advise readers of the changes Transparency Done
Inform subscribers of the CPS error Transparency Done
Review CPS update procedure Prevent 2024-08-31
Rename “SSL certificate profile” to “OV TLS certificate profile” Prevent 2024-08-31
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: