Subject: RE: Cert Dist Changes

From: "David P. Kemp" <[email-masked]>
Date: Fri, 2 Jun 2000 10:52:16 -0400 (EDT)

> From: "Jim Schaad" <[email-masked]>
> To: "David P. Kemp" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
> 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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 7 Jun 2000 22:46:03 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David P. Kemp
> Sent: Friday, June 02, 2000 7:52 AM
> To: [email-masked]

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