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

[Ryan Sleevi]

On Thu, Feb 2, 2017 at 7:58 AM, Doug Beattie via Public <public at cabforum.org
> wrote:

> I don’t understand this how this is the “single greatest impediment
> towards improving the security of the Web PKI” or how misissuance decreases
> with shorter validity periods.  While the SHA-1 deprecation was difficult,
> this primarily was driven by customers technical ability to give up SHA-1
> and not with the technical ability of the CAs to change over.
>

I'm surprised to hear you say that, Doug, given how long the deliberations
took for SHA-1 (and ultimately involved browsers having to act
unilaterally, because CAs opposed change)

For example, consider the (many) SHA-1 exception requests. A shorter
certificate lifetime would have allowed for a more nuanced phase-out, and
customers (such as Symantec's) could have been better informed of the SHA-1
deprecation - through the natural process of certificate expiration. We
could have surfaced these issues considerably faster, and thus avoided (or
reduced) the need for an exception process.

Consider the impact of Ballot 169 (or whatever its future form may be).
Browsers and relying parties *cannot* be assured that the certificate is
not unauthorized for another 78 months (at least! - assuming we can get
improvements), due to the combined use of previously validated data and
long lived certificates. This is, simply put, unacceptable. GoDaddy's
recent misissuance (
https://groups.google.com/d/msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ
) as an example of where adopting the methods from Ballot 169 are critical
to the ecosystem.

Consider any reform about extensions and their content - again, the
ecosystem of relying parties and browsers cannot rely upon those changes
being effective until they're forced to either a) break users or b) they
naturally expire.

Consider how the long validity period of certificates has artificially
suppressed the need for automation, making it more difficult, rather than
easier, for customers to obtain certificates - because they only need to do
it once every 3 years. And while being sensitive to our antitrust policy, I
cannot help but think opposition to one year certs is, in part, motivated
by CAs trying to artificially constrain the market in ways that advantage
them, because their customers are much less likely to look at their
competitors if they only look once every three years (... or 6), rather
than every year.

Consider the challenges in distrusting a CA - as Google is currently doing
for WoSign/StartCom (
https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html
). Shorter-lived certificates ensure the ecosystem is more robust and
resilient to changes in trust stores, and in turn creates greater
incentives for CAs to abide by the Baseline Requirements that they've
developed.

These are all considerable improvements to the natural state of security.
Improvements like CAA or CT simply don't work meaningfully, so long as
certificates are allowed to be valid for 39 months and reuse cached
validation for 39 months. Imagine how much more secure the ecosystem could
be if, within a year, we could be assured that every CA would have checked
the CAA record and disclosed via CT.

If there are significant numbers of certificates with invalid/outdated DN
> information then we need to address this (is this true?), but that does not
> necessarily mean short validity certificates or shorter re-use periods.
> Further, when we find such certificates, regardless of validity period,
> they need to be revoked and the revocation status needs to be respected by
> the Web PKI.  Today the revocation process is broken.
>

I wholeheartly agree that the revocation process is broken, but so far, CAs
have largely opposed improvements. I'm incredibly grateful that GlobalSign
supported Ballot 153, which would have seen an incredibly useful
introduction of a means to solve that problem, but it's also clear that not
all CAs share your awareness or attention to resolving the revocation
problem.

It's also important to consider that shorter-lived certs create the
opportunity to make CRLs *more* viable and performant, which might be able
to see their reintroduction in the WebPKI. A significant challenge to the
CRL problem has been the fact that many (too many) CAs have deployed their
CRLs incredibly inefficiently. By allowing shorter expiration, we allow
CRLs to be smaller, and thus improve the security of the ecosystem by
making them more reliable. I'll note that this isn't a perfect solution -
there are still other normative requirements needed to reform CA's
practices, since too many have trouble reading or understanding their
business or RFC 5280 - but it's an important step into making these more
viable.

But even in the absence of CRLs, the validity period of a certificate
represents a natural revocation, so surely you can see how supporting this
helps _improve_ the revocation story on the Web, more than any other action
CAs or the CA/B Forum has taken to date.


> As Dean said previously, this was discussed without resolution a while ago
> and I haven’t seen consensus or constructive discussions on recent
> proposals to change either the maximum validity period or re-use of vetting
> data.  Assigning across the board values for max validity and vetting data
> is shortsighted.  These should be set based on risk and business processes
> and not “being consistent for the sake of being consistent”, or “making Web
> PKI more secure”.
>

It's understandable that CAs would be opposed to things that represent
change. If anything, the activity of the Forum for the past 4 years - and
the considerable and numerous failures of the CAs participating
(_especially_ the failures of the CA Security Council membership, which is
both ironic and disappointing) - has shown that the most meaningful way to
make changes - such as SHA-1 deprecation - ultimately require making
concrete action rather than endless deliberations.

I realize we don't have a perfect solution, because there will always be CA
members who oppose change because they're either afraid to adapt or unable
to, but as we look to move more of the Web to HTTPS, it's simply necessary
that we take steps to ensure the ecosystem can move forward in a timely way
and that we take concrete steps to improve security.


> We must understand the issues we’re trying to solve and come up with an
> approach that is acceptable to TLS customers, CAs, Root programs and
> balance security with usability vs. applying a blanket 13 max across all
> certificate types “just because”.  I’d propose that this be taken up in a
> working group where the necessary discussions and requirement gathering can
> be done.
>

Frankly, this comes across as an attempt to ignore the many misissuances
we're seeing, by artificially delaying discussion.

We know that CAs are opposed to changes or supportive of longer certs (by
the large majority, as our strawpolls saw). We know that browsers have, to
date, expressed support for shorter certificates.

At this point, we need to establish concrete reasons why 13 months is
harmful or insurmountable. I haven't seen any such reason yet for 13 months
- although the discussion of the challenges with 12 months was incredibly
useful and informative - and I would hope that if such reasons exist, CAs
would and could be bringing them to the Forum.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170202/7312cda2/attachment-0003.html>