The following incident report is also posted in Bugzilla
https://bugzilla.mozilla.org/show_bug.cgi?id=1541064
Incident Report
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.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
