1719451 - PKIoverheid: KPN CPS Lists Forbidden Domain Validation Method 3.2.2.4.6

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[David Weissenberg]

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

Comment 1

[David Weissenberg]

We noticed this message from Anrew Ayer {https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/ahCHlHVEHaw/m/S-7RvXTRAQAJ} in the MDSP discussion concerning the Public Discussion of certSIGN's Externally Operated CA by KPN

The CPS for KPN's current intermediate CA under PKIoverheid (https://certificaat.kpn.com/files/CPS/KPN_PKIoverheid_CPS_v5.5_English.pdf) says on page 34 that KPN uses method 3.2.2.4.6 for domain validation, which is forbidden

PKIoverheid and KPN are looking into this matter. We will come up with a Post Mortem shortly.

Comment 2

[David Weissenberg]

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.

We noticed this message from Andrew Ayer in the MDSP discussion concerning the Public Discussion of certSIGN's Externally Operated CA by KPN.
See: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/ahCHlHVEHaw/m/S-7RvXTRAQAJ%7D

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.

(Times in UTC +2h)
Timeline
Date Time Action
31-01-2020 Ballot SC25 passed
19-05-2020 KPN Implemented New HTTP Domain Validation Methods v2
06-07-2021 17:59 Posting by Andrew Ayer on the MDSP mailing list: Public Discussion of certSIGN's Externally Operated CA by KPN
07-07-2021 10:45 KPN noticed the message from Andrew Ayer in the MDSP discussion
07-07-2021 11:00 Start analysis by KPN
07-07-2021 12:55 PA PKIoverheid informed KPN
07-07-2021 13:00 KPN started drafting a new version KPN CPS
07-07-2021 13:35 PA PKIoverheid filed bug 1719451

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.

As for any change in (external) requirements KPN did perform an analysis and identified the changes needed to the validation procedure. These were implemented on May 19, 2020. However, although the analysis also indicated that a new version of the CPS was required (to reflect the changed procedures) this did not take place. The root cause for this seems to be insufficient attention from KPN to update the CPS after changes in operational procedures.

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.

The PA PKIoverheid has a process in place that for each change in CABForum requirements a PKIoverheid TSP will use a default template to analyze the impact of the new requirements. After a ballot is adopted by the CABForum the PA PKIoverheid requires of it's TSP's to show proof of conformance to the ballot before the effective date. If a TSP isn't able to show proof of conformance as of the effective date, certificate issuance will be suspended until the TSP can supply evidence to the contrary (effective since 09/01/2017). This template will now be expanded and updated with a checklist of potential CA systems or procedures that need to be changed because of the new or modified requirements (including the necessary documents, like the CPS). The PA PKIoverheid can then check before or on the date if the TSP has effected the necessary changes. This should act as a safeguard to prevent the initial omission made by KPN in this case.

Comment 3

[Ryan Sleevi]

David: Thanks for providing the update.

Can you share more comprehensively what this template contains? The answer to question 6 reads a little like "human error", but the existence of this checklist you mention suggests PKIoverheid at least has some processes and controls to try to mitigate human error, and then explains why this existing system failed to catch it (because it was omitted). Having a better sense of what's on the template can hopefully lead others to highlight any other potential gaps, beyond CP/CPS documents, that may wish to be considered.

Comment 4

[David Weissenberg]

Attachment: Modified_Ballot_Template_PKIoverheid.pdf

Hello Ryan,

The Ballot conformance form that we mentioned earlier contains a set of questions regarding the adopted ballot for which the TSP needs to supply satisfactory answers.

The original template of the Ballot conformance form was focused on the (high-level) impact on PKIoverheid of the Ballot, the necessary changes to be made by the TSP, the implementation timeline and the expected date on which the change was fully implemented. The submitted form was reviewed by the PA PKIoverheid and if necessary, further interaction with the TSP ensued if the described actions and timeline were deemed insufficient. In case of a satisfactory result, the normal process ended there. The PKIoverheid team has done some spot check in the past, mainly in the case when there were changes in the certificate profile.

However, as shown by this incident, this process is not flawless and as such improvements are necessary. We have the following measures in mind to strengthen this mechanism:

1. A new ballot form, which requires more detail regarding the actual changes that the TSP makes (see the attachment as an example of this). This also explicitly includes the changes to any (external) documentation like the CPS and details about which systems and processes are affected by the changes in the requirements.
2. A more strict policy regarding follow-ups and due dates, including checking up with the PKIoverheid TSPs before the effective date to make sure that all changes listed in the form were actually made. To facilitate this, PKIoverheid will set a mandatory effective date that is at least two weeks before the BRG effective date. The original process allowed the TSP to set a due date that was just before or the same as the effective date of the ballot. However, this means that in some cases that the PKIoverheid can only check the result after the effective date of the ballot, which could result in misissuance of certificates.
3. PKIoverheid TSPs are already required to notify the PA PKIoverheid when they upload a new version of their CPS. However, this is a manual process (via e-mail). We’re currently investigating if this can be automated so that the PA PKIoverheid will get an automatic notification when the TSP changes their repository. This way it can also act as an automatic check when CPS changes were listed in the ballot compliance form.

With these proposed changes, we feel that it will give the PA PKIoverheid better insight and control over the change process as implemented by the PKIoverheid TSPs as to prevent future similar issues.

Comment 5

[David Weissenberg]

Hello Ryan,

The Ballot conformance form that we mentioned earlier contains a set of questions regarding the adopted ballot for which the TSP needs to supply satisfactory answers.

The original template of the Ballot conformance form was focused on the (high-level) impact on PKIoverheid of the Ballot, the necessary changes to be made by the TSP, the implementation timeline and the expected date on which the change was fully implemented. The submitted form was reviewed by the PA PKIoverheid and if necessary, further interaction with the TSP ensued if the described actions and timeline were deemed insufficient. In case of a satisfactory result, the normal process ended there. The PKIoverheid team has done some spot check in the past, mainly in the case when there were changes in the certificate profile.

However, as shown by this incident, this process is not flawless and as such improvements are necessary. We have the following measures in mind to strengthen this mechanism:

1. A new ballot form, which requires more detail regarding the actual changes that the TSP makes (see the attachment as an example of this). This also explicitly includes the changes to any (external) documentation like the CPS and details about which systems and processes are affected by the changes in the requirements.
2. A more strict policy regarding follow-ups and due dates, including checking up with the PKIoverheid TSPs before the effective date to make sure that all changes listed in the form were actually made. To facilitate this, PKIoverheid will set a mandatory effective date that is at least two weeks before the BRG effective date. The original process allowed the TSP to set a due date that was just before or the same as the effective date of the ballot. However, this means that in some cases that the PKIoverheid can only check the result after the effective date of the ballot, which could result in misissuance of certificates.
3. PKIoverheid TSPs are already required to notify the PA PKIoverheid when they upload a new version of their CPS. However, this is a manual process (via e-mail). We’re currently investigating if this can be automated so that the PA PKIoverheid will get an automatic notification when the TSP changes their repository. This way it can also act as an automatic check when CPS changes were listed in the ballot compliance form.

With these proposed changes, we feel that it will give the PA PKIoverheid better insight and control over the change process as implemented by the PKIoverheid TSPs as to prevent future similar issues.

Comment 6

[Ryan Sleevi]

Thanks David. While there's no question that super-CAs generally pose greater risk to users, by virtue of adding many more participants and layers of indirection through supervision, I'm impressed that PKIoverheid continues to take the concerns seriously enough to take many good proactive steps here to reduce the risk to users.

Sending to Ben to see if he has further questions. Comment #5 leaves things open-ended on timelines, though, so more detail here is appreciated.

Comment 7

[David Weissenberg]

Hello Ryan, we can confirm that as of augustus first PKIoverheid and its TSPs will use the new/modified ballot template. That makes that steps 1 and 2 from comment #5 are in place.

Concerning step 3 we are still exploring the possibilities of automating the process of detecting a newly published CPS. We expect to have a final action plan ready within two weeks.

Comment 8

[Robert Leyting]

We expect to have the automating of the process of detecting a newly published CPS to be ready within two weeks. With this process the PA PKIoverheid will get an automatic notification when the TSP changes their repository. This way it also acts as an automatic check when CPS changes were listed in the ballot compliance form.

Comment 9

[Robert Leyting]

Our tooling now makes it possible to automatically detect a newly published CPS. It can act as an automatic check when CPS changes are listed in the ballot compliance form.

Comment 10

[Robert Leyting]

We believe this bug can be closed.