Part2: Certificate Policies extension – all you should know (part 2)


In this post I’ll discuss about Certificate Policies certificate extension. This article assumes that you have understanding about certificate chaining engine basics.

Intro

Not all certificates are the same or issued in the same way. Some certificates are issued in an automated way, some with minimal validation, but some with strong validation and even by requiring a face-to-face meeting. What is the difference here? In these case we usually say that these certificates were issued under different issuance policies.

A company may have certificate templates that are configured to require user key archival (for backup purposes) in the CA database. Another template requires that client certificates must be stored on smart cards. Thousands cases and each case may have a distinct issuance policy. Users should be aware about them. How? As per best practices, a company should have a written policy about their PKI usage. Your policy may be implemented as a single web page (or web site) or downloadable document and has common name: Certificate Practice Statement (CPS). IETF has developed a framework that helps PKI administrators to effectively create a CPS document. CPS Framework is defined in RFC3647. If certificate was issued under specific policy, this information shall be included in the certificate: Certificate Policies extension.

CPS describes the status of internal PKI, its structure and how it is functioning. It includes user and CA operations in standard and in non-standard cases, their obligations and liability. Standard operations describe procedures shall be taken to enroll for certificate and usage rules. Non-standard operations include (but not limit to) exceptional cases when client certificate is stolen or compromised in some other way. CPS shall describe user steps to report and revoke stolen or compromised certificate.

The following sections will focus on technical aspects of certificate policies extension.

Certificate Policies extension

As per RFC5280 §4.2.1.4, an entry in the Certificate Policies extension consist of a policy identifier (OID) at a minimum. Single Certificate Policies extension may contain multiple entries, an entry per particular policy. Policy identifier may be combined with one or more policy qualifiers. RFC5280 supports two policy qualifiers:

  1. CPS Pointer
  2. User Notice

CPS Pointer is an URL to a Certificate Practice Statement document that describes the policy under which the certificate in the subject was issued.

User Notice is a small piece of text (RFC recommends to use no more than 200 characters) that describes particular policy.

Microsoft requires that Certificate Policies extension must consist of a policy identifier and one or more policy qualifiers. Preferred policy qualifier is a CPS Pointer, because User Notice is very short and can’t provide enough information, while in CPS Pointer you can provide an URL to CPS document or web page. Another reason to use CPS Pointer is that when you open digital certificate in UI, there is a button called “Issuer Statement”:

image

Certificate GUI dialog looks for Certificate Policies extension in the certificate, and activates the button when found. By pressing the button, you are redirected to a first CPS Pointer URL where you can read certificate issuer statement.

Policy identifier, where to get?

Object Identifiers (OID) are controlled by IANA and you need to register a Private Enterprise Number (PEN), or OID arc under 1.3.6.1.4.1 namespace. Here is  PEN registration page: http://pen.iana.org/pen/PenApplication.page

When acquired, your OID namespace will look as follows: 1.3.6.1.4.1.{PENnumber}. You can assign certificate policies under your private namespace, for example:

  • 1.3.6.1.4.1.{PENnumber}.1.1 – Smart Card issuance policy
  • 1.3.6.1.4.1.{PENnumber}.1.2 – Digital signature certificate issuance policy
  • 1.3.6.1.4.1.{PENnumber}.1.3 – encryption certificate with key archival issuance policy
  • etc.

For general purpose CAs you can use an universal object identifier with value: 2.5.29.32.0. This identifier means “All Issuance Policies” and is sort of wildcard policy. Any policy will match this identifier during certificate chain validation.

Although, “All Issuance Policies” OID will cover any issuance (or certificate) policy, it do not allow you to restrict CA server to issue certificates only for specified policies. Because it is a wildcard policy identifier, it will override any explicit policy identifier. Therefore, All Issuance Policies identifier shall not be combined with any other policy in the same certificates. In other words: either, a list of allowed policies, or All Issuance Policies identifier. Do not combine!

Where to include Certificate Policies extension?

In order to stay conformant with RFC5280, any certificate policy must be valid for entire certification path (or certificate chain). 4 main rules apply when processing certificate policies extension:

  1. Certificate Policies extension must appear in all certificates in the chain except root certificate.
  2. Object Identifiers are not inheritable. This means that tow OIDs: 1.3.6.1.4.1.9999.1 and 1.3.6.1.4.1.9999.1.1 are different identifiers and they do not match each other (although, they share the same OID namespace).
  3. Certificate policy OID presented in leaf certificate must be valid for entire certification path.
  4. If Certificate Policies extension is missing in the CA certificate, no explicit certificate policies are allowed below that CA certificate.

First, why root CA certificate don’t need to have a Certificate Policies extension? It is because an implicit Certificate Policies extension with wildcard “All Issuance Policies” is implied for self-signed certificates. And no custom policies shall be defined at root level. Certificate Policies extension must appear at 2nd level (Policy CA in a 3-tier hierarchy, or Issuing CA when Policy and Issuing CA roles are combined in a 2-tier hierarchy). For example, Certificate Policies appearance in a 3-tier hierarchy:

Root CAno Certificate Policies extension
    Policy CACertificate Policies extension with one or more policies
        Issuing CACertificate Policies extension with one or more policies
            Leaf certificateCertificate Policies extension with one or more policies

In a 2-tier hierarchy, the path is shorter, but the same rules apply:

Root CAno Certificate Policies extension
    Issuing CACertificate Policies extension with one or more policies
        Leaf certificateCertificate Policies extension with one or more policies

Remember that these configurations are invalid:

Root CAno Certificate Policies extension
    Policy CACertificate Policies extension with one or more policies
        Issuing CAno Certificate Policies extension
            Leaf certificateCertificate Policies extension with one or more policies

Root CAno Certificate Policies extension
    Issuing CAno Certificate Policies extension
        Leaf certificateCertificate Policies extension with one or more policies

they are invalid, because non-root (presented in non self-signed form) CA certificate has missing Certificate Policies extension, while certificate below has Certificate Policies extension. Once Certificate Policies extension is not presented, no explicit policies are allowed.

This is almost all theoretical aspects of Certificate Policies extension. In the next post I will cover practical aspects. Stay tuned!


Share this article:

Comments:

Tom Aafloen
Tom Aafloen 05.03.2015 09:19 (GMT+2) Certificate Policies extension – all you should know (part 1)

Great post (as always)! Small spelling mistake, "tow" should be "two". Looking forward to more posts :-)

AndrePKI
AndrePKI 05.11.2016 00:22 (GMT+2) Certificate Policies extension – all you should know (part 1)

Why exactly do you not want issuing policy extensions in the root CA certificate? Is that specified in the RFC or is it that you can add polices later on to Issuing CAs without having to renew the root CA? We have Company High, Company Medium And Company Low certificate policies at the root CA. And in our two-tier hierarchy different issuning CAs each with one of the three issuing policies.

If we should change the root CA to allow All Issuing policies (the default, say), should we remove these from capolicy.inf and renew the root?

Also, how exactly does policy verification work (e.g. by certutil -verify leaf.crt)? Does that require the policies of the leaf certificate all to be present in each certificate in the chain (perhaps All Issuance policy at the root)? or must it just be present at the root? I can't quite figure out what happens and how to resolve the "one of the CA certificates in the chain is not trusted by the policy provider" message in the certutil -verify output.

Any insights greatly appreciated!

Vadims Podāns
Vadims Podāns 05.11.2016 23:57 (GMT+2) Certificate Policies extension – all you should know (part 1)

> Why exactly do you not want issuing policy extensions in the root CA certificate?

There are two things to consider:

  1. Root CA already have implicit "All Issuance Policies" identifier and policy limitation at that level makes little to no sense. This means that Certificate Policies extension absence in root certificate means valid wildcard policy. At other levels, policy identifiers must be presented explicitly.
  2. When policies are explicitly defined in root certificate, you cannot modify them (add a new one, or edit/remove existing) without renewing root CA certificates. This will significantly increase administrative overhead on root certificate distribution.

> If we should change the root CA to allow All Issuing policies (the default, say), should we remove these from capolicy.inf and renew the root?

I would do that. Remember that you will need to renew root certificate with new key pair.

> Also, how exactly does policy verification work

It is quite complex process (you can get example details in RFC5280). In short, policies are validated starting from the root certificate, down to leaf certificate. If there are no specific constraints and inhibit policies, then specific policy identifier must be presented in each certificate in the chain starting at level 2. Once the policy identifier disappears from certification path, it becomes invalid for that path (and any path below) (see 3rd example).

This means that policies can be restricted down in the chain, but not extended. If you define particular policy identifier at 2nd level, you will be unable to add another policy identifier at lower levels, because only that particular policy identifier may be valid at lower levels.

Juergen Key
Juergen Key 26.10.2017 17:26 (GMT+2) Certificate Policies extension – all you should know (part 1)

Hi,

thank you for this great write-up - i am just about to add the possibility to specify CPSs in my home-brew system for managing CAs. It is something for people with only a unixy terminal environment tired of typing endless openssl-statements: i use expect and ncurses to give prospective CA users easy to use tools for everyday tasks like issuing certificates or revoking them. After now being able to provide the opportunity to integrate CPS into certificates - my next tasks at hand are improvement of the documentation and a frontend for operating a TSA.

Thanks again for the information here - it helped me a lot and probably saved me some time...

Regards,

 

Juergen (and yes - it is really my name: working in IT security i often have to point this out...) Key


Post your comment:

Please, solve this little equation and enter result below. Captcha