[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE: ldapv2-schema and CA Certificates
>Putting the interoperability burden on clients would be a very unfortunate
>outcome.
But it may be inescapable.
I was going to comment on Santosh's suggestion to the effect that it seemed
very CA-centric, and understandable from that point of view, but didn't
necessarily accommodate a repository that publishes certificates from a
number of different CAs.
The problem as I see it is that the "domain" or the "hierarchy" is strictly
dependent on the point of view of the relying party. It is the RP that
chooses the root that she considers to be acceptable for certifying other
CAs, not the repository.
Unfortunately, what root is acceptable may vary depending on the application,
or even the context within an application. Even within the confines of certificates
issued by one organization, e.g., VeriSign, I may accept class 1, 2, or 3 certificaes for
one context within my S/MIME application, and only class 3 certificates if I am
doing something else using the same application.
Unfortunately, the structure of the directory pretty well has to be fixed. And in
the schema (presumably) can't change depending on which user is retrieving
certificates, much less on a particular context within an application.
Bob
>
>> ----------
>> 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
>>