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

Ryan Sleevi sleevi at google.com
Fri Feb 10 16:03:46 UTC 2017

On Fri, Feb 10, 2017 at 2:32 AM, Christian Heutger via Public <
public at cabforum.org> wrote:

> > If the effort of replacing a certificate is equivalent to the effort of
> deploying a new version of Windows, then something is very wrong in that
> environment.
> I don’t talk about the effort of replacing a certificate. I talk about the
> driver behind limiting the lifetime and what would and primarly (as it’s
> the driver of this ballot) will happen on limiting the lifetime: Algorithm
> changes in 1 year.

Apologies for any miscommunication I may have contributed to, but I think
it's significant to address this:

The driver is not _just_ algorithm changes in a year. I fully and
wholeheartedly agree with you that, as an industry, that there are far
greater ecosystem challenges to such systems than we can reasonably
accomplish, and am not trying to suggest that in a years time (or less!) we
can move to a new algorithm.

Rather, the driver is that we set the _minimum_ time for any change in
practices to be 13 months. That's not to say that the _maximum_ for any
change takes 13 months - we still may and very likely will need to phase
some changes in over years.

However, as the Forum discusses changes to domain validation (Ballot
169/181/182 and the subsequent activities of the PAG), as it discusses CAA,
as the Forum evaluates precision around the scope of the Baseline
Requirements, these are all presently things which Relying Parties and
Subscribers - such as yourself - cannot currently expect to take place
sooner than 39 months.

Put differently, imagine that the validation practices presently practiced
by CAs are insecure (which, by the way, they unfortunately are). As a
customer, don't you feel better assured that you can have consistent
protection within a years time, as opposed to knowing that browsers and
relying parties will continue to accept 'bad' certificates for years?

If the answer is "The CAs should revoke those certificates," then again, as
a customer, are you prepared for the possibility that your CA may suddenly
make your site or server stop working - potentially even with no
notification (again, as we've seen some CAs do)?

In many ways, as a customer, this reduction helps protect you and your
users. It does so by ensuring that if any practice is deemed to be insecure
- whether it's something like an algorithm (which has a whole host of
ecosystem dependencies) or something like how the CA validates a
certificate request for your domain (which I'm sure you would only want
them to issue to you, and not a malicious attacker) - the damage is limited
to, at worst, a year.

However, you can only be assured that when Relying Party software (browsers
and libraries) actually enforce whatever the 'new' requirements are, making
sure they reject anything that uses the 'insecure' thing. However, browsers
and software can only enforce when the 'old' certificates are expired. This
is why it allows for a more rapid rotation.

The 'cost' to you, as a customer, is that you have to replace your
certificate once every 13 months, rather than once every 39 months.
However, hopefully you can see how that small cost - easily human
maintainable - comes with significantly more assurance that bad practices
will be stopped.

If it would help, if you'd like to share which CA or CAs you use, I'd be
happy to go through and find practices or issues that the CA has, which you
may not be aware of, and that would show why you and your customers are at
risk from their negligence or lack of care.

I propose, we shouldn’t go to an automated job as this conflicts with many
> security best practices as stated before. Simple it can be (the technical
> job itself), but should not be automated.

On this point, we must respectfully disagree. Across the spectrum of
Internet security - whether through the IETF, through the practices
software vendors practice (Apple, Microsoft, Google, Mozilla, among just a
few), or through what you see through modern web development - there's
universal agreement that regular security updates is a necessary thing.
This is why 'native' software is released regularly, on the order of days
(websites), weeks (applications in the Android and Apple App Stores), or
even within months (modern browsers). The lack of such routine and modern
updates is also why we have such Internet-crippling issues like Mirai (
https://en.wikipedia.org/wiki/Mirai_(malware) )

While I am unlikely to convince you that automation is the right answer,
despite the industry widely moving towards that and recognizing it as a
global "health" crisis, I do want to highlight that the opinion you're
advocating is not one that is widely shared within the industry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/89fbf666/attachment-0003.html>

More information about the Public mailing list