X.509 certificate policy mapping question

Question

So I'm a little confused how X.509 certificate policy mappings work. So let's say the following depicts my cert chain:

root CA ---> intermediary CA ---> client cert

Would the root CA have a policy mapping? If so how could there be a subjectDomainPolicy? If the subjectDomainPolicy is supposed to match the parent certs issuerDomainPolicy and the cert in question is the top level cert in the hierarchy, how can subjectDomainPolicy match anything? And if it can't match anything what should it be?

From the X.509 RFC:

   In general, certificate policies that appear in the
   issuerDomainPolicy field of the policy mappings extension are not
   considered acceptable policies for inclusion in subsequent
   certificates in the certification path.

How could that even be? If root CA, in the above diagram, has an issuerDomainPolicy, that's pretty much saying that the intermediary CA's policy should be the same, isn't it?

Answer 1

The idea behind certificate policies is that a policy applies to the complete certification process, from root down to end-entity, and this is reflected in the certificate by inclusion of the policy OID in all the certificates in the chain. Policies are "vertical". A validator (someone who validates the certificate chain) is supposed to have in its trust store the definition of acceptable policies, on a per-root basis. To picture this in simple words: a typical trust store entry should be something like "I trust this root CA (name+public key) for verifying certificates which comply to policy 1.2.3.4". If the policy 1.2.3.4 does not appear in all certificates in the chain, the validator will reject the chain.

However, in hierarchical PKI like what X.509 supports, it is common to have horizontal isolation: entities which control CA and sub-CA operates at distinct levels and each level has its own requirements and conventions. Therefore, a mechanism for dealing with such level-based changes has been including, and that's the certificate mappings. When a mapping "1.2.3.4 to 1.5.6.7" appears in a CA certificate somewhere in the chain, it means "what was known as policy 1.2.3.4 in the upper levels, is called 1.5.6.7 from this point downwards". Our validator, who initially requires policy 1.2.3.4, takes note that what he should now look for in subsequent certificates is 1.5.6.7.

This process is made more complex by the following characteristics:

• You can map one OID to several OIDs.
• There is a special OID called "anyPolicy" which is a wildcard: it matches all policies.
• Each certificate in the chain can prohibit the anyPolicy, or require an explicit policy from some point in the path.
• A lot of widely deployed CA get it completely wrong and use policies as a kind of comment (in particular, they give each CA a single CA-specific policy OID, which the CA includes in its certificate, without any mapping).

So the sad state of affairs is that certificate policies, as currently deployed, do not work as was intended. Trust stores contain only root CA without any set of policies (i.e. all policies are accepted for paths starting with these roots, and no explicit policy is required -- the "policy tree" is allowed to be empty).

Root CA in themselves do not contain policy mappings. They are not real certificates. A root CA, known in the standard as a trust anchor, is the a priori knowledge of a name and associated public key. A pervasive tradition is to encode root CA as certificates, often self-signed (because there is a non-optional "signature" field in a certificate). The certificate format is just convenient for that. However, certificates may contain a lot of features (in particular many extensions) which make no sense for root CA; policy mappings are such features.