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:
- CPS Pointer
- 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”:
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:
- Certificate Policies extension must appear in all certificates in the chain except root certificate.
- 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).
- Certificate policy OID presented in leaf certificate must be valid for entire certification path.
- 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 CA – no Certificate Policies extension
Policy CA – Certificate Policies extension with one or more policies
Issuing CA – Certificate Policies extension with one or more policies
Leaf certificate – Certificate Policies extension with one or more policies
In a 2-tier hierarchy, the path is shorter, but the same rules apply:
Root CA – no Certificate Policies extension
Issuing CA – Certificate Policies extension with one or more policies
Leaf certificate – Certificate Policies extension with one or more policies
Remember that these configurations are invalid:
Root CA – no Certificate Policies extension
Policy CA – Certificate Policies extension with one or more policies
Issuing CA – no Certificate Policies extension
Leaf certificate – Certificate Policies extension with one or more policies
Root CA – no Certificate Policies extension
Issuing CA – no Certificate Policies extension
Leaf certificate – Certificate 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!
Great post (as always)! Small spelling mistake, "tow" should be "two". Looking forward to more posts :-)
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!
> Why exactly do you not want issuing policy extensions in the root CA certificate?
There are two things to consider:
- 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.
- 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.
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
I'v prepared apopriate CAPolicy befor install IssuingCA but button called “Issuer Statement” dosen't work, any idea why? :(
[Company Internal Policy]
OID=x.x.x.x.x.x.yyyyy.zzz.a.b
URL=http://pki.company.ad/pki/cps.html
[Mobica Extended Validation Policy]
OID=x.x.x.x.x.x.yyyyy.zzz.a.b
URL=http://pki.company.ad/pki/cps.html
[AllIssuancePolicy]
OID=2.5.29.32.0
URL=http://pki.company.ad/pki/cps.html
Is Certificate Policies extension presented in certificate? I suspect that there is no such extension, thus Issuer Statement button is inactive. I believe that your INF is malformed and certificate policies sections were skipped.
You have right, certificate policies sections were skipped, I have no ide why? :(
This is my orginal CAPolicy.inf, I have the same at test and everything is ok?
Can I fix it without reinstall IssuingCA,
[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies="Company Internal Policy","Company Extended Validation Policy",AllIssuancePolicy
Critical=FALSE
[Company Internal Policy]
OID=1.3.6.1.4.1.xxxxx.yyyy.a.b
URL=http://pki.company.ad/pki/cps.html
[Mobica Extended Validation Policy]
OID=1.3.6.1.4.1.xxxxx.yyyy.a.b
URL=http://pki.company.local/pki/cps.html
[AllIssuancePolicy]
OID=2.5.29.32.0
URL=http://pki.company.local/pki/cps.html
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
CrlPeriod=Weeks
CrlPeriodUnits=1
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=12
LoadDefaultTemplates=FALSE
[Extensions]
2.5.29.15=AwIBBg==
Critical=2.5.29.15
I have checked Certificate Templates console and I see "Company Internal Policy and OID"
strange???
Try to remove spaces from INF section names.
Didn't help :(
Post your query to MS TechNet Security forum.
> 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.
According to this statement below chain is not a valid one:
- Issued Certificate Policies:
- Policy Identifier=2.16.12.3.2.1.1
- Policy Identifier=2.16.12.3.1.3.1.1
- Issued by Certificate Policies:
- 2.16.12.3.2.1.1
Is it? and what standard/rfc states this?
In a given scenario, only policy with ID=2.16.12.3.2.1.1 is valid, because it is presented in CA certificate and leaf certificate. Certificate policy processing rules are described in RFC 5280 §6.
I have read the RFC section 6 but unable to extract below result from it.
once policy is explicitly defined at 2nd level, all certificates below shall contain only valid policies. In other words, child CAs may define all or subset of policies defined in the 2nd level CA certificate. Certificates below cannot extend this list.
Can you please guide me in this?
What result you were able to extract? Again, each certificate policy is evaluated/validated separately. In order to consider the policy OID valid, it must present in all certificates below root (root is excluded) down to leaf certificate. If particular policy is not presented in all certificates below root, this policy OID is considered not valid.
> In order to consider the policy OID valid, it must present in all certificates below root (root is excluded) down to leaf certificate. If particular policy is not presented in all certificates below root, this policy OID is considered not valid.
If the above statement is considered true then below two certificates issued by publically trusted CAs would carry invalid policy OID
- www.signinghub.com
- Policy Identifier=1.3.6.1.4.1.8024.0.2.100.1.2
- Policy Identifier=2.23.140.1.1
- Issued by "QuoVadis EV SSL ICA G1"
- Policy Identifier=1.3.6.1.4.1.8024.0.2.100.1.2
- Issued by "QuoVadis Root CA 2"
Policy Identifier=2.23.140.1.1 is not present in the Issuer "QuoVadis EV SSL ICA G1" of cetificate for www.signinghub.com. Similarly for below one where Policy Identifier=1.3.6.1.4.1.11129.2.5. not present in issuer certificate:
- *.google.com
- Policy Identifier=2.23.140.1.2.2
- Policy Identifier=1.3.6.1.4.1.11129.2.5.3
- Issued by "GTS CA 1O1"
- Policy Identifier=2.23.140.1.2.2
- Issued by "GlobalSign"
In a given example (www.signinghub.com), the following policy are VALID:
- OID=1.3.6.1.4.1.8024.0.2.100.1.2 -- this policy is presented in all certificates in the chain below root.
the following policies are NOT VALID:
- OID=2.23.140.1.1 -- this policy is NOT presented in all certificates in the chain below root
Likewise in the second example, the following policies are VALID:
- OID=2.23.140.1.2.2 -- this policy is presented in all certificates in the chain below root.
the following policies are NOT VALID:
- OID=1.3.6.1.4.1.11129.2.5.3 -- this policy is NOT presented in all certificates in the chain below root
So, yes, both certificates carry invalid certificate policies. And if client application will validate certificates against invalid policies, certificate validation will fail.
RFC 5280 section 6.1.2 describes certificate policy graphically as under to describe certificate policies and path validation:
+----------------+
| anyPolicy | <---- valid_policy e.g Policy Identifier=1.3.6.1.4.1.8024.0.2.100.1.2
+----------------+
| {} | <---- qualifier_set CPS and User Notice, optional qualifiers
+----------------+
| {anyPolicy} | <---- expected_policy_set WHAT IS THIS?????
+----------------+
Is explicit policy set is a list of policies defined in CPS ??? If it is so then then above two certificate shared by me would be valid as CPS includes 1.3.6.1.4.1.11129.2.5.3 although it is not present in Issuer Certificate. Is it right??
What you show is initial policy state created during initialization. Initial policy set is "anyPolicy" which is a special policy with OID=2.5.29.32.0 which accepts all policies. Processing rules are provided on next pages: 81 and 82 which explains how policies are processed. On page 81, you can find a diagram that matches what I'm trying to say:
For example, consider a valid_policy_tree with a node of depth i-1 where the expected_policy_set is {Gold, White}. Assume the certificate policies Gold and Silver appear in the certificate policies extension of certificate i. The Gold policy is matched, but the Silver policy is not. This rule will generate a child node of depth i for the Gold policy.
Expected policies are Gold and White. But if actual policy is Silver, it is stripped as invalid. Only Gold policies are valid for "expected policy set = Gold".
> Is explicit policy set is a list of policies defined in CPS ???
no. expected policy set is dynamically built during each certificate processing.
> If it is so then then above two certificate shared by me would be valid as CPS includes 1.3.6.1.4.1.11129.2.5.3 although it is not present in Issuer Certificate. Is it right??
no.
Vadims Podāns! thanks for your support. You made things clear to me.
> no. expected policy set is dynamically built during each certificate processing.
One more question. As you said expected policy set is built dynamically, what is the source of this list. Is it comes from the Certificate Policy extention of the issuer (i.e. nod of depth i-1)?
> what is the source of this list.
Exactly what you mentioned in your previous comment -- "anyPolicy". "anyPolicy" is not a general word, it is a special (defined in RFC 5280) policy identifier that matches all policies. This is why root CA do not need to define any policies, "any policy" is implied. And this expects any policy. Once you define Gold and White policies at 2nd level, you start to constrain them.
Are we saying that the below two certificates are issued violating RFC 5280:
1----
- *.google.com
- Policy Identifier=2.23.140.1.2.2
- Policy Identifier=1.3.6.1.4.1.11129.2.5.3
- Issued by "GTS CA 1O1"
- Policy Identifier=2.23.140.1.2.2
- Issued by "GlobalSign"
- No policy
2----
- www.signinghub.com
- Policy Identifier=1.3.6.1.4.1.8024.0.2.100.1.2
- Policy Identifier=2.23.140.1.1
- Issued by "QuoVadis EV SSL ICA G1"
- Policy Identifier=1.3.6.1.4.1.8024.0.2.100.1.2
- Issued by "QuoVadis Root CA 2"
- No Policy
I cannot believe GlobalSign and Quovadis interpreted the RFC 5280 incorrectly and they have issued millions of certificates and none of the certificate was ever challenged. The CA product they are using has a bug that it allowed issuing these SSL certificates
There must be a reference that how the above two certificates are valid.
> Are we saying that the below two certificates are issued violating RFC 5280
partially. Some policies in the certificate are not RFC5280 compliant. However, they can be valid if certificate policies check is done differently than described in RFC.
> I cannot believe GlobalSign and Quovadis interpreted the RFC 5280 incorrectly and they have issued millions of certificates and none of the certificate was ever challenged.
normally, client applications do not enforce policy validation, therefore certificates are validated normally. But if client application attempts to validate the certificate against invalid policy, certificate validation will fail. Most likely GlobalSign use these policies just to put reference to some of their policies in certificate.
As per RFC 5280 section 4.2.1.4. Certificate Policies, the semantics of end entity certificate and a CA certificate are different as following:
For the end entity certificates, the policy indicates the terms under which the certificate is issued and the purpose for which the certificate can be used.In a CA certificate, the policy information terms limit the set of policies for certification paths that include this certificate.
According to PKITS test cases which are written according to the rfc3280 which is obsoleted by rfc5280, the certificate policy validation is not only performed based on the list of certificate policy OIDs of the issuer but a number of other parameters as following:
- initial-policy-set
- initial-explicit-policy
- initial-policy-mapping-inhibit
- initial-inhibit-any-policy
Above is also documented in rfc5280 section 6.1
There fore, for endentity certificate Issueing CA would have a list of policy OIDs (expected_policy_set) for end entity certificate instead of certificate policy OIDs in Issueing CA Certificate. Is it?
> In a CA certificate, the policy information terms limit the set of policies for certification paths that include this certificate
If CA certificate doesn't include particular policy, then any such policy in end entity certificate is not valid for the chain. Period.
Post your comment:
Comments: