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.
******************************************************************************