Subject: Cert Path Validation in pkix-new-part1

From: "Ozols, Maris" <[email-masked]>
Date: Tue, 4 Apr 2000 15:26:35 +0930

Hi,

I have a question about pkix-new-part1.

My understanding is that a major reason for the new-part1 was to deal with
certificates that validated under RFC2459, when they really ought not to
have. It seems that policy mappings can still be used to introduce cert
policies in validated certificates which might have been thought excluded.  

Consider the following scenario. CA1 holds (is subject of) a cert with cert
policies {P-HIGH, P-LOW}, which then certifies CA2 (perhaps a child CA
within the same security domain) with a cert that only includes {P-LOW}. CA1
does not want CA2 to issue valid certificates with {P-HIGH} (perhaps because
they are linked to access control over which CA2 has no authority).

Then, provided that policy mappings are still permitted at this level, CA2
could issue a self-certificate (maybe when doing a rekey) with the policy
mapping {(P-LOW --> P-HIGH), (P-LOW --> P-LOW)}. Then CA2 may issue
certificates with the policy P-HIGH (and/or P-LOW). Alternatively, CA2 could
certifiy another CA3 (which is also not permitted to issue P-HIGH certs)
with the same mapping, and thus enabling CA3 to issue certs with P-HIGH. 

Is inhibitPolicyMapping the only way of avoiding such abuse (given the new
algorithm)? Note that this might not always be a viable option, as you may
wish to allow legitimate policy mappings from CA2. Consider the case where
CA2 is primarily involved with the external relations/e-commerce of your
organisation, and thus may need to have extensive flexibility to
cross-certify into commercial and business-partner PKI's. However CA2 is
considered too exposed to be permitted to issue P-HIGH certificates (which
are only intended for internal use). 

It might be a preferable to consider an algorithm such that when issuers
explicitly omit cert policies down the chain (as CA1 did for P-HIGH to CA2)
that these be tracked in the algorithm as an excluded set which can't be
mapped into. Is this an option worth pursuing? Alternatively, maybe there
should be some words to explain that the cert policies extension in a CAs
certificate provides little control over a CA, if it is still permitted
policy mapping. More generally, it would be nice to have some guidance on
how cert policies and other associated extensions can achieve a given
outcome. I think that at the moment the 2459 (and new-part1) explanations of
the intended semantics of cert policies for end-entity certs is simple and
well-defined, but this is not the case for cert policies in CA certificates.

Maris

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 04 Apr 2000 16:06:05 -0400

Maris,

I understand your concern with the possibility that a CA could use policy mapping to issue certificates under policies that it was not "authorized" to use. However, I do not believe that the problem is a great as you suggest.

Using your example, the policy tree created by the path processing algorithm would look something like this (although the P-HIGH at Level 1 would be deleted):

Level 0:        any-policy
                 /       \
                /         \
Level 1:   P-HIGH        P-LOW
                            |
                            |
Level 2:                 P-LOW
                         /     \
                        /       \
Level 3:            P-LOW     P-HIGH

As you suggest, in this scenario an end-entity could be issued a certificate under the policy P-HIGH. However, I believe that a relying party accepting such a certificate path would treat the path as if it had been accepted under the policy specified at Level 1 (P-LOW in this case). The reason for this is that the policies at Level 1 are the policies of the relying party's domain and thus, presumably, the policies that the relying party understands. In general, the relying party should not expect to be familiar with the policies that appear further down in the tree, as these policies may have been introduced as a result of policy mapping. So, while CA2 may succeed in issuing certificates under a policy that CA1 did not authorize it to use, this does not result in CA2's end-entities being granted any additional privileges.

It should also be noted that the main reason for the change in the algorithm was to properly address issues of transitive trust. For example, suppose that Company A makes widgets and buys parts from Company B. In order to enable secure communication/purchasing/design sharing/etc., Company A and Company B cross-certify their CAs. Since Companies A and B are trading partners, each company trusts the other to properly issue certificates under its own policies. By cross-certifying, the relying parties at Company B can validate the certificates of employees at Company A. However, Company A also has a trading partner relationship with Company B's competitor, Company C. So Company A and Company B are cross-certified.

While Company A trusts Company C to issue certificates properly, Company B does not. In fact, Company B wants to ensure that its employees (acting as relying parties) will not validate any certificates issued by Company C no matter what the certificates that Company C issues look like.

In this scenario, Company B will issue a cross-certificate to Company A under policy P-A with policy mapping P-A --> P-B and with policy mapping inhibited. Similarly, Company A will issue a cross-certificate to Company C under policy P-B, with policy mapping P-B --> P-C. Using the new path processing algorithm, Company B's relying parties will reject all certificates issued by Company C. Using the old path processing algorithm, on the other hand, it would have been possible for Company C to get its certificates accepted by Company B's relying parties by issuing certificates under either policy P-B or P-A.