QuoVadis: Failure to provide a preliminary report within 24 hours
The case concerns a key compromise problem report sent to QuoVadis compliance. The reporter said they provided the compromised private key to c**********e@quovadisglobal.com on 2022-03-28 14:42 UTC and did not receive what they considered a preliminary report until two days later, after follow-up. QuoVadis/DigiCert argued that an acknowledgement email received on 2022-03-28 15:25:59 UTC should count as the required preliminary report under Section 4.9.5, and requested the bug be closed as INVALID. The reporter disagreed, stating the acknowledgement did not contain findings and therefore did not constitute a preliminary report. The thread also discussed whether the preliminary report language needed to include findings and a clear revocation timeframe, noting that the expected revocation date depends on whether key compromise confirmation is obtained. The bug was ultimately marked RESOLVED with resolution INVALID, and QuoVadis/DigiCert indicated the case was ready to close as INVALID.
- A key compromise problem report was submitted to QuoVadis compliance.
- The certificate was revoked.
- Puckipedia representative — Reported that the preliminary report was not received until two days after the key compromise evidence was sent, and provided a timeline including acknowledgement and revocation.
- DigiCert — Argued that the acknowledgement email received within 24 hours satisfied Section 4.9.5 and requested closure as INVALID.
- Puckipedia representative — Quoted the email contents and stated it did not include findings, so it should not be considered a preliminary report.
- DigiCert — Responded that the email contained the findings available at the time and that there is no requirement for a specific findings format.
- Community commenter — Said the comment may partially satisfy the BRs language but argued it may not meet requirements for sequencing and for establishing revocation timeframe.
- DigiCert — Provided details on the 24-hour upper bound for the key-compromise process and referenced an automated reporting URL.
- Community commenter — Agreed that the suggested approach meets the requirement, emphasizing clarifying the targeted date.
- DigiCert — Said they would add the expected revocation date and described routing of key-compromise vs non-key-compromise reports into different revocation queues.
- DigiCert — Indicated the bug was ready to close as INVALID.