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

[Ryan Sleevi]

On Fri, Feb 10, 2017 at 10:25 AM, Christian Heutger <ch at psw.net> wrote:

> > 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.
>
>
>
> I don’t believe, such changes need to wait 39 months. Why not introduce
> them to new certs from date x?
>

That's actually the crux of the issue here :)

That is, we want (and do) do exactly that - new certificates get introduced.

The problem is that we have a large body of certificates using the 'old
rules', and those certificates will stay valid for 39 months. That means
browsers/software can't actually enforce those rules, since enforcing those
rules means rejecting the 'old' (but still valid) certificates.

The consequence of this is that, without enforcement, we're simply relying
on CAs to do the right things and not mess up. And unfortunately, many CAs
aren't doing the right thing, or they are messing up frequently. And
because even a single CA messing up puts the whole of the Internet at risk,
browsers really want to be able to enforce the new rules (AFTER they've
been phased in), and reject any certificate that does the 'old' thing.

Right now, it generally takes about 4 years for any change to become
enforceable, at a minimum. However, because some CAs were able to issue 10
year certificates (~pre 2014) or 5 year certificates (~pre 2016), there are
a LOT of old certificates out there, so many of the improvements we're
making, we're just having to trust that CAs are taking them seriously. And,
unfortunately, we keep finding out that CAs are not taking them seriously,
and that makes everyone (... except that CA, and perhaps their customers)
sad.

Indeed, if browsers aren't enforcing the rules, not following the rules can
be a competitive advantage for CAs. That is, they can make more money by
doing the wrong thing, even though its forbidden, and thus it's very hard
to convince them to do the right thing, the thing that they agreed to. By
being able to enforce it in software, we help CAs resist the temptation to
put the Internet at risk.


> > 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)?
>
>
>
> If the CA doesn’t give me a deadline to replace because of bad validation,
> it’s the longest time, I was with this CA.
>

I'm not sure I understand?


> If any practice is insecure, revoke, that’s one of the reasons for
> revocation. Why wait one year or is the final proposement certificates for
> hours or minutes, revoke and it’s done.
>

Odds are, whatever certificates you currently have, they were validated
with a method prior to Ballot 169. As Ballot 169 significantly changed the
rules for validation, to improve security, we can logically conclude that
your certificates were issued with a practice that's insecure.

Should all of your certificates be revoked then? Of course not.

The *Online Certificate Status Protocol* (*OCSP*) is an Internet protocol
> <https://en.wikipedia.org/wiki/Internet_protocol> used for obtaining the
> revocation status of an X.509 <https://en.wikipedia.org/wiki/X.509> digital
> certificate <https://en.wikipedia.org/wiki/Digital_certificate>. ?! It’s
> the way to reject anything insecure by demanding revocation, when status
> can be checked via OCSP. If you disalike OCSP, you want to have CT logs for
> all certs in future. Then set the status in the CT log and check against
> that?
>

CT is not a revocation method. It doesn't address the same set of problems.

However, even if revocation worked (and it doesn't), you still have the set
of issues I highlighted in
https://cabforum.org/pipermail/public/2017-February/009526.html regarding
warning fatigue. If you haven't heard that phrase before, you can learn
more about it at https://en.wikipedia.org/wiki/Alarm_fatigue . The basic
idea is that the more warnings a system makes, the more likely they are to
be ignored. It's a very primal part of human cognition.

So things which drastically increase the set of warnings - such as revoking
all the certificates done with something insecure (like pre-169
validation), unfortunately drastically increases the number of false alarms
(relative to the user's perceived risk), and the less secure the whole
ecosystem becomes.


> Updates are okay, but managed patch management (see ISO 27001 clause
> A.12.6.1 and best practice A.12.6.1 in ISO 27002).
>

Certificate updates are just patching the 'old' certificate with the 'new'
standards. That is, it's an update, it's patch management. Luckily,
applying patches once a year is something you're no doubt familiar with, so
it's likely not an issue.


> Mirai is a lack of awareness of users (no passwords, no updates at all),
> which is a problem of the consumer world, we talk about automation for
> enterprises or minimum users, which are able to run web, ... servers and
> may harm end users security while browsing the web and no noob installing a
> home router or camera without knowing anything about what he is doing
> there. For this ones, autoupdate may be a solution, however awareness is
> better.
>

Unfortunately, the understanding of Mirai isn't quite accurate - many of
the devices were compromised due to firmware issues, for which updates are
available, but of course, few have installed. I was trying to make the
point that not applying updates puts the Internet at risk. It sounds like
you agree with me, and so I'm trying to convince you that replacing
certificates once every 13 months is just another type of update.


> > 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.
>
>
>
> Depending on the target group I agree or disagree. Automatism, especially
> necessary required one, isn’t the solution for everything,
>

Thankfully, this proposal is only focused on 13 month certificates, and
automation is not required for that, and it sounds like you agree with
that. Does that hopefully address your concern about this specific proposal
- of limiting certificates to (effectively) 13 months?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/b70ebf89/attachment-0003.html>