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
From: Russ Housley <housley(_at_)spyrus(_dot_)com>
See draft-ietf-smime-certdist-04.txt for a description of
userSMimeCertificate. I think the document does a good job explaining why
userSMimeCertificate and userCertificate both exist.
Russ