On 28 February 2018 at 19:40, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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. Agree with who? Both asking for the keys and providing them seems weird to me. The more secure thing to do would be to ask for proof of possession of the keys, e.g. by signing a random string with them... > 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. > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
