Russ,
I too would like to resolve the outstanding issue of what attributes
are used to hold certificates, both End Entity and CA,
in the case where certificates are retrieved from an LDAP directory.
As I noted after the 22 October 1999 announcement of working group last
call for certdist-04, the paragraph added in response to Ella's concern
is an improvement, however it does not go far enough because it does
not require a single location that all applications can count on in
order to ensure interoperability. The text I proposed, quoted below,
does ensure that all applications can count on finding both EE and CA
certs in the PKIX-standard location, but it is not the only possible
text which would ensure this result. If Jim or anyone else has
alternate proposed text for interoperability when using LDAP, please
put it forward.
Blake agrees that the PKIX attributes should be mandatory for LDAP in the
SMIME cert-handling specification. I am concerned that if certdist-04
becomes an RFC, it will conflict with cert-handling and perpetuate
confusion over which LDAP attributes should be used. It will result
in hard-to-diagnose problems when some apps look in one directory
attribute and other apps look elsewhere, and it would not ensure
that SMIME and non-SMIME applications can share the same directory
infrastructure.
Can we get a clear statement that when the smimeUserCertificate
attribute is populated in an LDAP directory, it contains NO
certificates?
Regards,
Dave
Date: Mon, 10 Apr 2000 16:34:33 -0400
To: "David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil>
From: Russ Housley <housley(_at_)spyrus(_dot_)com>
Subject: Re: which usercertificate attribute
Cc: ietf-smime(_at_)imc(_dot_)org
Dave:
Of course, Jim Schaad should be the one to answer this question. He is the
author of CERTDIST. Note: The CERTDIST document is in Working Group Last
Call, so if there are issues, they need to be resolved NOW.
The paragraph that you are talking about was added because if comments
received from Ell Gardner at MITRE. If memory serves, she was concerned
about two locations in the Directory for the same information. The
paragrah that you quote is Jim Schaad's proposed solution: Get the certs
from userCertificates and the algorithm preference information
userSMimeCertificate.
Russ
At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote:
Russ,
Certdist-04 section 4.5 explains:
"If the SignedData object is to be published in userSMimeCertificate,
the end-entity certificates MAY be omitted from the certificate bag
and published in the userCertificates [sic] LDAP attribute instead."
How is an application developer supposed to interpret this requirement?
I would read it to say that since the EE cert MAY be in either attribute,
applications MUST look for it in BOTH attributes. But Terry Hayes'
posting indicates that (without an add-on) Communicator does not look
in the userCertificate attribute.
Section 2 justifies the inclusion of a cert path in the SignedData
object by claiming that in non-X.500 (DAP or LDAP) directories it is
difficult to impossible to obtain CA certificates. But it does not
follow through with that logic by *not* requiring a full cert path when
the object *is* stored in an LDAP directory.
Section 4.3 should be changed from:
"A chain of certificate from the end-entitycertificate(s) to the root
certificate(s) MUST be included in the CertificateSet."
to:
"A chain of certificate from the end-entitycertificate(s) to the root
certificate(s) MUST be included in the CertificateSet unless the
SignedData object is published in userSMimeCertificate, in which case
the CertificateSet MUST be empty."
and section 4.5 should be adjusted accordingly.
This would ensure that when using LDAP, applications always use the
PKIX-standard locations for both CA and EE certificates.
Dave Kemp