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 220.127.116.11". If the policy 18.104.22.168 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 "22.214.171.124 to 126.96.36.199" appears in a CA certificate somewhere in the chain, it means "what was known as policy 188.8.131.52 in the upper levels, is called 184.108.40.206 from this point downwards". Our validator, who initially requires policy 220.127.116.11, takes note that what he should now look for in subsequent certificates is 18.104.22.168.
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.