Christian,
A light dawns, and I now understand your problem. I had
been focussing on the difficulty of supporting a new attribute
within PEM on an end-user to end-user basis, and had ignored
the problem that might be faced by a multiplicity of Directory
Service Agents. But now I am even more concerned that X.500
may not be the solution that we had hoped for, for if the
problem is this difficult we may never be able to make very
effective use of the directory itself, for anything. Certainly if all
of the DSAs throughout the world have to be re-sysgened every
any applications developer or proprietary service provider wants
to add a new feature or widget, the system will never work.
Let me play back some of the issues and make sure that we are
synch, and then think what we might do about it.
1. PEM elected to use the X.509 certificate infrastructure --
overall a good move, as it promotes the wider use of available
support tools such as X.500. Although an X.500 directory is not
required to distribute public key certificates, if we expect that
one might be available, we should at least try to be compatible.
2. The existing X.509 certificate, even the '93 version, does
not provide for any flexibility in adding attributes about a user.
Other than the Distinguished Name, the various attributes
in the certificate are all technical, e.g., algorithm type, public key,
etc. This was perhaps an understandable oversight, since the
Directory folks would naturally assume that you would retrieve any
other attribute information from the directory itself.
3. Relying on the Directory for those "other" attributes is not
sufficient, however, first of all because the other attributes
cannot easily be signed by the equivalent of a CA, and second
because the Directory does not provide any archive capability.
In order to support nonrepudiation, it is necessary to archive the
certificate along with the message, and it is highly desirable
to archive ALL of the necessary information in one place, i.e.,
the certificate chain. Any other solution would seem to make
nonrepudiation of archived messages extremely complex.
4. We are now beginning to understand that a number of new
attributes would be desirable, or at least much cleaner from an
architectural point of view. (Some may of course debate this.)
The CAname is one example, and there are many more that do
not involve authorization attributes at all.
5. Unfortunately, because the DN is the only place where additional
information can be placed within the X.509 certificate, we are
stuck with an ever-increasing series of hacks that add
semantic content and/or additional attributes to the DN that are
not required and probably not desirable from a directory
name construction and search standpoint.
6. In getting to this point, we may have made an implicit
assumption that the Distinguished Name contained within the
X.509 certificate is in fact a real DN that exists in the directory,
and not just an alphameric string that happens to look like a DN.
This does not seem to be an explicit requirement of X.500,
although it is certainly a natural implication. It's just a thought,
but perhaps we should see if there is some lattitude here.
OK, now what could we do about this problem (if there is one)?
1. We could fix X.509 as a temporary, PEM-only work-around.
Lets call the new certificate X.509-1/2. The PEM community
can start using it, and if it breaks X.500 directories that is
regretable, but not the end of the world. The new definition
can be circulated at the OIW and aggessive implementers can get
on board at their own pace, and the final revised standard
can be adopted de facto in 1996. This of course would break, or
at least bend, all of the existing PEM implementations, but at the
current rate of adoption, that wouldn't be the end of the world
either.
2. We could abandon the use of X.509 entirely, and adopt a new
certificate structure that is more along the lines of ANSI
X9F1 authorization certificates. How those certificates will
be disseminated is anybody's guess -- if X.500 can't solve
the problem by adding a new certificate type attribute, some
other distribution mechanism will ultimately have to be used. This
would have even more serious breakage consequences for
both X.500 and PEM, but perhaps it is better to break a few eggs
now and support new EFT and EDI capabilities, rather than wait.
3. We could load all sorts of semantic baggage into existing,
presumably already supported X.520 attributes, and cram them
into the DN as at least an expedient measure until the problem
sorts itself out over the next three to five years.
4. We could do nothing, insisting that PEM is absolutely fine
exactly as it currently exists, and when (or if) the use's find
out that they really can't make the system work because
some of these key features are missing, we can just let the
effort collapse of its own weight.
From my point of view as a potential user, CA administrator, and
the manager of a group that is trying to evaluate whether or not
GTE should play a role as an X.500 service provider, I am inclined
recommend that we use option 3 as an expedient for this year, and
start working immediately on a revision to X.509 that will
provide sufficient extensibility to support a wide variety of
new attributes suitable for electronic funds transactions,
EDI transaction sets, and other authorization capabilities
that we surely don't understand as yet.
I suppose that you could argue that enforcing some convention
such as OU="@#$%*** Certification Authority ***%$#@" to indicate
the difference between a user and a CA is no worse a hack than
abusing some other attribute, such as Owner="RSA Commercial
Hierarchy" or supportedApplicationContext="Certification Authority".
Steve Kent has already proposed something similar by
suggesting a backdoor authorization (non-authorization) attribute
of the form O=BBN, OU=Employee, CN=Steve Kent. That's OK
for applications that are scanned by humans, but poor form
for any other kind of systems.
Even if we had a supported authorization certificate available
today, I think we would still have the problem of saying that
"Everything that is not explicitly allowed is forbidden", so
that attributes are additive.
Some legal folks might argue that putting such a statement in a PCA
policy might not constitute adequate notice, but I feel that a
reasonably decent case could be made for making the PCA
policy a "trade practice", to be evaluated the same way that
the use of Chinese chops and other industry unique customs.
However, I wouldn't bet the ranch on using the PCA policy
to shield me from implied liability, even if I could persuade a
friendly PCA to write such a policy (unless we set up our own
PCA, which would seem to be the start of a regrettable trend.)
So at this point, I literally don't know how to move forward on
this issue, satisfy the various corporate lawyers, the slow-
moving standards assocations, the PEM community, etc.
Much as I dislike it, I am increasingly inclined to put some
sort of Caveat Emptor warning notice in a Description
field, make it a part oc the CA name, and insist on name
subordination. The certificate will be ugly almost beyond
belief, but at least the recipient will see the information,
and if an when an X.500 directory comes along they can
define a more user friendly alias that refers back to the DN of
long-winded certificate.
Assuming that you take on faith my legal problems, do you see
any other technical solution?
Bob