[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

[Doug Beattie]

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Friday, February 3, 2017 6:01 PM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

I'll try to simplify the replies, because it seems that giving a long list of reasons is causing too much confusion:
* I agree, but I think there were some meaningful responses to the concerns you raised.  This long email may be better served via a collaborative document or wiki, then follow up at the F2F.  I’ll see what I can do, because there are valuable points that were dropped in this response.

* Did you know that Google’s CAA record is not correct? – Google is issuing SSL certificates to their domains but google.com is not listed in the CAA record.  Am I misinterpreting CAA?
  https://toolbox.googleapps.com/apps/dig/#ANY/google.com
  google.com. 86399 IN CAA 0 issue "symantec.com"
* Current CPS says you’re not checking CAA – as the proponent of CAA shouldn’t you be checking it, else how can you criticize CAs for dragging their feet?
https://static.googleusercontent.com/media/pki.google.com/en//GIAG2-CPS-1.4.pdf


1) Do you acknowledge and agree that a shorter-lived certificate makes for a natural revocation?
* No, not really.  Expired certificates let you click-through while revoked certificates are a hard fail, the way it should be (per Rob)
* Phishing sites that have a 3 month certificate and that are identified on day 1 as being bad have a full 89 days to continue phishing without certificate expiration, so, there is no help with shorter validity period certificates there
* Wouldn’t a WebPKI revocation system help more than shorter validity period certificates?

2) Do you acknowledge and agree that a shorter-lived certificate ensures that policies regarding new issuance can come in effect quicker than the current system?
* Yes, but at I apparently place less value on this than you do.  Based on issuance date you know what policy it was issued under.  As I’ve said repeatedly, short validity certificate would have had no benefit to SHA-1 deprecation because it was the relying party applications that needed to be updated.

What real world benefit of recent changes would have we have realized if we had 1-year max validity period in the past 3 years?

CT: The set of log servers is just getting to the point of being robust and stable and we’re all moving that way. Some CAs are ahead of others.
CAA – Google isn’t even doing CAA for their CAs yet, so how important can it really be?
SHA-1 – as I’ve said before, not related to short validity certificates

So, what changes have we made or what changed do we envision needing to be applied to all active certificates in order for them to be trusted?  I suggested in the last email making DV short validity – can we at least try to build agreement on that before we boil the ocean?  I might even OK with warning users that receive certificates that are valid longer than 18+- months that they may need to reissue them to be trusted by browsers before they expire, if that helps get us to agreement.  What do you think of baby steps and making at least some progress forward?



Your attempts to ignore the SHA-1 issue are surprising. I would have thought the data that Microsoft shared regarding their efforts to deprecate this - due to the security risk to their users - while minimizing impact - would have unquestionably shown why this was necessary. To recap and refresh - the significant challenge reported was due to the long-lived nature of the certificates meaning that disabling SHA-1 - thus protecting the ecosystem - would and did cause considerable impact.
* The issue with SHA-1 deprecation came from the user base where applications and systems just didn’t support SHA-256 and not CAs. I keep saying this is a bad example of a policy change that would have benefited from shorter validity period certificates.  I hope we can agree on this and drop deprecation of SHA-1 as a reason for needing shorter validity certificates.

The irony here of your objections to continuing the SHA-1 discussion is that, anticipating these problems, Google tried to help communicate to users and site operators the risk that CAs' repeated failures would cause, and the CA Security Council objected to this. So we have a situation where CAs are not actually trying to help the ecosystem (or their users) be more secure, we have ample evidence how the practice of long-lived certs prevents meaningful improvement, and CAs objecting to any and all efforts to improve the ecosystem to date that don't involve CRLs/OCSP, a set of unusable technologies in part due to CAs poisoning that well. That's not a healthy ecosystem.

Let’s identify the problems that we want to solve and come up with solutions rather than forcing a solution on the industry and trying to justify it.  I don’t know about the other CAs, but GlobalSIgn is fine with short validity certificates as long as all of our customers are.  Changing the max validity period is trivial. What we keep missing here is that the consumers of SSL certificates need to be part of this discussion, in fact, they are THE key element and the solutions needs to align with their technical and business needs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170206/206b2d8e/attachment-0001.html>