Designing CP and CPS for multiple hierarchical CAs

Question

I am thinking about how to design and structure CP and CPS for multiple CAs build in a hierarchical manner and compliant to RFC 3647.

The structure of CAs in build from one Root CA to multiple subordinate CAs each serving different PKI service and certificate profiles:

Root CA --> CP0 and CPS0

• Sub CA 1 --> CP1 and CPS1
  • issuing VPN certificates
• Sub CA 2 --> CP2 and CPS2
  • issuing client certificates
  • issuing RA certificates
• Sub CA 3 --> CP3 and CPS3
  • issuing certificates for authentication with custom extension
• Sub CA 4 --> CP4 and CPS4
  • issuing certificates for devices
• Sub CA 5 --> CP5 and CPS5
  • issuing certificates for payment cards
  • issuing certificates for payment authorization
  • issuing certificates for merchant access
• etc...

Now I know what is OID and how to define CP in certificate together with URL to CPS. Currently only Root CA has defined "any policy" with OID 2.5.29.32.0. Every subordinate CA has its own definition of OID and therefore should have its own CP and CPS for PKI services it provides. But with growing number of Sub CAs it is really hard to maintain all of these CP and CPS.

What is the best practice how to handle complex PKI environments point of view of CP and CPS?

Should I start using OID on certificate profile level and not on Sub CA? And in that case create one or two CP with the definition of all OIDs related to certificates that can be issued?

In that case there can be one CP with:

• CP --> OID1
• issuing VPN certificates --> OID2
• issuing client certificates --> OID3
• issuing RA certificates --> OID4
• issuing certificates for authentication with custom extension --> OID5
• issuing certificates for devices --> OID6
• issuing certificates for payment cards --> OID7
• issuing certificates for payment authorization --> OID8
• issuing certificates for merchant access --> OID9

So I can maintain only one version of CP and several version of CPS related to PKI services different from each other or also only one CPS for whole environment?

Answer 1

Well, your design makes some sense for me and may be valid. If each policy has its own unique procedures (defined in CPS), then you may need to create as much policies as many different policies are defined. Even if they operate under the same PKI Management Authority.

Your question requires some research to examine the procedures for each certificate type. For example, are there any difference between issuing VPN certificates and issuing certificates for authentication with custom extension? What kind of difference? Usually, most important difference includes (but not limited to):

• The way how certificate applicant is authenticated (say, can request the certificate by email, or through face-to-face meetings and handsigning the document, requirements the applicant must meet, etc.)
• The way how certificate is delivered and stored (say, the policy requires to store certificates on smart cards only)
• Does the policy allow key recovery?
• ...

In other words, sections §4.3 and §4.4 can be different for a single PMA (the rest paragraphs are usually the same across all policies) and each set will require separate CP. Then, if two or more CAs operate under the same CPS (has no significant differences that may be critical to software where multiple certificates may be presented, but only specific are accepted based on a policy), then you can merge and assign the same CP/CPS to these CAs.

For example, it doesn't seem to have notable difference between CP1 and CP4. You may consider to merge them in one CP. CP3 makes very little sense in terms of CP. The fact that certificate includes some extra extension means literally nothing, because it (most likely) doesn't employ distinct practices and procedures. You may consider to get rid of this CP at all. CP2 may be merged with CP1 and/or with CP4. CP5 is the only policy that seems to require a separate CP, because these certificates falls (most likely) under highest insurance level and the most strict requirements.

When you examine all policies, you may end up with only two policies: CP1 assigned to SubCA1-SubCA4 and CP2 assigned to SubCA5 with corresponding OIDs (OID1 and OID2).

Regarding mapping between CP and CPS. You may create single CPS document and describe all policies in the same document. Like it was said, most sections (except §4.3 and §4.4) will be the same across all policies, because they operate under the same PMA. And provide separate §4.3 and §4.4 for each policy.

In addition, I would review entries for CP5. Each entry may have different policy OID. Certificates for merchant access and payment authorization may look the same, but there will be a software that will check whether the presented certificate falls under specified category (even though, they are issued under the same CP and CPS). Not sure how they are used in your environment.

Tip: you should not define Certificate Policies extension at root CA level. An absence of Certificate Policies extension on root certificate implies Any Policy for it. First Certificate Policies appearance should be at level 2 in hierarchy. Most likely, all CAs are under the same administrative control and don't require a separate policy for CAs. However, if root CA (or subordinate CAs) is outsourced, you may need to move to 3-tier hierarchy with dedicated Policy CA under root that defines the policy attributed to 3-level CAs.