All:
It is clear to me that we have not reached consensus on CERTDIST. I cannot
recommend forwarding this document to the IESG until this certificates
issue is resolved. I hope that the most interested parties can have an
objective discussion and develop a solution that aligns with the PKIX LDAP
schema.
Russ
At 09:22 AM 04/11/2000 -0400, David P. Kemp wrote:
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