From: epg(_at_)gateway(_dot_)mitre(_dot_)org (Ella P. Gardner)
To: vcerf(_at_)CNRI(_dot_)Reston(_dot_)VA(_dot_)US,
yee(_at_)atlas(_dot_)arc(_dot_)nasa(_dot_)gov
Subject: Re: PEM Test Service
Cc: Stef=pem(_at_)nma(_dot_)com, pem-dev(_at_)TIS(_dot_)COM,
shirey(_at_)mitre(_dot_)org
Sender: pem-dev-relay(_at_)TIS(_dot_)COM
Content-Length: 1105
Well, Rob quoted the text from RFC 1422 as follows:
To complete the strategy for ensuring uniqueness of DNs, there is a
DN subordination requirement levied on CAs. In general, CAs are
expected to sign certificates only if the subject DN in the
certificate is subordinate to the issuer (CA) DN. This ensures that
certificates issued by a CA are syntactically constrained to refer to
subordinate entities in the X.500 directory information tree (DIT),
and this further limits the possibility of duplicate DN registration.
CAs may sign certificates which do not comply with this requirement
if the certificates are "cross-certificates" or "reverse
certificates" (see X.509) used with applications other than PEM.
This appears to make the CA a registration authority for names. "In
general, CAs are expected to sign certificates only if the subject DN in
the certificate is subordinate to the issuer (CA) DN." Is this what is
meant?
Ella Gardner
MITRE
RFC 1422 in fact requires a strict relationship between the DIT and the
certification tree from a certain level on downwards, and this may create
a problem, depending on your view of what certification means.
You simply may consider certification as a means to make your DN provable
to others. This is what an X.509 certificate technically is: a key-to-DN
binding. In an e-mail environment like PEM, DNs are read by human users,
and certification just provides you a proof that a sender has the claimed
name. What the receiver concludes from that DN is outside the system. As
long as certification is only used to be able to provably present DNs to
others, it sounds reasonable to link the certification tree to the DIT.
I admit that PEM does not require a particular DN structure for user-DNs
(nor does it need CAs which are naming authorities for users). It can deal
with any DN coming from the real word. But it requires a CA structure which
fits to these DNs.
In the case that certification is being used for authorization purposes,
i.e. when you derive capabilities, access rights or whatever from authen-
ticated DNs, that certification structure is too restrictive, in my view.
The Directory itself is a good example. If you access a DSA using strong
authentication, the DSA will grant or deny you access rights to the DIB
which he may derive from your authenticated DN, following an authorization
policy. It could also be part of the particular DSA authorization policy,
for instance, that your access rights are not derived from your name, but
from the name of the issuer of your certificate. I can imagine a lot of
applications where X.509-certification is being used to derive capabilities
not from your DN, but from the place where you are in the certification
tree.
For the greatest possible flexibility and a wide-range applicability of the
certification infrastructure, I think RFC 1422 style CA naming requirements
are an obstacle. The DIT and the certification tree should be independent.
In the particular case of my company, for instance, the PEM certification
structure would not fit to the certification structure which we have already
established. Participating in PEM would mean for us to open up a new certifi-
cation line. It is our goal, however, to establish a security infrastructure
for our people which is usable in a number of applications, not only in PEM.
RFC 1422 tries to solve technical problems through naming conventions which
should probably be solved at other places or by other means.
Wolfgang Schneider
---------------------------------------------------------------------------
German National Research Center Tel +49-6151-869-262
for Computer Science (GMD) Fax +49-6151-869-224
Institute I2
Dolivostr. 15
D-6100 Darmstadt - Germany
---------------------------------------------------------------------------