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.
One part of me would be more that happy to deprecate the use of
userCertificate given some of the problems assocated with its use (outlined
in the draft), but I don't expect that to happen any time soon. What does
it mean if some other application which does not understand or reference the
userSmimeCertificate (having only implemented the PKIX docs) removes a
certificate from userCertificates that is referenced by the
userSmimeCertificate property. This leads to inconsistancies on the
other-side of the fence if the certificates are not included. I don't think
that you would ever be able to ensure consistancy unless the directory
itself does so.
jim
-----Original Message-----
From: David P. Kemp [mailto:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil]
Sent: Thursday, May 18, 2000 7:54 AM
To: ietf-smime(_at_)imc(_dot_)org; jimsch(_at_)nwlink(_dot_)com
Subject: Re: Cert Dist Changes
Jim,
If the new draft specifies that the userSmimeCertificate LDAP attribute
contains either user certificates or CA certificates, it is in conflict
with the PKIX directory schema. *No* certificates should appear in this
attribute, *All* certificates should be populated in the standard PKIX
locations: userCertificate and caCertificate.
Size considerations are a very minor concern to me, although the size
difference between "smimeCapabilities only" and "smimeCapabilities +
full cert path" is significant. The major concern is the duplication
of data, and the corresponding likelihood that the data will get out of
sync. If you believe that it is too difficult to fetch certificates
from the directory when formatting a CertDist object for http
retrieval, or alternatively stripping the cert path out when populating
the CertDist object as a directory attribute, then you certainly must
not be inclined to check CertDist objects which contain certificates
for consistency with the certs already in the userCertificate and
caCertificate attributes of the directory.
SMIME LDAP attribute definitions must be compatible with and
non-duplicative of PKIX LDAP attribute definitions. Until that is the
case with Certdist, I will continue to oppose its approval as an RFC.
Regards,
Dave
From: "Jim Schaad" <jimsch(_at_)nwlink(_dot_)com>
To: ietf-smime(_at_)imc(_dot_)org
Date: Wed, 17 May 2000 21:41:41 +0800
Subject: Cert Dist Changes
X-User-Info: 131.107.3.84
Since I have been out of touch and have not be able to respond well to
comments
on this draft, I will attempt to summerize the comments in this message as
well
as the action that I have taken about them. A new draft is on the way to
the
editors at the same time as this message went out.
1. LDAP was not understandable as writen. I have changed to using the
LDAP
v2 rather than LDAP v3 descriptions so that they look more like what
people
understand. It is perfectly possible that I did not understand what the
v3
docs were trying to do and so got the v3 schema completely wrong.
2. May omit user's certificate if publishing to LDAP. This is the one
with
the most traffic. The arguments that I have found are:
a) The document should be modified so that the text states that the
certificate
MUST NOT appear in an LDAP entry.
- I don't like the text MUST NOT. It is quite possible that when I
prepare
a CertDist object for publication I don't know where it will appear or it
may
appear in multiple places. Putting the MUST NOT text in says that I need
to
either be able to manipulate the object at publication time or potentially
start
creating multiple objects. Note this goes in the opposite direction as
well,
something move the attribute from LDAP to http get would need to insert
the
certificate.
b) The document does not say what do to in the absence of the property.
- I don't believe the document needs to discuss other ways of obtaining
certificates.
More specifically the text to deal with this is very LDAP specific and I
don't
want to tie the document any closer to LDAP than necessary.
c) Need to look at two attributes to find the certificates.
- Given the relative time involved, I think that most applications are
going
to pull down multiple attributes at once in any event. The time involved
in
pulling down extra bytes vs the time involved in establishing and
re-querying
to get the correct result seems to me to indicate that all possible
attributes
should be pulled at once if you even suspect that you might need this.
From
my days at Microsoft one of the worse things to do for performance was to
ask
anything new of the directory or message store. The cost of doing one
extra
RPC was just a killer.
d) Does not work with existing code bases as currently written.
- We are writing standards not documenting existing code. This implies
that
we need to do things right and not just document things that are wrong but
already
in use.
RESULT:
I have pulled the MAY text from the document for the following reasons:
1. The reason it was put in was to deal with size issues in the
directory.
After looking at this, the savings from not having the end-entity
certificate
duplicated in a single directory entry, but still having the entire chain
of
certificates above it duplicated in every end-entity record just seems a
bit
extreme. It would be possible for a server which really cared about space
to
do this operation itself, and do the space savings on chaining
certificates
as well.
2. The difficulty of moving an item from an LDAP to a non-LDAP location
where
the certificate is inserted or removed as appropriate seems to be a killer
type
problem.
If the searching abilities are not present, then we need to look at how to
add
them to the document, but I will need help from some real LDAP people on
how
to do this. Please provide me with the necessary set of text and
references
so that I can understand what you have suggested.
jim
http://www.nwlink.com
****************************************************************************
*
This confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
****************************************************************************
**