Naming conventions for OIDs registered under the PKIoverheid arc v1.1

Table of Contents

1 Introduction

This document establishes the methodology for assigning OID numbers within the PKIoverheid arc, ensuring coherence and uniformity. It provides a versatile and instinctive OID structure for deployment starting from PKIoverheid architecture G4 onwards.

1.1 Changes between version 2.x and 3.x of this document

The 3.x version is a thorough revision of the original version 2.x series. The 2.x series has organically grown from the original inception onwards. Preparations for the major revision of the PKIoverheid Programme of Requirements (PoR) from series 2.x to 3.x has led to a revision of this OID document as well.

The biggest change between versions 2.x and 3.x of this document is the change to the English language since this will also be the case in version 3.x of the PoR. However, close examination of the 2.x series of this document also showed several shortcomings. Some of these could be easily fixed by retrofitting changes, others unfortunately cannot. Missing guidelines for expanding the PKIo OID-arc and subsequent organic growth are the main cause of this. The next paragraph describes how to mitigate this in future iterations of this document.

The major changes between version series 2.x and 3.x are:

  • The document has been translated to English.
  • Each OID node and node sequence has consequently been named (using ASN.1) and has been given a description; in series 2.x it was not always clear what was the name of a node, node sequence, or description.
  • To make it possible to clarify domains between different roots and root generations (which is needed for future iterations), identifiers (G1, G2, G3, Public, Private, EV) have been added in the name of relevant nodes and node sequences.
  • The definition of all nodes and node sequences now has been separated from the tables displaying relevant information in a more reader-friendly format.
  • Distinct parts of the OID tree have been places in separate chapters and paragraphs.
  • The status of each identifier has been clearly marked.

2 OID structure conventions

Because of missing guidelines for expanding the PKIo OID-arc for the first up to and including the third generation of PKIo hierarchies, organic growth occurred resulting in several inconsistencies or counter-intuitive sub-arcs. To remediate this for future iterations of the PKIo hierarchies, strict rules need be followed in both structure and naming conventions. This chapter defines these rules.

This OID naming structure only describes the Certificate Policy identifier and the Organization identifier arcs, since only these two are in use within the G4 PKIoverheid certificates.

DISCLAIMER: Certain node sequence names are used in the naming conventions below. Definition for these node sequence names can be found in the next chapters describing the actual PKIo naming arcs.

2.1 Expanding the PKIo Certificate Policy and Organization arcs

The current PKIo Certificate Policy arc should be expanded to be able to define any CP imaginable. This also applies to the Organization arcs, which should also contain CA domains of issuing CAs. The way to achieve this is not to work with a static list of OIDs, but a parameterized approach in which only values of parameters are static and are only introduced in the PKIoverheid OID-arc on a need-to basis.

For the Certificate Policy OID-arc this means it should be able to reflect any current and future iteration of the PKIoverheid Differentiation Model (PDM) found in the PKIoverheid architecture documentation. This means the following parameters must somehow be part of the CP OID-arc:

  1. Generation of a root;
  2. Trust type;
  3. Cipher suite;
  4. Area of application;
  5. CA type;
  6. Subject type;
  7. Validation type;
  8. Trust purpose.

For the Organization arc the list of parameters looks similar and only the “Trust purpose” parameter needs to be replaced with CA organization name:

  1. Root generation;
  2. Trust type;
  3. Cipher suite;
  4. Area of application;
  5. CA type;
  6. Subject type;
  7. Validation type;
  8. CA organization name.

An obvious approach to translating the PDM to an OID-scheme is creating a sub-arc for each of the parameters in the model. However, this will lead to very long OIDs making reading certificate policies more difficult. Just like how the G4 certificate hierarchy is based on the PDM without 1-on-1 copying it, so can be the OID-scheme. However, a smart approach needs to be chosen as not to lose the flexibility of the PDM.

2.2 Considerations for expanding the PKIo Certificate Policy arc

There are several things to consider when creating a flexible OID-scheme. First of all the OIDs still need to meet the two main needs the CP OIDs were created for:

  1. uniquely identify a set of rules for a CA to use in the life-cycle of each kind of certificate it generates (and against which it can be audited), and
  2. enable insight in all characteristics (both technical and non-technical) of a certificate for a recipient thereof.

Secondly, the scheme should be both flexible and pragmatic:

  1. it should enable any kind of future change or expansion without the need of changing naming conventions,
  2. it should be intuitive to use,
  3. it should not be unnecessarily long.

Making a 1-on-1 translation of the PDM in an OID-scheme sure adds flexibility but falls short in the “it should not be unnecessarily long” category. This same problem exists in the actual G4-hierarchy itself. This hierarchy also does not copy the PDM 1-on-1 because of the cost of creating and maintaining too many intermediate certificates. Design decisions from the G4 hierarchy can therefore be glanced at in creating an OID-scheme.

Observations:

  1. In a single root certificate the “Trust type”, “Cipher suite”, “Area of application”, and “CA type” parameters are all present, making the combination of these parameters a unique identifier which we will now call “Root identifier”.
  2. Each “Root identifier” can have multiple generations. Starting with the G4 architecture, all different roots created under it will begin with a generation identifier of 4.
  3. The number of both “Subject type” and “Validation type” values are limited and also closely related which makes combining the two a valid choice.

When translating these observations in an OID naming scheme, the identifier will be as short as possible without needing to sacrifice in flexibility or intuitiveness: it still closely resembles the actual certificate hierarchy.

2.3 Conventions for G4 Certificate Policy naming arc

Starting with all G4 root certificates the following naming syntax must be adhered to within the Certificate Policy top-level identifier in the PKIo naming arc:

CP OID Alias Naming CP OID Numerical
id-pkio-cp-[rootGeneration]-[rootType]-[subjectValidation]-[trustPurpose] 2.16.528.1.1003.1.2.[rootGeneration].[rootType].[subjectValidation].[trustPurpose]

Each of the parameters described in this syntax can have different values. Actual OIDs therefore do not have to be obtained from a (semi-) static list, but can be deduced based on the conventions expanded upon below.

Parameter [rootGeneration]

The [rootGeneration] identifier is itself also parameterized and consists out of a generation identifier followed by a DTAPE-identifier (Development, Testing, Acceptance, Educational):

[rootGeneration] = [[generationID][dtapeID]]

[generationID] value Partial name Description
1 g1 Generation 1
2 g2 Generation 2
3 g3 Generation 3
4 g4 Generation 4
n gn Generation n
[dtapeID] value Partial name Description
0 g Not bound to a specific DTAPE (generic)
1 d Development
2 t Testing
3 a Acceptance
4 p Production
5 e Educational

Example: [rootGeneration] identifier 44 stands for “G4 Production” and corresponds to OID alias g4p.

Parameter [rootType]

The [rootType] identifier is also parameterized and uses the following structure:

[rootType] = [[caType][applicationType]]

[caType] value Partial name Description
1 gen10 Generic CA using cipher 10
2 pa10 Specific CA: PA Logius using cipher 10
3 def10 Specific CA: Defensie using cipher 10
4 cibg10 Specific CA: CIBG using cipher 10
5 ilt10 Specific CA: ILT using cipher 10
[applicationType] value Partial name Description
0 None Not specified
1 PubTLS Publicly-trusted: TLS
2 PubSM Publicly-trusted: S/MIME
3 PubCS Publicly-trusted: Code Signing
4 EUTLSig EUTL: Document Signing
5 PrvTLS Private: TLS
6 PrvOth Private: Other

The [caType] parameter descriptions contain both the “CA type” and “Cipher suite” components from the PKIoverheid Differentiation Model. The “CA Type” can be Generic or one of the specific CA types, meaning CAs for specific branches. The “Cipher suite” indicates which cipher is used in signing a certificate. Currently only Cipher 10 has been defined, meaning the cipher with identifier 10 in the PKCS-1 OID-arc (1.2.840.113549.1.1), which corresponds with RSASSA-PSS.

The [applicationType] parameter descriptions contain both the “Trust type” and “Area of application” components from the PKIoverheid Differentiation Model. The “Trust type” can be “Publicly-trusted”, meaning trusted by Browser parties and having to satisfy with CA/Browser Forum Baseline Requirements documents. Currently the “Area of application” can be TLS, S/MIME, code Signing, Document Signing, or Other for everything else (now mainly used for client authentication purposes).

Example: [rootType] identifier 14 stands for “Generic root signed with RSASSA-PSS meant for Document Signing with EUTL trust” normally also referred to as eSignatures or eSeals, and corresponds to OID alias gen10EUTLSig.

Parameter [subjectValidation]

The [subjectValidation] identifier is also parameterized and uses the following structure:

[subjectValidation] = [[subjectType][validationType]]

[subjectType] value Partial name Description
1 np Natural Person (or CA for np)
2 lp Legal Person (or CA for lp)
3 sys System (or CA for sys)
4 root Root CA only
[validationType] value Partial name Description
0 Gen No specific validation type
1 Ind Individual validation
2 RegP Regulated Profession validation
3 Spon Sponsor validation
4 RPSp Regulated Profession with Sponsor validation
5 Org Organization validation
6 Dmdi Domain, Mailbox, or Device identifier validation
7 Root Root CAs only
8 Int Intermediate CAs only
9 TSP TSP CAs only

Example: [validationType] identifier 12 stands for “Natural Person with Regulated Profession validation” and corresponds to OID alias npRegP.

Parameter [trustPurpose]

The “trustPurpose” parameter is the only one not parameterized:

[trustPurpose] value Name Description
0 generic No specific trust purpose
1 car CA certificates: Root
2 cai CA certificates: Intermediate
3 cat CA certificates: TSP Issuing
4 authy Authenticity certificates
5 nonrep Non-repudiation certificates
7 conf Confidentiality certificates (Legacy)
8 authon Authentication certificates
9 combi1 Combination certificates (1: Legacy Autonomous Devices)
10 ocsp Delegated OCSP Responder certificates
11 tls Server Authentication
21 cscs Code Signing
22 csts Time Stamping for Code Signing certificates
31 lso Legacy profile Signing-only S/MIME certificates
32 lkm Legacy profile Key Management S/MIME certificates
33 ldu Legacy profile Dual Use S/MIME certificates
34 mso Multi-purpose profile Signing-only S/MIME certificates
35 mkm Multi-purpose profile Key Management S/MIME certificates
36 mdu Multi-purpose profile Dual Use S/MIME certificates
37 sso Strict profile Signing-only S/MIME certificates
38 skm Strict profile Key Management S/MIME certificates
39 sdu Strict profile Dual Use S/MIME certificates

Note: There are different types of the same trust purpose, like “Authenticity” for which exists a legacy version in G3 and a strict version in G4. Another example is “Server Authentication” for which exists different validation types and requirements. However, since these parameters are not to be interpreted as single values, but only as a component in an entire OID, the actual type of a trust purpose can always be deduced from the other values in the OID.

2.4 Conventions for G4 Organization naming arc

For the Organization naming sub-arc the following syntax should be used:

Organization OID Naming Organization OID Numerical
id-pkio-org-[rootGeneration]-[rootType]-[subjectValidation]-[caOrganizationName] 2.16.528.1.1003.1.3.[rootGeneration].[rootType].[subjectValidation].[caOrganizationName]

The structure of the [rootGeneration], [rootType], and [subjectValidation] parameters can be found in the previous section. The [trustPurpose] parameter is not parameterized and its values below:

[caOrganizationName] value Name Description
0 generic No specific CA organization
1 pa PKIoverheid PA
11 dn Diginotar
12 get Getronics
13 esg ESG
14 venwBCT Ministerie van Verkeer en Waterstaat: Boordcomputer Taxi
21 ienwBCT Ministerie van Infrastructuur en Waterstaat: Boordcomputer Taxi
22 def Dutch Ministry of Defence
23 cibg CIBG
31 kpn KPN
32 ddy Digidentity
33 qv QuoVadis
34 cb Cleverbase

Note: In this table spreading is used to differ between legacy TSPs, and current governmental and commercial TSPs. However, this is completely arbitrary since this is not sustainable over a longer period because when TSPs decide to leave PKIo on a later date they will always keep their identifier and will not move to another segment.

Exported on: 2024-05-08.