[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE: The Carl & Bob show



Lots of interesting comments from folks -- I won't try to respond to them
all.

But Phil Whittaker (or at least someone who often uses that name) said in
part:

>If the merchant is going to accept electronic credentials and
electronically signed purchase orders, I would hope that the merchant
accept only those credentials that it knows were issued by CAs using
sound business models, including adequate client registration and due
diligence.

>I would then expect that the merchant would either obtain from the
customer's real physical address from the customer's CA, and would
dispatch the sheriff to that address.

>In this instance, is the identity in the certificate not largely
irrelevant, or, more to the point, relevant only to the CA?  Is not a
global name-space in some ways completely beside the point, even for
X.509 certificates?

That is an interesting thought.  Obviously if people who "need" to know such
information could go to the CA and ask for it, the need to include lots of
personal information in a certificate would be lessened. On the other hand,
having to go to the CA for that information very often would be inefficient,
even if they maintained a easily accessible directory containing that
information.

In addition, including physical locality information (such as street
address) in a certificate does permit one very useful function -- it allows
a merchant to restrict delivery of valuable goods to the address specified
in the certificate, so someone can't steal your key and ask to have a
Ferrari shipped to some different address.

So if there is a need to have such physical address information available,
should it be in the certificate, in a relatively easily accessed directory,
or locked up on a CA's drawer somewhere? If the information is going to be
accessible and cross-referenced in a directory, then the privacy issue is
moot, so the only argument is one of efficiency in processing -- the
additional space in the certificate vs. the access time to retrieve it from
some directory.  In general, I would opt for including it in the directory
in such cases.

Another interesting thought is one that used to be debated back in the PEM
days, but I haven't heard argued much recently -- what is, or should be, the
relationship between the distinguished name in an X.509 certificate, and a
matching distinguished name in an X.500 directory (or the LDAP equivalent
thereof)?

When X.509 was first invented, its primary use was envisioned as
authenticating access to a directory by the user whose information was
associated with that DN.  If the certificate authenticated the user's
digital signature, the user was allowed to modify the contents of the
directory listing under that name, in order to post the color picture of his
dog, for example, and other presumably useful functions.

Now, obviously the DN in the directory didn't have to contain the user's
name -- it could have just been some obscure ID of some type.  BUT THAT
WOULD HAVE DEFEATED THE PURPOSE OF THE DIRECTORY, which was to provide a
convenient mechanism for looking up people's phone numbers, e-mail
addresses, etc., either by a direct read if you knew the person's name, or
by a browse if you didn't.

It is also the DIRECTORY which really imposes the requirement for a globally
unambiguous name, because you don't want to have to deal with the name
collision problem every time you search for someone -- it is just easier to
include the country, state, etc., information in order to limit the
searching, and to ensure that the other directory attributes, the payload,
are uniquely associated with the index, the DN.

Since X.509 came out of the directory work, the requirement for a DN in the
certificate was carried over, even though initially there weren't any
deployed directories to speak of in which to store certificates.  So when
the technical/legal community started looking at these concepts, and
figuring out how they could be used to support electronic commerce and other
functions, the requirement for global uniqueness was always in place, and it
seemed like a good idea to carry forward in order to limit confusion in the
age of the global village. I still think so.

Putting things back in directory speak, I would claim that are we are really
arguing about is the SCHEMA, which is something the X.500 folks haven't yet
solved either.

What kind of names/attributes are we going to use/allow/require to be in a
name, considering the tradeoffs involved in establishing both the accuracy
and uniqueness of those components?

Carl likes the idea of using the key (or a hash of the key) as the ID.
Obviously this would permit a very flat, and presumably efficient search
strategy.  But this strategy has some problems with it, in that the
relationship between a user and a key isn't one to one.  The person
possesses the key, the key doesn't "possess" the person, and it is easy to
give away the key. In addition, the person may have multiple keys, whereas
presumably the key doesn't belong to multiple people.

My house, on the other hand, doesn't possess me (although it sometimes seems
like it does), but it is strongly tied to me by sole occupancy -- an
attribute which changes slowly and with difficulty -- about 20,000 pounds of
difficulty the last time I moved. And because my house doesn't have wheels,
my address also changes slowly and with difficulty.

If someone really, really, wanted to have a unique numeric ID that wouldn't
by itself reveal anything at all about the user, then some work I did a
number of years ago on trying to build a global B3 system might be relevant.
 The requirements for a B3 computer system include access controls which
either allow OR DENY access to any named individual or group of individuals.
 Now, how can you deny access to someone by name in a global network unless
you have a globally unique ID? And furthermore, what happens to your access
controls if someone changes their name.  If you are mad at her, it doesn't
matter whether she uses the name Mrs. William Clinton, or Hillary Rodman,
you still don't want her to gain access to your files.

The only way I could think of to reasonably solve that problem was to use a
message digest of a canonical form of the person's birth certificate.  No
matter how many times they change their names, move around the country, etc,
even born-again Christians only have one legitimate birth certificate. By
combining the mother's maiden name, the time, date and place of birth, and
the baby's recorded birth name via an SHA-1 message digest, a 140-bit ID is
created that has an infinitesimally small probability of ever being
duplicated, even across the eons, it is permanently associated with the
user, and yet by itself it reveals nothing at all about the user.  (It is
also the ultimately user-unfriendly search index.)

If a CA demanded the user's birth certificate (and proof that the birth
certificate was really that of the user), a unique ID could be established
that would not depend on regional naming authorities.

For what it's worth.

Bob


                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                   

Follow-Ups: