1541064 - SwissSign: Error in OrganisationIdentifier in signature/seal certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Mike Guenther]

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

Steps to reproduce:

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
   An unusual organisationIdentifier for an Austrian entity was detected within an end-user certificate for an electronic signature/seal (no SSL certificate) in the internal review cycle and reported for further evaluation to the compliance function.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
   Timeline of incident handling

• 29.03.2019, 17:06 CET report by an internal employee
• 01.04.2019, ~10:00 CEST Compliance team double checks with the Certificate Authority Manager the reported certificate
• 01.04.2019, 14:11 CEST Compliance team informs TÜV Austria (SwissSign Auditor) of a possible noncompliance (via e-mail).
• 01.04.2019, -16:00 CEST Compliance team reviews the Austrian laws and registration number practices. => confirmation of a misissuance because of form factor
• 01.04.2019, 16:00 CEST risk evaluation for community and customer => low risk rating
• 02.04.2019, 09:00 - 10:15 CEST Compliance team reviews the customer application together with the operationally responsible team => evaluation of reason of mistake
• 02.04.2019, 11:00 CEST Compliance team has a conference call with TÜV Austria to confirm the misissuance because of the form factor.
• 02.04.2019, 13:15 CEST Documentation of the incident report
• 02.04.2019, 15:00 CEST Order for revocation and establishing contacts with the customer
• 02.04.2019, 16:30 CEST Publishing incident report in moz.dev.security.policy and Bugzilla

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
   Already in February 2019 and independent from this report SwissSign decided because of business-reasons to stop issuing seal certificates for non-Swiss entities. (see below why we still issue seals for Swiss entities)

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
   As of today, only one seals is affected. Further inspections are ongoing

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
   The following signature/seal certificate (not SSL) is affected:
   Issuing CA: SwissSign CH Person Platinum CA 2017 - G22
   Serial number: 31:ab:70:1b:f4:a2:89:ad:b7:91:92:57:c4:f2:f4:ed
   SHA2 fingerprint: 60:30:91:32:16:DE:24:F1:06:32:F5:BA:F1:61:0F:93:BD:E3:F8:5F:02:E0:82:50:46:A1:90:40:EE:5A:87:1D

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   Our customer is based in Austria. The reason for revocation is that a space was added to the organisationIdentifier.
   The organisationIdentifier in Austria has the following structure "NTRAT-" followed by the official registration number (in this case the Austrian Firmenbuchnummer) which consists of 6 digits (e.g. NTRAT-123456). Sometimes this number is followed by a check digit in form of a letter (e.g. "NTRAT-123456a"). Based on our current research both alternatives are equal and are used in official matters.
   The mistake was introduced as the information provided by the customer included a space after the hyphen (NTRAT- 123456a).
   The RAO checklists at that time included that the Firmenbuchnummer matches the official registration. This was the case because:

   • if you enter the number in the search engine you receive the correct customer
   • if you enter the customer's name you receive the correct number.
     Looking back the checklist should have included a checkpoint saying: "For Austrian entities the form of an organisationIdentifier MUST follow the structure "NTRAT-123456a"."
     Additional remediation is not needed as we stopped issuing seals (based on ZertES the Swiss Signature law) for non-Swiss entities (Feb 2019). For Swiss entities the space would have been detected as the checklist has more details and the people doing the checks know exactly what to expect.
     Should we decide to start issuing seals for the European jurisdiction we will create detailed checklists for different European nations based on our customer base.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
   a) We are checking all certificates involving Austrian customers if the error is also found in other seals.
   b) We have informed the customer and revoked the seal while providing a new correct certificate.
   c) We include the lessons-learned into our knowledge database for future products for our European customer base.

We will keep the community updated as soon as we have further information.

Comment 1

[Mike Guenther]

Link to mozilla.dev.security.policy posting: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/FsukBDNbq48

Comment 2

[Mike Guenther]

Update
We have completed all the steps listed in point 7

• we checked all seals from EU-customers and did not have additional findings
• certificate is revoked
• Update of our knowledge database for future products

Therefore we ask that this ticket is closed.

Thanks Mike

Comment 3

[Ryan Sleevi]

Could you detail what the checks are you have for Swiss entities? Are they technical or manual?

Comment 4

[Mike Guenther]

The checks for seals are executed manually and in dual control.

For Swiss entities the check of the organisation are:

• consult the Swiss UID register (publicly trusted source provided by the state)
• Check that the structure of the organisationIdentifier follows 'NTRCH-<UID#>';Note A UID# has the structure 'CHE-123.456.789'
• Check the documents provided by the customer

As mentioned above the organization-ID structure of other European countries are different.

Comment 5

[Wayne Thayer]

It appears that remediation is completed.