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

Reply via email to