Rich,
Thanks for the tutorial on X.500 hierarchies. Now that I understand that
the X.500 '88 handled these issues informally, some of my confusion
goes away. I just received a copy of the 1993 spec, and haven't mastered
it yet. Where should I look for the NAME-BINDING and structure rule
constructs?
The real problem we are having is that we want to make use of some of the
attributes which aren't normally used for naming (hence don't look nice
in a DN and probably wouldn't be suitable for naming in a real X.500
directory), and we don't have the X.500 directory underneath. This does
all work nicely with a real (somewhat trusted) X.500 directory.
No, the REAL problem is that the X.509 certificate didn't include any
of these fields, leaving us with only the DN as a potential repository
for this kind of information.
Actually, I have implicitly been making the assumption that the current
PEM and X.509 certificate structure must be maintained as inviolate,
or all sorts of applications would break. But maybe it would be worthwhile
testing this assumption. For example, what will happen to a version 0
(1988) PEM implementation when it receives a version 1 (1993) certificate
containing a subjectUniqueIdentifier? Will it choke and reject it, or will
it be somewhat mroe polite and say, "I never heard of this attribute
before, but this is what it says?" If this is the case, maybe PEM could
be an early adopter of a new Disclaimer attribute type within the
certificate?
However, assuming that the information has to be encoded within
the DN, and based on the discussion to date, I am now thinking of
using something like:
C=US, O=GTE Labs,
CN=Robert R. Jueneman,
Serial=22934,
Description="Not legally binding when used outside of GTE."
Perhaps you can clarify something for me, based on either the
informal '88 version of the '93 version. Is this the right sequence
for these attributes? Len D'Alotto of my staff is of the opinion that
the CN should (must?) be the leaf of the tree, which would presumably
mean that the serial number and description should come earlier.
I don't care about the order of the serial number, but I can imagine that I
have two different certificates, and that the other one says:
C=US, O=GTE Labs,
CN=Robert R. Jueneman
Serial=22934,
Description="Legally binding if and only if used in accordance with my
digitally signed and witnessed Affidavit of Legal Mark dated x/yy/zz,
hash value hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh."
I therefore want use the Description field to differentiate between
my two certificates. However, I suppose that it could come earlier
in the RDN sequence, although it doesn't feel as natural.
Even though the Description field is a free form text field, I see that
the attribute syntax is the same as the Name type, with an Equality
Matching Rule defined. I would therefore assume that it could be
used as an RDN to make up a DN. However, because it is not a subtype
of Name (in the 93 version), I wonder if this could cause a problem?
Likewise, I see that Serial is not a subtype of Name, although it is one
of the labeling attribute types. On the other hand, streetAddress isn't a
subtype of Name either, yet I would assume that it would be a part of
a residential person's DN. Does an attribute have to be a subtype of
Name in order to form part of a DN?
Finally, Mark Wohl of ISODE has suggested that if we have an object
identifier assigned to us by ANSI, presumably as part of our ANSI
registration, we could define our own "Disclaimer" attribute,
with attribute type name "disclaimer" and syntax "PrintableString"
underneath the GTE Labs OID subtree. I would prefer to use something
of broader applicability, but perhaps the PEM WG could register such
an attribute and use it for such a purpose? Any thoughts?
With regard to your observation "This does all work nicely with a real
(somewhat trusted) X.500 directory.", I have some reservations.
First of all, I think there are some serious issues about X.500 archives,
and what a given certificate means at a given point in time, but I
don't think I can count on X.500 to maintain the necessary history
file for me. That means that an X.509 certificate must be enduring
over time, and I am not sure that X.500 represents more than a
time-ambiguous, not-necessarily-synchronized snapshot of these
relations.
Second, although we may someday have real X.500 directories,
I think that it is unlikely that we will have trusted X.500 in any
meaningful sense. Perhaps in Germany or France, where people are
somewhat more conditioned to producing papers to verify their
identity, a PTT might be able to step up to such a role, but I think
that is it very unlikely that one of the Bell operating companies,
AT&T, or the Post Office (or GTE, for that matter) will ever be in a position
to make statements about their customers that have any additional
level of trust other than what the customers themselves are willing to
sign. Remember Trust <==> Liability. You can't have one without the other.
Bob