[cabfpub] SHA-1 Collision Found

Eric Mill eric at konklone.com
Fri Feb 24 16:38:44 UTC 2017

On Fri, Feb 24, 2017 at 10:46 AM, philliph at comodo.com <philliph at comodo.com>

> On Feb 23, 2017, at 11:31 PM, Eric Mill <eric at konklone.com> wrote:
> On Thu, Feb 23, 2017 at 10:54 PM, Phillip Hallam-Baker via Public <
> public at cabforum.org> wrote:
>> Things have to break before some people will act. Which is why I consider
>> the proposal to further reduce validity intervals to provide more
>> procrastination time positively harmful.
> To restate this, you're saying that it's better to keep long-lived certs
> around, so that the heightened damage their misissuance would do will
> increase the motivation of CAs/browsers to deprecate weaker algorithms.
> I think that's a very difficult stance to defend. Holding one security
> feature hostage to spur support for another doesn't seem likely to produce
> security benefits, either in this case or the general case.
> You are misrepresenting what I am saying. Do not put words in my mouth
> again. You do not speak for me. Only I speak for me.
> Is that totally clear?

It's clear, but not relevant. As best as I can tell, it is an accurate
representation of what you said, and nothing in the rest of your message
indicated otherwise.

> There is a WebPKI mechanism for dealing with certificates that were issued
> to people who should not have them. It is called revocation. It has been
> part of the PKIX specification from the very start.
> Revocation is required for much more than dealing with situations like
> DigiNotar. The vast majority of certificates that are revoked for cause
> were validly issued and then revoked because of actions by the subject like
> setting up a phishing site.
> If a browser provider decides not to support revocation as per the
> specification for the sake of shaving off a few milliseconds from their
> response, that is a choice they have made. They are the party that has
> decided to put their customers at risk. If they then go round pointing
> fingers at others for not mitigating the consequences of their decision,
> they are going to have the fingers pointed back to them.

This just comes across as bitterness. While you may think their calculus is
wrong, Chrome's rationale for dropping support for most end-entity
revocation has been clearly expressed and defended, in blog posts,
articles, and many mailing list posts here. Disagree, but don't suggest
it's bad faith -- and don't use it as an excuse to not budge on improving
the security of another aspect of the Web PKI.

In the PKIX architecture, the choice of certificate validity interval has
> no security consequences whatsoever. The only consequence of a longer or
> shorter validity interval is that the revocation infrastructure has to
> track certificate status for longer or shorter periods of time.

That's flatly wrong, and dangerous. Even if we were in a world where
revocation was fully enforced and hard-failed by all relying parties -- a
world we're so very far away from -- revocation requires that someone
*know* to revoke the certificate. You can only use revocation to mitigate a
known attack.

Expiration will remove a compromised certificate from being used in an
attack, whether or not any human is aware of the compromise.

And again, universal revocation support is a million miles away, and not
blocked by Chrome. Relying parties are composed of many more than browsers.
If you look at the ecosystem of non-browser relying parties -- libcurl,
countless libraries baked into programming languages, other custom
implementations -- go and compare support for enforcing expiration
(something you can do with a system call and primitive math operations)
with enforcing revocation (something that relies on a crazy web of remote
services and various failure modes). And make sure to compare whether
they're on by default, too. I would be shocked if you could find strong
revocation support used in practice in much of the non-browser world.

-- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170224/81cc30ef/attachment-0003.html>

More information about the Public mailing list