[cabfpub] How do you handle mass revocation requests?

[philliph at comodo.com]

Going back to the original question.

We have a format for a certificate request (well a few actually). Do we have a PKIX feature that can be used to allow a key holder to request revocation? I can’t think of a PKIX standard for one and it does appear to be a missing feature.

Ron Rivest and Butler Lampson suggested a ‘suicide note’ for requesting revocation. It obviously can’t be the only form of request but it should be one.

People should not need to be emailing private keys about to force revocation. One simple measure would be to consider a CRL for a cert, signed by the cert key to be a valid revocation. But that only works of course if you have a key that can be used to generate a signature (doing this with Curve448 would be hard).


We still don’t know how the private keys were obtained or more importantly when and why. Is this an isolated incident or is there some unmet requirement leading subscribers to some unsatisfactory management practices?

Are these SSL keys or S/MIME? 



> On Feb 28, 2018, at 12:39 PM, Jeremy Rowley via Public <public at cabforum.org> wrote:
> 
> 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
>  
>  
>  
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public <https://cabforum.org/mailman/listinfo/public>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180302/ce7ce2c1/attachment.html>