1762456 - QuoVadis: Failure to provide a preliminary report within 24 hours

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[Puck Meerburg]

On 2022-03-28 14:42 UTC, I sent a problem report to [e-mail] concerning a key compromise. Only after asking them, 2 days later, did I receive what I would consider a (preliminary) report. I was also told that the acknowledgement of the problem report constituted a valid preliminary report, which I do not believe to be the case.

Full timeline: (UTC)

• 2022-03-28 14:42:26: Provided compromised private key to compliance@
• 2022-03-28 15:25:59: Received acknowledgement of the report
• 2022-03-29 13:39:29: (Certificate revoked)
• 2022-03-30 20:24:22: Asked about the status of the report
• 2022-03-30 22:31:12: Received report

Comment 1

[Jeremy Rowley]

This was the preliminary report:
2022-03-28 15:25:59: Received acknowledgement report preliminary incident report

Section 4.9.5:
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate
the facts and circumstances related to a Certificate Problem Report and provide a
preliminary report on its findings to both the Subscriber and the entity who filed the
Certificate Problem Report.

We did both: 1) investigated the fact and circumstances and 2) provided a preliminary report to the entity and Subscriber. The response was that we were investigating the issue and planned to revoke if appropriate.

Note that we did automate this process (of tracking and ensuring a response was made) a year or so ago. Because we met both points under 4.9.5, I'm requesting this bug be closed as invalid.

Comment 2

[Puck Meerburg]

The contents of that email are as follows:

We are currently investigating, and if the key confirmed to be compromised
we will ensure that the certificate is revoked within the required time
constraints.

As it does not contain any statement on any findings, I do not believe this to constitute a preliminary report.

Comment 3

[Jeremy Rowley]

The finding was that we hadn't confirmed key compromise and need more time for investigation. It contains the findings we had when the email was sent, even if it wasn't the findings you wanted. There isn't a stipulation on what the findings must be or what those findings look like.

Comment 4

[Ryan Sleevi]

Based on the report in Comment #2, this does seem to partially satisfy the BRs language.

That said, Jeremy, you'll recall when you were proposing this language, we discussed a little of the sequencing, with the expectation of the final report being delivered before revocation. That's why this language was future-tense (pre-dating revocation), bolded below.

After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or
other revocation‐related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate.

I would argue that Comment #2 may not satisfy those two requirements, namely: it indicates it MAY be revoked (contingent on other factors) and doesn't establish the timeframe for revocation.

That said, the easy way to satisfy that test would be to say the same thing, but worded differently, and I'm not sure that such a phrasing would make much of a difference. Namely, had DigiCert said

We are currently investigating. Our present plan is to revoke the certificate on 2022-03-29 based on the available information. This plan may change if new information comes to light.

Then it unquestionably meets the language, but says... well, basically the same thing you said. So I think I'm inclined to agree INVALID here, with a caveat of perhaps clearer indication of what DigiCert is considering the upper-bound of the shotclock.

Comment 5

[Jeremy Rowley]

The upperbound of the shot-clock is 24 hours from the time we received the key compromise. If no action is taken to not revoke the certificate after receiving a key compromise report, the certificate is revoked at 22 hours. Note that using this form: https://problemreport.digicert.com/key-compromise/report will automatically kick off the key compromise check and revocation process. Anything sent to DigiCert by email ends up dumped into this automated system.

Also, thank you for the suggestion on our reply language. I'll have our template be something like you suggested but add a caveat that we are still investigating (in case the system hasn't confirmed key compromise for whatever reason). Something like:

Thank you for submitting evidence of a compromised key. Our present plan is to revoke the certificate on 2022-03-29 assuming the system confirms key compromise. Please note that key compromise confirmation is required to revoke the certificate. We will notify you if the evidence submitted is insufficient to confirm key compromise.

For non-key compromise reports, I'm thinking of something like this:

We are currently investigating the certificate problem report. If revocation is required under industry standards or our certificate practice statement, we will revoke the certificate on or before 2022-04-2. We will notify you if the evidence submitted is insufficient to determine that revocation is required.

Sound good?

Comment 6

[Ryan Sleevi]

Yeah; sorry if my Comment #4 wasn't clearer that while this (specific) case seemed on the line, it also wasn't clear that rewording was strictly necessary. That is, especially when factoring in the various CAs' languages (e.g. tenses in Japanese), splitting too fine a hair seems to not be productive. So the only suggestion I felt was important was clarifying what the date being targeted is, since that both avoids the tense issue, and offers a clear point for follow-up as to whether the CA is interpreting 24 hours, 5 days, or something else.

So yeah, I think those both meet it.

Comment 7

[Jeremy Rowley]

Makes sense. I'm still going to have the expected revocation date added to clearly specify whether the request dropped into the 5 days or 24 hour revocation process.

All reports submitted as key compromise get funneled into the 24 hour process (22 hour process where the tool is used). Everything else reported by non-subscribers goes into the five day revocation queue.

Comment 8

[Jeremy Rowley]

Hey Ben - I think this is ready to close as "INVALID"