-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of David P.
Kemp
Sent: Friday, June 02, 2000 7:52 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Cert Dist Changes
From: "Jim Schaad" <jimsch(_at_)nwlink(_dot_)com>
To: "David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil>,
<ietf-smime(_at_)imc(_dot_)org>,
<jimsch(_at_)nwlink(_dot_)com>
Subject: RE: Cert Dist Changes
Date: Thu, 1 Jun 2000 21:34:34 -0700
I am a bit loss for words. Are you saying that data is to
appear in one and
only one location in the directory and not to be duplicated?
If this is not
the case then I don't see your problem although consistancy can
be a problem
depending on the different tools used to update the directory
for different
purposes. (A mail program publishing information vs an access control
program (such as the Win2K directory might not keep/correctly update all
fields.)
There is nothing that does not let you put things into the
userCertificate
and caCertificate fields, however many programs only update the
userCertificate field at present. The code that I wrote while
at Microsoft
would publish into both the userSMimeCertificate and
userCertificate fields
but ignored the caCertificate field as this exists only on CAs.
This means
that if a user publishes a certificate in a different directory
(possibly
unaccessable) directory, the client has no way of getting to CA
certificates, thus for the general case caCertificates is unuseful.
Jim,
That is precisely the situation (CA certificates not being accessible
to all consuming applications) I think we should be trying to avoid.
If you start with a directory environment where caCertificate is not
useful, and you want to allow a particular application (S/MIME) to
operate, you have two possible courses of action:
1) encourage directory administrators to make caCertificate useful, or
2) encourage directory administrators to populate an S/MIME-specific
attribute to bypass the need for caCertificate.
I believe that option 2 is harmful to the Internet environment.
Once administrators have made the effort to populate a repository with
certificates, the identical repository should be usable by S/MIME, SSL,
IPsec, and other applications. Developing a stovepipe (single-purpose)
solution is easier in the short run, but will cost us dearly later.
Regards,
Dave
Dave,
If this is what you believe, I encourage you to immeadiately put a draft of
some type in the PKIX working group that will allow me to do path discovery
in a non-X509 directory environment (the internet) where all information
currently in the certificate is X509 based. When I have looked that the
problem I have come to the conclusion that the problem is not solvable in
the general case given: 1) X509 certificates are based on X509 names but
directory lookup is not for non-X509 directories. 2) Attempting to identify
the directory that needs to be used for doing the lookup is not presently
doable (what is the LDAP directory that I should use for c=us, o=missi).
CRLs may be found though the CDP, but certificates cannot be found from the
DN.
jim