10

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?

3
  • Can you explain what is different in this question from your earlier one?
    – Rory Alsop
    Commented Mar 11, 2012 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
    Commented Mar 12, 2012 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
    Commented May 30, 2012 at 11:44

2 Answers 2

6

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 1.2.3.4.5 only if all certificates in the path were issued in ways compatible with policy 1.2.3.4.5, a property that the certificates themselves advertise by containing policy 1.2.3.4.5 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.

3
  • 2
    +1 There are great many CAs who get Certificate Policies wrong... This is using the extension as a kind of glorified comment Commented Jan 4, 2013 at 1:02
  • Do you know any recommended reference that explains (in simpler terms) the concept of certificate policies, other than the extensive and formal tools.ietf.org/html/rfc3647? Commented Apr 29, 2017 at 2:27
  • If there's a certificate without the Certificate Policies extension, should it be considered as 0 polices or as non-relevant in the validation for the policy tree?
    – not2savvy
    Commented Feb 15, 2023 at 14:09
4

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

https://www.rfc-editor.org/rfc/rfc2527

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .