1596923 - PKIoverheid: KPN CPS lacks CPR problem reporting instructions

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

Per BR 4.9.3:

The CA SHALL publicly disclose the [problem reporting] instructions through a readily accessible online means and in section 1.5.2 of their CPS.

However, the CPS disclosed for https://crt.sh/?sha256=5679A431E79D4EB9EE967C60D8703C7C78F443F71DB97157E43059DE42D850DF does not have a section 1.5.2:

https://certificaat.kpn.com/files/CPS/KPN_PKIoverheid_CPS_v5.1_English.pdf

Comment 1

[Jorik van 't Hof]

Andrew, Ryan,

Thank you for your report. We have asked KPN to look into this matter. The information normally listed in the missing section 1.5.2 can be found under section 4.9.3, per RFC 3647.

KPN will amend this omission in a future update of their CPS which is scheduled for November 28.

Regards,

Jorik

Comment 2

[Ryan Sleevi]

The concern here is regarding the process for reviewing and incorporating changes from the BRs, understanding why that failed, and hopefully finding opportunities to improve that process.

Comment 3

[Jorik van 't Hof]

Hello Ryan,

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. Nevertheless, there should have been a section 1.5.2. in the CPS of KPN, but this wasn’t implemented due to human error.

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

An updated and reviewed CPS can be found on https://certificaat.kpn.com/files/CPS/KPN_PKIoverheid_CPS_v5.2.2_English.pdf

Regards,

Jorik

Comment 4

[Wayne Thayer]

(In reply to Jorik van 't Hof from comment #3)

An updated and reviewed CPS can be found on https://certificaat.kpn.com/files/CPS/KPN_PKIoverheid_CPS_v5.2.2_English.pdf

Section 1.5.2 of this version of the CPS states "Information regarding this CPS and comments can be directed to". That statement excludes problem reporting. Because this section includes contact information that is described as not being for problem reporting, and does not include anything described as problem reporting instructions, I do not consider it to be compliant with the BRs. This is a real concern because as a relying party reading this section I would not understand how to report a problem to the CA.

Comment 5

[Jorik van 't Hof]

Hello Wayne,

The CPS has been corrected and an updated version is now online at https://certificaat.kpn.com/files/CPS/KPN_PKIoverheid_CPS_v5.2.3_English.pdf

Regards,

Jorik

Comment 6

[Wayne Thayer]

Thank you Jorik. Version 5.2.3 looks good to me.

Please submit a full incident report as required by Mozilla policy. While much of the information required in the incident report may have already been presented or may be irrelevant, following the standard reporting structure ensures consistency. and that no important learnings are missed.

https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Comment 7

[Jorik van 't Hof]

Hello Wayne,

Please find a full incident report at 1610507.

Regards,

Jorik

Comment 9

[Ryan Sleevi]

Thanks Jorik. Since the incident report provided in Bug 1610507 is for this bug, I went ahead and merged it in as a duplicate, so that it's easier to track :)

Comment 10

[Ryan Sleevi]

Jorik: Regarding the 4-eyes principle, I'm trying to understand how Comment #3 implemented that, with the updated policy, but then Comment #4 noted that it had still not been completed properly. Was this a case where four eyes were involved (in reviewing the updated CP/CPS), but still lead to an error in judgement/interpretation of the requirements?

Are there any suggestions for how either the language could be improved or the overall process?

Comment 11

[Jorik van 't Hof]

Hello Ryan,

I think our explanation created some confusion. Comment #3 explains how we double check the returned ballot forms of the TSP’s. The ballot form checks whether the TSP can comply with CABF ballots. Information on the returned ballot form was missed by de PA and therefore we decided it is necessary to double check these forms.

When we stated “An updated and reviewed CPS can be found on https://certificaat.kpn.com/files/CPS/KPN_PKIoverheid_CPS_v5.2.2_English.pdf” we did not refer to the 4-eyes principle review mentioned in Comment#3, we just reviewed the CPS to check whether section 1.5.2 contained the contact information.

Unfortunately the update and the check were apparently made too hastily and the information in section 1.5.2. was correct, but not complete.

As for the language or the overall process, for now we don’t have any suggestions for improvement. In our opinion the Ballot and the process are clear enough, we are confident our 4-eyse principle review will improve our subsequent handling considerably.

Regards,

Jorik

Comment 12

[Ryan Sleevi]

Wayne: Given the report in Bug 1610507, I don't have any further questions.

I admit, I'm not really confident in a 4-eyes principle, due to situations like Comment #10. My understanding from the incident report in Bug 1610507 is that the current requirement is simply self-assessment and promises to abide, rather than a careful review and examination about how they apply. The failure to implement multi-party review for sub-CAs, just as you and I implement multi-party review for Root CAs' policies and practices, easily leads to situations like those in Comment #4.

That said, I'm not sure there's much more to address here. Mozilla Root Store Policy 2.7 explicitly addressed the expectations in Section 2.1, with the addition of

CAs whose certificates are included in Mozilla's root program MUST:
...
7. ensure that all certificates within the scope of this policy, as described in Section 1.1, adhere to this policy.

While the above is a suggestion for how to help that, I think it may be the best we can do. If a CA decides to involve external parties in their operations, they're taking on that risk, pursuant to Mozilla's policies, if they or their sub-CAs violate that.

Setting N-I for you to review and close out.

Comment 13

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.