[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ldapv2-schema and CA Certificates
Putting the interoperability burden on clients would be a very unfortunate
outcome.
> ----------
> From: Santosh Chokhani[SMTP:chokhani@cygnacom.com]
> Sent: August 14, 1998 9:16 AM
> To: 'Dave Horvath'; Larry Layten
> Cc: ietf-pkix@imc.org; 'kpcm'
> Subject: RE: ldapv2-schema and CA Certificates
>
> Larry:
>
> Thanks for bringing the thread back in focus.
>
> I also agree that we should define something that accommodates both
> points of view.
I agree, but I don't agree that this text does so. Rather the text appears
to accommodate only the case where the efficiency is achieved if the
preferred path is constructed with the set of certificates issued from one
CA to another in the same domain (again I think the term domain can be
ambiguous) and does so to the detriment of interoperability and of efficient
path building on other bases. My point is that efficiency should be equally
possible on a number of different basis not just this one. Also in the
interests of interoperability, since a relying party really has no a priori
way to know what they should be looking for or how a CA has placed the
material in the directory, I propose that all the certificates be held in at
least one place with optimization being an optional additional feature
independent of the criteria used to establish the efficiency.
If we must have two attributes, would it be acceptable that all
certificates issued from one CA to another are placed in the
crossCertificatePairs attribute, separated into their respective forward and
reverse natures and those which are expected to be especially useful in
efficient path building for a community of relying parties be also
optionally placed in the cACertificate attribute? At least that way there is
one place any relying party can go to and can be assured they are getting
the complete information, but also another place to go if they are part of a
known community of relying parties which can make more efficient path
building from a subset of that information?
Regarding self signed certificates I really think they should be in the
cACertificate attribute because they don't fit cleanly into the
forward/reverse separation syntax of the crossCertificatePairs attribute.
Sharon
> I also agree with what Dave Horvath has suggested. The following are my
> thoughts. They are in line with what Dave has said.
>
> In order to support both positions, the interoperability burden can be
> put on the client.
>
> I propose the following language (be it in X.509, ldap or some other
> place)
>
> START OF SUGGESTED TEXT
>
> "The infrastructure components (namely the authority, repository or a
> directory) may populate certificates issued to an authority in the
> caCertificate, in the forward component of the crossCertificatePair
> attribute, or both attributes of the subject authority's directory
> entry. The clients should be designed to retrieve certificates from
> both of these attributes in order to develop certificate paths.
>
> However, in order to make the path development efficient, it is
> recommended that the certificates issued to the authorities in the same
> PKI domain as that of the issuing authority be stored in the
> caCertificate attribute. Similarly, the certificates issued to the
> authorities in the PKI domain(s) other than that of the issuing
> authority should be stored in the appropriate component of the
> crossCertificatePair attribute.
>
> Self-signed certificates may be stored in either or both attributes.
> However, when an authority rekeys itself and issues two self-signed
> certificate (one to certify the current public key with the new private
> key and another to certify the new public key with the current private
> key), these two certificates should be stored in the authority's
> crossCertificatePair attribute."
>
> END OF SUGGESTED TEXT
>
> Suggestion are welcome in the area of whether two cross certificates
> pairs should be created. In that scenario the forward and reverse
> certificates will flip flop in the two attribute values.
>
> If Sharon has preference for treating the self-signed certificate
> differently, we can revise the text accordingly.
>
> We should also include the following definition of a self-signed
> certificate.
>
> " A self-signed certificate is the one in which the issuer DN = subject
> DN and issuer alternate name = subject alternate name (if one extension
> is present, other must be present). The subject public key in a
> self-signed certificate may or may not be the companion of the private
> key used to sign the certificate"
>
> -----Original Message-----
> From: Dave Horvath [SMTP:dave@chromatix.com]
> Sent: Thursday, August 13, 1998 8:14 PM
> To: Larry Layten
> Cc: ietf-pkix@imc.org; 'kpcm'
> Subject: Re: ldapv2-schema and CA Certificates
>
> All,
>
> I don't think we are too far apart if we make the following
> assumptions
> and support the conclusion listed below.
>
> 1) Entrust-enabled products currently use
> non-hierarchical
> (bi-lateral) cross certification. (Sharon is this
> correct?)
> I also note that Entegrity implemented to the
> ldapv2-spec
> so we will need concurrence from them.
>
> 2) Other communities such as DOD use a hierarchical
> CA model at this time.
>
>
> We propose we modify the X.509 defect report and ldap-v2 spec to
> place
> all hierarchical CA certificates in the cACertificate attribute
> of that
> particular CA's entry. Self signed CA certificates shall also
> be placed
> in the cACertificate attribute.
>
> The non-hierarchical (bi-lateral) CA's certificates shall be
> placed in
> the crossCertificatePair attribute. When DOD implements cross
> certification, it will then start populating the
> crossCertificatePair
> attribute. When Entrust implements a hierarchical model, the
> hierarchical CA's certificates shall be placed in the
> cACertificate
> attribute.
>
> This approach allows all parties to do business the way they
> have been.
>
>
> Regards,
> Dave Horvath, Pete Peterson
>
> Larry Layten wrote:
> >
> > I am sorry that I brought up "political issues".
> >
> > Perhaps someone out there could summarize the pros and cons
> > of each approach.
> >
> > Maybe someone could propose a way that a structure could
> > be built that would incorporate both approaches, allowing for
> > interoperability between the approaches based upon a mapping
> > to the appropriate method and programming for both.
> >
> > Non-flamming responses only please! My mailbox is full :-)
> > Larry
> >
>
> --
> ================================================
>
> _/_/_/ David J. Horvath
> _/ _/
> _/ _/ Chromatix, Inc.
> _/ _/ _/ 10451 Twin Rivers Road, Suite 265
> _/ _/_/ Columbia, MD 21044
> _/ _/ _/_/ Phone: (301) 596-8466 |
> http://www.chromatix.com
> _/_/_/ _/ _/ Fax: (410) 997-4306 | dave@chromatix.com
>