Well it seem for the most part I have failed miserably at getting
my point across. I will give this one more effort. Please be patient with
a little back ground so hopefully my point will be clear. First off my
understanding of the DIT is that it is made up of "objects" each object is
in turn made up of "attributes". Every object has one or more of its
attributes selected to be its RDN. The sequence of "objects" RDNs from the
root of the DIT to the "object" of interest is the DN. So if I have the
following DNs:
c=US, s=MD, o="Trusted Information System PCA"
c=US, o="RSA Data Security, Inc.",
ou="Low Assurance Certification Authority"
the corresponding DIT looks like
/
|
c=US
/ \
s=MD o="RSA..."
/ \
o="Trus..." ou="Low..."
this as defined requires us to look at the actual text of each item
to identify what that item is. This does not seem desirable or
consistent with X.500. For example if I look at how X.500 defines
people in the DIT for me it would look something like this:
c=US, o="NASA", ou="JPL", cn="Matthew McGillis"
which has the following DIT
/
\
o="NASA"
\
ou="JPL"
\
cn="Matthew McGillis"
If we look closely in X.521 we will not see any object which can be used to
corresponds with cn="Matthew McGillis" which has any information about
certificates. If I become a user that uses certificates then a new object
"strongAuthenticationUser" is created beneath the object that represents
my name. So the DIT looks like (X.520 does not define a abbreviation for
userCertificate but for simplicity I will use "uc"):
/
\
o="NASA"
\
ou="JPL"
\
cn="Matthew McGillis"
\
uc="....."
NOTE X.500 did NOT just add an attribute to my person object but instead
created a entirely new object. (This is what I'm suggesting be done for PEM)
This means the DN for one of my certificates is:
o="NASA", ou="JPL", cn="Matthew McGillis", uc="....."
So with this idea in mind I feel PEM should define a new object class lets
say:
policyCertificationAuthority OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
pCAName, --abbreviation will be pca
--this is also the RDN of this object
pCACertificate,
policy,
certficateRevocationList,
authorityRevocationList}
::= {objectClass XX}
So what does this do or not do for us if we use this definition along
with the existing X.521 definition of an object for a certificationAuthority
certificationAuthority OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
cACertificate, --abbreviation will be ca
--this is also the RDN of this object
certificateRevocationList,
authorityRevocationList}
MAY CONTAIN {crossCertificatePair}
::= {objectClass 16}
Consider the following scenario
TIS runs a PCA but also has a CA for all local users. RSA runs
two PCAs one is High assurance the other Low assurance and two CAs
one is a CA that services persona certificates with in the Low assurance
PCA the other is a CA under the High assurance PCA which is used for local
users.
with the above definitions the DIT might look something like:
/
|
c=US
/ \
s=MD \
/ \
o="Trusted Information Systems" \
| | \
pca=TIS ca="..." o="RSA Data Security, Inc."
/ | | \
pca="High Assurance" ca="..." ca="..." pca="Low Assurance"
with this the pca's and ca's are clearly identified with in the DIT
and in fact you can now query the Directory for such objects this seems
like a desirable thing. The only slight difficulty is in identifying what
pca a specific ca belongs to. Although this can be determined from
looking at the ca certificate.
Well I hope this clarifies my point. If it does not I'm not
sure how else to write it. Perhaps a conversation would be easier.
I believe their are many benefits to this style of structure. Especially
since most organizations will have many other objects besides these beneath
it.