As to why these certificates have to be revoked, you should see this the other way round: as a very generous service of the community to you and your customers!
Certificates with (pseudo-)hostnames in them are clearly invalid, so a conforming implementation should not accept them for anything and they should not pose any security risk. Based on this assessment (no revokation if no security risk), a CA could very well issue a certificate including any of the (psuedo-)hostnames "example.com_cvs.com", "example.com/cvs.com", "cvs.com/example.com", "https://example.com/cvs.com";, "[email protected]" to the owner of example.com (who, arguably, has the exact same right to them as the owner of cvs.com has) and refuse to revoke them. As to the consequences (in case this really becomes an incident report/incident reports): this shows a SEVERE lack of ability to revoke certificates on DigiCert's side, which must have been known AND ACCEPTED for a long time (this cannot be the first "blackout period" of (in the best case) 3.5 months). Thus, it seems to be a good idea to: 1. Henceforth, make NSS only accept certificates by DigiCert with a maximum validity of 100 days. Let's Encrypt has shown that this is clearly feasible. or 2. Henceforth, require DigiCert to revoke a small, randomly (e.g., using RFC 3797) selected subset of their certificates every day (within 7 days). If this, e.g., for the same reasons as outlined in these incident reports, is not possible, it will trigger (a incrementally decreasing number of) more incident reports. Both proposals would lead to more automation and a better understanding of the requirement of timely revocation, while pushing the ecosystem in the right direction. For its easiness, the first proposal would be my favorite but I would be very interested in hearing other people's thoughts about these proposals. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
