[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ldapv2-schema and CA Certificates
Sharon Boeyen wrote:
>
> 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.
Could you please explain why this is a detriment of interoperability and
of efficient path building on other bases. If you want to retrieve all
CA certificates, just invoke a search request specifying the OIDs of
both attributes. I believe your requirement is satisfied by issuing one
search request. Why is this a problem, unless you have an installed
base issue? If the problem is installed base, I understand.
> 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.
How can you make the statement "since a relying party really has no a
prior way to know what they should be looking for or how a CA has placed
the material in the directory"? We are attempting to define the rules.
The only way you can make this statement is if you don't allow us to
define the rules. Then we have chaos.
Again, if your interests are backward compatibility I understand your
concern.
>
> 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?
I really cannot see any technical advantage to storing all the
certificates in one place. Only a technical disadvantage since there is
no organization to the data and we cannot make processing decisions.
It's just not organized, and if it is not organized it is less efficient
in this case. Again, the relying party can issue one search request
with both OIDs to get all certs if that's what you really want.
Otherwise we can make a decision.
By drawing a clean line between internal and external domains we can
make decisions on path building. I do want to point out that the
directory should not be used for making path "certification" decisions
(unless you really trust your directory), just efficient path
construction decisions.
>
> 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.
Agreed!
>
> 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
> >
--
================================================
_/_/_/ 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