The end user agreed to the subscriber agreement, not Trustico. Our analysis follows what Peter B. posted – the subscriber is the “natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use"—which in this case was Trustico’s customers. In addition, we felt that given (1) the number of certificates Trustico was asking us to mass-revoke and (2) the lack of any substantiation of why Trustico thought the certs were “compromised,” we needed more information before revoking. At the minimum, it warranted alerting the contact for each certificate that revocation was imminent.
I also agree that there’s no problem with the way or that the keys were provided to DigiCert for cert revocation. I certainly don’t want to discourage revocation of compromised certs! My main question is how do you handle these things? The process at scale should not be different if a reseller requests revocation compared to any other security researcher. The question is how you handle the this volume of revocations when its happen? I’ve never received a revocation request of this magnitude before so I’m seeking the wisdom of the community in what we do. I’m happy to share any of the details I can. Jeremy From: Ryan Sleevi <r...@sleevi.com> Sent: Wednesday, February 28, 2018 11:58 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: How do you handle mass revocation requests? On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: 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. I think there's a little nuance to this in the general case (e.g. consider "Resllers" who are also the hosting provider, and thus constitute the Applicant/Subscriber even when they're not the domain holder, but authorized by them), but based on this specific case, I think this sounds like a correct determination. I think the biggest question is who agreed to the terms - Trustico or the end-user - and that mostly impacts the rest of the decision here. Further, did Trustico warrant on behalf of the user that the user agreed to the terms (in which case, I would think it's a bit of a copout, and it's really Trustico agreeing, thus the Subscriber), or did DigiCert have direct communication with the user on the basis of Trustico's introduction (in which case, yeah, the Subscriber is the user) Anyway, just highlighting it here as perhaps not a uniform consensus, but perhaps not as material as what follows. 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). I think all of this sounds reasonable, no different than a security researcher (or random member of the public) who were to claim compromise with no evidence of that. 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. For the same reason that "Jane Random User" should not be able to cause revocation merely by assertion, I think that sounds reasonable. 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. I think the question here is less about who is the Applicant, but who is the Applicant Representative. If the Reseller is signing/agreeing the request on behalf of the applicant, or the Subscriber Agreement, they're the Applicant Representative and ostensibly should be taken as authorized. I think the gap here is we have this notion of Applicant/Applicant Representative prior to the issuance - in which some 3P may agree to a Subscriber Agreement (or warrant agreement), yet claim the Subscriber is somehow a different entity or that Representative is no longer bound in scope. That seems pretty troubling - both in terms of how the Applicant Representative is verified as authorized (which seems fundamentally what a Reseller who agrees to a ToS is) - and as to how revocation works. 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? I think Wayne's still looking at the revocation space (and I'm much belated in my offering feedback), but I think one of the gaps is one we've seen come up with Google domains and Let's Encrypt. And while I share these stories, to be clear, I don't think LE has done anything wrong in issuance or handling of it - it just is a good demonstration of the nuance that any such clarification should consider. Consider https://crt.sh/?id=245397170 , which was a google.tg <http://google.tg> certificate obtained from LE following an apparent Registry compromise. Prior to the compromise, Google operated google.tg <http://google.tg> , during the compromise, an unknown third-party did, and following the compromise, Google again operated/controlled google.tg <http://google.tg> . When it came to requesting revocation, however, this highlighted a challenge. Let's Encrypt has several defined methods for validation - the HTTP-01 method, TLS-SNI-01 (at the time), and DNS-01. Google services - particularly those hosting/serving google.tg <http://google.tg> - do not support any of those methods (by somewhat intentional design). Google also did not control the private key - naturally. Based on the evidence Google provided - and, importantly, through consultation with 3P - LE was able to determine the .tg compromise and revoke the certificate. A mandate of 'due diligence' that suggested demonstration of private key, or of using LE's preferred methods, would have prevented that revocation. A model that offers CA significant flexibility and discretion does have the downside of the CA choosing to *refuse* to revoke, and them claim that they were operating within the bounds of the Baseline Requirements. Thus, any form of requiring due diligence has to consider an adversarial model of CAs (sorry Jeremy!), in which the CA may have incentives, whether real or imagined, not to revoke and/or to impose hardship on the domain operator. The current structure favors the 'victims' in the example I just gave, but I think also presents risks - as you raise - of 3P requesting revocation without authorization. I don't know if or how we'll be able to square those somewhat competing interests, but I think it's worth keeping in the consideration. If we stretch the idea out further, one could imagine that CAs must support 'all' validation methods to authenticate a revocation request. But now that shifts the burden from the victim (in having to prove control) onto the CA - which is its own set of tradeoffs. It also introduces new risk - in which adversaries may use a weaker method of authentication maliciously (for example, consider 3.2.2.4.8, in which anyone sharing an IP could cause the revocation of a cert of anyone else sharing that IP) In any event, I'm hugely appreciative of the details you've taken to share and be transparent with the community regarding this. This is an incredibly valuable discussion to have, and more importantly, and valuable level of transparency regarding the incident, given the amount of apparent misinformation and confusion regarding this flying about.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
