John,
We may be violently agreeing, depending on your reaction to
my more detailed proposal.
Bob,
You seem unhappy that only certain attributes were chosen for
use as DISTINGUISHED naming elements.
(5'2" - eyes of blue) may be distinguishing to you but is merely
descriptive, i.e. attributes to me.
No, although that certainly would have characterized my view as of a few
months ago. As a result of the recent discussion, I am now more
comfortable with the fact that the DIT has to be structured in SOME
fashion, and that there will inevitably be many compromises along the way.
I am mearely trying to find a way to include those DESCRIPTIVE
attributes, including Internet e-mail address, perhaps, within the
certificate where it can be accessed by those who don't have X.500
availalbe, and also where I can find it long after th message was sent,
assuming that I archived the sel-contained certificate along with the
message itself.
AttributeCertificates as proposed by X9.30 in fact do NOT contain
the holder's DN but a pointer (consisting of issuer DN, UID etc.)
to the holder's key certificate. (Note that one needs to use a
DN to lookup and validate the AttributeCertificate issuer as well)
I have a copy of X9.30, but haven't yet read it. If what you say is true,
it would seem to be a poor design, since it would seem to require that
an X.500 directory exist in order to support the capability. Including a DN
rather than a pointer to an issuer would have made it self-sufficient,
but maybe there is something I don't understand. (Quite likely, I'd say!)
X9.30 would allow you to construct any attribute or group any set
of attributes your heart desires, associate those SIGNED attributes
with a primary certificate, and manage them through an entirely
separate hierarchy. Included could be the "Bob Jueneman Trusted
Mail Address Attribute" which could be signed in (digital) blood
by the GTE Lawyers(tm).
Yes, I certainly think that I understand. In fact, my detailed proposal
message discussed having H&HS, MasterCard, Blockbusters, etc.
all sign various certificates. Whether these are all of my proposed X.509
v3 format or some other format is a detail. For uniformity, I would like to
see one common certificate type, and if there is something my
extended format can't handle, maybe we should add it.
You still haven't supplied me with a global reference key (DN)
and database (Directory) to find your foomail certificate and
authorizations so I can decide whether to talk to you or not !
Other than X.500, the only other way we have defined at present is to
exchange certificates on an end-to-end basis. Although that may be
a little cumbersome from an esthetic viewpoint as compared to having
a worldwide distributed directory, it is guaranteed to WORK. The
Directory may or may not. but I didn't mean to deprecate X.500
or suggest any alternate mechanism other than what we have already
discussed.
At the risk of belaboring the obvious, the end-to-end certificate
distribution scheme works as follows:
User 1: Does anyone out there have or know where I could buy a foo?
User 2: I might, and I might not. You didn't include your certificate,
so I don't know whether I want to talk to you or not. But my certificate
is blah. Send me an encrypted message telling me why you need a foo,
and I'll respond in kind if you include your certiifcate.
User 1: I see that you are one of my competitors for foo, so I don't think
I'll say much more.
User 2: At least we have each other's certificate now. Tell me if there
is anything else we could do that wouldn't involve foo.
Of course, what happens once the various certificates arrive at a user
is a "local matter". If the PEM implementation doesn't support some form
of a local database, they will spill out all over the floor. But the certificate
DO NOT have to be indexed by the DN locally. They could, but
storing them by nickname might be more convenient. I'm not building
PEM or mail UA software, so I don't care, but certainly they should
be stored somewhere. Maybe 80 column punched cards?
Bob