IdenTrust: Delay beyond 5 days in revoking misissued certificates
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: roots, Assigned: roots)
Details
(Whiteboard: [ca-compliance] [leaf-revocation-delay])
Attachments
(5 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Edg/116.0.1938.62
Steps to reproduce:
While reviewing the certificates to be revoked due non-compliance with our CPS disclosed via bug 1850807, we determined that all of the affected certificates are from enterprise customers, for which prompt revocation is expected by the BRs, would result in a greater operational disruption and harm to them and their end users, than the potential harm from waiting to revoke the certificates in a more timely and orderly manner.
We are working in the details to provide the full incident report which will be disclosed no later than September 15, 2023.
|
||
Updated•8 months ago
|
- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.
On 2023-08-30 10:31 MT IdenTrust reported a compliance incident described in bug 1850807.
As of 2023-09-03 not all of those certificates have been revoked as required by the Baseline Requirements v1.8.7, in force at the time. Section 4.9.1.1 states, “With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: … the CA is made aware that the Certificate was not issued in accordance with … [the] Certification Practice Statement.”
- 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.
• 2023-08-28 12:20 MST: During an internal review of the CPS, we found that CPS Section 7.1.2.3 “End Entity Server Certificates,” requires that the ‘basicConstraints’ extension must be marked as critical if it is present. Our certificate profile required the presence of basicConstraints but marked it as "not critical."
• 2023-08-28 13:00 MST: We began investigating the scope of affected certificates.
• 2023-08-28 16:05 MST: We examined the certificate database and found 1,187 instances of EV TLS certificates issued by one CA – HydrantID Server CA O1 – that had the basicConstraints extension present but not marked as critical.
• 2023-08-29 11:00 MST: We updated the certificate profile of the ICA issuing EV TLS certificates by removing the basicConstraints extension.
• 2023-08-29 11:15 MST: We began the initial outreach to some affected customers that the misissued certificates would be revoked and replaced. Communication was difficult due to the weekend and US holiday 2023-09-04 through 2023-09-04.
• 2023 -08-30 11:31 MST: We posted the preliminary report bug 1850807.
• 2023-09-03 15:00 MST: we confirmed that 3 certificates had been revoked and 4 certificates were expired.
• 2023-09-13 15:00 MST: we confirmed that 67 certificates had been revoked and 9 certificates were expired.
• 2023-09-15 15:00 MST: we confirmed that 107 certificates had been revoked and 33 certificates were expired.
- Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation
We have removed the basicConstraints extension from the EV TLS certificate profile for the affected issuing CA as described in bug 1850807.
- In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued.
Files are attached to both this bug and the original bug 1850807 with the set of affected certificates issued between 2022-08-08 and 2023-08-29
• Affected certificates still valid:1,048
• A list of revoked certificates: 107 certificates
• A list of Expired certificates: 33 certificates
- In a case involving TLS server certificates, 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. It is also recommended that you use this form in your list "https://crt.sh/?sha256=[sha256-hash]", unless circumstances dictate otherwise. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
Please see files attached here and in bug 1850807 that includes
• A list of affected certificates still valid (not expired and not revoked): 1,047certificates
• A list of revoked certificates: 107 certificates
• A list of Expired certificates: 33 certificates
Of the 1187 affected certificates, 107 have been revoked, 33 have expired as of 2023-9-15. Many of the remaining certificates have been replaced and put into service for testing before the affected certificates are revoked. IdenTrust does not have an accurate way of determining how many certificates are in this category.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Risk to critical infrastructure
We performed a risk assessment focused on the revocation impact our enterprise customers involved in the incident will have, compared with the risks associated with leaving the affected certificates in place for a little longer. We found that the volume of affected certificates and the critical infrastructure disruption the revocation could cause to customers and relying parties is greater than the risk posed by the continued use of the affected certificates. Revocation activities have therefore been delayed beyond the expected five days.
About 40 percent of our customers have been able to revoke all their affected certificates already, accounting for about 10 percent of the certificate total. We are actively working with our remaining affected customers to establish a rapid and appropriate timeline for revoking the remaining certificates. We expect that most of these certificates will be revoked by 30 November 2023, with less than 10% extending beyond that date.
Most customers will replace the affected certificates and complete testing before revocation of the old certificates. We will provide weekly updates on the revocation progress.
Timing
Communication with customers was difficult due to the weekend and US holiday 2023-09-02 through 2023-09-04.
- List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
• We have removed the basicConstraints extension from the EV TLS certificate profile.
• With the basicConstraints extension removed from the certificate profile, no changes need to be made to other items.
As noted in the response to item 6 above, we will provide weekly updates on revoked certificates. The next update is scheduled for Friday, 2023-09-22.
As of today, we have 112 revoked certificates, 56 expired certificates, and 1,019 certificates still active.
Many of the remaining certificates have been replaced and put into service for testing before the affected certificates are revoked. IdenTrust does not have an accurate way of determining how many certificates are in this category. The next report is scheduled for Friday 2023-09-29.
|
||
Comment 10•7 months ago
|
||
Could IdenTrust explain the exceptional reasons why IdenTrust's subscribers may keep using their misissued certificates way beyond the stipulated 5 day deadline? It seems that these exceptional reasons weren't included in the report in comment #8, at least none that don't sound a lot like the unacceptable "we do not deem this non-compliant certificate to be a security risk" response, and none seem to go deep into "critical systems" - which could be anything.
Could IdenTrust also add why IdenTrust expects it to take until the end of November (3 months!) to revoke 90% of their problematic certificates, when the stipulated timeline is 5 days?
Does IdenTrust have a timeline for the remainder of the problematic certificate corpus to be revoked? I.e. one including the last 10%?
We are actively working with our remaining affected customers to establish a rapid and appropriate timeline for revoking the remaining certificates. We expect that most of these certificates will be revoked by 30 November 2023, with less than 10% extending beyond that date.
First, I find that a certificate revocation delay of 3 months for 10% of the certificates is neither "rapid" nor "appropriate". Why does IdenTrust consider that "rapid and appropriate" when the BR make clear that all leaf certificates must be revoked within 5 days of detected misissuance?
Second, could IdenTrust share this established timeline with us, assuming that the timeline has been established? If not yet, then could IdenTrust share when they're expecting they'll be able to share that timeline with us?
- List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future
• We have removed the basicConstraints extension from the EV TLS certificate profile.
• With the basicConstraints extension removed from the certificate profile, no changes need to be made to other items.
What are IdenTrust's steps to prevent this issue from occurring, i.e. a late revocation of a significant amount of certificates?
The quoted remediations don't seem to change any process that touches on the topic of revocation within the BR-stipulated timeline, nor does it seem to do anything to improve their enterprise customer certificate revocation risks.
|
||
Comment 11•7 months ago
|
||
In addition to the valid comments in c10, could you please detail exactly what kind of 'fingerprint' you are using for these certificates, preferably adding crt.sh and/or censys links so that we may see exactly which certificates these are?
|
Assignee | |
Comment 12•7 months ago
|
||
(In reply to Matthias from comment #10)
Hello Matthais. please see below for our response.
Could IdenTrust explain the exceptional reasons why IdenTrust's subscribers may keep using their misissued certificates way beyond the stipulated 5 day deadline? It seems that these exceptional reasons weren't included in the report in comment #8, at least none that don't sound a lot like the unacceptable "we do not deem this non-compliant certificate to be a security risk" response, and none seem to go deep into "critical systems" - which could be anything.
• These are EV certificates. They are being used by our customers in the more sensitive parts of their systems, and are therefore harder to replace quickly without testing their replacements before revoking the misissued certificates.
• Below are a few of the responses we received from customers that support the difficulty they faced during the revocation and replacement processes.
o Mission critical certificates were affected by the misissuance, this will result in disruption of day-to-day functionality if revoked within
the allotted time.
o The affected certificates are used for public-facing websites, which go through strict change control.
o Customer utilizes globally diversified teams with change management processes that require testing and approval before deploying
to production.
o Customer had communication and implementation barriers within the company
o Customer had difficulty locating internal certificate refresh processes.
Could IdenTrust also add why IdenTrust expects it to take until the end of November (3 months!) to revoke 90% of their problematic certificates, when the stipulated timeline is 5 days?
• Many of the remaining certificates have been replaced and put into service for testing before the affected certificates can be revoked. IdenTrust unfortunately cannot have an accurate way of determining how many certificates are in this category. Revoking the certificates before a new certificate propagates fully would introduce risk to customers and will cause significant disruptions to the day-to-day functionality of the customers involved.
• 38.5% (457 certificates) are scheduled to be revoked by EOD 2023.09.30.
• 61.5% (730 certificates) are scheduled to be revoked by EOD 2023.10.30.
o 98% of the 730 certificates of the certificates are associated with 2 customers.
Does IdenTrust have a timeline for the remainder of the problematic certificate corpus to be revoked? I.e. one including the last 10%?
• We expect all misissued certificates will be revoked by end of day 2023.12.31
We are actively working with our remaining affected customers to establish a rapid and appropriate timeline for revoking the remaining certificates. We expect that most of these certificates will be revoked by 30 November 2023, with less than 10% extending beyond that date.
First, I find that a certificate revocation delay of 3 months for 10% of the certificates is neither "rapid" nor "appropriate". Why does IdenTrust consider that "rapid and appropriate" when the BR make clear that all leaf certificates must be revoked within 5 days of detected misissuance?
• The process does not appear rapid because many of the remaining certificates have been replaced and put into service for testing before the affected certificates can be revoked. IdenTrust unfortunately cannot have an accurate way of determining how many certificates are in this category.
Second, could IdenTrust share this established timeline with us, assuming that the timeline has been established? If not yet, then could IdenTrust share when they're expecting they'll be able to share that timeline with us?
• 38% have the deadline of 2023.09.30.
• 62% have the deadline of 2023.10.30.
- List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future
• We have removed the basicConstraints extension from the EV TLS certificate profile.
• With the basicConstraints extension removed from the certificate profile, no changes need to be made to other items.What are IdenTrust's steps to prevent this issue from occurring, i.e. a late revocation of a significant amount of certificates?
The quoted remediations don't seem to change any process that touches on the topic of revocation within the BR-stipulated timeline, nor does it seem to do anything to improve their enterprise customer certificate revocation risks.
• The revocation timeline depends on the certificates affected and the customer’s use of those certificates.
• EV certificate customers have their internal processes for requesting and implementing changes in their respective sensitive environments, and IdenTrust does not control those processes. This inevitably leads to delays.
• To improve our internal processes, we have created a quicker process of reporting, root cause analysis, and customer notification. This will help contribute to earlier revocation expectations and implementation from customers.
|
|
Assignee | |
Comment 13•7 months ago
|
||
(In reply to JR Moir from comment #11)
In addition to the valid comments in c10, could you please detail exactly what kind of 'fingerprint' you are using for these certificates, preferably adding crt.sh and/or censys links so that we may see exactly which certificates these are?
The data column om that file was mislabeled as a hash when in fact it contained the certificates' serial numbers. We are attaching an Excel file using the initial list of 1187 certificates, this time with crt.sh links using the serial number for each certificate. This should allow for more efficient searching.
|
|
Assignee | |
Comment 14•7 months ago
|
||
This file replaces the initial "full report" file, and contains a URL for each certificate that was misissued.
|
|
||
Comment 15•7 months ago
|
||
(In reply to IdenTrust from comment #12)
Thanks for the response, but I have some remaining comments and questions. The primary issue I'm seeing is detailed in the last section ("how do you ensure that this won't happen again"), but other comments are also interspersed.
(In reply to Matthias from comment #10)
Could IdenTrust explain the exceptional reasons why IdenTrust's subscribers may keep using their misissued certificates way beyond the stipulated 5 day deadline? It seems that these exceptional reasons weren't included in the report in comment #8, at least none that don't sound a lot like the unacceptable "we do not deem this non-compliant certificate to be a security risk" response, and none seem to go deep into "critical systems" - which could be anything.
• These are EV certificates. They are being used by our customers in the more sensitive parts of their systems, and are therefore harder to replace quickly without testing their replacements before revoking the misissued certificates.
• Below are a few of the responses we received from customers that support the difficulty they faced during the revocation and replacement processes.
- Mission critical certificates were affected by the misissuance, this will result in disruption of day-to-day functionality if revoked within
the allotted time.
There are many "mission critical" systems that I know of that can get their certificates replaced within 5 days, let alone 30, if it really needs to be replaced. I fail to see the exceptionality here: several other CAs have had to revoke such certificates before.
- The affected certificates are used for public-facing websites, which go through strict change control.
I fail to see the exceptionality here: Strict change control is not uncommon, nor are public-facing websites, nor the combination of the two.
- Customer utilizes globally diversified teams with change management processes that require testing and approval before deploying
to production.- Customer had communication and implementation barriers within the company
- Customer had difficulty locating internal certificate refresh processes.
Under BR section 9.6.3, the CA is required to include in their Terms of Service or Subscriber Agreement "the following obligations and warranties:
[...]
- Reporting and Revocation : An obligation and warranty to: [...]
b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate; [...] - Acknowledgment and Acceptance : An acknowledgement and acceptance that the CA is entitled to revoke the certificate immediately if [...] revocation is required by the CA's CP, CPS, or these Baseline Requirements."
Assuming that IdenTrust has included this in their Subscriber Agreement and/or ToS, swift revocation shouldn't be an issue for IdenTrust. I don't appreciate that IdenTrust makes the unilateral decision to not follow the baseline of requirements that were made to build trust and security.
Could IdenTrust also add why IdenTrust expects it to take until the end of November (3 months!) to revoke 90% of their problematic certificates, when the stipulated timeline is 5 days?
• Many of the remaining certificates have been replaced and put into service for testing before the affected certificates can be revoked. IdenTrust unfortunately cannot have an accurate way of determining how many certificates are in this category.
Please note that while swift revocation is a requirement in the BR, replacement before revocation is not. Why does IdenTrust consider replacement more important than the timely revocation required by the BR?
Revoking the certificates before a new certificate propagates fully would introduce risk to customers and will cause significant disruptions to the day-to-day functionality of the customers involved.
The choice not to revoke problematic certificates introduces risk to end users, and while I do understand that customers keep the lights on, a CA that introduces more risk to end users is not worth my trust as an end user.
Does IdenTrust have a timeline for the remainder of the problematic certificate corpus to be revoked? I.e. one including the last 10%?
• We expect all misissued certificates will be revoked by end of day 2023.12.31
Given that certificates have a maximum lifespan of 397 days, you have issued certificates that (given current plans) are to live over 30% of their useful lifetime in an incorrect revocation status: They have been determined problematic, but have not been revoked within the time required by the BR. I don't think that's justifiable.
Second, could IdenTrust share this established timeline with us, assuming that the timeline has been established? If not yet, then could IdenTrust share when they're expecting they'll be able to share that timeline with us?
• 38% have the deadline of 2023.09.30.
• 62% have the deadline of 2023.10.30.
Thank you for providing this timeline.
What are IdenTrust's steps to prevent this issue from occurring, i.e. a late revocation of a significant amount of certificates?
The quoted remediations don't seem to change any process that touches on the topic of revocation within the BR-stipulated timeline, nor does it seem to do anything to improve their enterprise customer certificate revocation risks.
• The revocation timeline depends on the certificates affected and the customer’s use of those certificates.
• EV certificate customers have their internal processes for requesting and implementing changes in their respective sensitive environments, and IdenTrust does not control those processes. This inevitably leads to delays.
• To improve our internal processes, we have created a quicker process of reporting, root cause analysis, and customer notification. This will help contribute to earlier revocation expectations and implementation from customers.
As you've shown, your customers have replacement timelines of up to 4 months. Even if you were able to do all Certificate Problem Report processing instantly, as long as you put certificate replacement in the critical path before revocation you are all but guaranteed to see this issue again: As you yourself acknowledge, the customer will not have replaced their certificate within the deadline that the BR stipulates for revocation.
That is why I'm asking you about the (planned) changes in your processes, about what are you doing to make sure that you will revoke the certificates on time next time: Improving internal processes is nice and all, but as long as the customer's processes are part of the critical revocation process flow, I don't see how you'll ever be able to comply with this requirement of the BR.
|
|
Assignee | |
Comment 16•7 months ago
|
||
We are attaching a file showing the misissued certificates that have been revoked or have expired to this date. The next update is scheduled for Monday, 2023-10-09.
|
|
Assignee | |
Comment 17•7 months ago
|
||
We acknowledge receipt of comment #15 from Mathias and will provide a reply no later than October 13, 2023.
|
|
Assignee | |
Comment 18•7 months ago
|
||
As of October 11, 2023, of the 1187 misissued certificates:
- 411 have been revoked
- 185 have expired naturally
- 591 remain in not revoked / not expired status, with replacement certificates being tested before existing ones are revoked.
Several hundred more certificates are ready for revocation, and several hundred replacement certificates have been shipped to customers in preparation for revocation.
IdenTrust and its customers remain committed to an October 31, 2023 date for completion of the revocation/replacement process.
|
|
||
Updated•7 months ago
|
|
|
Assignee | |
Comment 19•7 months ago
|
||
(In reply to Matthias from comment #15)
Assuming that IdenTrust has included this in their Subscriber Agreement and/or ToS, swift revocation shouldn't be an issue for IdenTrust. I don't appreciate that IdenTrust makes the unilateral decision to not follow the baseline of requirements that were made to build trust and security.
IdenTrust:
Certainly, our TLS Subscriber agreement explicitly allows for immediate revocation in cases where certificates are not correctly issued. However, in the recent incident, we acknowledge the oversight in promptly sharing a preliminary incident report detailing the reasons behind the requested extension for revocation.
In the event of a security compromise, we affirm our commitment to exercising the right to revoke within 24 hours, prioritizing the mitigation of risks over potential consequences to Subscribers or the Internet. Yet, after a thorough review of the criteria outlined in BR Section 4.9.5 and extensive consultations with our Subscribers, we made the informed decision to extend the revocation deadlines. This was based on the following considerations:
- The perceived risk of harm to relying parties and the internet was assessed as low.
- The potential consequences of immediate revocation to Subscribers and relying parties were deemed high.
- No Problem Reports were received regarding this issue.
- The internal discovery of the issue, without involvement of third parties, meant that external interests were not at stake.
- No relevant legislation applied to the incident.
In response to this incident, we have taken steps to enhance our processes. Specifically, we have implemented improvements to ensure more timely disclosure through preliminary incident reports when revocation within the 5-day period is unavoidable. We understand the importance of upholding trust and security, and we are committed to continuous improvement in alignment with the expectations set forth in the CA/B F. Baseline Requirements
Please note that while swift revocation is a requirement in the BR, replacement before revocation is not. Why does IdenTrust consider replacement more important than the timely revocation required by the BR?
IdenTrust:
Our customers emphasize the need to test each new or replaced certificate before undergoing revocation.
The choice not to revoke problematic certificates introduces risk to end users, and while I do understand that customers keep the lights on, a CA that introduces more risk to end users is not worth my trust as an end user.
IdenTrust:
In this specific case, the identified problem doesn't pose additional risk to end users. Instead, it involves an incorrect flag in an optional field. The disclosure of this issue is necessary due to the conflict with the (CPS).
Given that certificates have a maximum lifespan of 397 days, you have issued certificates that (given current plans) are to live over 30% of their useful lifetime in an incorrect revocation status: They have been determined problematic, but have not been revoked within the time required by the BR. I don't think that's justifiable.
IdenTrust:
As highlighted earlier, the mississuance problem does not currently present a risk to end-users.
That is why I'm asking you about the (planned) changes in your processes, about what are you doing to make sure that you will revoke the certificates on time next time: Improving internal processes is nice and all, but as long as the customer's processes are part of the critical revocation process flow, I don't see how you'll ever be able to comply with this requirement of the BR.
IdenTrust:
In response to your inquiry about our planned process changes, we've enhanced our approach to deliver earlier disclosure in preliminary incident reports when revocation within a 5-day period is unavoidable.
|
|
||
Comment 20•7 months ago
|
||
Given that certificates have a maximum lifespan of 397 days, you have issued certificates that (given current plans) are to live over 30% of their useful lifetime in an incorrect revocation status: They have been determined problematic, but have not been revoked within the time required by the BR. I don't think that's justifiable.
IdenTrust:
As highlighted earlier, the mississuance problem does not currently present a risk to end-users.
The basis of trust is that a CA complies with its publicly stated policies, including those on the revocation of certificates. If it becomes clear from public communications that a CA does not plan to fully comply with all their publicly stated policies, then I don't see why we should keep the trust bits for this CA. This includes fringe cases like newly issued certificates not matching the certificate profiles included in the CP/CPS.
That is why I'm asking you about the (planned) changes in your processes, about what are you doing to make sure that you will revoke the certificates on time next time: Improving internal processes is nice and all, but as long as the customer's processes are part of the critical revocation process flow, I don't see how you'll ever be able to comply with this requirement of the BR.
IdenTrust:
In response to your inquiry about our planned process changes, we've enhanced our approach to deliver earlier disclosure in preliminary incident reports when revocation within a 5-day period is unavoidable.
All valid incident reports related to misissuance of subscriber certificates have a revocation period of at most 5 days. I don't see how you can "avoid" this period, let alone whether a CA should try to avoid this 5-day period, but please do tell if there is something on this topic that I was not yet aware of.
|
|
Assignee | |
Comment 21•7 months ago
|
||
(In reply to Matthias from comment #20)
The basis of trust is that a CA complies with its publicly stated policies, including those on the revocation of certificates. If it becomes clear from public communications that a CA does not plan to fully comply with all their publicly stated policies, then I don't see why we should keep the trust bits for this CA. This includes fringe cases like newly issued certificates not matching the certificate profiles included in the CP/CPS.
All valid incident reports related to misissuance of subscriber certificates have a revocation period of at most 5 days. I don't see how you can "avoid" this period, let alone whether a CA should try to avoid this 5-day period, but please do tell if there is something on this topic that I was not yet aware of.
IdenTrust:
We fully support Matthias’s emphasis on CA’s public trust, but we must express disagreement regarding his interpretation of our stance on compliance with certificate policies. Our disclosure of a self-discovered misissuance, stemming from a mismatched certificate profile for an optional field against the documented CPS, underscores our commitment to transparency within the community.
Our feedback has addressed the unfortunate circumstances of this incident. By the time we confirmed the misissuance, meeting the Baseline Requirements for revoking all affected certificates within the expected timeframe was not feasible. Our commitment for future incidents of a similar nature is to ensure the revocation of all certificates within the stipulated 5-day period and to promptly raise awareness with the appropriate through a separate incident reports, following Mozilla’s s revocation guidelines.
As mentioned previously, we have already improved our internal processes to create a quicker methodology for internal reporting, root cause analysis, and customer notification. These steps will improve our ability to identify and respond to issues such as this, and to ensure compliance with the Baseline Requirements.
|
||
Comment 22•7 months ago
|
||
Our commitment for future incidents of a similar nature is to ensure the revocation of all certificates within the stipulated 5-day period and to promptly raise awareness with the appropriate through a separate incident reports, following Mozilla’s s revocation guidelines.
I would like to ask some clarifications about this statement which seems a bit ambiguous. On one hand you say "ensure the revocation" and on the other hand you say "separate incident reports" implying the delayed revocation process described in Mozilla's revocation guidelines. I'm reading these two statements as mutually exclusive but I could be wrong. Can you please clarify?
|
|
Assignee | |
Comment 23•7 months ago
|
||
(In reply to Dimitris Zacharopoulos from comment #22)
Our commitment for future incidents of a similar nature is to ensure the revocation of all certificates within the stipulated 5-day period and to promptly raise awareness with the appropriate through a separate incident reports, following Mozilla’s s revocation guidelines.
I would like to ask some clarifications about this statement which seems a bit ambiguous. On one hand you say "ensure the revocation" and on the other hand you say "separate incident reports" implying the delayed revocation process described in Mozilla's revocation guidelines. I'm reading these two statements as mutually exclusive but I could be wrong. Can you please clarify?
Dimitris, You pose a good question. Here is what we intended to write but via copy/paste got unwanted text (sorry about that):
Our commitment for future incidents of a similar nature is to ensure the revocation of all certificates within the stipulated 5-day period and to promptly raise awareness with the appropriate incident reports, following Mozilla’s s revocation guidelines.
|
|
||
Comment 24•6 months ago
|
||
(In reply to IdenTrust from comment #21)
(In reply to Matthias from comment #20)
The basis of trust is that a CA complies with its publicly stated policies, including those on the revocation of certificates. If it becomes clear from public communications that a CA does not plan to fully comply with all their publicly stated policies, then I don't see why we should keep the trust bits for this CA. This includes fringe cases like newly issued certificates not matching the certificate profiles included in the CP/CPS.
All valid incident reports related to misissuance of subscriber certificates have a revocation period of at most 5 days. I don't see how you can "avoid" this period, let alone whether a CA should try to avoid this 5-day period, but please do tell if there is something on this topic that I was not yet aware of.
IdenTrust:
We fully support Matthias’s emphasis on CA’s public trust, but we must express disagreement regarding his interpretation of our stance on compliance with certificate policies. Our disclosure of a self-discovered misissuance, stemming from a mismatched certificate profile for an optional field against the documented CPS, underscores our commitment to transparency within the community.
I do appreciate your transparency; that transparency has never been an issue.
Our feedback has addressed the unfortunate circumstances of this incident. By the time we confirmed the misissuance, meeting the Baseline Requirements for revoking all affected certificates within the expected timeframe was not feasible. Our commitment for future incidents of a similar nature is to ensure the revocation of all certificates within the stipulated 5-day period and to promptly raise awareness with the appropriate through a separate incident reports, following Mozilla’s s revocation guidelines.
As mentioned previously, we have already improved our internal processes to create a quicker methodology for internal reporting, root cause analysis, and customer notification. These steps will improve our ability to identify and respond to issues such as this, and to ensure compliance with the Baseline Requirements.
See my comment 15, but also later in this comment: You've shared no material improvement to the policies you shared with comment 12, so to me this is an empty claim.
(In reply to IdenTrust from comment #19)
(In reply to Matthias from comment #15)
That is why I'm asking you about the (planned) changes in your processes, about what are you doing to make sure that you will revoke the certificates on time next time: Improving internal processes is nice and all, but as long as the customer's processes are part of the critical revocation process flow, I don't see how you'll ever be able to comply with this requirement of the BR.
IdenTrust:
In response to your inquiry about our planned process changes, we've enhanced our approach to deliver earlier disclosure in preliminary incident reports when revocation within a 5-day period is unavoidable.
What does this 'enhancement' mean exactly? I'm asking this because there is no real indication that the process has changed materially, nor how it was changed, from what was detailed in comment #12, of which I showed with comment #15 that there were structural issues w.r.t. compliance to BR revocation deadlines.
I'll repeat from my comment 15, that in comment 12 your process indicates that the actual revocation happens only after a subscriber has replaced their certificate, which happens only after the subscriber was notified.
The subscriber's replacement process can be of an unbounded duration, which makes it impossible for IdenTrust to guarantee they will revoke the certificate within the 5 day period, thus giving me no confidence that IdenTrust will be able to comply with the BR the next time they need to follow their bulk revocation process.
Again, the only information about your bulk revocation process is that which was shared in comment #12, where you share that you wait for your subscribers to replace their certificates before you revoke the problematic certificates.
History shows that if you wait for subscribers to act this is all but guaranteed to exceed the 5-day revocation period when subscribers have not automated their certificates, which you acknowledge is the case for at least some of your subscribers.
Subsequent comment #19 and #21 have not materially updated the shared information of your bulk revocation process, which to this day keeps me concerned about your ability to process issuance or validation issues in large portions of your valid certificates corpus if and when they pop up.
|
|
Assignee | |
Comment 25•6 months ago
|
||
(In reply to Matthias from comment #24
As noted in earlier updates, this issue stands out as an exceptional circumstance to our normal revocation process.
The Mozilla revocation guidelines provide for the ability to assess on a case-by-case basis as was done in this case. We have had other situations including another recently where it was determined to revoke all affected certificates with the 5-day period so we believe we are doing as permitted by the guidelines. As clarified in the last paragraph of comment #23, our commitment for future incidents of a similar nature, is to again following the Mozilla’s revocation guidelines and assess this on a case-by-case basis.
Prompt revocation in accordance with misissuance types is outlined in our policy documents.
|
|
Assignee | |
Comment 26•6 months ago
|
||
As of 11/8/2023, 95% of the affected certificates have either expired or been revoked.
|
|
||
Updated•6 months ago
|
|
|
Assignee | |
Comment 27•5 months ago
|
||
As of 11/29/2023 100% of the affected certificates have been revoked. No further actions are pending regarding this incident.
|
|
||
Comment 29•4 months ago
|
||
Unless there are any objections, I will close this ticket on Wed. 3-Jan-2024.
|
|
||
Updated•4 months ago
|
Description
•