Open Bug 1917405 Opened 14 days ago Updated 3 days ago

Sectigo: S/MIME OV Mis-issuance

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: q, Assigned: martijn.katerbarg)

Details

(Whiteboard: [ca-compliance] [smime-misissuance] [external])

I requested an S/MIME certificate via work (MGP e.V.) for my email client. This certificate was issued by Sectigo. I believe these certificates have been issued in non-compliance with the S/MIME BR. Below is the certificate as issued by Sectigo.

The specific issues with this certificate are in the stateOrProvinceName and organizationIdentifier fields of the subject. Specifically:

  • Max-Planck-Gesellschaft zur Förderung der Wissenschaften e.V. is registered in the state of Berlin, not Bavaria.
  • NTRDE-VR 13378 is not a valid organization identifier. S/MIME baseline requirements section 7.1.4.2.2 stipulate the construction of this field. There is no national Vereinsregister (register of associations) in Germany, they are administered at the regional level. MPG e.V. is registered with the Vereinsregister of the court of Berlin-Charlottenburg. The correct construction is therefore NTRDE+BE-VR 1337.

I have reason to believe all certificates issued to the MPG are in violation of BRs in this way.

I have contacted Sectigo about this who have stated the following regarding the organization identifier:

The Registration QGIS source used to verify the organization is one that has been confirmed to administer organizations at the federal level. As such, the inclusion of the “+BB” code would be incorrect and considered a misissuance. We have confirmed the interpretation with the QGIS in the past that all their registrations are in fact done at the federal level, not at the local level.

This is demonstrates a misunderstanding of the government structures of Germany. There is no national Vereinsregister (or any national company register for that matter). A national search is available at https://www.handelsregister.de, however this is merely a service provided by the Ministry of Justice of North-Rhein-Westfalia which performs searches against local registers. It is not in and of itself a national register of associations.

As further proof of this there are other registered associations in different courts of Germany with the same registration number, for example:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            c7:68:48:6e:ca:09:60:81:7b:df:f3:d6:3f:b2:67:0b
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=NL, O=GEANT Vereniging, CN=GEANT Personal ECC CA 4
        Validity
            Not Before: Sep  6 00:00:00 2024 GMT
            Not After : Sep  6 23:59:59 2026 GMT
        Subject: C=DE, ST=Bayern, O=Max-Planck-Gesellschaft zur Förderung der Wissenschaften e.V., organizationIdentifier=NTRDE-VR 13378, emailAddress=qmisell@mpi-inf.mpg.de, SN=Misell, GN=Q, CN=Q Misell
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:66:2a:ee:1b:e7:75:31:fe:1d:8f:48:df:e9:ab:
                    b4:97:4d:c9:71:b9:87:df:67:91:73:af:3a:41:7e:
                    64:06:c9:04:8e:55:6d:03:b4:0f:c5:23:8c:a1:64:
                    bb:aa:95:b7:93:be:3c:2c:5b:47:17:32:63:ed:d7:
                    d6:63:21:21:05:7c:de:3a:33:80:cb:34:91:82:4c:
                    89:c6:af:a1:a8:22:ec:31:6e:6f:01:39:55:6e:a6:
                    4c:5c:91:b5:96:c6:39
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                A8:2D:6D:81:32:64:8D:E6:B2:4F:AC:FE:11:F2:65:99:85:13:A9:6E
            X509v3 Subject Key Identifier:
                87:EF:FA:D3:A7:3B:31:51:15:DC:35:41:8F:8B:BB:71:AE:E4:54:83
            X509v3 Key Usage: critical
                Digital Signature, Key Agreement
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                E-mail Protection, TLS Web Client Authentication
            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.6449.1.2.1.10.4
                  CPS: https://sectigo.com/SMIMECPS
                Policy: 2.23.140.1.5.3.2
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://GEANT.crl.sectigo.com/GEANTPersonalECCCA4.crl
            Authority Information Access:
                CA Issuers - URI:http://GEANT.crt.sectigo.com/GEANTPersonalECCCA4.crt
                OCSP - URI:http://GEANT.ocsp.sectigo.com
            X509v3 Subject Alternative Name:
                email:qmisell@mpi-inf.mpg.de
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:45:02:21:00:af:82:72:c7:65:30:10:74:92:94:ba:b9:cc:
        cd:90:f7:d8:bb:42:3e:71:85:33:ff:06:50:48:c2:1c:b0:33:
        19:02:20:17:d2:2a:b9:44:3e:6f:5e:d8:ee:72:e1:d2:db:b7:
        cc:94:17:36:a8:be:a7:8d:19:b5:aa:1f:34:45:be:4b:de
-----BEGIN CERTIFICATE-----
MIID+jCCA6CgAwIBAgIRAMdoSG7KCWCBe9/z1j+yZwswCgYIKoZIzj0EAwIwSjEL
MAkGA1UEBhMCTkwxGTAXBgNVBAoTEEdFQU5UIFZlcmVuaWdpbmcxIDAeBgNVBAMT
F0dFQU5UIFBlcnNvbmFsIEVDQyBDQSA0MB4XDTI0MDkwNjAwMDAwMFoXDTI2MDkw
NjIzNTk1OVowgdcxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCYXllcm4xRzBFBgNV
BAoMPk1heC1QbGFuY2stR2VzZWxsc2NoYWZ0IHp1ciBGw7ZyZGVydW5nIGRlciBX
aXNzZW5zY2hhZnRlbiBlLlYuMRcwFQYDVQRhEw5OVFJERS1WUiAxMzM3ODElMCMG
CSqGSIb3DQEJARYWcW1pc2VsbEBtcGktaW5mLm1wZy5kZTEPMA0GA1UEBBMGTWlz
ZWxsMQowCAYDVQQqEwFRMREwDwYDVQQDEwhRIE1pc2VsbDB2MBAGByqGSM49AgEG
BSuBBAAiA2IABGYq7hvndTH+HY9I3+mrtJdNyXG5h99nkXOvOkF+ZAbJBI5VbQO0
D8UjjKFku6qVt5O+PCxbRxcyY+3X1mMhIQV83jozgMs0kYJMicavoagi7DFubwE5
VW6mTFyRtZbGOaOCAbowggG2MB8GA1UdIwQYMBaAFKgtbYEyZI3msk+s/hHyZZmF
E6luMB0GA1UdDgQWBBSH7/rTpzsxURXcNUGPi7txruRUgzAOBgNVHQ8BAf8EBAMC
A4gwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw
UAYDVR0gBEkwRzA6BgwrBgEEAbIxAQIBCgQwKjAoBggrBgEFBQcCARYcaHR0cHM6
Ly9zZWN0aWdvLmNvbS9TTUlNRUNQUzAJBgdngQwBBQMCMEUGA1UdHwQ+MDwwOqA4
oDaGNGh0dHA6Ly9HRUFOVC5jcmwuc2VjdGlnby5jb20vR0VBTlRQZXJzb25hbEVD
Q0NBNC5jcmwwewYIKwYBBQUHAQEEbzBtMEAGCCsGAQUFBzAChjRodHRwOi8vR0VB
TlQuY3J0LnNlY3RpZ28uY29tL0dFQU5UUGVyc29uYWxFQ0NDQTQuY3J0MCkGCCsG
AQUFBzABhh1odHRwOi8vR0VBTlQub2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAY
gRZxbWlzZWxsQG1waS1pbmYubXBnLmRlMAoGCCqGSM49BAMCA0gAMEUCIQCvgnLH
ZTAQdJKUurnMzZD32LtCPnGFM/8GUEjCHLAzGQIgF9IquUQ+b17Y7nLh0tu3zJQX
Nqi+p40ZtaofNEW+S94=
-----END CERTIFICATE-----

This is to acknowledge we have seen this bug post and will respond in the next few days.

All,

Max-Planck-Gesellschaft zur Förderung der Wissenschaften e.V. is registered in the state of Berlin, not Bavaria.

While the registration was completed by the Court in Berlin, the official registered address of the organization is listed in Munchen. As a result, we deem the subject:stateOrProvinceName value of “Bayern” as included in the certificate to be correct.

NTRDE-VR 13378 is not a valid organization identifier. S/MIME baseline requirements section 7.1.4.2.2 stipulate the construction of this field. There is no national Vereinsregister (register of associations) in Germany, they are administered at the regional level. MPG e.V. is registered with the Vereinsregister of the court of Berlin-Charlottenburg. The correct construction is therefore NTRDE+BE-VR 1337.

We do not agree with the assessment that NTRDE+BE-VR 13378 should be used. The S/MIME BRs heavily used the ETSI implementation of the subject:organizationIdentifier. ETSI EN 319 412-1 does not allow the inclusion of states. While an exception was added in the S/MIME BRs, this was originally targeted for non-EU countries.

The provided details in comment 0 showing that it is possible for multiple legal entities to share the same identifier does pose a potential issue. Yet, we do not believe the construction of NTRDE+BE-VR 13378 is correct.

We will be raising this matter in the S/MIME WG call of the CA/Browser Forum this coming Wednesday, as we believe there may be a conflict in the requirements at the moment.

However, out of an abundance of caution, we will be revoking the certificates issued to this organization within the required deadline.

Assignee: nobody → martijn.katerbarg
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance] [smime-misissuance]
Whiteboard: [ca-compliance] [smime-misissuance] → [ca-compliance] [smime-misissuance] [external]
Summary: S/MIME OV Mis-issuance by Sectigo → Sectigo: S/MIME OV Mis-issuance

Inclusion of the ISO 3166-2:DE code of the federal state is not sufficient. For example, three organizations exist with code HRB 1000 in the state of North-Rhein Westphalia, "Ferdinand Henneken GmbH" (registered with District Court Paderborn), Kley & Trümper GmbH (District court Hamm) and proraum Wohn- u. Freizeitbedarf Vertriebs GmbH (District court Bad Oeynhausen)

This is a known problem and my colleage Adrian presented a workable solution at the CA/B Face-2-Face meeting in Redmond in June 2023, which basically stated:

German public register Ids and OrganizationIdentifier

Problem:

  • German trade registers are managed by district courts («Amtsgerichte»).
  • These are active on a local level, not on the national and not on a «Bundesland» (state) level.
  • Therefore, the assigned IDs are nor unique Germany-wide -> problem with usage as OrganizationIdentifier.

Solution:

  • A unique prefix for every district court that provides uniqueness on a Germany-wide level is required.
  • The «EUID» (basedon EU legislation) provides a list of such unique prefixes for every district court.

Hi Roman, do you have a reference for the EUID? I can't find it with some quick searching.

All,

As we already addressed the included subject:stateOrProvinceName value in comment 2, which is confirmed to be the proper value, we have closed the investigation into that claim, marking it as not an incident.

Regarding the organizationIdentifier, we have concluded that the included value is both in line with the language in the S/MIME BRs, as well as the original intent. Ultimately Sectigo is looking to close this bug as RESOLVED INVALID.

Before we request to do so, we’d like to address a couple of items.

The claim made that we should have included the state level identifier is incorrect. As comment 4 also points out, even at a state level, registration references are not uniquely assigned, this would thus not resolve a potential requirement for the registration reference to be unique at the state level.

As we already stipulated in comment 2, the S/MIME BRs heavily used the ETSI implementation of the subject:organizationIdentifier. ETSI EN 319 412-1 does not allow the inclusion of states. While an exception was added in the S/MIME BRs, this was specifically included for non-EU countries. Previous minutes of the S/MIME Working Group also state as such, showing examples for Switzerland and the United States.

Having had another read of the relevant sections of the S/MIME BRs, we question the idea of a requirement for the registration reference to be unique at a country or state level.

The definition of Registration Reference says: A unique identifier assigned to a Legal Entity. We will note how this does not state at which level this needs to be unique. City, State, Country, Global? We read this as unique to the entity creating the assignment. For example, a city-level registration would require an identifier unique at the city level while a country-level registration would require an identifier unique at that level. As we have seen, at least for Germany a country- or state-wide unique identifier is not guaranteed.

The example that Note 1 in Section 7.1.4.2.2 (d) of the S/MIME BRs provides reads: “Unique Identifier at Country level”. Combined with the known understanding that all European based NTR identifiers are supposed to be registered at the country level, and the fact that an example may not be the only allowed way, our reading of this example is:

(Unique Identifier as assigned to the Legal Entity) – (and registered at the Country Level), which we deem handelsregister.de to be.

I do want to thank Roman for bringing up the option of using the EUID in comment 5. This issue was further discussed in the S/MIME Working Group call earlier this week, during which participants agreed that the language needs updating and clarification for the German case.

Sectigo has considered using BRIS and the EUID. However, we have been hesitant to conclude that it would be a compliant method and reliable source at the moment. We are still hesitant to use it as an NTR reference, since we have seen discrepancies between the registration number shown in BRIS versus the actual registration number that was assigned to an organization. We are however considering whether EUID should be a Registration Scheme in and of itself.

We do agree that it seems like a possible solution, and we have started conversations with a subgroup of S/MIME WG participants to update the S/MIME BR language. We agree the EUID should be an allowed option, yet we have also observed that it is unable to find several companies which are available through national trade registers. As such, while an option for many cases, it may not be viable for all German organizations.

I find Sectigo's argument here deeply puzzling. It seems to be that, because the S/MIME BRs do not specify the scope of uniqueness of a unique identifier, it does not actually have to be unique. This seems like an extremely unusual reading; one would, perhaps naively, assume that if a standard specifies a "unique identifier" and does not specify a scope of uniqueness then the identifier should be globally unique.

(This would obviously mean pretty much every S/MIME certificate is invalid except for those with XGLEI organizationIdentifiers; so we can assume, more charitably, that the expected scope of uniqueness is the registration scheme applicable to the identifier, and note that there is a need for revision of the text of the S/MIME BRs)

Regardless, it does say

3.2.3.1 Attribute collection of organization identity
The CA or RA SHALL collect and retain evidence supporting the following identity attributes for the Organization:
...
6. Unique identifier and type of identifier for the Legal Entity.

The unique identifier SHALL be included in the Certificate subject:organizationIdentifier as specified in Section 7.1.4.2.2 and Appendix A.

It is hard to argue that an identifier is unique when multiple legal entities posess the same identifier.

Appendix A - Registration schemes
The following Registration Schemes are recognized as valid under these Requirements for use in the subject:organizationIdentifier attribute described in Section 7.1.4.2.2, in addition to the GOV and INT identifiers described therein.
NTR: For an identifier allocated by a national or state trade register to the Legal Entity named in the subject:organizationName.

(ETSI's equivalent wording is '"NTR" for identification based on an identifier from a national trade register.')

The identifier was assigned by neither a national or state trade register; the trade registries of Germany operate at a sub-state level.

In your response you state:

(Unique Identifier as assigned to the Legal Entity) – (and registered at the Country Level), which we deem handelsregister.de to be.

handelsregister.de is not a registration authority. As the top of the information page itself states:

The Register Portal of the German Federal States is the electronic communication system specified by the states’ justice departments through which data from the legal entity registers of the judiciary kept by the register courts may be retrieved.

It is a retrieval interface which allows one to lookup corporate information from all of the courts of Germany at once. It is not itself a registration authority.

Even if it were a national register, I would hope that the response from CAs to discovering that the identifiers were not in fact unique would be to discontinue use of the register, not to shrug and go "oh well, nothing I can do"

And as we have noted, the identifiers are indeed not actually unique.

Lets speak plainly here - the wording of the BRs may be vague, but clearly their intention is that the organizationIdentifier itself comprise a globally unique identifier for an organization. There may be multiple valid organizationIdentifiers that represent a given organization, but there should never be one valid organizationIdentifier that represents multiple organizations.

You need to log in before you can comment on or make changes to this bug.