[Top] [All Lists]


2000-04-12 11:30:22
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.:

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,


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

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


It is clear to me that we have not reached consensus on 
CERTDIST.  I cannot 
recommend forwarding this document to the IESG until this 
issue is resolved.  I hope that the  most interested parties 
can have an 
objective discussion and develop a solution that aligns with 


At 09:22 AM 04/11/2000 -0400, David P. Kemp wrote:

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

Can we get a clear statement that when the smimeUserCertificate
attribute is populated in an LDAP directory, it contains NO


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


Of course, Jim Schaad should be the one to answer this 
question.  He is 
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


At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote:


Certdist-04 section 4.5 explains:

  "If the SignedData object is to be published in 
  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 
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."


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

<Prev in Thread] Current Thread [Next in Thread>