Closed Bug 1650234 Opened 4 years ago Closed 4 years ago

PKIoverheid / QuoVadis: CPS inconsistencies

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: matthias, Assigned: stephen.davidson)

Details

(Whiteboard: [ca-compliance] [policy-failure])

I found the following inconsistencies and issues in the CPS of the delegated CAs from PKIOverheid to QuoVadis, of which the latest version I could find is available at [0]. The issues are ordered in order of perceived importance, which in this case is also in reverse order of discovery.

1.) BR 4.9.3: "The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS."
The section '1.5.2.1 - Revocation Reporting' in this CPS only links to a web portal which requires login, or phone numbers. The same data is duplicated in section 4.9.3 of the CPS. I believe neither of the included instructions qualify as "readily accessible online means", as this makes it near impossible to report a key compromise to the CA through official channels.

2.) The CPS limits in 4.9.2 those who can request revocation to

  • The CertificateManager
  • The Subscriber
  • QuoVadis as a TSP
  • Organisations of Registered Professionals
  • Authorities/regulators who are involved in the regulation of PKIo activities e.g. Logius.
  • Application Software Suppliers

I believe this is not in line with the same section in the BR, which states 'The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.'. Specifically, the provided list does not include third parties with proof of key compromise.

3.) At 2020-06-22 I've tried contacting the contact in '1.5.1 - Organisation Administering the Document' (which calls out to contact that address for comments regarding the CPS) and '1.5.2 - Contact person' (which contains the same mail address) about point 4 below, but have as of yet not received a reply, nor a confirmation mail. This implies that the contact info is incorrect.

4.) The CPS has a changelog that contains entries for previous versions that have version numbers higher than the current version. Although denoted by "previous document", this is confusing and the MRSP requires increasing the version number for CPS updates, implying resetting the number is not desired.

[0] https://www.quovadisglobal.com/wp-content/uploads/2020/05/QV_PKIO_CPS_V1.2.pdf

We acknowledge this report and will respond in more detail following investigation.

In particular, we will determine what has happened with your attempt to contact the address in CPS section 1.5.1. In the meantime, if you are reporting a key compromise, please contact compliance@quovadisglobal.com.

Regarding your item 4, previously QuoVadis had multiple CPSs in Dutch covering different aspects of our PKIo activities, whose different volumes had different version numbers. As noted in the version control of the CPS, these were consolidated into a single document in English with a different title, whose numbering commenced at v1.

if you are reporting a key compromise

I'm lucky in this case, as I do not have a key compromise.

Please also note that key compromise is only one of the reasons a certificate may need revocation, so adding "third parties with proof of key compromise" is not enough to solve point 2, it was only an example.

I must also note that a similar issue existed in previous versions of the CPS of another PKIOverheid-delegated CA: Bug 1596923

Assignee: bwilson → stephen.davidson
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance]

Some initial thoughts:

#1 - It's in the CPS and clearly directs where you report certificate problem reports. However, it is not an email address. I remember that being proposed as a requirement but I can't find one. Is there a Mozilla section that specifies email as a required process for revocation?

#2 - This seems like a stretch to call an incident, although the language should be updated to specify anyone can instead of these are just examples of who can. I know Quovadis does accept certificate problem reports from anyone submitting them.

#3 - A certificate problem report wasn't submitted. A question was. There is no requirement to respond to questions in 24 hours.

#4 - This one seems like an issue with understanding the various documents. This one is QuoVadis PKI Disclosure Statement for Netherlands PKIoverheid v1.4. It replaced a different program known as: Certification Practice Statement PKIoverheid Domeinen Organisatie (G2), Organisatie Persoon (G3) v1.8. They aren't the same program or CPS.

Different document, different numbering.

The only one that seems to be an issue is #1 and possibly a mismatch between the CPS and practices on #2.

(In reply to Jeremy Rowley from comment #3)

#1 - It's in the CPS and clearly directs where you report certificate problem reports. However, it is not an email address. I remember that being proposed as a requirement but I can't find one. Is there a Mozilla section that specifies email as a required process for revocation?

https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7

Mozilla requires that at least one of the mechanisms defined for Problem Reporting be an email address. Make sure that the CCADB has the correct email address for Problem Reporting, and test that this email address works and is connected to people or systems such that a timely response to a security incident can be expected 24/7.

However, subsequently, this was clarified as part of https://groups.google.com/d/msg/mozilla.dev.security.policy/AclrNBzklBo/OKLx6HkuCAAJ and closed as part of https://github.com/mozilla/pkipolicy/issues/98 , which led to Wayne proposing SC6 as part of https://cabforum.org/2018/09/14/ballot-sc6-revocation-timeline-extension/

Ah thank you. I knew it was required but couldn't find it in the policy. I think #1+#2 needs to be included in the incident report. #2 will be about the inconsistency in practice vs. language (not the language itself, which is easily remediated).

#1 - It's in the CPS and clearly directs where you report certificate problem reports. However, it is not an email address. I remember that being proposed as a requirement but I can't find one. Is there a Mozilla section that specifies email as a required process for revocation?

The problem is not that it is a web page (I believe that is fine), but that this webpage does not give public access to problem reporting - it requires one of 3 login options, neither of which I can use as a 3rd party.

#2, #3, #4

For all of these I don't really think that they are "non-compliances", but they are points of confusion for readers or people trying to contact the CA through CPS-detailed channels (#2 especially combined with #1). That's why I named this bug 'inconsistencies', not 'problems'. As the contact didn't respond in a reasonable time frame for issue #4, I searched the CPS for more info, and found the other inconsistencies - which were then reported here as potential points of improvement. I could have sent this to the CA contact as specified in the CPS, but contact did not reply (#3) to #4.

Yeah - #1 is a problem as it was specified in an email sent out as part of the Mozilla policy. Although this raises an interesting question about new CAs that join after an email is sent and their obligations to abide by it. That's out of scope of this discussion though.

Jeremy: My point was that Mozilla later determined an e-mail wasn't required. Instead, SC6 modified the BRs to require that a CA

The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties
with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of
fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL
publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.

The problem being highlighted with #1 is that it does not provide a means for Relying Parties ... and other third parties because of the requirements.

Okay - looking at this again, there isn't actually a bug at all. Matthias was not reviewing a CPS. He was a reviewing a PDS, which is a differnet document under the qualified regime. The corresponding CPS is:
https://www.quovadisglobal.com/wp-content/uploads/2020/05/QV_PKIO_CPS_V1.2.pdf

There is an email in 1.5.2 and 4.3 allows reports from everyone.

I think this is a case of looking at the wrong document, especially since it's clearly labeled as a PDS, not a CPS. This incident should be closed as invalid.

Jeremy: While I appreciate the quick reply, could I ask you carefully review things with your team before the next update?

Comment #0 describes a CPS, which is what you linked. This report rightfully points out the inconsistencies in 4.9.2 with 4.3 and 4.9.3 with 1.5.2.1. They email they reported, in 1.5.1, is the same as what's in 1.5.2.

Please, carefully review this report. I see no evidence of looking at the wrong document.

Flags: needinfo?(jeremy.rowley)

Sorry - no idea how I got on wrong document.

To be clear, in Matthias’ contact to QuoVadis there was no certificate problem report.

In his email he enquired regarding the CPS numbering. As noted in Comment 1, previously QuoVadis had multiple CPSs in Dutch covering different aspects of our PKIo activities, whose different volumes had different names and version numbers. As noted in the version control of the CPS, these were consolidated into a single document in English with a different title, whose numbering commenced at v1. We believe this is compliant with Mozilla policy.

In his bug report, Matthias notes that the revocation reason does not list third parties reporting keyCompromise among those who may request revocation. This is because third parties report keyCompromise to QuoVadis which requests the revocation in line with Mozilla policy. This is described in both sections 1.5.2.1 and 4.9.1.

Contact emails are listed in section 1.5.1 and 1.5.2. The CPS is undergoing ongoing revisions to improve the English expression of previous Dutch text, and we welcome the opportunity to improve that wording. However, there is a valid email in section 1.5.2: info.nl@quovadisglobal.com

In his problem report Matthias enquires regarding “readily accessible online means” for online reporting. The information in the CPS is correct and frontline support processes are well adapted to handle certificate problem reports.

Now that I'm on the correct document (grimace), I really don't see how there is an issue. The wording can be cleaned up, but with the email included and a process for contacting Quovadis about revocations, there isn't a compliance issue.

Flags: needinfo?(jeremy.rowley)

The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.

- Baseline Requirements 1.7.0, section 4.9.3

Although technically you have indeed published an email in section 1.5.2 which you probably use as a place to send problem reports, I'm very much on the fence on whether or not

In case of suspected Private Key Compromise, [...] or any other matter related to Certificates or this document, Subscribers, [...] and other third parties can contact QuoVadis directly.

qualifies as "clear instructions" due to the direct follow-up question that I have when reading this text: 'contact directly where?' Although the answer can be assumed the contact person mentioned above in the overarching section, this is not at all clear from this section and needed to be pointed out.

Though to be honest, the BR (strictly) only require you to share the [clear] instructions [for problem reporting] through 'a readily accessible online means and in section 1.5.2 of their CPS', they do not require that the problem reporting should (also) be through a readily accessible online means. Ryan, if you could add this to the list of BR improvements, then please

Like Matthias, I similarly have concerns about the reading of the CP/CPS and whether or not it meets the objectives. Hopefully, DigiCert/Quovadis has more to share on opportunities and timelines for improving the language here?

Thanks for highlighting this opportunity for improvement and clearer expectations, Matthias.

Flags: needinfo?(stephen.davidson)

I've filed https://github.com/cabforum/documents/issues/201 to track the BR cleanup

A routine version update of the CPS is in progress which includes both standards updates and improvements to English phrasing. In the meantime, to reiterate the current "QuoVadis Certification Practice Statement PKIoverheid":

  • QuoVadis accepts keyCompromise reports from third parties and acts in accordance with 4.9.1
  • Certificate holders may revoke their PKIo certificates directly online. Holders and other parties may contact info.nl@quovadisglobal.com and +31 (0) 30 232 4320
Flags: needinfo?(stephen.davidson)

Unless there are other questions, QuoVadis requests the closure of this bug.

Ben: I suspect you'll want to close this, based on QuoVadis/DigiCert proposing to fix this (in Comment #15).

While we understand the proposed explanation for how this happened ("It used to be in Dutch"), I don't think we've seen any good plans for preventing future inconsistencies and/or better review.

It would be good, regardless of Ben's next steps, if DigiCert were to document more how they perform their CP/CPS review, and hopefully more thoroughly than the key ceremony events that continue to be incorrectly performed. Having a good understanding, holistically, about the review process may serve as a useful model for both CAs that acquire other CAs and for CAs in their own management of their CP/CPS. At the same time, I do understand and appreciate "mistakes happen", and "lost in translation" is real. I'm just concerned that, as with unfortunately a number of poorly-behaving CAs, DigiCert's main focus has been on "remediation of the incident" without touching the systemic issues and flaws.

Flags: needinfo?(bwilson)

Do we know when the new CPS will be published and whether section 4.9.2 or 4.9.3 will be amended to clarify that third parties can request revocation through a problem reporting process?

Flags: needinfo?(bwilson)

It is intended that the next version 1.3 of this CPS will go before the QuoVadis Policy Management Authority (PMA) next week for approval. Among its revisions are edits for clarity to sections 1.5.2, 4.9.2 and 4.9.3.

To be clear, section 1.5.2 of the existing CPS (version 1.2) explicitly acknowledges third party problem reporting:

In case of suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates or this document, Subscribers, Relying Parties, Application Software Suppliers, and other third parties can contact QuoVadis directly.

In the event that a problem report is confirmed to be correct, QuoVadis revokes the cert as noted in section 4.9.2.

Concerning Ryan's Comment 17, QuoVadis’ CP/CPS management includes:

  1. Tracking of pending changes to applicable standards including CABF ballots, ETSI standards, and national laws/regs/standards (such as eIDAS, NL PKIoverheid or CH ZertES). At DigiCert this includes early and regular updating of affected product management and technical teams.
  2. Developing RFC 3647-based checklists where possible for compliance to applicable standards/required controls.
  3. Splitting roles in CPS production: topic specialist, central editor, second reviewer before going to PMA.
  4. Walkthru of redline with PMA to explain changes.
  5. In the case of QuoVadis, as integration progresses, readers will note the continued adoption of standard polices, practices, procedures and platforms from DigiCert with the benefits and efficiencies of scale.
  6. Annual assessment against BR, changes to standards, post-audit corrective action plans.

Ben, the next update on the CPS is set for next week per Stephen's post. Can we set the next update for no later than end of next week, August 7th? Let me know if any other information is needed for this bug to close out.

Whiteboard: [ca-compliance] → [ca-compliance] Next update 7-Aug 2020

An updated QuoVadis PKIoverheid CPS is at https://www.quovadisglobal.nl/~/media/Files/Repository/QV_PKIo_CPS%20v1.3.ashx
This includes improved language surrounding certificate problem reporting.

I note that QV has modified section 1.5.2. to improve revocation reporting, but I do not know if it is any more clear because it seems that there are two or three email addresses and two web addresses. It could be made clearer which ones should be used under which circumstances. There is also a reference to sections 4.9.17 and 4.9.18, but no corresponding sections.

Hello Ben: The CPS makes a distinction between certificate problem reporting and revocation because under PKIoverheid certain revocation requests must be processed within four hours. There is, respectively, a single email address and webpage shown for certificate problem reporting and for revocation.
An additional email is provided for normal (non revocation) support requests. Although labelled clearly, in the next CPS update we will move that to another section to avoid confusion.
QuoVadis requests closure of this bug.

I will close this on or about 25-Aug-2020 unless I hear any objections.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Summary: PKIOverheid / QuoVadis: CPS inconsistencies → PKIoverheid / QuoVadis: CPS inconsistencies
Whiteboard: [ca-compliance] Next update 7-Aug 2020 → [ca-compliance] [policy-failure]
You need to log in before you can comment on or make changes to this bug.