[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ldapv2-schema and CA Certificates
I just want everyone to know that path development efficiency becomes
more of a concern in non-hierarchical PKI domain. That domain may need
some of the mechanisms I am advocating.
-----Original Message-----
From: WHenry [SMTP:WHenry@pec.com]
Sent: Friday, August 14, 1998 10:43 AM
To: 'Steven Peterson'
Cc: 'ietf-pkix@imc.org'
Subject: RE: ldapv2-schema and CA Certificates
As previously noted, DoD's DMS program is a heirarchical PKI
(with a root
CA and subordinate military service/agency CA's). Entrust was
noted as
supporting a non-heirarchical or bilateral PKI.
It might be helpful to consider the following when discussing
different
PKI "communities."
The information exchange requirements (i.e.
communication) for DoD
(i.e. DMS) and the public at-large are VASTLY different. I don't
think
there's a commander in the U.S. military that intends to cross
certify their
DMS root CA with someone/group outside of DoD. There was
discussion
concerning cross certifiying with NATO nations and the like, but
I don't
believe it's been done (nor are there any plans to do so? I may
be wrong on
that). Therefore, if your PKI serves a closed community, why
demand a
standard for non-heirarchical communities (such as Entrust)?
DoD's Medium Assurance PKI does address communications between
DoD and
commercial/non-DoD entities (using COTS PKI software (Netscape
Certificate
Server last I heard)). It would be nice to hear from DoD/MISSI
folks on the
relationship between DMS and the Medium Assurance PKI. Aren't
these
different/competing requirements?
If DoD is embracing COTS PKI for external communications
purposes, why is
DoD/MISSI/DMS (internal DoD comms only) pushing to affect
changes to the
IETF standard(s)?
Bill Henry
Performance Engineering Corporation
> -----Original Message-----
> From: Steven Peterson [SMTP:Steven.Peterson@chromatix.com]
> Sent: Friday, August 14, 1998 7:33 AM
> To: Dave Horvath; Larry Layten; Nada Kapidzic Cicovic
> Cc: ietf-pkix@imc.org; 'kpcm'
> Subject: Re: ldapv2-schema and CA Certificates
>
> Here's the problem we are faced with:
>
> The X.509 standard has been implemented in two different ways.
One
> community stores hierarchical certs in the
crossCertificatePair attribute.
> Another community stores hierarchical certs in the
cACertificate
> attribute.
>
> The defect report is written to accommodate the community that
stores
> hierarchical certs in the crossCertificatePair attribute.
Where does that
> leave the other community?
>
> One might argue that the verbiage in the defect report doesn't
mandate
> that all communities use the crossCertificatePair attribute
for storage of
> hierarchical certs (since "may" is used in the report). But
since "may"
> IS used, it doesn't solve the problem of where to store
hierarchical
> certs, so why even have the defect report?
>
>
> Pete
> Chromatix
>
>
> -----Original Message-----
> From: Nada Kapidzic Cicovic < nada@cost.se
<mailto:nada@cost.se>>
> To: Dave Horvath < dave@chromatix.com
<mailto:dave@chromatix.com>>; Larry
> Layten < larry@ljl.com <mailto:larry@ljl.com>>
> Cc: ietf-pkix@imc.org <mailto:ietf-pkix@imc.org> <
ietf-pkix@imc.org
> <mailto:ietf-pkix@imc.org>>; 'kpcm' <
kpcm@postoffice.xservices.com
> <mailto:kpcm@postoffice.xservices.com>>
> Date: Friday, August 14, 1998 3:31 AM
> Subject: 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
> <mailto:dave@chromatix.com>
> >>
> >