Subject: RE: forward & reverse elements - population

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Sep 1998 12:05:30 -0400

Denis:

I agree with you.  Clarification of the text is easy.  However, I have a
question.  Must a certificate issued to a CA appear in the forward
element, caCertificate or can it be missing altogether?

I think the text in terms of saying that the forward element need not be
present in all cases is easy.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 8:44 PM
> To:	Santosh Chokhani
> Cc:	'Sharon Boeyen'; [email-masked]'
> Subject:	Re: forward & reverse elements - population
> 
> Santosh,
> 
> Your new proposed text does not address my concern correctly.
> 
> For a crossCertificatePair Attribute, either the forward element only
> MAY be present, or the reverse element only MAY be present, or the
> reverse and the forward elements may be both present.
>  
> Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward
> element
> shall not be mandated to be present in a crossCertificatePair
> Attribute.
> 
> Denis 
> 
> > Sharon:
> 
> > I can agree to the following text for the two option instead.
> Please
> > note that I have further clarified cross-certificate by tying the DN
> and
> > public keys.
> > 
> > I think the following texts are consistent with and further
> > clarifications of the two options.
> > 
> > I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> > 
> > NEW PROPOSED TEXT FOR OPTION 1
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store certificates
> > issued to this CA by CAs in other domains.  Optionally, the reverse
> > element of the crossCertificatePair attribute, held in a particular
> CA's
> > directory entry, may contain a subset of certificates issued by this
> CA
> > to other CAs.  When both the forward and the reverse elements are
> > present, issuer name in one certificate shall match the subject name
> in
> > the other and vice versa, and the subject public key in one
> certificate
> > shall be capable of verifying the digital signature on the other
> > certificate and vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > NEW PROPOSED TEXT FOR OPTION 2
> > 
> > The cACertificate attribute, held in a particular CA's directory
> entry,
> > shall be used to store certificates issued to this CA by CAs in the
> same
> > domain as this CA.
> > 
> > The forward element of the crossCertificatePair attribute, held in a
> > particular CA's directory entry, shall be used to store all
> certificates
> > issued to this CA.  Optionally, the reverse element of the
> > crossCertificatePair attribute, held in a particular CA's directory
> > entry, may contain a subset of certificates issued by this CA to
> other
> > CAs.  When both the forward and the reverse elements are present,
> issuer
> > name in one certificate shall match the subject name in the other
> and
> > vice versa, and the subject public key in one certificate shall be
> > capable of verifying the digital signature on the other certificate
> and
> > vice versa.
> > 
> > In the case of V3 certificates, none of the above CA certificates
> shall
> > include a basicConstraints extension with the cA value set to FALSE.
> > 
> > The definition of domain is purely a matter of local policy.
> > 
> > > -----Original Message-----
> > > From: Sharon Boeyen [SMTP:[email-masked]]
> > > Sent: Tuesday, September 08, 1998 5:46 PM
> > > To:   [email-masked]'; 'Santosh Chokhani'
> > > Subject:      RE: forward & reverse elements - population
> > >
> > >
> > >
> > > > ----------
> > > > From:       Santosh Chokhani[SMTP:[email-masked]]
> > > > Sent:       September 8, 1998 10:05 AM
> > > > To:         'Sharon Boeyen'; [email-masked]'
> > > > Subject:    RE: forward & reverse elements - population
> > > >
> > >       --stuff deleted
> > > > >
> > > >     []  I agree.  I do not have problem with the following
> language.
> > > > " A certificate issued to a CA by another shall be stored either
> in
> > > the
> > > > caCertificate or forward component of crossCertificatePair
> attribute
> > > of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA."
> > > >
> > > >     Please note that to me subset includes none, some, or all.
> If
> > > > folks want further clarification, it is ok by me.
> > > >
> > > Santosh, the only issue I have with this text is that (at least
> with
> > > the
> > > rationale behind option 2) any cert that appears in the
> cACertificate
> > > attribute of a given CA
> > > entry, should also appear in the crossCertificatePair attribute in
> the
> > > same
> > > CA entry.
> > >  What about deleting the reference to the cACertificate attribute
> from
> > > your
> > > text and proposing this as new text just for the
> crossCertificatePair
> > > attribute?
> > >
> > > Both Jan and David have indicated reasons to keep the "pair"
> together
> > > in the
> > > mutual case, so we should also consider adding the last paragraph
> of
> > > the
> > > text David proposed for that.
> > >
> > > Here's what the resulting text proposal would look like:
> > >
> > > > " A certificate issued to a CA by another shall be stored in the
> > > > forward component of crossCertificatePair attribute of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA. When both elements are present in the same
> value,
> > > the
> > > > value shall represent a mutual cross-certification of the two
> CAs. "
> > > >
> > > If we can come to consensus on that attribute, then let's see what
> we
> > > can do
> > > with the cACertificate attribute text.
> > >
> > > I agree with your view on what a subset is and I think that same
> > > definition
> > > would apply to the contents of the cACertificate attribute as a
> subset
> > > of
> > > the crossCertificatePair forward elements in option 2.
> 
> -- 
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 11 Sep 1998 11:23:10 -0700

Santosh,

Here is my answer to your question.

> I agree with you.  Clarification of the text is easy.  

???

> However, I have a

"MUST" is the wrong verb. A certificate issued by another CA is not
mandated to be present at all. It MAY be present. 

Let me now re-phrase your question: May a certificate issued to a CA by
another CA appear in the forward element, caCertificate or can it be
missing altogether?

My answer is the following: It may only appear in the forward element of
a crossCertificatePair.

I was quite happy (and still am I !) with the original text. I still
wonder with the rational of the two buckets.

Up to now, none of the arguments about the notion of "local domain" has
proven to be non-controversy. If the notion of local domain is important
(I still wonder about it), there might be a different way to look at the
issue. LDAPv2 allows to query any server that offers that interface, so
different set of queries could be considered:

  1) Queries made to one or more local domain servers,
  2) Queries made to one or more public domain servers.

As the name indicates it, local domain servers may not be publicly
accessible, e.g. protected by firewalls or some other access control
methods. Local domain servers would publish only what is relevant for
their notion of local domain. They must publish everything that is
relevant. 

Public domain servers would have no notion of "local domain". They must
publish everything certificate that is pertinent to a CA entry that they
publish. If entries for CA1, CA4 and CA5 are present, then all
certificates issued by these CAs must be present and all
cross-certificates, if any, between these CAs must also be present.
However, a cross-certificate issued by the CA 7 for the CA 1 would not
need to be present.

Denis

---

From: Dave Horvath <[email-masked]>
Date: Fri, 11 Sep 1998 11:06:33 -0400

Dennis,
	
	See comments below.

> wonder with the rational of the two buckets.

	The problem with the original text is that it breaks the
implementations
that used the certificationAuthority-V2 object class.  That object class
stated
the caCertificate was mandatory.  

	This has been established and accepted, therefore the original text
is not an option anymore.

	We have heard arguments from both sides for option 1 and option 2. Each
of which have their own pros and cons.  I suggest we stick with those
two options
and move forward.

	Furthermore, Santosh has submitted strong technical arguments for
the two bucket approach.  The two bucket approach allows you to
logically
distinguish between two types of CA Certs without mandating that a CA
define
its policies with respect to bucket population.  If the CA publishes it
in 
the "wrong" bucket it will NOT compromise security and it will NOT cause
a 
denial of service, as long as clients look at both attributes.  It lead 
to inefficient path construction in the worst case, but that's a given
if you
have a one bucket approach.  

	Another issue is the duplication of certificates.  After profiling
at least one directory server we know that performance degrades after an
entry reaches a certain size.  In other words you can usually get
excellent
sub second response time out of a server ( in fact many responses per
second )
if the entry stays small.  As the entry grows in size, the response gets
slower.
We have tested with entries up to several megabytes in size and have
proved this.  Additionally, many companies still use small pipes for
their network infrastructure, and those pipes can be easily saturated. 
We should make a conscious decision to
attempt to minimize the amount of data a client will retrieve from a
single entry
while satisfying both option 1 and option 2 proponents.

> However, a cross-certificate issued by the CA 7 for the CA 1 would not

	Are you saying the schema/or the DIT structure will be different
for a CA in a public directory vs a private directory?  If so, I think
we are going down a dangerous path.  Given a globally unique DN why
would you want to do this?

Dave Horvath

-- 
               ================================================

      _/_/_/                   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  |  [email-masked]