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

[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

[dtapeD] 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	gen	Generic CA
2	pa	Specific CA: PA Logius
3	def	Specific CA: Dutch Ministry of Defence
4	cibg	Specific CA: CIBG
5	ilt	Specific CA: ILT

[applicationType] value	Partial name	Description
0	None	Not specified
1	PubTLS	Publicly-trusted: TLS
2	PubSM	Publicly-trusted: S/MIME
3	PubSS	Publicly-trusted: Code Signing
4	EidasSig	eIDAS qualified: Document Signing
5	PrvTLS	Private: TLS
6	PrvOth	Private: non-TLS

Example: rootType identifier “14” stands for “Generic eIDAS Document Signing” also referred to as normal eSignatures or eSeals, and corresponds to OID alias “genEidasSig”.

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
2	lp	Legal Person
3	dev	Device

[validationType] value	Partial name	Description
0	Gen	No specific validation type
1	Ind	Individual validation
2	Prof	Regulated Profession validation
3	Emp	Employee validation (sponsor)
4	Dmdi	Domain, Mailbox, or Device identifier validation
5	Org	Organization validation
6	Orge	Extended orqanization validation

Example: subjectValidation identifier “12” stands for “Natural Person with Regulated Profession validation” and corresponds to OID alias “npProf”.

Parameter [trustPurpose]

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

[trustPurpose] value	Name	Description
0	generic	No specific trust purpose
1	ca	CA certificates
2	authy	Authenticity certificates
3	nonrep	Non-repudiation certificates
4	conf	Confidentiality certificates (Legacy)
5	authon	Authentication certificates
7	combi1	Combination certificates (1: Legacy Autonomous Devices)
8	combi2	Reserved for other combination certificates
9	combi3	Reserved for other combination certificates
10	ocsp	OCSP Certificates
11	tls	Server Authentication
21	cscs	Code Signing
22	csts	Time Stamping for Code Signing certificates
31	lso4	Legacy profile Signing-only S/MIME certificates
32	lkm4	Legacy profile Key Management S/MIME certificates
33	ldu4	Legacy profile Dual Use S/MIME certificates
34	mso4	Multi-purpose profile Signing-only S/MIME certificates
35	mkm4	Multi-purpose profile Key Management S/MIME certificates
36	mdu4	Multi-purpose profile Dual Use S/MIME certificates
37	sso4	Strict profile Signing-only S/MIME certificates
38	skm4	Strict profile Key Management certificates
39	sdu4	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:

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	Quo Vadis
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.