On 05/15/2017 09:32 AM, Jakob Bohm wrote: > This won't work for the *millions* of legitimate, not-misissued, > end certificates that were issued before Symantec began SCT > embedding (hopefully in the past) and haven't expired before such > an early deadline. >
Sorry, I could have been more clear here. What I'm proposing is that after a specific TBD NotBefore date, we require SCTs to be in place on the certificate to be trusted. Certificates from before that date would remain trusted as-is (pending any reduction of expiration time). I don't know if NSS has support for checking of SCTs (I can't pull the source at the moment to check), but it should fail if the SCT is missing, and otherwise behave like OCSP validation. > Also, since both Mozilla and Debian-derived systems such as Ubuntu > use the the Mozilla store as the basis for S/MIME checking, it is > worth noting that CT-logging of S/MIME end certs under the current > Google- dominated specifications is a guaranteed spam disaster, as > it would publish all the embedded e-mail addresses for easy > harvesting. > I didn't consider the S/MIME use case here. A brief look at the root store I'd be fine with the SCT restriction only applying when looking at CKA_TRUST_SERVER_AUTH, and not in other cases. Looking at certdata, it looks like at least some of the current Verisign/Symantec roots have both the S/MIME and server auth bits enabled. While I feel CT would be a nice thing for S/MIME, unfortunately, I have to agree with this point that we don't need to make spammers lives easier. That being said, part of me wonders if there would be other undisclosed intermediates if one could easily evaluate S/MIME issuances ... >> Mandating the X509v3 extension for TLS certificates means that >> downstream servers don't have to be updated for CT awareness, and >> we should never be in a case where a Mozilla product is accepting >> a certificate that we can't independent review at a further point >> via the CT logs. It should also prevent an undisclosed >> intermediately from being undetected (as we've seen with Issue >> Y). >> > > However it would mandate that they be updated with new > certificates instead. A lot easier, but still a mountain not > easily moved. See above on NotBefore. >> >> I'd also like to add the following to the transition plans: - >> Limit certificate expiration to nine months from the existing >> roots for new certificates. > > I strongly believe the "9 month" rule mysteriously proposed but > never explained by Google was designed specifically to make buying > certs from Symantec all but worthless, chasing away all their > customers. People *paying* for certificates generally don't want > to buy from anyone selling in increments of less than 1 year, > preferably 2 or 3. "9 months" is an especially bad duration, as it > means the renewal dates and number of renewals per fiscal year will > fluctuate wildly from an accounting perspective. > I can see the point here, but I'm not sure I agree. Every time we keep digging, we keep finding more and more problems with these roots. WebPKI depends on all certificates in the root store being trustworthy, and Symantec as a whole has not exactly shown themselves to be responsive or willing to communicate publicly on the various issues brought up on the list. There's a decent argument to be had to simply disallow new issuance from the existing roots and allow the current certificates to age out (in which case imposing SCT embedded as I propose is simple), but I'm not sure we've gotten a complete picture of how far this rabbit hole goe s. There's been a continual pattern of "this is everything", and then we find another bunch of misissued certificates/undisclosed subCAs/etc. Can we honestly say that we're comfortable with allowing these roots to still be active at all? >> - The above SCT requirement shall come into affect for the old >> roots no less that three months from the date the proposal is >> ratified. - Create a whitelist of intermediate certificates from >> the root that can continue issuing certificates, but cutting off >> RAs after an initial six month time period > > Are there any RA's left for Symantec? > TBH, I'm not sure. I think Gervase asked for clarification on this point, but its hard to keep track of who could issue as an RA. I know quite a few got killed, but I'm not sure if there are any other subCAs based off re-reading posts in this thread. >> - Require that Symantec reapply to the root program for a new DV >> and EV root certificates, and begin the migration here. Once the >> new roots are approved, then they can cross-sign from the old >> roots to the new ones. >> >> My thought process here is to try and keep impact on WebPKI a >> minimum, while making sure that we can externally audit how >> Symantec is using their root store for certificates that will be >> trusted by Mozilla. >> >> I'm concerned that spinning up new roots and having them be in >> the most common root stores is going to take a significant period >> of time and during that window we're still stuck with the old >> roots being in operation. By limiting the branches of the old >> roots, it should limit our risk while the new roots come into >> existence and begin to spread through the ecosystem. > > I believe the only reasonable interpretation of the "new root" > plan would be based on cross signing for trust by old Mozilla > browsers and other root programs. > Won't the cross signature though have to be embedded in Firefox, or included in a server's SSL bundle for it to actually work? Older Firefox/NSS won't have the whitelisting provisions in it, so they'd accept the cross-signature if they're presented with it in the certificate bundle. I realize that as I write this though that this might be a technical impossibility (or at least exceedingly painful) to do so that might kill this part of my proposal as a matter of course. > For starters, we can demand that Symantec never issues misdated > certificates lest they be thrown out instantly. So far the only > misdatings known were a very few that were well documented with > very good technical excuses. > > Forcing the stand-up of new roots operated by competent management > and staff is indeed good, but to do that safely (i.e. without > false security theatrics and same old flaws) would require that > Symantec spends several months to get their house in order before > generating the new root keys. > Which leaves us in the ugly situation of trusting roots which have serious trust questions on it. I agree that any case of backdating to evade a technical control is grounds for the CA death penalty regardless of customer fallout. Looking at the points you bring up though, I think we can deal with the issue as a whole as long as CT is enforced, and that we can independent confirm that enforcement via embedded SCT since frankly, I'm not inclined to trust Symantec saying "yes, this is everything" with regards to certificates they issued. > > The fundamental questions are: > > Should we light a fire under the sloppy Symantec management or > under their innocent users? > Honestly, part of me is thinking the only reason a full distrust is not being discussed is because Symantec is "too big to fail" in the WebPKI world. I don't like the idea of breaking end-users at all, but I also dislike the idea of weaking trust in the PKI system simply because the impact of doing something is too big. On some level, I do think a fire has to be lit. We won't be stuck in this situation otherwise. How big and how severe is TBDed > And should we allow enough of Symantec to keep standing to not > leave those users who cannot switch stranded with nowhere to go but > a 404 webpage? > Removing the EV trust bits at least has the effect of only making the green bar go away. I think a large part of this comes down to the question if the RAs could issue EV certificates or not which was still pending last I checked. However, going a step beyond that, EV represents that a CA has looked in-depth to make sure a cert is going to the right person. For example during the period the cross-signature to the federal PKI was in place, any fPKI CA could have issued a certificate that would have been green barred by Mozilla. I can't say with any confidence than any EV certificate issued by Symantec as things stand actually has had that check and balances. We might be able to limit the damage here if we could determine what was checked by who, and scoping EV removal based on that, but I'm not even sure we have a clear picture of who could sign with what at the moment. Short of independently re-validating EVERY certificate, I don't see a good solution for solving this though. That's not great for Symantec's customers, but its also far better than a broken website. It also lights a fairly huge fire on them to get new roots spun, and then allow for reissues from the old roots to the new. My 2 cents, Michael _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
