1897538 - Sectigo: Incorrectly included registrationStateOrProvince in PSD-based cabfOrganizationIdentifier extension

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Martijn Katerbarg]

Preliminary Incident Report

Summary

On May 15th, 2024 we received a personal call from an employee from another CA. During the call we were informed about two potentially misissued QWAC PSD2 TLS certificates.

Upon reviewing the certificates, we deemed one of the certificates to be misissued. The ASN.1 encoding of the cabfOrganizationIdentifier extension in this certificate is as follows:

SEQUENCE (2 elem)
OBJECT IDENTIFIER 2.23.140.3.1
OCTET STRING (1 elem)
SEQUENCE (4 elem)
PrintableString PSD
PrintableString IT
[0] BI
UTF8String 3075

The Extended Validation Guidelines (EVGs), show the following requirement:

CABFOrganizationIdentifier ::= SEQUENCE {
registrationSchemeIdentifier PrintableString (SIZE(3)),
registrationCountry PrintableString (SIZE(2)),
registrationStateOrProvince [0] IMPLICIT PrintableString
(SIZE(0..128)) OPTIONAL,
registrationReference UTF8String
}

In the case of a PSD2 organizationIdentifier, the registration always is done at the country level. As such, the registrationStateOrProvince, should not be part of the extension. In our case, we have included “BI” as the registrationStateOrProvince. While “BI” is a valid State value for Italy itself (Biella), in this case “BI” refers to “Bank of Italy”, the National Competent Authority (NCA) that assigned the unique identifier. As such, it should not be within the registrationStateOrProvince field.

We are currently investigating the cause of the misissuance, and are also investigating if any other certificates are affected by this issue. A complete incident report will be made available no later than May 29th, 2024.

For full transparency, we also want to give our insights and reasons for deeming the second reported certificate as not having been misissued. As the original claim referenced a potential misissuance within the same extension, we believe covering this within this preliminary report is warranted. The remainder of this comment will therefore address this.

The second certificate has the cabfOrganizationIdentifier extension encoded as follows:

SEQUENCE (2 elem)
OBJECT IDENTIFIER 2.23.140.3.1
OCTET STRING (1 elem)
SEQUENCE (3 elem)
PrintableString PSD
PrintableString GE
UTF8String MIBGGE22

The subject:organizationIdentifier attribute value reads as: PSDGE-NBG-MIBGGE22

The report claimed that the “NBG“ string, aka the NCA indicator, should be a part of the UTF8String, also known as the registrationReference.

After having reviewed and carefully considered the wording in Section 7.1.4.2.8 of the EVGs, we are of the belief that this is not the case.

Specifically, the examples listed within the requirement (and by that, part of the requirement), show this breakdown for a PSD-based value:

“PSDBE-NBB-1234.567.890 (PSD Scheme, Belgium, NCA's identifier is NBB, Subject Unique Identifier assigned by the NCA is 1234.567.890)”

In the example, “NBB” (which in our case would be “NBG”), is marked as the NCA identifier, where 1234.567.890 is marked as the Subject Unique Identifier.
Since the requirement calls for the Registration Reference to be included in the registrationReference UTF8String, we took a close look as the definition of “Registration Reference”, which reads:

“A unique identifier assigned to a Legal Entity.”

It is the NCA that assigns the Unique Identifier of (in the case of the example) “1234.567.890” to the Legal Entity. As such, we conclude that the NCA code itself is not to be a part of the registrationReference.

Comment 1

[Ryan Dickson]

Hi Martijn,

It does not appear as if the subject:organizationIdentifier and CA/Browser Forum Organization Identifier Extension values included in the second certificate match. Notably, the NCA indicator (i.e., “NBG") is missing from the CA/Browser Forum Organization Identifier Extension value.

This does not appear to be the case in the first certificate.

It would seem to me that the expectation is that the subject:organizationIdentifier and CA/Browser Forum Organization Identifier Extension values match exactly. Similar discussion took place in 1626078, and it’s not clear to me there have been circumstances that would have caused this interpretation to change.

Can you help me understand:

• What has caused the inconsistency observed between the first and second certificates in terms of NCA use?
• Whether Sectigo also considers the subject:organizationIdentifier and CA/Browser Forum Organization Identifier Extension values should match exactly? If not, why?

-Ryan

Comment 2

[Martijn Katerbarg]

Incident Report

Summary

On May 15th, 2024 we received a personal call from an employee from another CA. During the call we were informed about two potentially misissued QWAC PSD2 TLS certificates.

Upon reviewing the certificates, we deemed one of the certificates to be misissued. The ASN.1 encoding of the cabfOrganizationIdentifier extension in this certificate is as follows:

SEQUENCE (2 elem)
OBJECT IDENTIFIER 2.23.140.3.1
OCTET STRING (1 elem)
SEQUENCE (4 elem)
PrintableString PSD
PrintableString IT
[0] BI
UTF8String 3075

The Extended Validation Guidelines (EVGs) show the following requirement:

CABFOrganizationIdentifier ::= SEQUENCE {
registrationSchemeIdentifier PrintableString (SIZE(3)),
registrationCountry PrintableString (SIZE(2)),
registrationStateOrProvince [0] IMPLICIT PrintableString
(SIZE(0..128)) OPTIONAL,
registrationReference UTF8String
}

In the case of a PSD2 organizationIdentifier, the registration always is done at the country level. As such, the registrationStateOrProvince should not be part of the extension. In our case, we have included “BI” as the registrationStateOrProvince. While “BI” is a valid State value for Italy itself (Biella), in this case “BI” refers to “Bank of Italy”, the National Competent Authority (NCA) that assigned the unique identifier. As such, it should not be within the registrationStateOrProvince field.

Impact

2 Certificates, both issued on July 21st, 2023.

Timeline

All times are UTC.

2024-05-15:

• 12:00 I receive a private message requesting a call from another CA.
• 12:00 The message is acknowledged, and we start a private call. During this call we receive information about a misissued certificate.
• 12:24 The finding is shared internally for peer-review.
• 13:06 We agree the certificate is misissued. An internal communications channel is opened with members from several areas of the organization, including compliance, development and customer service.
• 13:09 We present our findings and request development resources to be allocated to resolve the matter.
• 13:27 We decide to halt QWAC PSD certificate issuance until the patch is released.
• 13:28 Based on our findings, we request a database report of all issued certificates with a PSD-based subject:organizationIdentifier attribute value.
• 13:47 Our development team starts investigating the issue.
• 15:23 Our development team finishes writing the database query to retrieve the report data.
• 19:28 Based on QA testing and code review, the suspicion is raised that there is a bug in our code, which incorporates the NCA value found in the subject:organizationIdentifier attribute field into the cabfOrganizationIdentifier extension’s referenceStateOrProvince field, if the value matches with a valid stateOrProvince value as they are known within our system. Code review continues.
• 20:19 A development ticket is created specifying the requirements of the cabfOrganizationIdentifier extension to track patching efforts.

2024-05-16:

• 01:27 The database query is executed, and the results are sent to the compliance team.
• 09:22 Compliance confirms one additional misissued certificate after investigating all certificates in database report.
• 10:04 The development team provides an update. Our suspicions are confirmed that the presence of a valid stateOrProvince value (BI – Biella) within the subject:organizationIdentifier attribute field value caused the incorrect inclusion of the referenceStateOrProvince field within the cabfOrganizationIdentifier extension.
• 10:05 The development team confirms a patch is being created to resolve this bug. QA is notified of an upcoming need for resources.
• 10:05 The decision is made to include the patch in the upcoming weekend’s release, scheduled for May 18th at 23:00 UTC, pending QA signoff.
• 14:38 We deploy the patch to our QA system.
• 15:00 We discuss how to offer a timely replacement of the affected certificates to this customer, as our patch will be deployed during the weekend and we cannot issue a correct replacement prior to the deployment of our patch.
• 18:35 We schedule a revocation event for both certificates for May 20th, 2024 at 11:20 UTC.
• 20:46 QA completes testing and approves the change for deployment.

2024-05-17:

• 08:25 We initiate customer contact informing them of the situation. A call is set up with their engineers, which lasts several hours. A plan is formulated to issue replacement certificates on Sunday, May 19th, 2024, and schedule a follow-up call with the customer that same Sunday.
• 14:43 The Subscriber orders their replacement certificate.

2024-05-18:

• 23:00 We start our scheduled maintenance window to deploy our patch.

2024-05-19:

• 00:59 Deployment and post-deployment checks are completed. We end our scheduled maintenance window.
• 12:41 We issue the replacement certificate for the Subscriber’s production environment. The subscriber has indicated they will replace the second affected certificate at a later time.

2024-05-20:

• 07:43 We receive confirmation that the certificate for the Subscriber’s production environment has been installed.
• 08:00 We revoke the affected certificates.

Root Cause Analysis

Back in 2020, we first implemented support for QWAC certificates within our issuance system. As was now revealed, an error was introduced in the way the cabfOrganizationIdentifier extension for PSD2-based QWAC certificates is created.

The original request for implementation did not define clearly enough when the referenceStateOrProvince field must and must not be included. Due to that, the eventual implementation allowed for the inclusion of the field if a valid referenceStateOrProvince value was detected within the subject:organizationIdentifier attribute value’s 7th and 8th position. In this case, that is what occurred, leading to the mis-issuance.

The fix deployed on May 18th, 2024, blocks the inclusion of the referenceStateOrProvince field in the extension for PSD-based organizationIdentifiers.

Lessons Learned

What went well

• We were able to halt issuance during our investigation and until our patch was released.

What didn't go well

• We did not have any proprietary lint or guard rail against this specific issue implemented.

Where we got lucky

• The issue was due to the edge case of an NCA code being the same as a value stateOrProvince value within the same country, which led to only 2 certificates having been affected.

Action Items

Action Item	Kind	Due Date
Patch our systems to no longer incorporate the referenceStateOrProvince for PSD-based QWAC certificates	Prevent	Completed
Write a lint for zlint to provide an error in the case of a PSD-based QWAC certificate containing the referenceStateOrProvince within a (TBS)certificate.	Detect	2024-05-31

Appendix

Details of affected certificates

Serial Number	Certificate	Precertificate
0083A7CE462C65DD31C3D385C97CB72ED7	Certificate	Precertificate
2CA21D324A18BB76FD77E3E49D0C0197	Certificate	Precertificate

Comment 3

[Martijn Katerbarg]

(In reply to Ryan Dickson from comment #1)

Ryan, please see this comment as an acknowledgement that we have seen your questions.

We decided to post our full incident report before responding to your questions, as peer review for our incident report was already nearing completion when we saw your comment.

We will respond in detail to the questions asked in the next few days.

Comment 4

[Martijn Katerbarg]

Correction: Upon an additional review, we spotted the term "referenceStateOrProvince" was used in comment 2. This should in all cases be "registrationStateOrProvince"

Additionally, we have updated the title of this bug to more clearly reflect the nature of the incident.

Comment 5

[Martijn Katerbarg]

(In reply to Ryan Dickson from comment #1)

Hi Martijn,

Hi Ryan,

It does not appear as if the subject:organizationIdentifier and CA/Browser Forum Organization Identifier Extension values included in the second certificate match. Notably, the NCA indicator (i.e., “NBG") is missing from the CA/Browser Forum Organization Identifier Extension value.
This does not appear to be the case in the first certificate.

Actually, that is somewhat incorrect. Let me show a side-by-side comparison of the ASN.1 structure of both certificates.
Please note that if a value is empty in this table, the field is not included in the ASN.1 structure:

Field	First Certificate Value	Second Certificate Value
registrationSchemeIdentifier	PSD	PSD
registrationCountry	IT	IT
registrationStateOrProvince	BI
registrationReference	3075	MIBGGE22

As we can see, “BI” was incorrectly added into the registrationStateOrProvince field (that being the bug as outlined in our incident report).

Neither of the certificates have the NCA included in the registrationReference field. It is our stance (see comment 0 and the further explanation below) that it should not be.

It would seem to me that the expectation is that the subject:organizationIdentifier and CA/Browser Forum Organization Identifier Extension values match exactly. Similar discussion took place in 1626078, and it’s not clear to me there have been circumstances that would have caused this interpretation to change.

While acknowledging bug 1626078, neither the original report nor the discussion that followed showed exactly which requirement was violated.

More to the point, it does not show how the CA in question came to the initial conclusion that the NCA should not be included, only that they received a recommendation to start including it, nor how they concluded that it should be included. As such, it’s hard to draw any conclusions on the reasoning.

We believe our outline in comment 0 does go into detail on why we read the requirement as that it should not be included.

Can you help me understand:

• What has caused the inconsistency observed between the first and second certificates in terms of NCA use?

We hope our earlier paragraph within this comment, as well as the full incident report makes this clear. In short, neither has the NCA included within the registrationReference field. The first certificate has it incorrectly included in the registrationStateOrProvince field, however.

• Whether Sectigo also considers the subject:organizationIdentifier and CA/Browser Forum Organization Identifier Extension values should match exactly? If not, why?

If by exactly you mean that every character within the subject:organizationIdentifer attribute value must be placed within the cabOrganizationIdentifier, then no. There simply is no such requirement.

The requirements for the subject:organizationIdentifier attribute value are shown here. This section does not make any reference to the cabfOrganizationIdentifier extension.

The requirements for the cabfOrganizationIdentifier extension are shown here. This calls out a few requirements:

• If the subject:organizationIdentifier is present, this field MUST be present.

  • We have included the extension.

• If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance with the identified Registration Scheme.

  • Looking at the definition of “Registration Reference”, we find:
    “A unique identifier assigned to a Legal Entity.”
    If we then look back at how the PSD scheme is explained in Section 7.1.4.2.8, specifically the example for PSD, which clearly shows which string is used for what:
    “PSDBE-NBB-1234.567.890 (PSD Scheme, Belgium, NCA's identifier is NBB, Subject Unique Identifier assigned by the NCA is 1234.567.890).”
    This clarifies for us that the Unique Identifier (1234.567.890) is assigned by the NCA to the Legal Entity. Combining that with the Registration Scheme definition of “A unique identifier assigned to a Legal Entity“, we follow the logic that:

    1. The NCA assigned the unique identifier to the Legal Entity (1234.567.890).
    2. The Registration Reference is defined as the unique identifier assigned to the Legal Entity (still 1234.567.890).
    3. The Registration Reference needs to be included in the “registationReference” UTF8String of the cabfOrganizationIdentifier extension (still 1234.567.890).

• The Registration Scheme MUST be encoded as described by the following ASN.1 grammar

  • The correct fields and ASN.1 encoding have been included: registrationSchemeIdentifier, registrationCountry and registrationReference.

• where the subfields have the same values, meanings, and restrictions described in Section 7.1.4.2.8.

  • That too, is the case. The NCA identifier itself is not part of the Registration Reference as explained in the bullet points above.

    Rather, if the intent is to have all sections of the subject:organizationIdentifier attribute value included within the cabfOrganizationIdentifier extension, we would suggest the definition of the extension should be updated, by adding an additional (Optional) PrintableString called “registrationNca”, for the purpose of specifying the NCA identifier.

Additionally Section 7.1.4.2.8 has a Note, stating:

“Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference.”

We read this as “if the unique identifier contains a hyphen, it is still part of the unique identifier”. We see the examples that follow below the note as additional clarification on top of the Note, carving out an exception for the PSD-based organizationIdentifiers. We do not see why else the NCA is called out specifically as not part of the Unique Identifier (a.k.a., the Registration Reference).

Based on all the above, we conclude the mentioned second certificate is indeed issued in accordance with the EVGs.

Comment 6

[Clint Wilson]

(In reply to Martijn Katerbarg from comment #5)

Thank you for the thorough explanation of the thought process behind Sectigo's conclusion and interpretation of this certificate extension. For context, I agree with Ryan's position here that the cabfOrganizationIdentifier, as described in the EVGs, does expect the NCA to be included for the PSD registration scheme.
This also appears to be the general consensus among CAs issuing similar certificates, though the overall population is very small in comparison to the overall TLS certificate population so I acknowledge there's a disparity in the breadth of CAs having implemented any particular interpretation of this requirement.

Certificates containing the PSD Registration Scheme, but no NCA
Certificates containing the PSD Registration Scheme, with an NCA

The requirements for the subject:organizationIdentifier attribute value are shown here. This section does not make any reference to the cabfOrganizationIdentifier extension.

It does, however, make reference to Appendix H, which I think ends up being relevant.

The requirements for the cabfOrganizationIdentifier extension are shown here. This calls out a few requirements:

• If the subject:organizationIdentifier is present, this field MUST be present.
  • We have included the extension.
• If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance with the identified Registration Scheme.

  • Looking at the definition of “Registration Reference”, we find:
    “A unique identifier assigned to a Legal Entity.”
    If we then look back at how the PSD scheme is explained in Section 7.1.4.2.8, specifically the example for PSD, which clearly shows which string is used for what:
    “PSDBE-NBB-1234.567.890 (PSD Scheme, Belgium, NCA's identifier is NBB, Subject Unique Identifier assigned by the NCA is 1234.567.890).”
    This clarifies for us that the Unique Identifier (1234.567.890) is assigned by the NCA to the Legal Entity. Combining that with the Registration Scheme definition of “A unique identifier assigned to a Legal Entity“, we follow the logic that:

    1. The NCA assigned the unique identifier to the Legal Entity (1234.567.890).
    2. The Registration Reference is defined as the unique identifier assigned to the Legal Entity (still 1234.567.890).
    3. The Registration Reference needs to be included in the “registationReference” UTF8String of the cabfOrganizationIdentifier extension (still 1234.567.890).

This perhaps misses some components of what a Registration Reference must include. Section 7.1.4.2.8 requires the CA to "Apply the validation rules relevant to the Registration Scheme as specified in Appendix H".

Appendix H stipulates, for the PSD Registration Scheme: "Authorization number as specified in ETSI TS 119 495 clause 4.4 allocated to a payment service provider and containing the information as specified in ETSI TS 119 495 clause 5.2.1"

The EVG's don't specify a version for "ETSI TS 119 495", but I don't think this wording has changed so I'm using the Version 1.6.1, which I believe is the most recent. Clause 5.2.1 seems to clearly connect the inclusion of the "Competent Authority identifier" alongside the "identifier (authorization number as specified by the Competent Authority." and, perhaps more notably, require that the Competent Authority identifier be included in the certificate. This TS even goes so far, in Section 5.3, as to emphasize that the ETSI requirements for this information (i.e. Clause 5.2.1) take precedence over the EVGs (though it also currently references a non-existent section of the EVGs).

I would posit that the PSD Registration Scheme, as documented by ETSI, requires inclusion of the Competent Authority identifier or NCA and thus the cabfOrganizationIdentifier also requires its inclusion. While the format for its inclusion is arguably underspecified, I think the note in Section 7.1.4.2.8 does provide sufficient information to determine, at minimum, a compliant method of meeting this intersection of requirements.
"Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference."

That is, in both the examples of the EVGs and ETSI TS 119 495, the second (and third) hyphen is part of the Registration Reference (and therefore part of "the unique identifier assigned to a legal entity"), meaning the entirety of the Registration Reference is NBB-1234.567.890 in the EVG example of PSDBE-NBB-1234.567.890 or FINFSA-1234567-8 in the ETSI example of PSDFI-FINFSA-1234567-8.
Based on your description/interpretation of this (and the wording of the "Note" above), the second hyphen would itself be part of the Registration Reference, but the NCA would not. This results in the Registration Reference being -1234.567.890 in the EVG example of PSDBE-NBB-1234.567.890 or -1234567-8 in the ETSI example of PSDFI-FINFSA-1234567-8. I think even if that were correct, the referenced certificate still doesn't contain that hyphen... but also it seems odd to me to leave some characters as fully separate from any of the otherwise defined portions of the organizationIdentifier.
Either way, when mapping these to the (imo) more discrete and much more easily discernible-as-separated values of the cabfOrganizationIdentifier, the entire Registration Reference string should be placed into the CABFOrganizationIdentifier:registrationReference field.

• The Registration Scheme MUST be encoded as described by the following ASN.1 grammar

  • The correct fields and ASN.1 encoding have been included: registrationSchemeIdentifier, registrationCountry and registrationReference.

• where the subfields have the same values, meanings, and restrictions described in Section 7.1.4.2.8.

  • That too, is the case. The NCA identifier itself is not part of the Registration Reference as explained in the bullet points above.

As described above, I don't believe the registrationReference contains the information it should... the correct field is included, but not the correct content of that field.

I believe there is broad agreement that the "Registration Reference" of the subject:organizationIdentifier must be the same as the CABFOrganizationIdentifier:registrationReference, and the only item around which different conclusions have been reached is whether the NCA is part of the "Registration Reference" in the subject:organizationIdentifier. Is that fair to say?

If so, does my thought process above, alter the conclusions you've drawn here?

Rather, if the intent is to have all sections of the subject:organizationIdentifier attribute value included within the cabfOrganizationIdentifier extension, we would suggest the definition of the extension should be updated, by adding an additional (Optional) PrintableString called “registrationNca”, for the purpose of specifying the NCA identifier.

While I don't think it necessary to update the EVGs here, I'm not opposed to it either, however I think this approach would also require updating the subject:organizationIdentifier to better define the NCA as a separate component of the resultant string and ensuring the second+ hyphen delimiter is clarified to not be part of the Registration Reference itself.

Alternatively, if updates were to be made, I would personally prefer the core definition be placed in Section 7.1.2.2 with Section 7.1.2.4.8 only defining how the components of the cabfOrganizationIdentifier extension should be combined into a string; I suspect the result would be overall clearer.

Additionally Section 7.1.4.2.8 has a Note, stating:

“Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference.”

We read this as “if the unique identifier contains a hyphen, it is still part of the unique identifier”. We see the examples that follow below the note as additional clarification on top of the Note, carving out an exception for the PSD-based organizationIdentifiers. We do not see why else the NCA is called out specifically as not part of the Unique Identifier (a.k.a., the Registration Reference).

I read this differently, as "if the subject:organizationIdentifier contains more than one hyphen, then all values after the first hyphen are part of the Registration Reference". The first hyphen separates the Registration Scheme+ISO 3166 identifiers from the Registration Reference, so it seems that it must follow that everything after the first hyphen is, by definition, the Registration Reference -- hence also why the NTR Registration Scheme uses a + character as its delimiter between the Registration Scheme+ISO 3166 identifier and the ISO 3166-2 identifier, which ensures consistency in this logic. Put another way, the Unique Identifier is only equivalent to the Registration Reference for certain Registration Schemes (NTR and VAT), while for PSD the Registration Reference is a concatenation of the NCA and the Unique Identifier.

Comment 7

[Martijn Katerbarg]

(In reply to Clint Wilson from comment #6)

Hi Clint,

Thank you for your explanation. You make a few good points on reasons to include the NCA within the extension. However, it leaves a few questions open.

I would posit that the PSD Registration Scheme, as documented by ETSI, requires inclusion of the Competent Authority identifier or NCA and thus the cabfOrganizationIdentifier also requires its inclusion.

Note we are not debating if it should or should not be included in the subject:organizationIdentifier attribute value. We very much believe that yes, it has to be within the attribute value, as is our policy. This issue comes specifically down to the extension.

and thus the cabfOrganizationIdentifier also requires its inclusion.

This is where we don’t agree. We have found no requirement that these values be an exact match. For the Registration Scheme and the Registration Reference, yes, that is clear, and those do need to be included. But as far as we’re aware, the cabfOrganizationIdentifier extension is not mentioned at all within the ETSI documents.

I believe there is broad agreement that the "Registration Reference" of the subject:organizationIdentifier must be the same as the CABFOrganizationIdentifier:registrationReference, and the only item around which different conclusions have been reached is whether the NCA is part of the "Registration Reference" in the subject:organizationIdentifier. Is that fair to say?

That is exactly our point, and the thing that remains troubling to us. We are not opposed to changing our behavior and can do so on short notice. Yet we still believe that including the NCA within the registrationReference field isn’t allowed. The Registration Reference is defined as: "Registration Reference: A unique identifier assigned to a Legal Entity." But the NCA is not part of the unique identifier assigned to the Legal Entity. In fact, it is the NCA who assigns the unique identifier to the Legal Entity.

It appears to us that this language actually prevents the inclusion of the NCA. We agree the reading you give appears to require its inclusion. That puts the requirements directly in conflict with each other. In such a case, we wonder:

• Are both options currently allowable?
• Is neither currently allowable, meaning PSD-based QWACs correctly cannot be issued by a publicly trusted CA?

It would put European banking in a bit of a pickle were we to conclude that no public CA can issue a compliant PSD QWAC, that all existing certificates must go onto a five-day revocation schedule, and that no CA can issue replacements for these certificates until CABF passes a ballot amending the EVGs.

We'd greatly appreciate your thoughts, as well as those from the Chrome and Mozilla root stores.

Comment 8

[Clint Wilson]

(In reply to Martijn Katerbarg from comment #7)

I believe there is broad agreement that the "Registration Reference" of the subject:organizationIdentifier must be the same as the CABFOrganizationIdentifier:registrationReference, and the only item around which different conclusions have been reached is whether the NCA is part of the "Registration Reference" in the subject:organizationIdentifier. Is that fair to say?

That is exactly our point, and the thing that remains troubling to us. We are not opposed to changing our behavior and can do so on short notice. Yet we still believe that including the NCA within the registrationReference field isn’t allowed. The Registration Reference is defined as: "Registration Reference: A unique identifier assigned to a Legal Entity." But the NCA is not part of the unique identifier assigned to the Legal Entity. In fact, it is the NCA who assigns the unique identifier to the Legal Entity.

I think this is why the NCA is part of the unique identifier in the context of how the EVGs (and ETSI) utilize the Registration Reference. If it is possible for the 1234.567.890 identifier to be assigned to 2 different organizations within the scope of a Registration Scheme+Country Code of PSDBE, then the 1234.567.890 value is no longer a unique identifier without the additional context of NBB.

It appears to us that this language actually prevents the inclusion of the NCA. We agree the reading you give appears to require its inclusion. That puts the requirements directly in conflict with each other.

FWIW, I don't perceive a conflict here. A unique identifier is only ever unique within some particular scope. This bug's ID (1897538) is only useful within the context of bugzilla.mozilla.org (unless you're looking for automotive terminals of some sort, I suppose). Similarly, for the PSD Registration Scheme, the Competent Authority identifier is a component of the Registration Reference necessary for the Registration Reference to be a unique identifier.

In such a case, we wonder:

• Are both options currently allowable?

I don't believe so, personally.

• Is neither currently allowable, meaning PSD-based QWACs correctly cannot be issued by a publicly trusted CA?

I also don't believe this to be the case.

I believe the only allowable format for PSD-based QWACs is for the Registration Reference to include the Competent Authority identifier (aka NCA).

Section 7.1.2.2 establishes that the cabfOrganizationIdentifier's subfields "have the same values, meanings, and restrictions described in Section 7.1.4.2.8"

Section 7.1.4.2.8 establishes that "if more than one hyphen appears in the [subject:organizationIdentifier] structure.... the remaining hyphens are part of the Registration Reference."

The example given for a PSD-based subject:organizationIdentifier is the only one containing more than one hyphen (PSDBE-NBB-1234.567.890), which maps to the requirements listed in Section 7.1.4.2.8 without conflict:

• 3 character Registration Scheme identifier => PSD
• 2 character ISO 3166 country code => BE
• a hyphen-minus => -
• Registration Reference => NBB-1234.567.890

This is also in-line with the description of the ballot which introduced this language in SC-017 which described the changes since version 5 of that ballot in part as addressing this topic (emphasis mine): "Note that Registration References MAY contain hyphens, and clarify that the first hyphen is the separator." Previously the ballot had proposed simply disallowing Registration References from including hyphen-minus characters, but that was changed due to the incompatibility with PSD2 requirements.

I do want to note that my focus here has been solely on interpreting what the current EVGs state and what was added with SC17; this interpretation doesn't mean I agree with the way subject:organizationIdentifier and cabfOrganizationIdentifier are currently implemented in the EVGs. As the discussion at the time thoroughly documents, a better technical representation of these data is possible in the cabfOrganizationIdentifier extension (as you've proposed above) which would remove opportunity for such discrepancies to occur.

Comment 9

[Martijn Katerbarg]

(In reply to Clint Wilson from comment 8)

If it is possible for the 1234.567.890 identifier to be assigned to 2 different organizations within the scope of a Registration Scheme+Country Code of PSDBE, then the 1234.567.890 value is no longer a unique identifier without the additional context of NBB.

As each country only has one NCA for the purpose of the PSD directive, the combination of PSD + country + 1234.567.890 is no less unique than PSD + country + NCA + 1234.567.890.

Moreover, ETSI in defining the structure of its subject organizationIdentifier explicitly references the NCA as a separate component of the structure and not part of the authorization number assigned to the Subject. One might even argue the NCA should be part of the Registration Scheme, but current requirements clearly do not allow for that.

The above is why we still see our current practice to be in line with the requirements.

Plus, this approach is more functionally useful. When searching within the NCA registry, one can find the Legal Entity by searching for the Unique Identifier, but a search using NCA + Unique Identifier would actually fail. It’s hard to see how appending unnecessary content to this field and in the process rendering it search-unfriendly is an improvement over our interpretation. In the example case above, PSDBE is all that is required to provide the necessary context. This indicates that the entity issuing the Registration Reference is the Belgian NCA for payment service providers, of which only one exists.

We would further argue that the Registration Reference should not contain information other than the identifier assigned by the registrar identified in the Registration Scheme as doing so means that the Registration Reference will not match the information published by the registrar.

This is also in-line with the description of the ballot which introduced this language in SC-017, which described the changes since version 5 of that ballot in part as addressing this topic (emphasis mine): "Note that Registration References MAY contain hyphens, and clarify that the first hyphen is the separator."

We think that this is also part of the problem. Under the ETSI PSD format, the first hyphen is a connector and not a separator. The unique NCAId takes the following format:

• 2 character ISO 3166-1 [8] country code representing the Competent Authority country;
• hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); and
• 2-8 character Competent Authority identifier without country code (A-Z uppercase only, no separator).

[ETSI TS 119 495 v1.6.1. GEN-5.2.3-2]

In Section GEN-5.2.1-3 where the structure of the ETSI subject:organizationIdentifier is laid out, Note 2 states that the “hyphen-minus is required when linking country code with a Competent Authority identifier” (my emphasis). By turning this connector into a separator, the EVG allows for an interpretation that forces information other than that assigned to a subject by a registrar to be included as part of the Registration Reference. As discussed above, this is problematic because it creates a mismatch between the Registration Reference and the information published by the registrars, but it is also inconsistent with VAT and NTR schemes which only contain the information assigned to the Subject by the registrars.

In short wording: The Registration Scheme shows where one would look up the Legal Entity, and the Registration Reference shows which Legal Entity one would look up.

Please note that we continue to be open minded on this matter and greatly appreciate the insights you have provided. The points we make above leave us believing today that the current practice is within the requirements. We will point out that this shows certain conflicts between ETSI and the EVGs, and internally within the EVGs, which we will aim to resolve in a future ballot.

We are not opposed to changing our issuance practice if that is the final decision. We look forward to not only your reaction but also those of the other trusted root stores for which a needinfo is pending so we can take this matter to a conclusion.

Comment 10

[Clint Wilson]

(In reply to Martijn Katerbarg from comment #9)

Please note that we continue to be open minded on this matter and greatly appreciate the insights you have provided. The points we make above leave us believing today that the current practice is within the requirements. We will point out that this shows certain conflicts between ETSI and the EVGs, and internally within the EVGs, which we will aim to resolve in a future ballot.

This possibility, in particular, I find of interest given what the ETSI requirements state about ETSI TS 119 495 taking precedence over the EVGs in conjunction with the explicit requirements of Root Programs to comply with the EVGs, but the lack of such requirements related to compliance with ETSI TS 119 495.
And then, of course, the recursion that kind of/sort of seems to exist because of the EVGs pointing to ETSI TS 119 495 in Appendix H... it's certainly further highlighted an additional area of interest for me, regardless of the other outcomes which may occur from this Bug.

We are not opposed to changing our issuance practice if that is the final decision. We look forward to not only your reaction but also those of the other trusted root stores for which a needinfo is pending so we can take this matter to a conclusion.

Thank you Martijn. From what I can tell, all other CAs/TSPs issuing PSD-based EV TLS Certificates currently include the NCA within the Registration Reference, so in addition to the other Root Programs, I'm also interested in understanding the perspective of those CAs/TSPs on this topic.

Comment 11

[Ben Wilson]

Is there still an ambiguity or question that needs to be resolved here with my input? Or can my "need-info" be cancelled? Otherwise, can the question(s) I need to look at be narrowed, so I can focus on them? Thanks.

Comment 12

[Martijn Katerbarg]

The Incident Report posted in comment 2 had one action item remaining to complete. As we did not want to disrupt the lively discussion, we did not yet provide an update for that.

However, on May 28, 2024 we opened a PR for the zlint project. This completed the action items as listed in the incident report and closes our handling of the incident.

We request that this bug remains open for at least an additional week, in order to allow other parties to comment regarding the discussed case of the second reported certificate. Meanwhile, we will start working on addressing the cabfOrganizationIdentifier extension language over in the Server Certificate WG.

Comment 13

[Martijn Katerbarg]

(In reply to Ben Wilson from comment #11)

Is there still an ambiguity or question that needs to be resolved here with my input? Or can my "need-info" be cancelled? Otherwise, can the question(s) I need to look at be narrowed, so I can focus on them? Thanks.

Ben, it’s a very hard question to narrow down, given the lengthy and detailed report.

The short gist (which doesn’t do justice to the discussion above) is that we do not deem the certificate listed here as having been misissued.

It seems most, if not all, other CAs are including the NCA within the registrationReference field of the cabfOrganizationIdentifier. We don’t agree with this approach.

For the non-PSD schemes (VAT & NTR), the registrationReference contains only the unique identifier assigned to the Subject by the registration authority identified by the registrationScheme. Including the NCA code as part of the registrationReference under the PSD scheme introduces information into that variable that is (1) is inconsistent with the other schemes and (2) at odds with the definition of Registration Reference set out in the EVGs.

Differently stated: The NCA is not assigned to a Legal Entity but rather it assigns the Registration Reference to the Legal Entity. Additionally, there is no language stating they must match exactly.

Our contention is that if the NCA code is to be included as part of the cabfOrganizationIdentifier, it belongs in the registrationScheme, which is used to identify the organization assigning the unique identifier to the Subject. A problem arises because this is not permitted by 7.1.4.2.8 as currently written. Omitting the NCA code, on the other hand, still allows the source of the unique identifier to be determined without polluting the registrationReference by including characters that are not a part of that unique identifier.

At the moment, we believe our current practice to be in line with the TBR requirements. However, we do recognize that the language in the TBRs needs updating as it does not properly clarify PSD-based Organization Identifiers.

Our [needinfo] to Mozilla and Chrome was to determine if these two root programs have specific direction for us or if they are satisfied with the process of public commentary as it is operating. If Mozilla is satisfied, then we will continue on the course we’re presently taking.

Comment 14

[Martijn Katerbarg]

Our update in comment #12 both completed the action items of our incident report and requested an additional week of time for other parties to comment on the case of our second certificate.

We continue to monitor this bug for additional comments or questions. With regards to the second certificate, we are currently drafting proposed updates to the EVGs, and will send this out to the SCWG soon.

However, as there have not been any further comments on either case, we now request that this bug be closed.

Comment 15

[Ryan Dickson]

No concerns or objections from Chrome given the approach described above, and subsequent discussion in this bug after my initial comment.

As always, other opinions from the community are welcome.

Comment 16

[Ben Wilson]

I will leave this open until Friday, 14-Jun-2024, for additional questions or comments.

Comment 17

[Playa Litoral]

Before saying this issue is done, did anyone check that all Sectigo PSD2 certificates have the same form? That is to say, make sure the NCA is not in any organization identifier extension.

Comment 18

[Martijn Katerbarg]

(In reply to Playa Litoral from comment #17)

Before saying this issue is done, did anyone check that all Sectigo PSD2 certificates have the same form? That is to say, make sure the NCA is not in any organization identifier extension.

Our current code-path does not allow for this to happen, nor has it since we originally implemented support for PSD2 based organization identifiers.

While working on this case, we previously also verified that no other certificates issued by us containing a PSD2 based organization identifier had the NCA included anywhere in the cabfOrganizationIdentifier extension.

Comment 19

[Playa Litoral]

Thank you Martijn. I have the two following questions for your answer:

1. How does your system emit this certificate: https://search.censys.io/certificates/100895ed7466d34c0fbe502b2c4ef251abb52f6203a20e839b815d0999265dbf. It seems to me that it is strange. Maybe the NCA was put two times in the subject? Or maybe the second NBG is a part of the unique value?
2. In the EV guidelines, the specific order of the organizational identifier of the subject is written. Sectigo puts the NCA in the subject, but Sectigo also says that the NCA is not a part of the registration reference. If so, how can you put NCA in the subject?

Also, if it is OK, I have a question for root programs. Several years ago, a root program said BuyPass must revoke the certificates without the NCA in the extension. BuyPass said the rule is not clear, but the root program said they must revoke. Now, the words of the rule have not changed, but maybe it is OK if Sectigo does not revoke for the same problem. What is the difference now? Is it because Sectigo uses many words to explain? It does not seem to me that the rules are equal…

Comment 20

[Martijn Katerbarg]

(In reply to Playa Litoral from comment #19)

How does your system emit this certificate: https://search.censys.io/certificates/100895ed7466d34c0fbe502b2c4ef251abb52f6203a20e839b815d0999265dbf. It seems to me that it is strange. Maybe the NCA was put two times in the subject? Or maybe the second NBG is a part of the unique value?

Thank you for bringing this to our attention. This certificate also does not have the NCA included within the registrationReference, thus is not related to anything outlined in this incident.

However, indeed as you hypothesize, it does appear that the subject:organizationIdentifier attribute value is incorrect for this certificate. As such, we’ve started an internal revocation event. As this is a separate issue, we will open up a new bug to address the incident report and root cause of what happened there.

In the EV guidelines, the specific order of the organizational identifier of the subject is written. Sectigo puts the NCA in the subject, but Sectigo also says that the NCA is not a part of the registration reference. If so, how can you put NCA in the subject?

The subject:organizationIdentifier attribute value does not just contain the Registration Reference. It also contains the Registration Scheme. As we wrote in comment #10: The Registration Scheme shows where one would look up the Legal Entity, and the Registration Reference shows which Legal Entity one would look up.

Since the NCA is part of “where” one would look up the Legal Entity, we should consider the NCA as part of the Registration Scheme.