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:

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]]

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]]

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]]

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:

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:

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:

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.