Steve, et al. at the WG,
I want to make sure that my position regarding binding
additional attributes to a user beyond his distinguished
name is clearly understood, because there may be some
confusion caused by some of my earlier positions on this
issue.
I do NOT want to address the issue of AUTHORIZATION
certificates, or even authorization attributes within
a certificate. I think that the ANSI X9.30 people,
notably Frank Sudia and Richard Ankney, are
on top of that issue and will come up with a good,
general solution. I understand and agree that in
general, the CA that signs such certificates may be
quite different from the CA that signs someone's
basic identity certificate. To use your example,
the Mass. Dept. of Corrections might issue
an identity certificate to an inmate, so that he
or she could file petitions, communicate with
legal counsel, etc. Whether MasterCard would
issue them an authorization certificate would
be quite another story!
So let's concentrate on those issues which
are (almost) exclusively associated with a basic
X.509 identity certificate.
We currently have several problems:
1. The existing RFCs do not address the use of the
UniqueID field that is defined in X.509 '93. Without
the use of this field or something like it, CAs will be
forced to ask a user to effectively change his name
or add further qualification in order to guarantee
an unambiguous mapping between the DN and the user.
If we consider the problem of differentiating between
diufferent users over a span of time, the problem
becomes even worse.
So we need the UID field, and we ought to add it
to the PEM RFCs. I might have preferred a field
with a more descriptive semantics than an
arbitrary bit string, but we can live with this. Maybe
people will hash their birth certificate information
to guarantee uniqueness, or use an employee ID number,
or the time of epoch when the certificate was
generated.
2. However, even if we have a UID to provide
unique certificate names, we have not solved the
problem of how the user who wishes to validate another
user's identity can distinguish between the two
entries. Clearly we don't expect users to memorize
other users employee IDs, much less some even more
arbitrary bit string.
On the other hand, we don't want to clutter up the
X.500 directory search process (or any other type of
directory, for that matter), with a lot of information
that won't be needed 95% of the time. It will just make
the search process more difficult.
If we were assuming the ubiquitous deployment of
X.500, we could use the additional attrbites stored in
the entry along with the DN to resolve these issues.
For example, if Ed Starr's favorite drink is Scotch, and if
Susan Tarr's favorite drink is a Pink Lady, then those
individuals could be distinguished on that basis, even
if (god forbid) their only DN was starr(_at_)bbn(_dot_)com(_dot_)
Of course a more rational selection of attributes to
be used for making such a selection might be
their nickname, department, physical description,
or even (unlikely) a full motion video.
Yes, it could be argued that any or all of these attributes
could be crammed into the DN, in particular because
_are_ being used to distinguish between two similar
entities. But if people think that DNs are ugly now,
imagine if they have to start over-specifying DNs with
e-mail names, Eyes=Blue, favoriteDrink=Scotch, etc.
(This assumes that we are still assuming an X.500
directory for searching purposes. If not, then the
semantics of a distinguished name become meaningless,
and we could just view the entire DN as a collection
of arbitrary typed attributes.)
3. Although I have strong feelings on some of these issues,
let me be neutral for the sake of this particular argument.
Let's assume that it is decided that in order to facilitate
the process of binding a key to a name, and a name to
an individual, we also want to bind that individual to
a particular mailbox, and that we want to do it within
the certificate.
As in the old blues eyes example, we _could_ cram all
of this information into the DN and stay within the
existing X.509 format. However, I believe that approach
would greatly increase the complexity of searching
for a given DN, and might make the use of strong
authentication within the directory itself very difficult.
In addition, from a purely architectural point of view,
such an approach would be overloading the semantics
of the distinguished name construct. In a word, YUCK.
Although I have discussed the possibility of saying
something like C=US,O=GTE,CN="Jueneman, Robert
<Jueneman(_at_)GTE(_dot_)COM>", I really believe that
burdening one attribute with two semantics would
be WRONG, WRONG, WRONG. So forget it,
and I'm sorry I even thought of it.
I am forced to conclude that we need a DN for searching
purposes, and that we may also need other attributes
that can be used BY USERS to distinguish between
two similar DNs, and potentially to carry other useful
identity information as well.
(No, I would not propose that we include a 1 megabyte
MPEG file containing the user's face and voice within
the certificate! :-)
I would therefore like to put my previous proposal for
an enhanced X.509 certificate definition on the table
again. On Feb. 7th, I proposed the following (my apologies if these
lines are too long to be easily readable, but the ASN.1 definitions
themselves are a little long):
My specific suggestion, then, is that we define a new X.509 certificate type
that could
contain both a minimal DN (a true DN) to unambiguously identify the user and
facilitate looking up additional information in the Directory), AND it would
contain
an arbitrary number (extensible) of additional attribute values to provide
additional
useful information that can and should be signed by the CA.
At the risk of displaying my ignorance of the fine points of ASN.1, I would
propose
the following new definition for a version 3 X.509 certificate:
Certificate ::= SIGNED {SEQUENCE {
version [0] Version DEFAULT FOR PEM v3,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerAttributes [1] IMPLICIT IssuerAttributes OPTIONAL
-- If present, version must be v3
subjectAttributes [2] IMPLICIT SubjectAttributes OPTIONAL
-- If present, version must be v3 --}}
Version ::= INTEGER {V1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
AlgortihmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.&ID({SupportedAlgorithms)},
parameters ALGORITHM.&Type ({SupportedAlgorithms}{ @algorithm})
OPTIONAL }
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime }
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Other than the version number, the only changes are that the v2 attributes
issuerUniqueIdentifier and subjectUniqueIdentifier are replaced with
IssuerAttributes
and SubjectAttributes, respectively, as defined by:
IssuerAttributes ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
SubjectAttributes ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE
type ({AttributeType}),
value ({AttributeValue
({SupportedAttributes}{(_at_)type)})}
Note that the previous issuerUniqueIdentifier and subjectUniqueIdentifier
attributes now
become just one each of many possible additional attributes relating to the
issuer and the
subject. For that reason, the version 1 and 2 definitions of Certificate are
compatible
subsets of the proposed version 3.
[However, since this aspect of the suggestion was criticized when it was
proposed
previously, I would be quite happy to leave the '93 UID fields alone, and add
these
additional attributes as pure extensions. I would also be happy to have someone
clean
up any errors or misunderstandings of the ASN.1 syntax. RRJ 3/22/94]
With the new definition, the DN should reasonably be confined to the proposed
NADF
naming rules for civil authorities, i.e., conform more or less to the "What God
Intended"
rule.
But the additional attribute fields could contain anything and everything that
a CA would
be willing to sign, including attributes defined with private OID
qualifications, where
the ASN.1 syntax would hopefully be made available through the directory itself,
but the semantics may or may not be widely known outside of that private domain.
Reasonable examples of such attributes would certainly include the X.400 ORA
and/or the Internet mail address (assuming that an internationally standardized
OID
is assigned), roleName (another not-yet-standardized attribute), description
(5'2",
eyes of blue), and perhaps the very useful caveatEmptor attribute.
[caveatEmptor="Everything which is not explicitly allowed by virtue of some
other
attribute signed by this CA is hereby forbidden and eschewed, and any purported
contract, agreement, or obligation to the contrary is and shall forever be
deemed to be
null and void and without merit or value and subject to being bent, spindled,
and
mutilated."]
I feel that the benefit of this proposal is that:
1. It allows the current X.509 certificate to be extended an a compatible way.
In fact,
since to the best of my knowledge there are NO X.500 implementations available
as
yet that support strong authentication, implementing this certificate format
per se should
have zero impact on any of the DSAs or DUAs.
2. It would allow DSAs and DUAs to be gracefully extended to support additional
attributes that may not have even been thought of to date, without requiring
that the
DIT or schemas be modified.
3. It provides a mechanism whereby PEM users can capture both the essential
and
perhaps the merely useful information within a certificate, without having to
have X.500
up and operational in order to support PEM, and without having to worry that
some new
attribute would "break" X.500 DSAs or DUAs.
4. It seems to provide a means of supporting X.500 strong authentication, PEM,
and other forms of certificate-based authentication with a common identity
validation
mechanism.
The drawbacks would appear to relatively minor, and might literally amount to a
few
additional lines of code to search through the sequence of additional
attributes,
assuming that the attribute syntax is already specified. If not, and if the
attribute is really
needed, then it would have had to have been specified sooner or later in any
case.
[Since the 1993 version of X.500 has not yet been formally adopted, it would
appear
that we would have several ways of registering this extended version, in
decresing
order of desirability:
1. Convince the X.509 defects editor to add it to the '93 version under the
ISO/ITU arc.
2. Define a new attribute, called ietfCertificate, and register it under the
IANA's OID.
3. Request that the NADF accept and define this certificate format under their
OID.
4. If all else fails, I'm willing to register it under the GTE Labs OID as soon
as we
get one, hopefully within a week or so, and certainly within 90 days after the
national
registration challenge period is up. RRJ 3/22/94]
I would appreciate the serious consideration of this proposal at the WG, and if
there
is a reasonable concensus I would be willing to transform this text into a
formal Internet
Draft or take whatever other next steps are required.
Bob