-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,03
MIC-Info: RSA-MD5,RSA,h3qGCzlzD9QovMEmm+qI48hekvW2+n47OleUkirWRGo
CGuL5GyWeauViFYn5d0yeySfvxJQgPumOPRVxFfBuvAyAokAo0b142LWC9G7e/e1
PSicj2YotlcsrSZ1gD9sZ
Bob,
This indeed interesting; your two messages do indeed seem to have
different thrusts. I've included both and will tryto respond to the
ideas here; it will be interesting to see how coherent the whole is
when I finish.
Reply-To: Jueneman(_at_)gte(_dot_)com
From: jueneman%wotan(_at_)gte(_dot_)com
To: pem-dev(_at_)tis(_dot_)com
Date: Fri, 04 Feb 94 18:19:58 EST
Subject: Re: Are X.500 names feasible?
Steve, Theodore, Peter, Donald, Carl, Steve, Tom, Anish, Christian, John,
Russ, Ned, William, et al:
It must be late on a Friday afternoon, for this thread is going downhill
rapidly! Before we all go totally bonkers, let's see if we can restore a
semblence of sanity and reason to the discussion.
Yes, Steve Crocker, I agree that there are some very serious problems
with the current structure of X.509, in particular its inability to handle
any user-related attributes except by stuffing them into a DN.
Yes, Christian and others, I will accept that there may be serious
difficulties with the existing IMPLEMENTATIONS of X.500, and in
particular the alleged difficulty of adding attributes to the structure,
conveniently and globally. In particular, I accept that adding attributes
which are supposed to be used as a part of a DN may continue to
be troublesome, becasue it impacts the directory schema. (I take this
on faith, having no personal experience in trying to do so.)
No, EMPHATICALLY NO, Steve Crocker, I do NOT agree that we should
even consider the use of Internet e-mail names in place of some form
of distinguished name in the X.509 certificate, at least if we every hope
to have this system grow up and be useful for something more than
adolescents to use to communicate their private giggles and conspiracies
securely across the Internet.
One of the tricky challenges in dealing with Internet issues is
gauging how fast things will grow, get adopted, etc. PEM has been
slow to take off. Despite appearances, I've been fairly passive about
the design of PEM. If it had all taken off like gangbusters, I'd have
no objection. However, it seems pretty clear that it's not taking off
very rapidly.
Is it too early to tell? Am I reacting to quickly? Shall we stay the
course? I'm afraid everything we know about the Internet says
otherwise. If there isn't a way to make use of a service fairly
easily within the existing framework, it's time to re-examine the design.
Examination of PEM reveals multiple problems. Christian listed his
analysis. Others have stated theirs. The use of X.500 names keeps
coming to the top of the list.
That does NOT mean that I think we should accept the limitations imposed
by the current X.520 attributes, attribute syntax definitions, and
directory schema. We need to do our thing, and let the X.500 people
do their thing, and hopefully we will eventually converge. But one of the
primary reasons for having layered architectures to to avoid having to
change everything all at once, for that becomes impossible.
Sounds good, and may serve some purposes, but doesn't go far enough.
Read on.
I have been consistant (to the point of being irritatingly dogmatic,
I'm sure) in urging two desiderata for naming criteria for digital
signature certificates:
Good. This is a very useful exercise.
1. The names created, assigned, or "discovered" must be sufficiently
well- qualified by geopolitical, organizational, or other
implicit or explicit "naming authorities" as to ensure that the
entity that is so named is unambiguously identified. (Note that
unambiguously identified does not mean uniquely identified, for
individuals will typically have multiple names that are distinct,
but which refer to the same metaphysical person, but perhaps in
different locations or in different roles. Naming is generally a
many-to-one mapping.)
Well, this is a broad statement, and I'm not sure it's precise enough
to tell whether we could agree on the general statement, but disagree
on its application. Test question: In what way would the use of email
names fail to meet this criterion?
2. The distinguished names that are so created should contain a
sufficient amount of physical universe descriptive information as
to allow the legal service of process against that person to
compel performance or seek redress, at least if this
distinguished name is to be used in a certificate is to be used
for any nontrivial purpose. In plain language, I want to know
where to send the sheriff if I need to sue you. I can't send the
the posse out into cyberspace, for the Force be not with me. And
I don't want to have to subpoena the records of CompuServe, etc.,
to find this information, for I think that would cause more
privacy harm than social good.
Ah. Now we're cooking. And in plain language, I think this is plain
wrong. It's perfectly fine to want to know this much about a person,
but that doesn't mean that the PEM certificate hierarchy should
provide it to you.
The Internet makes progress incrementally. PEM, RIPEM and PGP all
provide a mechanism for protecting the confidentiality, authenticity
and integrity of email. However, you're asking that PEM also give you
a entirely new naming infrastructure, and you're asking that PEM
messages give you a much more rigorous foundation for legal actions.
That goes way too far. Those are major social changes, not pure
technical innovations. The inclusion of these social changes is not
much different from the Government's Clipper initiative: We'll give
you high grade cryptography, but we insist on imposing certain
policies on you in exchange for this gift.
There are other ways to achieve your goals. One that comes to mind is
to shift the focus toward the use of the existing infrastructure of
email addresses, and then build separate directory mechanisms for
listing the legal and other descriptive information you have in mind.
This approach also satisfies your criterion above of separating the
issues and making incremental changes.
Over and above those two requirements, it would be "nice" if the DN
were more or less human readable and not deliberately misleading, but
that is primarily a UA presentation function.
Nice words, but too pat. The information necessary to present the DN
in a readable fashion may not be present if the OID is new. The
appearance of unregistered OIDs is what triggered this thread. And
this is the smallest of the various problems.
So far as I can tell, there isn't any way to build "nice" UAs in the
sense that you have in mind. Somehow, the DN information has to be
entered into local stores, caches, mail alias files or directories.
Somehow users have to specify who they want to send mail to. DNs are
broad and complex, and the rules for them are vague. It's not just a
matter of whipping up nice graphical interfaces; the information
necessary to support nice UAs just isn't available.
There's also been lots of talk about the Directory. I'm never sure
whether the Directory is an abstract idea or whether it's intended to
refer to an actual global directory service that will be built real
soon now. I don't think the latter is very likely in the near future.
And even if there were an approximation of it in the near future, I
don't foresee requiring access to it as an intimate part of operating
a mail user agent.
Further, because the more positively you attribute an utterance to me,
the more difficult time I (or my company) may have in repudiating
something that I might wish that I hadn't said or wasn't authorized to
say, I would like to have some means (PCA policy statment or caveat in
the certificate) of saying what I agree to be bound to and what is
considered to be excessive -- like requiring two signatures on a check
for more than $1000.
As far as I'm concerned, that falls very far outside the bounds of the
PEM system. Some other set of caveats will have to be used to provide
that level of assurance.
Those authorization and/or caveat attributes are absolutely going to
be required, probably sooner than later, if digital signatures are
going to take off in any meaningful way, IMHO. However, although those
attributes need to be included in the certificate so that they can be
signed by a Certification Authority as being authorized, they DO NOT
need to be, and probably shouldn't be, included in the Distinguished
Name, except as necessary to uniquely identify a title or role.
Well, I disagree that these attributes are needed before digital
signatures going to take off in any meaningful way. There are *lots*
of uses of digital signatures. The system of attributes you want
sounds very useful for some purposes, but the way to support that is
to separate the attributes and build up other means of dealing with
them. In this sense I agree with the latter part of your paragraph.
Similarly, in order to help cope with the problem of readily
distinguishing between two sufficiently well-qualified but
insufficiently descriptive DN, it would be quite useful to add
additional information, e.g., the 5' 2" good looking blond, or the Bob
Jueneman who is NOT the horse thief, to the information in the
directory, and potentially to the certificate, but as attributes that
are not part of the DN.
An unending problem. The more time we spend on this, the less
progress we make.
Finally, no one has yet advanced a compelling argument as to why the
most useful content of the X.509 has to be in Distinguished Name
format in any case, nor what the correlation should be between that DN
and the DN (any DN) in the X.500 directory itself. No other X.500
attribute that I am aware of contains a DN itself (except for the
obvious cases of aliases and seeAlsos, etc.), so this seems rather
strange.
I'm not at all sure of what you're saying here. Try again.
Granted that it may be useful to impose an OID structure and ASN.1
syntax description on the elements of the name contained within the
certificate, so that we can easily tell the difference between an
organization name and a street address, why does the name in the
certificate have to be a DISTINGUISHED name? (I am assuming that it is
generally desirable if not required for a DN to define a minimal
spanning tree, rather than being burdened with unnecessary leaf nodes.
But this is not necessarily true for the information content of a
certificate.)
I've lost you. My ground rule for discussion of PEM and certificates
is that it has to make sense independent of X.500 and any general
discussion of directories. (This is *not* the same as saying it can't
be consistent with X.500 and directories; it just has to stand on its
own.) With this ground rule, you'll understand my confusion because a
certificate binds a DN to a key. Or, put another way, a certificate
has an identifier" and a key. The identifier is called a "distinguished
name." Call it anything else you like; its properties are the same.
It's simply the identifier that's bound to the key.
Note that my desiderata didn't say anything at all about whether you
could use this information to send electronic mail to that person.
That might be a happy coincidence, and I would have no objection to
incuding the users X.400 address, Internet address, CompuServe
account, or even his Swiss bank account number as additional
attributes in the certificate, but that information is not needed in
the DN. (The only reason for including this information in the
certificate would be for the convenience of retrieving that auxiliary
information from the archive, and also to allow the CA to confirm the
accuracy of the information. Or if X.500 never comes to fruition and
we use a database of certificates in lieu of X.500.)
Hmmm... Maybe I get the drift. You want to change certificates so
that it has possibily several components, viz an identifier and one or
more attributes, e.g. a key, an email address, etc. Interesting...
Instead, I assume that a user's UA will keep a short address book of
nicknames that are referenced frequently, and a somewhat longer list
of less than fully qualified names of correspondents, and that BOTH of
these lists will reference that correspondent's fully qualified DN in
the directory to find the latest information available. (Not routing
information, for the Directory aways returns the same information
regardless of the source of the inquiry (neglecting synchronization
problems) and therefore isn't well suited for containing routing
information.)
(We'll just ignore the parenthetical remark about the Directory; it
doesn't mean anything in this context.)
Yes, some UAs may provide a local directory for the user. But how to
organize it, and what to use for indices? And what's considered
definitive?
(Many uses of the certificate infrastructure won't make use of e-mail
at all. They might use sockets or other protocols like DCE, or just be
used to sign programs distributed on CD-ROM as a means of
authenticating them.)
Still need some form of identifier.
If X.500 weren't available, the user could equally well keep this
information in any kind of a database he chooses to use. It just
becomes a little harder to look up people he hasn't corresponded with
so far, but we have that problem now. And at least in the e-mail
environment you can include your certificate in your first signed
message, and your correspondent can do the same, and so you never need
a global directory at all - just a local cache.
Well, we've tried this, and it's not so easy. Let's consider two
approaches to the UA problem. One is the DN-centric approach; the
other is the email name (EN-centric) approach.
In the DN-centric approach, DNs are the definitive identifier. To
associate an EN with a DN, someone has to certify that the EN belongs
to the DN. If you send me your certificate, and I want to store it
with your EN, someone has to specifically sign off on the
correspondence. Otherwise the system has a flaw and the
correspondence could be spoofed.
There are two ways to certify the correspondence. In most current
implementations, the person receiving the certificate has to manually
type in the EN which corresponds to the DN. This is a pain, it's
error-prone, and it's wasteful. Another possible approach is to have
the DN owner certify what his EN is. This requires a new document
that we do not yet have. I think you were suggesting that the DN
owner put this in his certificate as an extra attribute. This might
also work. In either case, there is not currently any mechanism for
the DN owner to certify his EN. We will have define and build new
mechanisms to support this.
Even this is not sufficient. If you, as a DN owner, certify that a
particular EN is yours, what am I going to do with that information.
Well, if I have your DN and need your EN, all is well. However, if I
have your EN and I want your DN, I need to do a reverse lookup. "No
problem," you say, "that's what computers are for." Ah, but suppose
someone else, perhaps with malicious intent, also sends me a
certification that matches his DN with the same EN? How do I know
he's lying?
If I look up information indexed by EN, I may get the wrong DN. The
only way I can protect myself is to examine each EN-to-DN lookup, each
and every time. This is not nice. It's clumsy and error-prone. The
fact of life is that I -- and most other mail users -- use ENs as the
primary identifier for someone on the net. I may use various lookup
mechanisms based on names or other atrributes, but until I have an EN
I believe is yours, I don't have an identifier I can use.
So let's examine the possibility of an EN-centric scheme. Here the EN
is the identifier. One might imagine an EN to DN mapping which
provides additional information. The finger protocol does
approximately that. Whois also returns DN information for EN
inquiries.
So what breaks if we use ENs as the identifiers for keys? DNs and
other attributes can be tied to ENs by having the EN owner certify the
correspondence. EN's must, of course, be assumed to be owned by a
single entity. This is not always true, but it's mostly true and the
consequences of shared mailboxes are already known. So far, so good.
UAs could provide nice, friendly lookup mechanisms which yield the EN
associated with a given DN. What about a malicious user who certifies
a bogus mapping between his EN and a DN? Well, that might indeed
cause confusion. Of course, if you only use ENs, you'd be ok, but if
you wanted to have a local store of ENs which is indexed by DNs, you'd
be in trouble.
Where does that leave us?
It seems to me it me that these considerations require something that
combines both the EN-centric view and the DN-centric view.
Specifically:
Let's associate a DN with every EN. Both the DN and the EN
have to appear in the certificate. The certificate continues
to be signed by an issuing authority. (The issuing authority
has both an DN and an EN, of course.)
SO:
If anyone is still in the mood to even consider the kinds of drastic
changes that have been proposed in this recent thread, I'll make my
suggestion:
RESOLVED, that the PEM community should unilaterally take steps to
suitably enhance the current X.509 certificate, perhaps calling it
X.509 V3 to distinguish it from the 1993 version (V2), and establish
that certificate as the initial de facto standard for a national
public-key infrastructure.
My proposal above fits into your suggestion, although perhaps not
quite as you envisioned.
If X.500 adopts it in the 1996 version, all will be well and good. If
they don't, we will just have yet another attribute that was not
defined in X.520 to add to the stack, along with ANSI X9F1, X12,
authorization certificates, etc. In any case, it should be no more
difficult to disseminate this kind of a certificate via an X.500
directory server than it will any other kind of attribute like the
QUIPU "Favorite Drink" attribute. And if by 1996 it is still that
difficult to add attributes to X.500, the entire directory structure
will collapse and we'll start using some other kind of system, such as
GOPHER.
Good.
The key to this entire proposal is to have the ability to sign
information (attributes) that are contained in a certificate without
having to add those attributes to the DN itself. Thus, Warwick Ford's
caName attribute would NOT be in the DN, but would be signed. I
haven't thought through all of the name subordination requirements,
but I suspect that they shouldn't be impacted too much.
Not sure what a caName is, but I think we're on the same track.
By now I'm sure that Steve Kent has set up the stake, laid the
kindling, found his lighter fluid and Zippo, and is looking for rope.
As they say at the start of the Olympics, "Let the flames begin!"
Q. When did the British burn Washington?
A. The British didn't burn Washington. Joan of Arc, yes, but not
Washington!
TGIF,
Bob
Now comes your second message. Maybe this will all work out ok.
Reply-To: Jueneman(_at_)gte(_dot_)com
From: jueneman%wotan(_at_)gte(_dot_)com
To: Russ_Housley(_dot_)McLean_CSD(_at_)xerox(_dot_)com
cc: pem-dev(_at_)tis(_dot_)com
Date: Fri, 04 Feb 94 18:29:04 EST
Subject: Re: CA Names
Russ,
Again, every DUA that uses strong authentication will encounter the
new attribute. If we are successful in deploying certificate-based
key management for PEM, then the Directory will very likely use the
same technology for authentication. I hope that the successful use
of certificates in PEM will lead to the use of certificates in other
authentication applications. After all, this is the reason why PEM
adopted the X.509 certifcate format....
Certainly it was the intent of the X.500 folks to use X.509 for the
purpose of strong authentication of user access to control changes to
the directory itself.
But after talking to Hoyt Kesterson, who speaks _ex cathedra_ on this
subject, I am not at all convinced that they have thought through all
of those issues. They haven't addressed the need to archive requests
for changes or updates to the directory, for example, and I strongly
suspect that they will discover that they need something remarkable
like authorization certificates to permit fine-grained control over
who can change what kinds of information, or even see certain kinds of
information in the directory.
Like you, I would certainly like to see a simple, common
infrastructure that could support a wide diversity of applications.
But X.509 does not meet that goal, and it therefore must either be
changed or abandoned.
Bob
My goodness! I agree with everything you said in this message.
'Night
Steve
-----END PRIVACY-ENHANCED MESSAGE-----