1995-10-02 - Certificate proposal

Header Data

From: Carl Ellison <cme@TIS.COM>
To: cypherpunks@toad.com
Message Hash: a743240acfb98a9b6b90189f7d01400c884106296d317e19a1caf23feeeadf03
Message ID: <9510021553.AA13756@tis.com>
Reply To: N/A
UTC Datetime: 1995-10-02 15:57:01 UTC
Raw Date: Mon, 2 Oct 95 08:57:01 PDT

Raw message

From: Carl Ellison <cme@TIS.COM>
Date: Mon, 2 Oct 95 08:57:01 PDT
To: cypherpunks@toad.com
Subject: Certificate proposal
Message-ID: <9510021553.AA13756@tis.com>
MIME-Version: 1.0
Content-Type: text/plain


X.509 certificates are not totally bad.  Their structure contains lessons
for anyone designing a certificate structure.  [Raw X.509 does not imply a
hierarchy, I believe.  Steve Kent & Co. do.]

However, there are also some serious problems with X.509 certs, aside from
their use of ASN.1.

Perhaps the biggest problem is the use of a name -- a text string (or some
abortion like the DN which can be reduced to a text string) -- as the
anchor point.

This anchor point needs to be unique.  Since it is just a text string, that
means that the certificate authority needs to guarantee uniqueness.
However, it is also supposed to stand for a unique individual.  Since it is
not that individual's DNA sequence -- it is not testable.  There has to be
machinery set up outside the certificate definition for binding this text
string to its individual.


PGP certificates have the same problem.  In that case, it is an e-mail
address and name (by tradition) as the text string.  That needs to be bound
to some physical body.  If it is an e-mail name, there is some binding
enforced by whatever access mechanisms protect access to that e-mail
account.  However, that binding is weak and also outside the certificate


Let me propose an alternative unique name: the public key (or a good hash
of it).  The public key has an advantage over both X.509 and PGP names.
The binding between it and its human being is testable.  You can challenge
the human in question to sign something.

Assuming you use a public key as the unique name, you end up with a much
simplified certificate.  In fact, the notion of "certificate" may go away,
in the sense that the certificate binds a key to a person through a unique
name.  The person binds himself to his key, on challenge (or on any message

What remains is a need for attributes to be bound to a key.  For example,
someone might testify that E0414C79B5AF36750217BC1A57386478 has brown hair,
is balding and wears a pony tail, by signing a message to that effect.
Someone else might sign a message stating that the person who owns the
private key of 61E2DE7FCB9D7984E9C8048BA63221A2 is authorized to spend
money from bank account number 07123 of Provident Savings in Columbia MD.
That latter signator needs to be verified as authorized to make such an
assertion -- and you end up with a certification chain -- but it is not
hierarchical like X.509 and it is not web-of-trust -- it is relational.  It
is not a chain binding key to person but key's person to attribute or
permission.  It goes directly to what we need to accomplish without the
middleman -- without stopping at a person in the middle.

I realize that if you want to revoke a key, then it might help to have
bindings be to something other than the key.  That way, you can change keys
out from under the binding.  However, every method I've examined for
accomplishing that has security weaknesses.  The best method I've found yet
has a very long signature key -- used only rarely (e.g., when acquiring an
attribute-certificate worth a great deal; and signing more transient keys) --
and never normally revoked (or, if revoked, causing a widespread
re-establishment of bindings -- like when you lose your wallet today).


Current certificates are going down a fundamentally wrong path.  They are
trying to bind keys to people and let Society somehow bind attributes to
people -- but the latter binding is too weak to permit keys to be bound to
attributes or permissions.

The community will discover this, soon, but the farther we play along the
X.509 path (especially, but also the PGP path), the more inertia there will
be to overcome in trying to fix this problem.  I would therefore suggest
that the PGP development process address this issue now and continue the
established habit of taking the lead into sanity.

 - Carl

|Carl M. Ellison    cme@acm.org    http://www.clark.net/pub/cme		   |
|PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2  |
|  ``Officer, officer, arrest that man!  He's whistling a dirty song.''    |
+---------------------------------------------- Jean Ellison (aka Mother) -+

Version: 2.6.2