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

[Ryan Sleevi]

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

> > 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.
>
>
>
> So the CAs can break the rules now for one year after another instead of
> many years in row? I can’t really follow that arguement.
>

I think the misunderstanding is that I'm not saying it's OK for CAs to
break the rules - it never is - but shorter validity times help reduce the
time to enforce the rules. By enforcing the rules, any breaking of the rules
1) Is detected sooner
2) Doesn't have any advantage, because the software will reject it.

Under today's world, so long as you don't get caught and called out, CAs
can find there are economic incentives to breaking the rules, as long as
the software accepts it.

If there are failures, revocation is required and reissue needed, if the
> validity period is 1, 3, 5 or 10 years. BR requirement failures are
> scanable, there are services out there doing that. CT already gives
> additional control. If you introduce new trusted validation rules, should
> be a one time thing and nothing done from year to year.
>

Unfortunately, we all need to learn from our mistakes, and as CAs make
mistakes with the validation rules, we need to adjust them to make sure
we've taken steps to prevent them. That is, there's a class of mistakes
that result from CAs intentionally violating the rules, but there's also a
class of mistakes that result from CAs misunderstanding the rules. The
second time can happen when things are unclear, or when the CA is not
acting in the interest of the ecosystem, and thus "looking for loopholes"
(much like you might find someone who is looking to reduce their taxes to
take advantage of every possible loophole, since that's the most personally
advantageous, even if it's not societally advantages)


> If I’m customer of a CA revoking certificates without notification and
> replacement deadline, I no longer will order any more certs from this CA.
>

Ah, I see. Unfortunately, this argument - that it's the CA's responsibility
to revoke - only works if revocation works. But even then - in a world
where revocation works - we still have many of the issues I've raised.

The messages in
https://cabforum.org/pipermail/public/2017-February/009471.html and
https://cabforum.org/pipermail/public/2017-February/009475.html expand upon
that.


> ... you say yourself here „relative tot he user’s perceived risk“, so I
> don’t see the need to revoke all and immediate. Revoke the real mis-issues,
> for other urgent situations give deadlines, so there are real not ignorable
> warnings for the ones without reaction or really harming security, all
> others should be done better in future.
>

I think the misunderstanding for many of the points raised in the part that
I snipped is that we don't have a way to determine what was "really"
misissued and what was simply done with a less secure method. Well, we
don't have any way short of relying on the CA. And the problem is this
threat model is that, when a misissuance happens, we don't really trust the
CA.

I think a good example of this - where the CA didn't understand or
downplayed the scope of the issue - might be found with an event that
happened two years ago. You can read Google's initial remarks
https://security.googleblog.com/2015/09/improved-digital-certificate-security.html
, but the more important part is with the follow-up, in
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html

And while that might seem like a one-off, it currently seems like we're
already seeing a repeat of the issues with the same CA, as you can see in
the following three messages:
-
https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ
-
https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/chC7tXDgCQAJ
-
https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/KrDBAoDNDgAJ

As you can see, when something 'bad' happens, relying on the CA to
responsibly detect and disclose the issues is a challenge, especially when
all the incentives of the ecosystem mean that there are benefits to be had
if the CA hides or misrepresents misissued certificates, since then they
can avoid revoking those certificates without warning or timeline, which
then, as you note, will cause customers to change CAs.


> As responded to Gervase before, I don’t talk about the certificate
> updates, I talk about rolling out new algorithms or other major changes,
> which require infrastructural changes to the environment, which can’t be
> done in one year.
>

Sure. But to be clear and repeat: This ballot is only about making
certificate updates more frequent, so that regardless of the change - new
algorithms that take a long time to phase in, or smaller security
improvements that can be done in months - consistently take effect within
13 months of their actual effective date.

I'm not saying we're going to change everything every year. Just that a
year is the longest reasonable time to go without 'patching' a bug or being
able to make sure it's fixed.


> No, it doesn’t as automatism is only a side-effect discussed with this
> Ballot. The primary focus are the 13 months to phase out anything faster
> and moving forward faster and I see other methods for urgent issues the
> right solution instead of limiting the lifetime and also not to just 13
> months, for evolution I believe 39 months are a good timeframe, followable
> by enterprises, as a compromise I would also vote (however, I can’t vote)
> for 27 months, but less is unrealistic.
>

You've misunderstood the point of this ballot then. It doesn't mean
everything will be phased out in a year or less. It simply means that
browsers can begin enforcing those changes - whatever they are - within a
year of them being required. In the time between "when it's required" and
"when it's enforced", the only protection you have is assuming that no CA,
anywhere, that's trusted, will make a mistake. And that's a big risk - too
big for the ecosystem - since mistakes happen, especially the more CAs you
have, and doubly so when there are economic incentives to intentionally
"make mistakes" if you can make money from it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/4367eb3a/attachment-0003.html>