As long as we're talking about where to put certificates, I thought that
I'd point out a draft that I wrote, that I received some pretty good
feedback on. Check out the draft with the title: "LDAP Object Class for
Holding Certificate Information" at your favorite ietf drafts site, e.g.:
http://search.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-schema
-02.txt
It defines a "certificateType" structural object class, and "Use the
certificateType structural class to indicate that an object in the
directory is a specific type of certificate. Each cer-
tificateType object in the directory appears directly beneath the owner of
the certificate in the directory hierarchy."
Comments are welcome... Cheers,
Bruce
At 11:47 AM 4/12/2000 -0400, Mike Just wrote:
Two points.
1) I agree with David. The document must be clear that if using LDAP, user
certificates should be in the userCertificate attribute; user certificates
MUST NOT be in the userSMimeCertificate attribute. (In other words,
userSMimeCertificate is only used as a source of a user's S/MIME
capabilities.)
2) The document doesn't specify the behaviour of a client in the case that
the userSMimeCertificate attribute is not populated (with the user's S/MIME
capabilities). This might only require a reference to the similar
discussion in RFC 2633. Though there should be some indication that the
userSMimeCertificate attribute is not required to be populated in an entry.
Mike Just
-----Original Message-----
From: Russ Housley [mailto:housley(_at_)spyrus(_dot_)com]
Sent: Tuesday, April 11, 2000 11:11 PM
To: ietf-smime(_at_)imc(_dot_)org
Cc: jis(_at_)mit(_dot_)edu; MLeech(_at_)nortel(_dot_)ca
Subject: CERTDIST
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
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com