ietf-smime
[Top] [All Lists]

RE: Cert Dist Changes

2000-06-02 07:46:45

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



<Prev in Thread] Current Thread [Next in Thread>