RE: CERTDIST

[Bruce Greenblatt <[e-mail]>]

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:[e-mail]]
>> Sent: Tuesday, April 11, 2000 11:11 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]
>> 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" <[e-mail]>
>> > > From: Russ Housley <[e-mail]>
>> > > Subject: Re: which usercertificate attribute
>> > > Cc: [e-mail]
>> > >
>> > > 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