[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Identity certification (was Re: ANNOUNCEMENT: SPKI ...)
I'm glad we're discussing this topic once again, in a more calm
form this time. [The last time was on pem-dev, several years ago, when I
first found out I couldn't use PEM because it required a DN and I couldn't
get anyone to define a DN.] The lack of calmness last time was almost
certainly my fault, BTW. I was annoyed at that frustration. I apologize,
a bit belatedly, to you and Steve Kent.
At 15:34 2/26/96, Jueneman@gte.com wrote:
>Yes, that is certainly true for many applications. I correspond with many
>people I have never met and probably never will meet, as far away as
>At that level, it is like arguing whether William Shakespeare or someone else
>wrote a particular sonnet. Who really cares (unless you want to put a rose on
>his gravestone) -- he wasn't even consistent in the way he spelled his name
>himself. But his thought patters, word usage, and many other subtle clues
>you to tell with reasonable certainly that the same author wrote most if not
>all of the different works ascribed to him.
With digital signatures, we have a much better link to the authorship of
something than just word choice. As long as the same key is used for
signing what we read, that key *is* the best identity of the author.
It is globally unique and it is tied to the author more strongly than
a fingerprint -- since it is tied to something he posesses [the private key]
*and* something he knows [a PIN or passphrase].
If you want to call that key [or its hash] a kind of distinguished name,
>So in that sense we don't need a "real" identity, at least at first -- we just
>need assured continuity. (No one knows you're a dog on the Internet. Until the
>first date!) The same is (almost) true for some banking and credit card
>applications -- no one cares what your name really is, so long as you keep
>paying the bills. But if you stop paying, then they ARE going to care, and
>is when life starts to get a little messy.
Ah - but it's not everyone who cares.
To care, you have to have extended me credit. That's a risk. If you
extended credit via a bank or credit card issuer, then it is the bank or
card issuer who needs to know who I am and where to find me. You, the
person accepting my card, don't need to know. You just need to get *your*
payment. I can imagine structures with physical accountability in which
there is nowhere a central database linking keys to human bodies. Each bank
could generate its own linkages.
More generally, if you're taking a risk, you need to decide what kind of
binding you want between a key and prosecutability of some human body.
>And if you want to extend some of these applications a little further to
>include business letters, then identity (at least the kind of identity you
>derive from your association with an organization) does matter. And if you
>extend it further yet, to the point of acting as a purchasing agent or a
>contracting officer, then your identity matters a lot more.
If you sign a business letter or P.O. in such a way as to act for the
corporation, you need your key signed by the corporation. That certificate
should also express what kind of authority you have been granted: permission
to spend up to $500 on your own signature, permission to issue press
releases, permission to open negotiations for purchase of other companies,
.... You can do that by role, by specific permission, or whatever, and all of
those possibilities are available in the structure I propose.
>You could validly claim that it isn't the identity that is so important, but
>rather the role you play. I wouldn't argue with you there, but conventionally
>we sign such documents with our names, and if we have a formal title or role,
>with that title or role.
Yes -- I realize that we conventionally use our given names for these functions
but I believe that the X.509 effort is an inappropriate carry-over of that
convention into a new age where it's no longer needed. In this new age,
we have digital signatures and pseudonyms. That doesn't make us any less
people or any less trustworthy. It just means that we don't rely on old
The way I usually describe the difference between identity certs and the ones
I propose is as follows:
1. An identity cert gives you a strong binding [via digital signature]
between a key and a text string [= Distinguished Name]. There is some less
strong binding between that text string and a human being. The CA policy
tries to make that strong, but compared to cryptographic strength, it's not
strong. There is an even more nebulous binding between the human being and
permission to act for the corporation, or whatever.
The identity cert lets a human assert a permission you, the
verifier, can't check but it lets you file a complaint if you've been
misled and identify the human body who misled you, so that he might be
2. A generalized cert gives you a strong binding between a permission and
the key employed. [Imagine having security clearance operate as in (1) above!]
Once you have the permission certified, you don't need the path to the
human body, in most cases. This one, direct link -- bound cryptographically
-- is far stronger than the 2 or 3 hop chain of bindings in (1), in which
only the first link is cryptographically strong.
>Would I be correct that it isn't the existance of a Distinguished name in a
>certificate that bothers you as much as the content?
No, it's the existence. I've been a developer/designer for 30 years and
I abhor unnecessary work/fields/code/etc. The DN is unnecessary -- and it
got in my way besides. Therefore, I am opposed to the existence of the DN
-- not to its particular content.
>Of course if you use that certificate to sign the deed to your house the bank
>may not accept it, but so what -- use another certificate for such purposes.
What the bank wants me to sign with is up to the bank. I don't envision
a world in which everyone is required to honor every Certifying-key.
Could that be one of the basic disconnects between the two of us, these
|Carl M. Ellison firstname.lastname@example.org http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430 http://www.cybercash.com/ |
|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091 Tel: (703) 620-4200 |