A mighty fortress is our PKI

[Peter Gutmann]

Paul Tiemann <paul.tiemann.usenet at gmail.com> writes:

>What if... Firefox (or other) could introduce a big new feature (safety
>controls) and ask you up front: "Do you want to be safer on the internet?"

The problem is that neither the browser vendor nor the users will see it like
this.  For the user its:

  "Do you want to have lots of sites that you normally use break?"

For the browser vendor its:

  "Do you want lots of your users to become frustrated when things stop
  working for them so that they switch to another browser?"

>Is there a good reason Firefox and other browsers shouldn't just get tough
>about [various sensible security measures]

None of the non-IE browsers can afford to do this because people will just
switch back to IE, and this has been observed in usability testing of proposed
browser security features by HCI researchers, as soon as anything goes wrong
the users switch back to IE, which allows pretty much anything through.  You
can even get IE as a plugin for other browsers (shudder) in order to "make
things work".

So you'd need to get the change made in IE (or at least get it made in such a
manner that fallback-to-IE is no longer an option).  I don't know what size
hammer you'd need to wield in order to get that done.

>This isn't true for all OCSP services.  For example, DigiCert's is not CRL
>based, so it really can say "Yes"

It can't say "yes" because the only thing OCSP can say is "not revoked" (and
in more general terms the only thing a blacklist can say is "not on the
blacklist").  "Not revoked" doesn't mean "valid", it just means "not in the
blacklist".

>and it really can say "Unknown" meaningfully.

"Unknown" is generally treated by client apps as "good", because if "revoked"
maps to "bad" then anything else must map to "good" (OCSP's muddle of non-
orthogonal response types is yet another perpetual motion-machine debate topic
among PKI people).

>It might not be hard to determine whose OCSP responders are CRL based and
>whose are database backed instead.

How can you do this?  Note that the various timestamps in OCSP responses are
as big a mess as the rest of OCSP, and can't be relied upon for any decision-
making.

More importantly, how can you possibly make any meaningful decisions in time-
critical protocols based on a system for which your responses can have come
from any time in the past?  As one security architect commented some years
ago, "learning in 80ms that the certificate was good as of a week ago and to
not hope for fresher information for another week seems of limited, if any,
utility to us or our customers".

The problem here is best seen by looking at certificates as capabilities.

1. You have an abitrary and unknown number of capabilities floating around out
   there.

2. Some of those capabilities (CA certs) have the ability to mint new
   capabilities.

2a. These capabilities can impersonate existing capabilities, and because of
    (1) the real issuer of the capabilities has no idea that they exist.

And the means of dealing with these unknown numbers of arbitraily-identified
capabilities is... a blacklist.

There's no way this can possibly, ever work.  It's the 1960s credit-card model
that Perry mentioned with the added twist that there are an unknown number of
cards and issuers involved, and some of the cards can invent new cards
whenever they feel like it.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com