[cabfpub] Certificate validity periods

[Ryan Sleevi]

On Wed, Mar 30, 2016 at 11:38 AM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Ryan,
>
>
>
> Rich summed it up pretty well without getting into the gory details –
> making certificates is a bit like making sausages, the details are better
> left out.
>

I appreciate the analogy, but I don't think it's a good position to take.
Ultimately, the CA/Browser Forum exists to balance the costs - the costs to
the ecosystem as a whole, the costs to users, the costs to browsers, and
the costs to CAs. There are things we can do to improve the ecosystem, but
at a cost to one or more parties - and we're always trying to strike a
balance.

For example, the SHA-1 is a great example where there's high costs to a few
particular users (those who didn't adequately plan for transition, either
directly or through their vendors), and for which solutions exist to trade
those costs on to browsers/relying parties (e.g. blacklisting) or to the
ecosystem as a whole (e.g. allowing it, putting the entire ecosystem at
risk).

So it's always helpful, and useful, to understand what the actual, concrete
costs or challenges are to a CA, to better inform the discussion and
balance the tradeoffs - that's why it helps to know how the sausage is
made. It also helps the public, who, for better or worse, I suspect have an
image of CAs' sausage making factories as a bit akin to those meatpacking
facilities in Sinclair's "The Jungle" ... to stretch the metaphor even more.


> From my perspective there is little  benefit – some customers like longer
> validity period certificates so they don’t need to change them as often
> (not everyone is fully automated), and we don’t mind selling them when
> asked. It’s a lot of work with sales, marketing, legal, compliance, vetting
> and development teams to make changes like this and  I don’t see the much
> of a gain in security from going from a max of 39 months to 27 months.
>

That's useful to understand, because then we can have a productive dialog
about the concrete security benefits. That said, given that Jeremy already
included some of them in the initial message, it's a bit of a challenge
trying to see if you don't understand the benefits outlined, or if you
don't agree - the former suggests there's productive room for discussion,
but the latter is harder to solve and may not be useful.


> Perhaps I’m not understanding the implications behind your statement
> “…reducing validity times and revalidation times is a big win for security
> and the ability to change”.  I think we’re actually contemplating
> increasing EV validation times.
>

While that was included by Jeremy's post, as discussed in the past,
multiple browsers were opposed to 2 (a and b). So unless new information is
shared, I don't think that's realistically a topic for discussion, but
moreso included for completeness.

As we know browsers can and do go off and update their root program
requirements when they feel it is in the interest of their users' and
security, it seems useful to use the Forum as the (public) venue to help
explain and understand the opposition to the variants of 1, and understand
whether the challenges faced are unique to a particular CA (and thus less
likely to be considered blocking, if the overall benefit is greater), or
whether they're shared by the industry (and thus require more discussion
and creative solution taking)

That's why it's important to understand why reducing the validity time to
27 months, across the board, is problematic, from a CAs perspective.


> Regardless, if there are things we need to change, let’s start moving out
> on making the changes sooner rather than later and leave the current
> validity period options unchanged.
>
> - Start making SCTs mandatory in DV (or in all certs with validity period
> of over 27 months)
>

While I appreciate this enthusiasm, I haven't seen any suggestions from CAs
on how to actually address the problems previously identified. While I am
and continue to be an ardent supporter of CT, when phrased like this, it's
a bit like saying "Start making everything fair" - which is a very loaded
statement, and requires unpacking what does "fair" mean and what is
"everything".

To that end, since you've brought it up before, I would encourage you to
think about how to quantify the "mandatory" from an audit perspective, and
how to determine what logs SCTs must come from. Please note, the log list
does change over time, and logs can and will be removed - in fact, we'll be
announcing something on ct-policy@ shortly to that effect.

If this is a topic you're passionate about, and I suspect you are, it may
be useful revisiting the past threads on this topic, and seeing if you can
put a ballot that addresses the concerns. However, it may be worth
considering that, at Google, we have yet to find what we believe is an
acceptable, consistent, and fair policy for mandating this, given the state
of the ecosystem - which is why we're working hard to improve and diversify
it.


> - Allow short lived certs to omit OCSP/CDP because nobody checks them
> anyway
>

Are you suggesting we revisit Ballot 153? I don't believe there's been any
new contributions to suggest the result would be any different.


> - Encourage the move to ECC-384 or RSA-4096, or whatever security changes
> you see coming
>

You're not the only CA that has brought this up, and I admittedly gave
responses in person rather than on the list. I think this line of thinking
is dangerous and short-sighted, though I appreciate that it's trying to be
forward thinking. When you consider the SHA-1 problem, and why it's been a
persistent thorn, it becomes clear that the reason for it is the inability
to express simultaneously the 'old' and the 'new' thing. That is, a
certificate has either SHA-1 or SHA-2, but not both. Past efforts (from
other CAs) to improve this has failed. Perhaps this is something GlobalSign
can invest its engineering resources on, to attempt to solve.

Similarly, parts of the SHA-1 problem relate to CAs' communications to
their customers. While I realize you can't change what another CA says to
their customers, perhaps this is something GlobalSign can investigate and
explore and propose solutions for.

Another part of the SHA-1 problem relates to legacy systems, and their
support for limited cryptographic options. There are no doubt opportunities
to improve the ecosystem there, and no doubt GlobalSign can make valuable
contributions to this space.

Finally, we also need to consider the "enterprise root" problem - mixing
public trust anchors and private use cases, unfortunately with different
change/release cycles.

The reason I highlight all of these is that any transition to security
changes - such as ECC-384 or RSA-4096, will inevitably suffer from the same
problems, much as we saw with the transition from MD5, the transition from
SHA-1, and the transition from RSA-1024. While browsers continue to try to
adapt new strategies to improve this transition, there remains a whole
unexplored field for CAs to contribute to. I want to encourage and exhort
you to revisit the systemic challenges the industry has faced, and to see
what contributions you can make, either as an individual CA, or to the
Forum at large.

Ultimately, if these are topics you're passionate about, I hope you'll
explore proposing solutions for them. However, just because these are also
challenges we as an industry need to solve, it shouldn't prevent or
discourage us from solving the problems faced with long lived certificates.
So while much of this email might seem 'off-topic' to the thread at hand,
my hope is that it meaningfully addresses your (unrelated) concerns, so
that you can see why there is value in exploring this issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160330/b1a27fba/attachment.html