[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ldapv2-schema and CA Certificates



I am afraid the general solution is not that easy. 

Publishing certificates in one or another attribute seems to be less of a
problem. 

Retrieval and searching for certificates in proper attributes seems to be a
bigger problem. For example we are currently not even looking for
certificates in cACertificate attribute, since we do not use self-signed
certificates in our verification process. I suppose that Entrust based
applications will have the same problem in path building process.

Regards,

Nada

At 20:14 8/13/98 -0400, Dave Horvath wrote:
>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
>