On Thu, Dec 27, 2018 at 12:53 PM thomas.gh.horn--- via dev-security-policy < [email protected]> wrote:
> > 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. > I'm not clear how you get that the owner of example.com is covered anywhere here. Parsed into labels, these all have com as the label closet to the root and then have 'com_cvs', 'com/cvs', 'com/example', 'com/cvs', and 'com@cvs' as the next label respectively. None have 'example' as the next label. > 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). I don't see how this follows. DigiCert has made it clear they are able to technically revoke these certificates and presumably are contractually able to revoke them as well. What is being said is that their customers are asking them to delay revoking them because the _customers_ have blackout periods where the customers do not want to make changes to their systems. DigiCert's customers are saying that they are judging the risk from revocation is greater than the risk from leaving them unrevoked and asking DigiCert to not revoke. DigiCert is then presenting this request along to Mozilla to get feedback from Mozilla. > 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. > I don't agree that demanding all certificate customers have "more automation" is desirable. I am very familiar with the Chaos Monkey approach Netflix has implemented and companies like Gremlin that offer similar "Failure as a Service" products, but forcing this on customers seems like a poor idea. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
