[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ldapv2-schema and CA Certificates
In addition to inconsistencies, comments are in-line. They are not the
final word until inconsistencies are resolved.
-----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:
The path development will start with subject certificate. In
this case the subject is Bob.
After a path is developed, path validation will begin from the
trust anchor and follow X.509 amendment process.
With my approach the algorithm will be as follows. I am assuming
your diagram and list of 2 paths are correct.
1. Get userCertificate issued to Bob. That is 1 issued by B2.
2. Is this my trust Anchor. Answer is no.
3. Get caCertificate and crossCertificatePair (forward) issued
to B2. I will get caCertificate = one from B1 and and crossCertificate
= one from A2.
4. I look for one of them to be my trust anchor and find A2 to
be so. I declare path development a success.
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