Subject: RE: CERTDIST

From: Mike Just <[email-masked]>
Date: Wed, 12 Apr 2000 11:47:26 -0400

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