On Wed, Feb 28, 2018 at 2:40 PM, 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. > Assuming Trustico sent the keys to DigiCert, it definitely sounds like even if Trustico was authorized to hold the keys (which is a troubling argument, given all things), they themselves compromised the keys of their customers, and revocation is both correct and necessary. That is, whether or not Trustico believed they were compromised before, they compromised their customers keys by sending them, and it's both correct and accurate to notify the Subscribers that their keys have been compromised by their Reseller. If your Reseller compromises your keys capriciously, it sounds like it might be time to find a new Reseller. 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. > For the remaining certificates, it sounds like, based on the evidence, that Trustico has no authority to request revocation for those remaining, and it would be monumentally hostile/unwise of them to subject that their customers to do that. To the more general case - how to handle mass revocations - this seems similar to when Heartbleed hit, and the lessons from then apply now: - CAs should design their systems and be prepared for mass revocations on sufficient demonstration - Sharding out CRLs, for example, to ensure no CRL becomes unreasonably large (say, >64KB, which is many clients' limits), using critical issuingDistributionPoint extensions on the CRLs and hosting at unique URLs - Designing the OCSP serving infrastructure to be able to handle a large influx of revocations - Reducing the overall lifetime of certificates to minimize the total number of ongoing (OCSP, CRL) signatures that would need to be produced - Site Operators should design their systems to be prepared for sudden revocation - Don't introduce unnecessary third parties (such as Resellers), when possible - Invest in automation such that certificate replacement is automated/automatic - Corollary: Have multiple CAs support the automation mechanisms used (such as standard automation methods) in the event it is the CA compromised - Corollary: Support multiple automation validation methods (such as DNS + HTTP + TLS) in the event it is the automation method that is compromised _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
