[Cryptography] Certificates and PKI

Nico Williams nico at cryptonector.com
Tue Dec 23 16:00:37 EST 2014

On Tue, Dec 23, 2014 at 05:49:40PM +0000, Ben Laurie wrote:
> On 23 December 2014 at 16:16, Nico Williams <nico at cryptonector.com> wrote:
> > On Tue, Dec 23, 2014 at 11:22:43AM +0000, Ben Laurie wrote:
> >> On 23 December 2014 at 03:38, Nico Williams <nico at cryptonector.com> wrote:
> >> > Then there's naming.  x.500 naming is just. such. a. disaster.
> >> >
> >> > People -perhaps every literate human with an Internet connection- are
> >> > conversant with domainnames.
> >>
> >> That is patently untrue - if they were, phishing would be a whole lot
> >> harder than it is.
> >
> > That's a different problem that PKIX naming is also susceptible to
> > (probably any naming scheme where "labels" of any sort are used would
> > be).
> Sure, but that does not alter the point that most people do not
> understand DNS, PKIX naming, or any other naming scheme we use.

People are definitely conversant with domainnames: they know how to read
them, how to type the ones they know well enough, they know how to
communicate these verbally, and so on.

[Phishing is orthogonal to DNS: any naming scheme would be subject to
 phishing, even plain old brick-n-mortar store signs are.]

In fact, domainnames are all that users ever see as far as naming of
services -- that and URLs and e-mail addresses containing domainnames.

Users never see PKIX names without drilling into the certificate used by
a service.  In that case the first thing the user see's is the service's
domainname, and then the user is left on their own as far as making
heads or tails of the certificate and its chain.  Even the best PKIX
GUIs can't actually say much more than "the chain validates to some
trust anchor and none of the certificates in it are expired".  With CT
they can also say "and the CAs participate in CT auditing".  The user
has no clue though if the service's owners really wanted to use that
cert and the corresponding private key.  No clue.

PKIX naming lacks even a decent textual form!  Much less a canonical
one.  (Really, I'm not joking.  See RFC4514.)  PKIX names can't reliably
be typed in.  Even in a GUI, displaying PKIX names is non-trivial.

x.400/x.500 naming is useless without conventions and naming constraints
that don't exist (and can't be deployed), and some relation to e-mail
addresses and service names that *also* don't exist in the wild.  X.400
addressing was not that uncommon in the 90s; I remember HP OpenMail.
Even in the 90s it was ironic that to exchange e-mail with the rest of
the world one needed gateways to SMTP and RFC822 addressing (sendmail
rewrite rules for this were something else, and if you've not seen them,
then count yourself lucky).

But since the web -since HTTP and the web- there's no popular service
that can even be named with a user-visible x.500 name.

DNS naming has naming conventions and rigid name constraints, and had
them from day 1.

There's no question as to which is superior.  And nothing is being
proposed to replace DNS naming, while DNS becomes more entrenched every
day.  We could conceivably replace DNS.  We can't conceivably replace
DNS-style domain naming.

And it can't get much simpler than DNS domain naming either.  If users
can't handle that ever, well, we're just going to have to be app-
centric, and goodbye to the Web.  Since the web isn't going away, I
submit that users are managing just fine (yes, yes, phishing, but see

> > DNSSEC/DANE has a simpler last mile problem than the problems that
> > plague PKIX as-deployed in the WebPKI.  The future is DNSSEC's.
> Is this like the future being IPv6's? :-)

No.  I fully expect to continue to toast to the universal deployment of
the latter for a long time.  DNSSEC deployment has much better universal
deployment prospects.  Particularly when we consider DANE stapling.

> The last mile problem is sufficiently problematic currently that we
> cannot realistically rely on DNSSEC (i.e. we would effectively


> disenfranchise a significant fraction of users). Obviously this is not
> ideal, but its where we are.

A migration path is clear.  Eventually critical mass will be reached.


More information about the cryptography mailing list