[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ldapv2-schema and CA Certificates
Sharon:
I do not have a problem with storing intra-domain CA certificates in the
caCertificate attribute and storing all CA certificates (including
intra-domain) in appropriate component of the crossCertificatePair
attribute.
However, it may break some of the existing systems and products. I hope
other weigh in on that topic.
I also feel that it is important to know my position on efficient path
development. Having CA certificates in a single attribute as the
current ldap draft states, takes away the path development efficiency
away from the clients. I have not figured out an algorithm when this
helps.
My proposal never hurts path development efficiency and helps when we
have NON-HIERARCHICAL domains with spaghetti graph for trust model.
-----Original Message-----
From: Dave Horvath [SMTP:dave@chromatix.com]
Sent: Friday, August 14, 1998 6:37 PM
To: Sharon Boeyen
Cc: Larry Layten; 'Santosh Chokhani'; ietf-pkix@imc.org;
'kpcm'
Subject: 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