RE: ldapv2-schema and CA Certificates

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

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