1610507 - PKIoverheid: TSP CPS lacks problem reporting instructions

Status: RESOLVED DUPLICATE of bug 1596923

(CA Program :: CA Certificate Compliance, task)

Description

[Jorik van 't Hof]

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.

Logius was notified by Bugzilla bugpost 1596923 that the CPS disclosed for https://crt.sh/?sha256=5679A431E79D4EB9EE967C60D8703C7C78F443F71DB97157E43059DE42D850DF does not have a section 1.5.2.

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.

(all dates are in the format dd/mm/yyyy)

15-11-2019 Logius was notified by Bugzilla bugpost 1596923 that the CPS disclosed for https://crt.sh/?sha256=5679A431E79D4EB9EE967C60D8703C7C78F443F71DB97157E43059DE42D850DF does not have a section 1.5.2.
18-11-2019 Logius asked KPN to look into this matter. The information normally listed in the missing section 1.5.2 was misplaced under section 4.9.3, per RFC 3647.
11-12-2019 An update of the CPS was published bij KPN.
24-12-2019 Wayne Thayer comments that unfortunately, a mistake has been made in the correction. Logius asks KPN to correct this.
16-01-2020 KPN published an updated CPS on https://certificaat.kpn.com/files/CPS/KPN_PKIoverheid_CPS_v5.2.3_English.pdf

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.

Not applicable

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.

Not applicable

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.

Not applicable

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

After an earlier issue regarding BR compliance the PA PKIoverheid has put forward requirements to our TSPs to send compliance forms in which they indicate the impact of a CABF ballot on their operations and indicate their commitment to required changes before the appropriate due date. In this case a compliance form was returned by KPN to the PA, in which they stated that in their opinion the information required in section 1.5.2 by ballot SC6 should be located in section 4.9.3 and they would create section 1.5.2 in their CPS but its contents would be limited to a line stating that the relevant information could be found in section 4.9.3. This (mistaken) belief stemmed from the fact that KPN interpreted the text of ballot SC6 to mean that revocation procedures should be listed in section 1.5.2 while they argued that, according to RFC3647, this should be listed under 4.9.3. This wasn’t acted on up by Logius at that time due to human error during the review process of the returned ballot form.

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.

As a result of this issue, the PA PKIoverheid has formulated the following measure to prevent reoccurrence of this issue:
•4-eyes principle (dual control) during review of the returned ballot forms to reduce the chance of human error and/or oversights