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@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@cabforum.org <mailto:Public@cabforum.org>
> https://cabforum.org/mailman/listinfo/public 
> <https://cabforum.org/mailman/listinfo/public>
_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to