Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I asked another question about certificate policy mappings. This is a different issue. This is about Certificate Policies.

To quote from the X.509 RFC:

   In an end entity certificate, these policy information terms indicate
   the policy under which the certificate has been issued and the
   purposes for which the certificate may be used.  In a CA certificate,
   these policy information terms limit the set of policies for
   certification paths that include this certificate.  When a CA does
   not wish to limit the set of policies for certification paths that
   include this certificate, it MAY assert the special policy anyPolicy,
   with a value of { 2 5 29 32 0 }.

So say we have the following X.509 cert chain:

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

It sounds like the set of policies possessed by each child in the chain will always be a subset of the parents policies? Is that correct?

share|improve this question
Can you explain what is different in this question from your earlier one? – Rory Alsop Mar 11 '12 at 21:10
The questions are addressing different extensions for X.509. One is for policy mappings and the other is for policies. The ASN.1 representation for each is different, among other things. – compcert Mar 12 '12 at 22:26
Will -> SHOULD. It's correct but as you MAY know, RFC are often poorly implemented, especially to fit one's business needs. Many factors can influence this, in both good and wrong way. – Aki May 30 '12 at 11:44

The base idea is that a policy describes the certification process over the whole path, not just at the level of a given CA. Within a given certificate C, the Certificate Policies extension gives the set of policies to which the process which resulted in the creation of C conforms.

During validation (see section 6.1 of RFC 5280), the verifier computes the "policy tree". In simple cases (see below for possible complications), the leaves of valid_policy_tree at the end of the processing will be the intersection of the sets of policies in all certificates in the path (the steps "prune the policy tree" are what really computes the intersection). In simple words, the set of policy which you obtain at the end will be the set of policies which appear in all the certificates in the path. It is quite logical: you can say that a given path conforms to policy only if all certificates in the path were issued in ways compatible with policy, a property that the certificates themselves advertise by containing policy in their Certificate Policies extension.

It is not required that each certificate only uses a subset of the certificates from the upper CA. This would be ill-defined, because paths may merge (a given CA may obtain several certificates from several über-CA, and they could contain distinct policies). The intersection work is done at validation, when a single path is considered. Conceptually, there is no path until validation.

Possible complications:

  • There can be certificates without the Certificate Policies extension.
  • There can be policy mappings, which allow for replacing some policies with others along the path.
  • There is a special policy called anyPolicy which alters the processing.
  • There are extensions which can inhibit anyPolicy, and/or require an explicit policy, beginning with a given path depth.

I have encountered a great many CA which get it wrong with regards to policies; that is, they include in each certificate a (non critical) Certificate Policies extension where they put a unique policy which is specific to that CA. End result is that, upon validation, valid_policy_tree is empty (this is not fatal, since these certificates do not include any extension requiring an explicit policy). This is using the extension as a kind of glorified comment.

share|improve this answer
+1 There are great many CAs who get Certificate Policies wrong... This is using the extension as a kind of glorified comment – LamonteCristo Jan 4 '13 at 1:02

I found an example here that is a lot more detailed than the text you are quoting from:

Section 3.2 and 3.3. This seemed particularly relevant from Section 3.3.1 -

When processing a certification path, a certificate policy that is acceptable to the certificate-using application must be present in every certificate in the path, i.e., in CA-certificates as well as end entity certificates.

Reading it, it sounds like they may not be a mathematically perfect subset (the ones I've seen are usually written in English, anyway), but the policies of the entire path relate when an application chooses to trust a given end entity.

In practice, I believe a common example is to have the main CA chain reference a given policy that is fairly general, but then specialized CAs and their issues certificates may reference a more restrictive policy that fits within the generalized one, for a specialized usage.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.