RE: ldapv2-schema and CA Certificates

[Santosh Chokhani <chokhani@xxxxxxxxxxxx>]

Sharon:

There are inconsistencies in the text, certificate path and diagram.
Please make them consistent.

	-----Original Message-----
	From:	Sharon Boeyen [SMTP:sharon.boeyen@entrust.com]
	Sent:	Monday, August 17, 1998 12:43 PM
	To:	Santosh Chokhani; 'Andreas Berger'
	Cc:	ietf-pkix@imc.org
	Subject:	RE: ldapv2-schema and CA Certificates

	Perhaps if we work from a concrete example it will help ensure
we're
	understanding one another and then be in an easier position to
determine a
	path forward (no pun intended).

	Let's try a hypothetical example with two companies Company A
and Company B.
	Each company has a pair of CAs CA A1, CA A2, CA B1 and BA B2.
Alice works
	for Company A and her trust anchor is CA A1 and Bob works for
Company B his
	user certificate was issued by CA B2. CA A1 issued a certificate
to CA A2
	and also issued a certificate to CA B2. CA A1 issued a
certificate to CA B1
	and CA B1 issued a certificate to CA B2. Therefore, in this
example, there
	are 2 valid paths for Alice to verify Bob's signature:
	a) CA A2->CA B2; CA B2 -> Bob
	b) CA A2->CA A1; CA A1->CA B1; CA B1->CA B2; CA B2->Bob

	                      CA A1------------------------> CA B1
	                         /\
|
	                          |
|
	                          |
\/
	                      CA A2-----------------------> CA B2
	                 (Alice trust anchor)                   |
	                                                               |
	                                                              \/
	                                                             Bob

	In Santosh proposal (I'll ignore all certs not used to build
path for Alice
	to verify Bob's signature, I believe that:

	Directory entry for CA A2 contains:
	   cACertificate attribute containing certificate CA A2->CA A1
	   crossCertificatePairs attribute containing reverse
certificate CA A2->CA
	B2

	Directory entry for CA A1 contains:
	   crossCertificatePairs attribute containing reverse
certificate CA A1-.CA
	B1

	Directory entry for CA B1 contains:
	    cACertificate attribute containing certificate CA B1->CA B2
	    crossCertificatePairs attribute containing forward
certificate CA A1->
	CA B1
	   
	Directory entry for CA B2 contains:
	    crossCertificatePairs attribute containing forward
certificate CA A2 ->
	CA B2

	(Santosh, please correct if I have any of this wrong):

	Assume Alice has Bob's certificate signed by CA B2. Santosh, if
I understand
	your algorithm correctly, Alice would start with her trust
anchor CA A2 and:
	1. Check the cACertificate attribute of the directory entry of
CA A2
	          - not find a certificate issued to CA B2
	          - find a certificate CA A2->CA A1
	2. Either a) Check the cACertificate attribute of the directory
entry of CA
	A1
	                              - find no values of interest, so:
	                  Check the crossCertificatePairs attribute,
finding
	certificate CA A1->CA B1
	                  Then check the cACertificate attribute of CA
B1's entry,
	finding CA B1->CA B2
	    Or:
	             b) Check the crossCertificatePairs attribute of CA
A2 entry
	finding CA A2->CA B2

	-----------------

	With my proposal, the contents of the entries, that are relevant
to the path
	building would be:

	Directory entry for CA A2 contains:
	   crossCertificatePairs attribute containing reverse
certificate CA A2->CA
	B2

reverse
	certificate CA A2->CA A1

	Directory entry for CA A1 contains:
	   crossCertificatePairs attribute containing reverse
certificate CA A1->CA
	B1

forward
	certificate CA A2->CA A1 

	Directory entry for CA B1 contains:
	    crossCertificatePairs attribute containing forward
certificate CA A1->
	CA B1

reverse
	certificate CA B1->CA B2
	   
	Directory entry for CA B2 contains:
	    crossCertificatePairs attribute containing forward
certificate CA A2 ->
	CA B2

forward
	certificate  CA B1-> CA B2

	If Alice starts with her trust anchor and checks the
crossCertificatePairs
	attribute of the directory entry for CA A2 she will immediately
find the
	certificate CA A2->CA B2.

	Assuming your rules follow choice b) in step 2 then there is one
additional
	step for validating external signatures in your proposal,
(because you're
	querying one attribute at a time). If your rules follow choice
a) in step 2
	then there are many additional steps for validating external
signatures
	because you'll not catch the crosscertificatePairs attribute in
CA A2's
	entry and end up using the longer path rather than the shorter
one. In my
	proposal there is the same number of steps regardless of whether
the
	signature was internal or external.  

	I do not think that we should be mandating, or assuming which
direction a
	path is built (either as described above starting from the trust
anchor
	entry and progress to the subject or whether you start from the
subject CA's
	entry and build toward the trust anchor), nor do I think we
should be
	assuming that most uses will be internal to any given domain
(and I'm still
	nervous about the definition of exactly is meant by "a domain").
Depending
	on the operating environment and depending on the trust model,
these can
	vary and we should not preclude them as being just as valid
business
	scenarios as the one you describe where most use is internal and
path
	building is done by checking directory entries from the trust
anchor toward
	the subject.

	Sharon