Closed Bug 1872374 Opened 1 year ago Closed 1 year ago

HARICA: subject:organizationIdentifier using VATEL as a prefix for tax identifier

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jimmy, Assigned: jimmy)

Details

(Whiteboard: [ca-compliance] [ev-misissuance])

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

Steps to reproduce:

HARICA has identified a potentially problematic case with some conflicting expectations between European Law (EU Directive), Local Law (via the Greek eIDAS Supervisory Body), the EV Guidelines and the S/MIME Baseline Requirements.

Incident Report

HARICA has identified a potentially problematic case with some conflicting expectations between European Law (EU Directive), Local Law (via the Greek eIDAS Supervisory Body), the EV Guidelines and the S/MIME Baseline Requirements.

Summary

During an internal quality check after enabling a new linter, we discovered that three (3) EV TLS Certificates, that were also Qualified Website Authentication Certificates under eIDAS, were issued with a subject:organizationIdentifier attribute using the "VAT" Registration Scheme, followed by the country identifier "EL" which is not the alpha-2 country code for Greece as stated in ISO 3166-1. Two of those EV TLS Certificates are still valid.

The EV Guidelines in section 9.2.8, state that the organizationIdentifier value must include the 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated. Section 7.1.4.2.2 (d) of the S/MIME Baseline Requirements has similar language.

However, there are extenuating circumstances because according to ETSI EN 319 412-1, the source document used by the CA/B Forum's Server Certificate Working Group when drafting this part of the EV Guidelines, contains an exception for Greece when used in conjunction with the VAT registration scheme. Specifically, the identifier value should comply with Council Directive 2006/112/EC, article 215 that states:

"Each individual VAT identification number shall have a prefix in accordance with ISO code 3166 — alpha 2 — by which the Member State of issue may be identified. Nevertheless, Greece may use the prefix EL."

In addition to that, the Greek eIDAS Supervisory Body has communicated to QTSPs operating in Greece that the use of VATEL (for the subject:organizationIdentifier field) and TINEL (for the subject:serialNumber field) are strongly recommended for Greece.

Impact

HARICA decided to disclose this issue asking for community feedback. The impact is minimal because the two currently valid certificates can easily be replaced/revoked within the 5-days timeline of section 4.9.1.1 of the Baseline Requiremnets. However, HARICA has decided to first wait for community feedback before making a revocation decision. We believe this is a responsible position regardless if it involves one or multiple Subscribers.

Timeline

All times are in UTC.

  • 2019-03-28: CP/CPS version 3.8 is published introducing the organizationIdentifier attribute stating that the semantics identifier for Greece should be "VATGR"
  • 2020-01-23: HARICA receives an official letter by the Greek eIDAS Supervisory Body that explains that for Qualified Certificates, "VATEL" is the preferred prefix for VAT entries of legal entities taxed in Greece and "TINEL" is the preferred prefix for TIN entries for natural persons taxed in Greece.
  • 2022-03-23: CP/CPS version 4.5 is published stating that the organizationIdentifier attribute should use the "VATEL" prefix for Legal Entities and the serialNumber attribute should use the "TINEL" prefix for Natural Persons.
  • 2023-08-31: Pkilint was added as a pre-issuance linter for all Certificate types (including S/MIME and TLS)
  • 2023-09-01 00:00: S/MIME Baseline Requirements become effective and HARICA has implemented pre-issuance linting using pkilint for S/MIME certificates.
  • 2023-09-01 12:20: Using the staging environment, during testing S/MIME certificate issuance, we received an error from pkilint that VATEL was not allowed.
  • 2023-09-01 13:30: The compliance team was notified and responded that the Supervisory Body strongly recommended VATEL. The recommendation was to try to patch the linter to allow VATEL, or remove that check, and invoke section 9.16.3 of the S/MIME BRs.
  • 2023-09-01 15:30: After more internal discussions, HARICA decided to plan for the separation of S/MIME and Qualified eSignature/eSeal Certificates which were combined at the time. This decision would allow the use of "VATEL" for Qualified Certificates for eSignatures/eSeals but not for non-Qualified S/MIME Certificates. Therefore, we switched to "VATGR" for non-Qualified S/MIME Certificates.
  • 2023-12-27 10:47: A QWAC was scheduled to be renewed but failed due the same error for the organizationIdentifier value, warning that the VATEL prefix was not allowed.
  • 2023-12-27 11:30: The compliance team was notified and gave the same response, that the Greek Supervisory Body strongly recommended VATEL and that VATEL is allowed based on ETSI EN 319 412-1. Due to the urgency of the renewal, an emergency procedure kicked in authorizing the bypass of the pkilint linter (other pre-issuance linters remained active)
  • 2023-12-27 16:00: Until the final decision on the organizationIdentifier VAT value prefix, the end-entity profiles were set to use VATGR for tax identifiers of Greek Legal Entities
  • 2023-12-28: A detailed investigation begun to collect information about the various requirements (legal and technical) for the proper value of that attribute.
  • 2023-12-29: After examination of evidence, the result was inconclusive. A decision was made to open a public bug to request community feedback, so that HARICA can get a better understanding of community and Root Store Program expectations before deciding to revoke the affected certificates or not.

Root Cause Analysis

After examining the evidence and history, the results were inconclusive:

  • Based on European Law, Greece may use "EL" when combined with VAT identifiers.
  • Based on Local Law, the Greek eIDAS Supervisory Body that has authority granted by the eIDAS Regulation, QTSPs operating in Greece are strongly recommended to use VATEL and TINEL for Greek tax identifiers.
  • ETSI rules (EN 319 412-1 Section 5.1.4) allows the exception for Greece to use "EL" when combined with VAT.
  • The CA/B Forum EV Guidelines do not include an exception for the use of "EL" for Greece.

Our preliminary analysis indicated that the Law takes precedence of any technical requirements by the CA/B Forum or other SDOs and it appears that this was an oversight by the CA/B Forum when drafting the rules for the organizationIdentifier field. More specifically, the CA/B Forum failed to include the exception stated in ETSI EN 319 412-1 secton 5.1.4 that the VAT identifier value should comply with Council Directive 2006/112/EC, article 215.

The team acknowledges that HARICA should have highlighted this conflicting issue to the CA/B Forum sooner, invoking the procedure described in section 9.16.3 of the BRs.

Lessons Learned

What went well

  • Pre-issuance linting with new linters demonstrated effective preventive controls
  • Separation of non-Qualified S/MIME Certificates from Qualified eSignature/eSeal Certificates that have conflicting policies, avoided a potential risk of revoking a large number of S/MIME Certificates (if they had used "VATEL" in the organizationIdentifier)
  • To prevent any further challenges, HARICA decided to stop using the VATEL prefix in publicly-trusted QWACs

What didn't go well

  • When detected in September 2023 for S/MIME Certificates, HARICA didn't follow up on the VATEL issue for TLS Certificates.
  • HARICA should have warned the CA/B Forum of the VATEL/VATGR conflict when the EV Guidelines and S/MIME BRs were amended to include the normative requirements for the organizationIdentifier value.

Where we got lucky

  • N/A

Action Items

Action Item Kind Due Date
Update the profiles to use VATGR instead of VATEL until the issue is resolved preventive Already completed
Wait for community feedback - 2024-01-07
Decide to revoke the affected certificates or not - 2024-01-08
Update CP/CPS according to section 9.16.3 and notify the CA/B Forum Server Certificate and S/MIME WGs - 2024-01-19

Appendix

Details of affected certificates

Whiteboard: [ca-compliance]
Assignee: nobody → jimmy
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance] → [ca-compliance] [smime-misissuance]
Whiteboard: [ca-compliance] [smime-misissuance] → [ca-compliance] [uncategorized]

Hi Dmitris, thanks for the thorough incident report.

I don't understand the stated conflict between various European laws and the EVGs. I have not read the relevant laws myself, so I am trusting your interpretation and presentation of them here to be correct. The laws say that Greece "may" use country code EL, and that use of the VATEL tax identifier scheme is "strongly recommended". Meanwhile, the EVGs clearly state that the country code MUST match the ISO country code. This is not a conflict -- the laws allow flexibility, and the EVGs do not. In general, the whole point of the BRs and the EVGs is that they impose restrictions and requirements above and beyond the law.

While I understand and agree that the EVGs can be updated to match the local law, they have not been updated yet, and that makes this a clear case of misissuance with required revocation. Why does HARICA believe that a "may" or "strongly recommends" in local law can override a "MUST" in the EVGs? Why does HARICA seem to believe that a change to the EVGs would apply to this certificate retroactively, allowing it to not be revoked? Will HARICA be filing a separate incident for failure to revoke this certificate within 5 days of discovering that it was not issued in compliance with the EVGs?

Hi Aaron,

We had a lot of internal discussions about this "may", that comes from the EU Directive of 2006 (link has been provided in the summary of the incident report). There is a different approach for "may" in legal documents compared to RFC 2119 which is what the technical standards are using for the interpretation of "MAY", "MUST", "SHOULD" and so on. One interpretation was that a "may" in the legal document, provides "the right" to do something. It's like, for Greece, it is the Country's right to use "EL" as a prefix for tax identifiers. Creating obstacles and disallowing this prefix means that Greece is blocked from "exercising their right" to use "EL". I hope the description makes sense.

In general, the whole point of the BRs and the EVGs is that they impose restrictions and requirements above and beyond the law.

I would like to hear some more feedback about this statement because it might be interpreted in various ways. All entities (CAs, Browsers) are obliged to follow the Law in their respective jurisdictions. I agree on the statement for the Standards defining policies/restrictions "above and beyond" the law, as long as there are no conflicting statements with the Law. Nothing can go against the Law. Using VATEL is definitely a provision allowed by Law, so Greece has a right to use that (because this is how all Greek tax identifiers are processed in the EU). The EVGs do not have such an exception so it is not allowed, therefore, the conflict.

I understand that this is a different case than if, for example, the Law says "TLS Certificates must include a subject:OU field identifying that this is a European CA/TSP" and the CA/B Forum says that "the OU field is not allowed for TLS Certificates". This is a more clear-cut case but could still invoke section 9.16.3 of the BRs and allow a CA to add an OU field in a TLS Certificate without it being considered a mis-issuance.

Why does HARICA seem to believe that a change to the EVGs would apply to this certificate retroactively, allowing it to not be revoked?

The change would only clarify what should have been allowed based on local Law, because the Law always takes precedence. It would not change something retroactively, this is clearly not the case. The reason for not revoking (yet) relies on section 9.16.3 of the BRs that allows exceptions based on local Law.

Will HARICA be filing a separate incident for failure to revoke this certificate within 5 days of discovering that it was not issued in compliance with the EVGs?

No, because we still have not determined that these certificates have been issued in violation of the EVGs in combination with section 9.16.3 of the BRs. According to our disclosed plan (7 days ago), we made it clear to the public that we would wait for the community feedback before making our final determination whether this is a violation or not. We have not received any feedback from Root Store Programs yet, but HARICA will make a decision on Monday regardless.

Creating incidents just for the sake of creating incidents doesn't seem like a win for the community. HARICA followed good practice and past suggestions from Root Store Managers, to reach out to the community in case of doubt. I hope this decision is not received in a negative way. We believe that if this was a clear-cut case, this bug would get some feedback sooner.

According to section 4.9.1.1 of the BRs, the revocation clock starts ticking when "the CA is made aware". We are still not 100% convinced, which is why we have not triggered a revocation event.

We kindly ask some more feedback from the community, especially from the Root Store Managers that can help us understand whether our doubts were reasonable or not.

Our focus is on the interpretation of section 9.16.3 of the BRs and whether local Law takes precedence over the CA/B Forum guidelines and ETSI technical standards.

One interpretation was that a "may" in the legal document, provides "the right" to do something. It's like, for Greece, it is the Country's right to use "EL" as a prefix for tax identifiers. Creating obstacles and disallowing this prefix means that Greece is blocked from "exercising their right" to use "EL". I hope the description makes sense.

No, this is not how the law and the EVGs interact with each other. If the law said that a CA must use "VATEL", then that would be in conflict with the EVGs, and it would be appropriate for HARICA to invoke Section 9.16.3 of the BRs, notify the CABForum of the conflict, and update their CPS to include a detailed reference to the relevant laws.

But the law does not say that. The law says that CAs may use "VATEL", and that they also may use "VATGR". Both are perfectly acceptable under the law. The EVGs simply restrict that choice.

The reason for not revoking (yet) relies on section 9.16.3 of the BRs that allows exceptions based on local Law.

Section 9.16.3 requires that HARICA update their CPS before issuing certificates based on modifications due to local law. Such an update has not been made, so HARICA cannot claim such an exception yet.

(In reply to Dimitris Zacharopoulos from comment #3)

There is a different approach for "may" in legal documents compared to RFC 2119 which is what the technical standards are using for the interpretation of "MAY", "MUST", "SHOULD" and so on. One interpretation was that a "may" in the legal document, provides "the right" to do something. It's like, for Greece, it is the Country's right to use "EL" as a prefix for tax identifiers. Creating obstacles and disallowing this prefix means that Greece is blocked from "exercising their right" to use "EL". I hope the description makes sense.

Can you point me to where this interpretation comes from or where this use of "may" is documented in the context of Council Directive 2006/112/EC?
If "EL" was the only option for Greece, this would be more obvious to me as the correct interpretation of the cited Article 215, but given that there is an alternative valid ISO code, it doesn't seem best to assume that the Article's allowance of EL's use creates a conflict as described in Section 9.16.3 of the TLS BRs.

Regardless of whether there is a conflict, however, it seems entirely clear already that the certificates were not issued after such a conflict was documented and communicated with the CA/B Forum, so solely based on the requirements of Section 9.15.3 of the TLS BRs, it seems these certificates were not issued in accordance with the TLS BRs.

Further, to my knowledge the EVGs do not support this same process when addressing a conflict between a law and the EVGs. Instead, they state:

If a court or government body with jurisdiction over the activities covered by these Guidelines determines that the performance of any mandatory requirement is illegal, then such requirement is considered reformed to the minimum extent necessary to make the requirement valid and legal.

My reading of this is that, even with an addition to HARICA's CPS and notification to the CA/B Forum, HARICA would not necessarily be able to issue an EV TLS Certificate until "a court or government body.... determines that [HARICA's rejection of VATEL in an EV TLS Certificate] is illegal".

Dimitris, to echo what others have said, (1) thank you for the detailed report, and (2) based on the current information within, revocation seems appropriate for non-compliance with the EVGs.

Despite the strong recommendation for the use of “EL” by the Greek Supervisory Body, continuing to rely on the ISO 3166-1 country code of “GR” would have allowed HARICA to minimally satisfy the expectations of both the EVGs and Article 215, given the state of HARICA's policy documents.

Additionally, HARICA’s current CPS (in Section 9.16.3) reinforces the stance that requirement modification procedures need to occur prior to issuance, which did not take place in this case.

Incident Report Update

HARICA identified a problematic case with some conflicting expectations between European Law (EU Directive), Local Law (via the Greek eIDAS Supervisory Body), the EV Guidelines and the S/MIME Baseline Requirements.

Summary

During an internal quality check after enabling a new linter, we discovered that three (3) EV TLS Certificates, that were also Qualified Website Authentication Certificates under eIDAS, were issued with a subject:organizationIdentifier attribute using the "VAT" Registration Scheme, followed by the country identifier "EL" which is not the alpha-2 country code for Greece as stated in ISO 3166-1. Two of those EV TLS Certificates are still valid.

The EV Guidelines in section 9.2.8, state that the organizationIdentifier value must include the 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated. Section 7.1.4.2.2 (d) of the S/MIME Baseline Requirements has similar language.

However, there are extenuating circumstances because according to ETSI EN 319 412-1, the source document used by the CA/B Forum's Server Certificate Working Group when drafting this part of the EV Guidelines, contains an exception for Greece when used in conjunction with the VAT registration scheme. Specifically, the identifier value should comply with Council Directive 2006/112/EC, article 215 that states:

Each individual VAT identification number shall have a prefix in accordance with ISO code 3166 — alpha 2 — by which the Member State of issue may be identified. Nevertheless, Greece may use the prefix "EL".

In addition to that, the Greek eIDAS Supervisory Body has communicated to QTSPs operating in Greece that the use of VATEL (for the subject:organizationIdentifier field) and TINEL (for the subject:serialNumber field) are strongly recommended for Greece.

HARICA failed to properly highlight this exception to the CA/Browser Forum per section 9.16.3 of the TLS Baseline Requirements and section 8.1 of the EV Guidelines. The fact that this exception was allowed by rules outside the CA/Browser Forum doesn't grant retroactive permission to use such exception without following the procedures described in section 9.16.3 of the TLS BRs or 8.1 of the EV Guidelines.

After receiving feedback from the community, there is a general agreement that if something is "optionally permissible" by Law, meaning that there are alternatives that are not in conflict with the policy requirements of the CA/B Forum, then the CA should apply only the rules that do not produce an "illegal" result. In this particular incident, the Law allowed Greece to use "EL" as a country identifier for VAT numbers but did not prohibit the use of "GR", therefore a fully compliant solution would be for HARICA to use "VATGR" as a prefix without breaking the Law nor the BRs/EVGs.

The BRs/EVGs focus more on avoiding something "illegal" rather than allowing something that is explicitly permissible by Law. This is possibly an area that is worth more discussion within the CA/Browser Forum and the community in the future.

Impact

HARICA decided to disclose this issue asking for community feedback. The impact is minimal because the two currently valid certificates can easily be replaced/revoked within the 5-days timeline of section 4.9.1.1 of the Baseline Requirements. However, HARICA has decided to first wait for community feedback before making a revocation decision. We believe this is a responsible position regardless if it involves one or multiple Subscribers.

Based on community feedback, HARICA decided that the certificates were mis-issued since the provisions of section 9.16.3 of the BRs and section 8.1 of the EVGs, were not followed as described. The two unexpired/unrevoked certificates will be revoked within 5 days based on section 4.9.1.1 of the BRs.

Timeline

All times are in UTC.

  • 2019-03-28: CP/CPS version 3.8 is published introducing the organizationIdentifier attribute stating that the semantics identifier for Greece should be "VATGR".
  • 2020-01-23: HARICA receives an official letter by the Greek eIDAS Supervisory Body that explains that for Qualified Certificates, "VATEL" is the preferred prefix for VAT entries of legal entities taxed in Greece and "TINEL" is the preferred prefix for TIN entries for natural persons taxed in Greece.
  • 2022-03-23: CP/CPS version 4.5 is published stating that the organizationIdentifier attribute should use the "VATEL" prefix for Legal Entities and the serialNumber attribute should use the "TINEL" prefix for Natural Persons.
  • 2023-08-31: Pkilint was added as a pre-issuance linter for all Certificate types (including S/MIME and TLS).
  • 2023-09-01 00:00: S/MIME Baseline Requirements become effective and HARICA has implemented pre-issuance linting using pkilint for S/MIME certificates.
  • 2023-09-01 12:20: Using the staging environment, during testing S/MIME certificate issuance, we received an error from pkilint that VATEL was not allowed.
  • 2023-09-01 13:30: The compliance team was notified and responded that the Supervisory Body strongly recommended VATEL. The recommendation was to try to patch the linter to allow VATEL, or remove that check, and invoke section 9.16.3 of the S/MIME BRs.
  • 2023-09-01 15:30: After more internal discussions, HARICA decided to plan for the separation of S/MIME and Qualified eSignature/eSeal Certificates which were combined at the time. This decision would allow the use of "VATEL" for Qualified Certificates for eSignatures/eSeals but not for non-Qualified S/MIME Certificates. Therefore, we switched to "VATGR" for non-Qualified S/MIME Certificates.
  • 2023-12-27 10:47: A QWAC was scheduled to be renewed but failed due the same error for the organizationIdentifier value, warning that the VATEL prefix was not allowed.
  • 2023-12-27 11:30: The compliance team was notified and gave the same response, that the Greek Supervisory Body strongly recommended VATEL and that VATEL is allowed based on ETSI EN 319 412-1. Due to the urgency of the renewal, an emergency procedure kicked in authorizing the bypass of the pkilint linter (other pre-issuance linters remained active).
  • 2023-12-27 16:00: Until the final decision on the organizationIdentifier VAT value prefix, the end-entity profiles were set to use VATGR for tax identifiers of Greek Legal Entities.
  • 2023-12-28: A detailed investigation begun to collect information about the various requirements (legal and technical) for the proper value of that attribute.
  • 2023-12-29: After examination of evidence, the result was inconclusive. A decision was made to open a public bug to request community feedback, so that HARICA can get a better understanding of community and Root Store Program expectations before deciding to revoke the affected certificates or not.
  • 2024-01-03: An email was sent to the Subscriber of one potentially mis-issued certificate to warn about the possibility of a revocation event, and verified that the identity validation evidence was still allowed for reuse.
  • 2024-01-04: First feedback received indicating that the Law doesn't seem to prohibit a fully compliant solution that avoids the use of "EL" as a country identifier. The team replied highlighting the fact that "The Law" explicitly allows some provisions, that should be respected. The team also requested more feedback on the provisions of section 9.16.3 of the BRs.
  • 2024-01-06: More feedback received indicating that there seems to be a non-conflicting option that would be allowed by Law and by the EV Guidelines. Also, the feedback highlighted that HARICA did not follow the provisions of section 9.16.3 of the BRs nor section 8.1 of the EV Guidelines.
  • 2024-01-07 09:00: HARICA decided that the certificates were mis-issued and started the revocation process.
  • 2024-01-07 09:13: One certificate (serial: 4D5C32CE03384F8BAFA4542C0871B2F5) was revoked.
  • 2024-01-07 11:08: An updated incident report was submitted.

Root Cause Analysis

After examining the evidence and history, the initial results were inconclusive:

  • Based on European Law, Greece may use "EL" when combined with VAT identifiers.
  • Based on Local Law, the Greek eIDAS Supervisory Body that has authority granted by the eIDAS Regulation, QTSPs operating in Greece are strongly recommended to use VATEL and TINEL for Greek tax identifiers.
  • ETSI rules (EN 319 412-1 Section 5.1.4) allows the exception for Greece to use "EL" when combined with VAT.
  • The CA/B Forum EV Guidelines do not include an exception for the use of "EL" for Greece.

Our preliminary analysis indicated that the Law takes precedence of any technical requirements by the CA/B Forum or other SDOs and it appears that this was an oversight by the CA/B Forum when drafting the rules for the organizationIdentifier field. More specifically, the CA/B Forum failed to include the exception stated in ETSI EN 319 412-1 section 5.1.4 that the VAT identifier value should comply with Council Directive 2006/112/EC, article 215.

From the first post of this incident, HARICA acknowledged that it should have highlighted this conflicting issue to the CA/B Forum sooner, invoking the procedure described in section 9.16.3 of the BRs but wasn't sure if the Law took precedence even in that situation. Based on community feedback, it is now clear that even if the Law allows some provisions that the CA/B Forum documents forbid, a CA must follow the disclosure provisions as described in the CA/B Forum documents before issuing such a certificate.

Also, the provisions of section 8.1 of the EV Guidelines state:

If a court or government body with jurisdiction over the activities covered by these Guidelines determines that the performance of any mandatory requirement is illegal, then such requirement is considered reformed to the minimum extent necessary to make the requirement valid and legal.

Despite having received an official letter from a "government body with jurisdiction over the activities covered by these Guidelines", the letter doesn't consider using "VATGR" an "illegal" activity, therefore the provisions of that section do not fully apply. HARICA will bring this issue to the CA/B Forum and try to merge section 9.16.3 of the TLS BRs and section 8.1 of the EV Guidelines as these sections try to address the same issue but with different language that might cause some confusion (for example, the EV Guidelines do not state that the CA/B Forum must be notified before the CA issues certificates in conflict with the EVGs).

Lessons Learned

Based on the feedback received by the community, CAs should implement options that are explicitly allowed by Law or Government Agencies, only if they do not conflict with mandatory requirements described in the CA/B Forum Guidelines. As long as the resulting policy does not cause the CA to do something "illegal", CAs should apply the more restrictive set of policies.

What went well

  • Pre-issuance linting with new linters demonstrated effective preventive controls
  • Separation of non-Qualified S/MIME Certificates from Qualified eSignature/eSeal Certificates that have conflicting policies, avoided a potential risk of revoking a large number of S/MIME Certificates (if they had used "VATEL" in the organizationIdentifier)
  • To prevent any further challenges, HARICA proactively decided to stop using the VATEL prefix in publicly-trusted QWACs
  • Opening a public incident as soon as a "doubt" on some interpretation of the requirements was discovered, and asking for community feedback, was very productive. It helped get a better understanding of the issue.

What didn't go well

  • When detected in September 2023 for S/MIME Certificates, HARICA didn't follow up on the VATEL issue for TLS Certificates.
  • HARICA should have warned the CA/B Forum of the VATEL/VATGR conflict when the EV Guidelines and S/MIME BRs were amended to include the normative requirements for the organizationIdentifier value.

Where we got lucky

  • N/A

Action Items

Action Item Kind Due Date
Update the profiles to use VATGR instead of VATEL until the issue is resolved preventive Already completed
Wait for community feedback - Completed on 2024-01-07
Decision to revoke the affected certificates - Completed on 2024-01-07
Update CP/CPS according to section 9.16.3 and notify the CA/B Forum Server Certificate and S/MIME WGs - 2024-01-19
Engage with the CA/B Forum WGs to propose an amendment of the Guidelines to allow the country identifier "EL" for Tax-related identifiers of Greece, since all companies/governments within the EU currently use the "EL" prefix to identify tax identifiers from Greece - 2024-02-29
Engage with the CA/B Forum SCWG to merge section 9.16.3 of the TLS BRs and section 8.1 of the EV Guidelines - 2024-02-29

Appendix

Details of affected certificates

Whiteboard: [ca-compliance] [uncategorized] → [ca-compliance] [ev-misissuance]

Updated Action Items

Action Item Kind Due Date
Update the profiles to use VATGR instead of VATEL until the issue is resolved preventive Already completed
Wait for community feedback - Completed on 2024-01-07
Decision to revoke the affected certificates - Completed on 2024-01-07
Update CP/CPS according to section 9.16.3 and notify the CA/B Forum Server Certificate and S/MIME WGs - Cancelled. Will work within the CA/B Forum first
Engage with the CA/B Forum WGs to propose an ammendment of the Guidelines to allow the country identifier "EL" for Tax-related identifiers of Greece, since all companies/governments within the EU currently use the "EL" prefix to identify tax identifiers from Greece - Started 2024-01-08
Revoked the last mis-issued certificate https://crt.sh/?id=9083811677 - Completed on 2024-01-11 19:59:06 UTC

Appendix

Details of affected certificates

We have proposed a new CA/B Forum ballot to amend the EV Guidelines accordingly. So far we have achieved the necessary consensus to put the ballot to a vote. No objections have been raised.

We believe that this completes our remediation actions for this bug.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.