[cabfpub] How do you handle mass revocation requests?

[Jeremy Rowley]

I posted this on the Mozilla dev list but it also impacts the Baseline
requirements.  I realize the list is mostly duplicative but thought I'd
share here as well so we can discuss clarification around "subscriber"

 

 

Hi everyone,

 

I wanted to share an incident report regarding the revocation of certain
certificates ordered through a reseller.

 

On February 2nd, 2018, we received a request from Trustico to mass revoke
all certificates that had been ordered by end users through Trustico.
Unfortunately, the email was not sent to the appropriate certificate problem
reporting channels and did not surface immediately so we're delayed in
sharing the concerns and information. Once we were alerted, the team kicked
off a debate that I wanted to bring to the CAB Forum. Basically, our
position is that resellers do not constitute subscribers under the Baseline
Requirement's definitions (Section 1.6.1). As such, we needed to confirm
that either the key was compromised or that they revocation was authorized
by the domain holder (the subscriber) prior to revoking the certificate. The
certificates were not alleged as compromised at that time.  

 

Later, the company shared with us that they held the private keys and the
certificates were compromised, trying to trigger the BR's 24-hour revocation
requirement.  However, we insisted that the subscriber must confirm the
revocation request or there must be evidence of the private key compromise. 

 

Normally, we permit partners to revoke and manage the certificates freely on
behalf of their customer, with DigiCert providing all validation and
issuance services. However, the sheer number of revocation requests (50k)
and allegation of compromise triggered concerns around the impact to the web
and browser users. Therefore, this was categorized as high risk, especially
considering the relationship between the reseller and DigiCert is
terminating.

 

On 2/27/2018, at my request for proof of compromise, we received a file with
23k private keys matched to specific Trustico customers. This definitely
triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
Once we received the keys, we confirmed that these were indeed the matching
private keys for the reported certificates. We will be revoking these
certificates today (February 28th, 2018).

 

At this time, Trustico has not provided any information about how these
certificates were compromised or how they acquired the private keys. As is
standard practice for a Certificate Authority, DigiCert never had possession
of these private keys.

 

Currently, we are only revoking the certificates if we received the private
keys. There are additional certificates the reseller requested to have
revoked, but DigiCert has decided to disregard that request until we receive
proof of compromise or more information about the cause of this incident.

 

DigiCert sent out emails to the affected customers in order to notify them
that their certificate(s) are being revoked. This revocation only affects
those customers and there is no additional exposure that we are aware of at
this time, nor any reason to believe there is.  

 

This raises a question about the MDSP policy and CAB Forum requirements. Who
is the subscriber in the reseller relation?  We believe this to be the key
holder. However, the language is unclear. I think we followed the letter and
spirit of the BRs here, but I'd like feedback, perhaps leading to a ballot
that clarifies the subscriber in a reseller relationship.

 

This also brings up a ballot about the level of due diligence required for
cert revocation. We generally believe that the private key or demonstration
of domain control is sufficient to request revocation. Others are at the CAs
discretion. Should we clarify what the due diligence looks like? Are there
other things we should have done or been doing? 

 

What kind of transparency would the Mozilla community like around this
issue? There aren't many more facts than I shared above, but there is a lot
of speculation. Let me know what I can share to help alleviate confusion and
answer questions.

 

Jeremy

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180228/28fbb6dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4984 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20180228/28fbb6dd/attachment.p7s>