This is accurate. We have the technical capability and policy ability to revoke the certificates. What we were hoping was a discussion based on impact of the revocation so we could hear what we should do. Blind obedience isn't my favorite answer, but it's an option. The guidance so far is file an incident report now so we can discuss the potential impact. I've filed for two companies, crossed a couple more off the list, and am still working with the remainder to get things resolved. Although some have escalated over my head, I think most are eager to hear what the community has to say. I also think this is an interesting question for Mozilla's policy - not sure we've ever addressed a potential non-compliance like this.
-----Original Message----- From: dev-security-policy <[email protected]> On Behalf Of Peter Bowen via dev-security-policy Sent: Thursday, December 27, 2018 2:19 PM To: [email protected] Cc: [email protected] Subject: Re: Underscore characters 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
