Russ Housely wrote to Warwick Ford:
Warwick:
I find many parts of your suggestion attractive, but we must find a way to
implement it without using a new attribute as part of the distinquished name.
Could you please expand on your strong opposition to the new attribute
proposal. X.500 was designed with a goal of straightforward
extensibility re adding attributes and, as I understand it, this has
been achieved with respect to chaining DSAs. There is certainly an
impact on DUAs which need to recognize the attributes, but it is not
obvious to me that we have a real problem in the CA-name case. Is your
concern something fundamental with X.500, or is it that some particular
implementation(s) might break?
My concerns is simply theone voice by Mike Roe, in practice the intoduction of
new attribute types has been shown to be difficult. If you can show a counter
example, then I might withdraw my objection. If we can show that the new
attribute will not seriously break existing DSAs or DUAs, then I really like
your suggestion.
Russ
I don't mean to discount experience, even anecdotal experience,
but I don't feel comfortable with the discussion of these points so far.
I'd like to hear from a major vendor or someone who is running a production
quality X.500 implementation, eg., one from Bull HN or from DEC, and have them
authoritatively discuss the following points:
1. How difficult is it to add a new attribute (and attribute syntax, if
necessary),
both to the DSA and to the DUA? Does this require vendor support, or
can the local administrator make these changes?
2. What does it take to modify the directory schema that defines what
attributes can be used with what object classes? X.501 (1993E),
section 12.2, says, "Note -- the schema enables the Directory system to,
for
example,
-- prevent the creation of subordinate entries of the wrong object class
(e.g.,
a country as a subordinate of a person)
-- prevent the addition of attribute types that are inappropriate to the
object class,
e.g., a serial number to a person's entry)
-- prevent the addition of an attribute value to a syntax not matching
that defined
for the attribute type, e.g., a printable string to a bit string).
(I am particularly concerned about the serial number, since I was planning
to use it
to represent an employee's ID number!)
3. What is the impact on the NADF or other groups of directory service
providers
who are trying to interoperate, if we have to add attributes or even new
object
classes to support X.509 and digital signatures?
If I understand correctly, and I got tripped up on this once before, we cannot
simply
use any old attribute we like out of X.520. Instead, that attribute has to be
listed
within the object classes defined in X.521, or we will need to define one or
more
new object classes.
Presumably, this is at least true with respect to the DSA and the DUA. However,
it is not quite so clear with respect to the DN that is contained within the
X.509
certificate.
Peter Williams brought up this point before, but to my knowledge it has never
been
resolved. What, EXACTLY, must the relationship be between the DN that is
contained
in the X.509 certificate and the DN that is used to look up that X.509
certificate as
an attribute under a user's name in the X.500 directory?
It is not clear to me that the Distinguished Name that is contained in the X.509
certificate has to in fact even exist within any X.500 directory (and in
general it won't,
at least for those PEM users who are not yet suppported by X.500).
Even if the user is listed in the Directory, it is not clear that the DN in the
certificate
must exactly match at least some DN in the directory. It is also not clear that
the object class for the DN in the certificate must be exactly the same as the
object
class of the user's "real" DN n the Directory.
What IS clear is that there are a number of attributes that could reasonably be
proposed to solve certain problems that have arisen from the intended use of
X.509 certificates for digital signatures that were not included within the
basic set of
attributes and object classes in X.520 and X.521.
We could debate each one of these, but to my knowledge we have proposed the
following new attributes or suggested that existing attributes be used in ways
that
are not included within the existing object classes:
1. roleName - to be equivalent to title, put in a matrixed organization.
2. caName - to uniquely identify the CA that is authorizing a user, as a means
of
relaxing and clarifying the name subordination rules.
3. serial - as a means of uniquely identifying multiple users with the same
common
name over time within an organization. Could be replaced with
uniqueIdentifier
in X.520 (1993), but at the expense of having any defined semantics.
4. description (or some other catch all field) - to explicitly state
liability limits,
"Not valid for trade under the Uniform Commercial Code" or otherwise
ensure that everything that is not explicitly allowed is forbidden, so that
authorization attributes are strictly additive.
5. Authorization attributes in general.
My feeling is that at the present time we do not yet have enough usage of PEM
that we could go huffing and puffing to the NADF or the X.500 directory vendors,
and/or the OIW, insisting that this, that, or the other attribute be added to
their
common list.
On the other hand, the number of fully-functional directory service offerings
out
there is countable on a few fingers, and the only reasonably wide-spread use
so far is for limited e-mail and telephone white pages. I can't say for sure,
but
I don't think anyone supports strong authentication or even access control as
yet, and when they start to, they will probably find that many of these same
issues
will come up. Certainly as directory service providers start to address EDI
these
issues will be extremely important.
I would therefore suggest the following:
1. Allow a very loose correlation between the DN that is contained in the
X.509
certificate and the DN of the user in the Directory. In particular, do not
require
useful attributes for X.509 certificates have to be contained or supported
by the
Directory.
2. Define a reasonable set of attributes for use in a national or
international
public key infrastructure, and add support for those attributes (and new
or
modified object classes if necessary) to the existing PEM implementations
as quickly as is feasible.
3. Keep the OIW, NADF, and X.500 people informed of our plans, so that they
can adapt over time.
In particular, I am suggesting that any difficulties in supporting the X.509
certificates and/or attributes within X.500 directories NOT BE ALLOWED TO DELAY
PROGRESS IN IMPLEMENTING PEM ON AS WIDE A SCALE AS POSSIBLE, AS
RAPIDLY AS POSSIBLE.
In fact, if push really came to shove and we couldn't solve the problem any
other way,
I would recommend abandoning X.509 and defining a new certificate structure
unique
to PEM that would allow some of these attributes to be included without having
to be
forced into the DN itself, then allow X.509 to catch up later.. Better that we
have a
version of PEM that works without X.500 support than to wait for another 3 to 4
years
to solve these problems.
When we get to the point that there are a large number of PEM users out there
demanding support from X.500, market pressure will make it happen. But if we
wait for the X.500 people to come up to the same level of understanding of these
problems as we currently have, PEM will have been abandoned in favor of more
pragmatic schemes, e.g., PGP.
Let's solve our own problems first. Compatibility can come later.
Bob