From: Carl Ellison <cme@TIS.COM>
Date: Tue, 3 Oct 95 07:25:35 PDT
To: stewarts@ix.netcom.com
Subject: Re: Certificate proposal
In-Reply-To: <199510022148.OAA26396@ix7.ix.netcom.com>
Message-ID: <9510031421.AA18121@tis.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

>Date: Mon, 02 Oct 1995 14:48:26 -0700
>From: Bill Stewart <stewarts@ix.netcom.com>
>
>1) X.509 explicitly addresses Certificate Revocation Lists, though it
>	   isn't real precise about how they should be distributed, and the
>	   hierarchical approach isn't necessarily the best.  (Maybe put the 
>	   location of the preferred CRL for a key certificate in the cert itself?)

The whole issue of CRLs is on shaky ground with me.  I think it's gotten
lost in debates about how to distribute them offline (or perhaps via
e-mail) and have them work.

CRLs are like the old credit card or check stop lists which used to be at
every supermarket checkout station.  They aren't there any more.
Checkout stations are now on-line.

I see nothing wrong with having a "certificate" which says ``certificate
available online only at xxx@yyy.zzz''.

>3) Neither PGP nor X.509 (as documented in the RFC1422 and PKCS#6) have any
>	   mechanism for additional information other than cramming it into
>	   the username, but supposedly X.509 Version 3 includes something?

Yup -- and it's ugly.  It counts on a defined OBJECT ID to define the
attribute.  That means that if you want to say something about a person
("Boy, she's good looking!") you need to get someone tied to the OBJID
hierarchy to issue you a number.  If that number is low enough in the
tree, (is long enough), then you have the problem that no one knows
what it means.  For that matter, even numbers high in the tree are
unknown to me.  I've never seen a dictionary of OBJECT IDs.

>Binding a key to a text-string usually representing a person does give you
>the slack to use other mechanisms rather than wait for the release of
>/standard-name="Attribute Semantics Notation"/version=32769/ORG="International
>Slowness
>Organization"/Country=none/reliability=ExtremelyHighTrustUsThisTime/versionh
>istory=

Clearly.  One should never wait for ISO.  In fact, ISO should probably be
ignored from now on.  (Have you seen on-line Dilbert today?)

but back to the question: the slack to use other mechanisms is the weak
link I was talking about.  You are building a chain from attribute or
permission or authorization over to a person where one link (certificate)
is a steel link and the other (binding to person) is mercerized cotton.  If
you want to strengthen the second link, you have to do things like the
national ID card -- or restrict the second link to corporate use (the
current approach) -- or otherwise regiment the human body in physical
space.  By chaining directly from key to authorization, the human can be
anonymous in physical space while still being known in cyberspace.

The thing to avoid is the following:

>Make a determination in your own mind whether this key actually
>belongs to the person whom you think it belongs to, based on available
>evidence.  If you think it does, then based on your estimate of
>that person's integrity and competence in key management, answer
>the following question:

The only way to make that determination is to look at the text string and
the list of other people who have signed it -- to see if I think they might
know a different Bill Stewart from the person I know.  But then, since I
don't know Bill Stewart at all (except by postings), that's irrelevant to
me.  Therefore, I can not meet that test.  However, there is no reason for
me to reject your key as invalid.  What's invalid is the assumption that
there must be a relationship (or even a person) in physical space *before*
one can have a relationship (or a person) in cyberspace.

>For now, there do seem to be some kinds of attributes that would benefit from
>better representations than a human-name plus free-form text, such as
>"which application does the user want you to use this key for?" "how much
>should I
>trust the user's desire to have me use that key for that application?"
>"how do I get this key's owner to give me money?" "does the key-holder 
>have the authority to speak for a given organization/human/bank account?"

I prefer text.  I didn't say it had to be free form -- only that it had to
include free form so that I could say, from one human to another, something
which no one had anticipated and sign that.

If you want a machine to read it, you can use SMTP-style "tag: value".

The idea that machine readability requires binary transfer and/or ASN.1
encoding (e.g., OBJECT IDs) is ludicrous.

>If you look at Verisign's DNs, or the text in my PGP keys, you'll see various
>ugly attempts at this.

I looked at your keys, just now, and see a whole bunch of keys but no
statements like:

"this person is allowed to withdraw money from bank account 017123 of xxx"
or
"this person is a trusted co-conspirator in the group called Cypherpunks"
or
anything else useful to me.

I tried adding an informative UserID to my key on the MIT server -- and
it came out as my primary ID.  ...big mistake..


>And then there's "WHICH person named Bill Stewart does this key belong to?"

Exactly.  Back to my point: the fact that you're named ``Bill Stewart'' and
are a person is probably important to you -- but if I'm accepting your
e-check, I don't give a damn about either.  What I care about is whether
the signature on the e-check (ie., the public key) is certified by the
bank.  In checking that authorization (attribute), I don't need to refer to
a person's name.  That's an irrelevant step in the process, brought on by
the way X.509 and PGP both define certificates.

>For the latter, I'm interested in solutions other than "Social Security Number",
>"Citizen-Unit Nationalized ID Card Number", etc.

Amen!

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison      cme@tis.com    http://www.clark.net/pub/cme	   |
|Trusted Information Systems, Inc.   http://www.tis.com/                   |
|3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |
+--------------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMHFF/lQXJENzYr45AQEMwQP8Dw1yd4vHzYGY57FpwWlWxquJLHsS3LrJ
tVYEEpCXu7/lGcHVd2o2KDeZHZy7r6qiQ7zo5eayFQlIkRPYjBmRzuvADwLisR7D
NK7l6dFVY2fA+SAmLiMtwz2VzsByZGB8HYw3joc+erNfmAmjeOLyVeg5pTaP9Rnu
/Xb2SWE4d14=
=WVyj
-----END PGP SIGNATURE-----