ECB Directory CP (OID:1.3.6.1.4.1.41697.509.10.100.1.1.0)

1 INTRODUCTION

This document ist a Certificate Policy for the European Central Bank certification service Public Key Infrastructure.

It is a named set of rules that indicate the applicability of a certificate to a particular community and/or class of application with common security requirements.

This certificate policy document describes the policies of the Certification Authority ECB RSA Sub CA 01 operated by European Central Bank. It is applicable to all entities that have relationships with the ECB PKI CAs, including end users- and Registration Authorities (RAs) and describes their responsibilities in requesting, issuing and using certificates under this policy. By setting forth the specific requirements for applications for and conditions for usage of such certificates, it may be used by a certificate user to decide whether or not to trust the certificate for a particular purpose.

1.1 Overview

The European Central Bank PKI (ECB PKI) offers a variety of certificates applicable to distinct user groups and/or certificate applications. While the ECB PKI CPS sets forth the responsibilities of the PKI participants, technical and organisational measures taken to ensure operational cotinuity and security for meeting specific requirements on certificate issuace, this CP document sets forth the requirements certificate applicants and subjects have to satisfy to qualify for such type of certificate.

Doing so, the CP states what level of assertion can be expected from a specific certificate issued by the ECB PKI, thus enabling relying parties assessing the level of trust they may associate to presented ECB PKI certifiates of this type.

Implementation of the ECB PKI certificate authority hierarchy

This CP applies to certificates issued by the ECB RSA Sub CA 01 trust chain based on the ECB RSA Root CA 01 trust anchor.

European Central Bank Private Key Infrastructure overview diagram

1.2 Document name and identification

This document is the “ECB Directory CP” for the ECB PKI services. The Object Identifier (OID) representing this document is 1.3.6.1.4.1.41697.509.10.100.1.1.0. For details on OID namespaces please refer to the ECB PKI IANA PEN namespace document referenced in the related documents section.

1.3 PKI participants

1.3.1 Certification authorities

The ECB PKI CAs involved in the trust chain issuing certificates under this ECB Directory CP are:

Policy root CA

ECB RSA Root CA 01

Issuing sub CA

ECB RSA Sub CA 01

1.3.2 Registration authorities

For the purpose of issuing certificates covered by this CP to subjects having an active id on the ECB directory, the RA role is ultimately delegated to upstream HR systems for user client certificates and to IT administration for machine server and7or client certificates.
In case additional approval is stipulated by business processes or policies, additional RA tasks MAY be delegated to and requests routed through ITSM/RA offices for approval.

1.3.3 Subscribers

Subscribers for certificates governed by this CP are ECB employees and contractors having an active account on the ECB diretory.
The subscriber holds a private key that corresponds to the public key listed in the associated certificate.

1.3.4 Relying parties

A relying party could be within or outside the organization of European Central Bank and may, or may not also be a Subscriber within the PKI. Relying parties implicitly agree to the terms of this CP documentation, the associated CPS documentation and referenced general ECB security policies in their respective latest version.

1.3.5 Other participants

1.4 Certificate usage

1.4.1 Appropriate certificate uses

All certificates issued by the ECB PKI MUST be used for ECB internal business purposes by ECB and approved ECB partners only.
ECB PKI certificates issued to users under this policy may be userd for authentication or digital signature
ECB PKI machine certificates may only be used for authentication purposes and to ensure the confidentiality of communication channels.
Appropriate certificate usage is limited to the applications given by the Key Usage or Extended Key Usage extension or combination thereof in the issued certificate.

1.4.2 Prohibited certificate uses

Any usage not covered in the appropriate certificate uses section of this CP is prohibited.
The certificate explicitly MUST NOT be used:

to sign lower tier CA certificates,
for other applications than outlined in the certification request,
outside their given validity period or after revocation,
for non-ECB and on non-certified partner subjects,
for non-ECB internal and partner purposes.

1.5 Policy administration

1.5.1 Organization administering the document

European Central Bank
DG-IS Digital Security Services
Security Governance
Sonnemannstrasse 20
60314 Frankfurt am Main
Germany

http://www.pki.ecb.europa.eu

1.5.2 Contact person

For questions regarding the ECB PKI please contact:

Ulrich Kühn
Email: ulrich.kuhn@ecb.europa.eu
Telephone: +49 69-1344-4857

1.5.3 Person determining CPS suitability for the policy

The ECB Policy Management Authority determines the suitability and applicability of this document. It consists of the ECB Deputy Director General Information Systems and the ECB Head of Digital Security Services Division.

1.5.4 CPS approval procedures

Approval of this CP and subsequent amendments shall be made by the PMA. Amendments SHALL be in the form of a document containing an amended form of the CP. The PMA shall determine whether changes to the CP require a change in the document object identifier.

1.6 Definitions and acronyms

Term	Alias	Definition
Certificate	public key certificate	A data structure containing the public key of an electronic identity and additional information. A certificate is digitally signed using the private key of the issuing CA binding the subject’s identity to the respective public key.
Certificate Management over CMS	CMC	transport mechanism that can be used for obtaining X.509 digital certificates in a PKI.
Certificate Policy	CP	A document containing the rules that indicate the applicability and use of certificates issued to ECB PKI subscribers.
Certificate Signing Request	CSR	A request from a Subscriber to an RA to create and sign a certificate for a subject with certain attributes specified in the request
Certification Authority	CA	The unit within ECB PKI to create, assign and revoke public key certificates.
Certification Practices Statement	CPS	A document containing the practices that ECB PKI certification authority employs in issuing certificates and maintaining PKI related operational status.
Common Name	CN	An identifier for an end entity (subject)
Directory		A database containing information and data related to identities, certificates and CAs.
Encryption		Cryptographic transformation of data (called plaintext) into a form (called cipher text) that conceals the data’s original meaning to prevent it from being known or used. If the transformation is reversible, the corresponding reversal process is called decryption, which is a transformation that restores encrypted data to its original state.
End Of Life	EOL	An end-of-life product is at the end of the product lifecycle which prevents users from receiving updates, indicating that the product is at the end of its useful life.
End-Entity		An entity that is a subscriber, a relying party, or both.
Internet Assigned Numbers Authority	IANA	A standards organization that oversees global Internet Protocol–related symbols and Internet numbers.
Machine Readable Zone	MRZ	The visual part of an official identity or travel document designed to be interpreted using optical character recognition.
Object Identifier	OID	An identification mechanism jointly developed by ITU-T and ISO/IEC for naming any type of object, concept or "thing" with a globally unambiguous name.
Policy Management Authority	PMA	This management authority sets the overall policies of the ECB PKI and approves the policies and procedures of trust domains within the PKI.
Private Enterprise Number	PEN	IANA assigned Private Enterprise Numbers are identifiers that can be used in SNMP configurations, in LDAP configurations, and wherever the use of an ASN.1 object identifier (OID) is appropriate.
Public Key Cryptography Standards	PKCS	are a group of public key cryptography standards published by RSA Security LLC.
Public Key Infrastructure	PKI	Framework of technical components and related processes for the distribution and management of private keys, public keys and corresponding certificates.
Registration Authority	RA	An entity that is responsible for the identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e. an RA is the delegate of certain tasks on behalf of a CA).
Relying Party		A recipient of a certificate issued by an ECB PKI CA who relies on the certificate, the respective ECB PKI trust chain and its corresponding policies.
Subject		Entity identified in a certificate as the holder of the private key associated with the public key given in the certificate.
Subscriber		Entity subscribing with a Certification Authority on behalf of one or more subjects.

2 PUBLICATION AND REPOSITORY RESPONSIBILITIES

no stipulation

2.1 Repositories

2.2 Publication of certification information

2.3 Time or frequency of publication

2.4 Access controls on repositories

3 IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of names

Names assigned to certificate subjects are REQUIRED to be X.500 distinguished names.

3.1.2 Need for names to be meaningful

Names are REQUIRED to be meaningful in the term that the name form has commonly understood semantics to determine the identity of a person.

3.1.3 Anonymity or pseudonymity of subscribers

Anonymous subscribers as well as pseudonyms for subscribers are not supported by the ECB PKI.

3.1.4 Rules for interpreting various name forms

Name forms not encoded in latin character sets SHALL be translated into latin characters. In case of names derived from identity cards or passports, the latin representation of the name on the MRZ of the document MUST be used.

3.1.5 Uniqueness of names

no stipulation

3.1.6 Recognition, authentication, and role of trademarks

no stipulation

3.2 Initial identity validation

3.2.1 Method to prove possession of private key

The certificate subscriber MUST demonstrate that it rightfully holds the private key corresponding to the public key to be listed in the Certificate.
The method to prove possession of a private key SHALL be PKCS #10 or CMC compliant CSR.
This requirement does not apply where a key pair is generated by a CA on behalf of a Subscriber.

3.2.2 Authentication of organization identity

Whenever a certificate contains an organization name, the identity of the organization and other enrollment information provided by certificate applicants is confirmed in accordance with the procedures set forth in the ECB PKI's validation procedures.

3.2.3 Authentication of individual identity

no stipulation

3.2.4 Non-verified subscriber information

Any enrolment request that holds non verifiable information SHALL be discarded without any further notice.

3.2.5 Validation of authority

Subscribers MUST be ECB employees or ECB contractors to be eligible for enrolling with the ECB PKI for user certificates.
This is validated by establishing an unique mapping between the user’s identity, his/her smart card and his/her active ECB directory user account.
In case the end-entity is a machine or a device, enrolment requests containing alias names or pseudonyms MUST be validated to a responsible administrative contact in charge for the end-entity machine or device that requests certification during the enrolment process.
Change of responsibility or role of the administrative contact while the ECB PKI end-entity certificate is still in use MUST be communicated to the responsible ECB PKI certificate and enrolment authority without being requested to do so.
Unless the machine or device is considered EOL and is to be decommissioned a new administrative contact taking up the responsibilities of the former administrative contact is MANDATORY.
This explicitly applies to virtual machines as well and is not limited to physical hardware.

3.2.6 Criteria for interoperation

n/a

3.3 Identification and authentication for re-key requests

no stipulation

3.3.1 Identification and authentication for routine re-key

3.3.2 Identification and authentication for re-key after revocation

3.4 Identification and authentication for revocation request

4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1.1 Who can submit a certificate application

Certificate applications may be submitted by the certificate subject, an authorized administration contact subscriber requesting certificates for appointed to subjects or a RA acting on behalf of the subscriber from within the validation process.
Certificate applicants MUST be ECB employees or approved partners of ECB to submit a certificate application.
A valid ECB Directory user account and appropriate authorization according to the applicant's role is REQUIRED.
For ECB standard devices and machines an automatic enrolment scenario is supported by the ECB PKI which REQUIRES an initial administrative contact to initiate the enrolment.

4.1.2 Enrollment process and responsibilities

Enrolment process

Client Authentication certificates to machine subscribers are enrolled automatically via Directory Group Policies based on computer object group membership.
Server Authentication, Server Client Authentication and Domain Controller Authentication certificates to machine subscribers are enrolled manually according to ECB PKI certificate enrolment processes and procedures in combination with the administrative contact that

generates a certificate signing request for ECB internal machine and device or
requests a certificate for an ECB internal machine or device including private key generation following the ECB PKI certificate request policies enforced by the certificate management portal.

Responsibilities

ECB PKI operations staff is responsible for successful enrolment of all auto-enrolled certificates. The administrative contact of each system is responsible for correct and appropriate use of the enrolled certificate based on the ECB PKI certificate policies.
For manually enrolled certificate types the administrative contact as the certificate requestor on behalf is responsible for successful enrolment and use after successful issuance of the certificate according to the existing ECB PKI certificate policies.

4.2 Certificate application processing

no stipulation

4.2.1 Performing identification and authentication functions

4.2.2 Approval or rejection of certificate applications

4.2.3 Time to process certificate applications

4.3 Certificate issuance

no stipulation

4.3.1 CA actions during certificate issuance

4.3.2 Notification to subscriber by the CA of issuance of certificate

4.4 Certificate acceptance

no stipulation

4.4.1 Conduct constituting certificate acceptance

4.4.2 Publication of the certificate by the CA

4.4.3 Notification of certificate issuance by the CA to other entities

4.5 Key pair and certificate usage

no stipulation

4.5.1 Subscriber private key and certificate usage

4.5.2 Relying party public key and certificate usage

4.6 Certificate Renewal

no stipulation

4.6.1 Circumstance for certificate renewal

4.6.2 Who may request renewal

4.6.3 Processing certificate renewal requests

4.6.4 Notification of new certificate issuance to subscriber

4.6.5 Conduct constituting acceptance of a renewal certificate

4.6.6 Publication of the renewal certificate by the CA

4.6.7 Notification of certificate issuance by the CA to other entities

4.7 Certificate re-key

no stipulation

4.7.1 Circumstance for certificate re-key

4.7.2 Who may request certification of a new public key

4.7.3 Processing certificate re-keying requests

4.7.4 Notification of new certificate issuance to subscriber

4.7.5 Conduct constituting acceptance of a re-keyed certificate

4.7.6 Publication of the re-keyed certificate by the CA

4.7.7 Notification of certificate issuance by the CA to other entities

4.8 Certificate Modification

no stipulation

4.8.1 Circumstance for Certificate Modification

4.8.2 Who may request certificate modification

4.8.3 Processing certificate modification requests

4.8.4 Notification of new certificate issuance to subscriber

4.8.5 Conduct constituting acceptance of modified certificate

4.8.6 Publication of the modified certificate by the CA

4.8.7 Notification of certificate issuance by the CA to other entities

4.9 Certificate revocation and suspension

no stipulation

4.9.1 Circumstances for revocation

4.9.2 Who can request revocation

4.9.3 Procedure for revocation request

4.9.4 Revocation request grace period

4.9.5 Time within which CA must process the revocation request

4.9.6 Revocation checking requirement for relying parties

4.9.7 CRL issuance frequency

4.9.8 Maximum latency for CRLs

4.9.9 On-line revocation/status checking availability

4.9.10 On-line revocation checking requirements

4.9.11 Other forms of revocation advertisements available

4.9.12 Special requirements upon private key compromise

4.9.13 Circumstances for suspension

4.9.14 Who can request suspension

4.9.15 Procedure for suspension request

4.9.16 Limits on suspension period

4.10 Certificate status services

no stipulation

4.10.1 Operational characteristics

4.10.2 Service availability

4.10.3 Optional features

4.11 End of subscription

no stipulation

4.12 Key escrow and recovery

no stipulation

4.12.1 Key escrow and recovery policy and practices

4.12.2 Session key encapsulation and recovery policy and practices

5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

no stipulation

5.1 Physical controls

5.1.1 Site location and construction

5.1.2 Physical access

5.1.3 Power and air conditioning

5.1.4 Water exposures

5.1.5 Fire prevention and protection

5.1.6 Media storage

5.1.7 Waste disposal

5.1.8 Off-site backup

5.2 Procedural Controls

5.2.1 Trusted roles

5.2.2 Number of persons required per task

5.2.3 Identification and authentication for each role

5.2.4 Roles requiring separation of duties

5.3 Personnel controls

5.3.1 Qualifications, experience, and clearance requirements

5.3.2 Background check procedures

5.3.3 Training requirements

5.3.4 Retraining frequency and requirements

5.3.5 Job rotation frequency and sequence

5.3.6 Sanctions for unauthorized actions

5.3.7 Independent contractor requirements

5.3.8 Documentation supplied to personnel

5.4 Audit Logging Procedures

5.4.1 Types of events recorded

5.4.2 Frequency of processing log

5.4.3 Retention period for audit log

5.4.4 Protection of audit log

5.4.5 Audit log backup procedures

5.4.6 Audit collection system (internal vs. external)

5.4.7 Notification to event-causing subject

5.4.8 Vulnerability assessments

5.5 Records archival

5.5.1 Types of records archived

5.5.2 Retention period for archive

5.5.3 Protection of archive

5.5.4 Archive backup procedures

5.5.5 Requirements for time-stamping of records

5.5.6 Archive collection system (internal or external)

5.5.7 Procedures to obtain and verify archive information

5.6 Key changeover

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

5.7.2 Computing resources, software, and/or data are corrupted

5.7.3 Entity private key compromise procedures

5.7.4 Business continuity capabilities after a disaster

5.8 CA or RA termination

6 TECHNICAL SECURITY CONTROLS

6.1 Key pair generation and installation

6.1.1 Key pair generation

User key pairs for authentication and signature MUST be generated on certified smart cards.
User certificates for encryption of data MAY be generated in secure environments and installed on certified smart cards. A copy of the key pair generated by the CA may be retained for private key archival/backup/escrow.

6.1.2 Private Key delivery to subscriber

Private keys for ECB PKI entities are either generated by the subscriber and protected locally or are generated by the CA.
Private keys generated by the entity do not require delivery, as the entity already has it.
CA generated private keys MAY be delivered encrypted (e.g. password protected PKCS #12) to the subscriber in a TLS protected session or by encrypted e-mail.

6.1.3 Public key delivery to certificate issuer

All subscriber public keys not generated by the CA on behalf of the user SHALL BE delivered to the ECB RSA Sub CA 01 by CSRs in CMC or PKCS #10 format.

6.1.4 CA public key delivery to relying parties

The ECB RSA Sub CA 01 public keys are encapsulated in the CA certificates published to the ECB directory and ECB PKI web site.
Relying parties MAY obtain those certificates from any of those sources if they were not part of the certificate chain during entity certificate presentation.

6.1.5 Key sizes

Acceptable Key Size and Algorithms for certificates issued under this CP:

Entity	Key Size and Key Algorithm
ECB RSA Root CA 01	4096 Bit RSA
ECB RSA Sub CA 01	4096 Bit RSA
Subscriber	4096 Bit RSA

6.1.6 Public key parameters generation and quality checking

no stipulation

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

Acceptable key usage purposes for certificates issued by ECB RSA Sub CA 01 under this CP:

digitalSignature
keyEncipherment
keyAgreement

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic module standards and controls

no stipulation

6.2.2 Private key (n out of m) multi-person control

no stipulation

6.2.3 Private key escrow

n/a

6.2.4 Private key backup

n/a

6.2.5 Private key archival

n/a

6.2.6 Private key transfer into or from a cryptographic module

no stipulation

6.2.7 Private key storage on cryptographic module

no stipulation

6.2.8 Method of activating private key

no stipulation

6.2.9 Method of deactivating private keys

no stipulation

6.2.10 Method of destroying private keys

no stipulation

6.2.11 Cryptographic Module Rating

no stipulation

6.3 Other aspects of key pair management

6.3.1 Public key archival

The CA public key and subscriber public key certificates are archived in the CA database and archival backups thereof.

6.3.2 Certificate operational periods and key pair usage periods

The following certificate operational periods and key pair usage periods are defined under this policy.

Certificate Type	Certificate Operational Period	Key Pair Usage Period
ECB PKI Domain server certificates	no stipulation	1 year
ECB PKI Domain client certificates	no stipulation	1 year
ECB PKI Domain user certificates	no stipulation	1 year
ECB PKI Domain controller certificates	no stipulation	2 years
ECB PKI VPN domain user certificates	no stipulation	1 year

6.4 Activation Data

no stipulation

6.4.1 Activation data generation and installation

6.4.2 Activation data protection

6.4.3 Other aspects of activation data

6.5 Computer Security Controls

no stipulation

6.5.1 Specific computer security technical requirements

6.5.2 Computer security rating

6.6 Life cycle technical controls

no stipulation

6.6.1 System development controls

6.6.2 Security management controls

6.6.3 Life cycle security controls

6.7 Network Security Controls

no stipulation

6.8 Time-stamping

no stipulation

7 CERTIFICATE, CRL, AND OCSP PROFILES

7.1 Certificate profile

7.1.1 Version number(s)

X.509 version 3 certificate

7.1.2 Certificate extensions

Certificate type	Extension	OID	critical	Value
Domain server	Authority Key Identifier	2.5.29.35	-	Issuing CA fingerprint
	Subject Key Identifier	2.5.29.14	-	Subject fingerprint
	Key Usage	2.5.29.15	critical	keyEncipherment, keyAgreement
	Certificate Policies	2.5.29.32	-	see section 7.1.6
	Subject Alternative Name	2.5.29.17	-	provided by subscriber
	Basic Constraints	2.5.29.19	critical	Subject Type = End Entity
	Extended Key Usage	2.5.29.37	critical	1.3.6.1.5.5.7.3.1 Server Authentication 1.3.6.1.5.5.8.2.2 IP security IKE intermediate
	CRL Distribution Points	2.5.29.31	-	http://cpki.ecb.europa.eu/cdp/ECB-RSA-Sub-CA-01-2033.crl
	Authority Information Access	1.3.6.1.5.5.7.1.1	-	http://cpki.ecb.europa.eu/aia/ECB-RSA-Sub-CA-01-2033.cer http://ocsp.ecb.europa.eu
	Microsoft SID	1.3.6.1.4.1.311.25.2	-	provided by subscriber
Domain client	Authority Key Identifier	2.5.29.35	-	Issuing CA fingerprint
	Subject Key Identifier	2.5.29.14	-	Subject fingerprint
	Key Usage	2.5.29.15	critical	digitalSignature
	Certificate Policies	2.5.29.32	-	see section 7.1.6
	Subject Alternative Name	2.5.29.17	-	provided by subscriber
	Basic Constraints	2.5.29.19	critical	Subject Type = End Entity
	Extended Key Usage	2.5.29.37	critical	1.3.6.1.5.5.7.3.2 Client Authentication 1.3.6.1.5.5.8.2.2 IP security IKE intermediate
	CRL Distribution Points	2.5.29.31	-	http://cpki.ecb.europa.eu/cdp/ECB-RSA-Sub-CA-01-2033.crl
	Authority Information Access	1.3.6.1.5.5.7.1.1	-	http://cpki.ecb.europa.eu/aia/ECB-RSA-Sub-CA-01-2033.cer http://ocsp.ecb.europa.eu
	Microsoft SID	1.3.6.1.4.1.311.25.2	-	provided by subscriber
Domain user	Authority Key Identifier	2.5.29.35	-	Issuing CA fingerprint
	Subject Key Identifier	2.5.29.14	-	Subject fingerprint
	Key Usage	2.5.29.15	critical	digitalSignature,keyEncipherment
	Certificate Policies	2.5.29.32	-	see section 7.1.6
	Subject Alternative Name	2.5.29.17	-	provided by subscriber
	Basic Constraints	2.5.29.19	critical	Subject Type = End Entity
	Extended Key Usage	2.5.29.37	critical	1.3.6.1.5.5.7.3.2 Client Authentication 1.3.6.1.5.5.8.2.2 IP security IKE intermediate
	CRL Distribution Points	2.5.29.31	-	http://cpki.ecb.europa.eu/cdp/ECB-RSA-Sub-CA-01-2033.crl
	Authority Information Access	1.3.6.1.5.5.7.1.1	-	http://cpki.ecb.europa.eu/aia/ECB-RSA-Sub-CA-01-2033.cer http://ocsp.ecb.europa.eu
	Microsoft SID	1.3.6.1.4.1.311.25.2	-	provided by subscriber
Domain controller	Authority Key Identifier	2.5.29.35	-	Issuing CA fingerprint
	Subject Key Identifier	2.5.29.14	-	Subject fingerprint
	Key Usage	2.5.29.15	critical	digitalSignature,keyEncipherment
	Certificate Policies	2.5.29.32	-	see section 7.1.6
	Subject Alternative Name	2.5.29.17	-	provided by subscriber
	Basic Constraints	2.5.29.19	critical	Subject Type = End Entity
	Extended Key Usage	2.5.29.37	critical	1.3.6.1.5.5.7.3.2 Client Authentication 1.3.6.1.5.5.7.3.1 Server Authentication 1.3.6.1.4.1.311.20.2.2 MS Smart Card Logon 1.3.6.1.5.2.3.5 Kerberos KDC (Key Distribution Center) 1.3.6.1.5.5.8.2.2 IP security IKE intermediate
	CRL Distribution Points	2.5.29.31	-	http://cpki.ecb.europa.eu/cdp/ECB-RSA-Sub-CA-01-2033.crl
	Authority Information Access	1.3.6.1.5.5.7.1.1	-	http://cpki.ecb.europa.eu/aia/ECB-RSA-Sub-CA-01-2033.cer http://ocsp.ecb.europa.eu
	Microsoft SID	1.3.6.1.4.1.311.25.2	-	provided by subscriber
VPN Domain user	Authority Key Identifier	2.5.29.35	-	Issuing CA fingerprint
	Subject Key Identifier	2.5.29.14	-	Subject fingerprint
	Key Usage	2.5.29.15	critical	digitalSignature, keyEncipherment
	Certificate Policies	2.5.29.32	-	see section 7.1.6
	Subject Alternative Name	2.5.29.17	-	provided by subscriber
	Basic Constraints	2.5.29.19	critical	Subject Type = End Entity
	Extended Key Usage	2.5.29.37	critical	1.3.6.1.5.5.7.3.2 Client Authentication
	CRL Distribution Points	2.5.29.31	-	http://cpki.ecb.europa.eu/cdp/ECB-RSA-Sub-CA-01-2033.crl
	Authority Information Access	1.3.6.1.5.5.7.1.1	-	http://cpki.ecb.europa.eu/aia/ECB-RSA-Sub-CA-01-2033.cer http://ocsp.ecb.europa.eu
	Microsoft SID	1.3.6.1.4.1.311.25.2	-	provided by subscriber

7.1.3 Algorithm object identifiers

Signature algorithm OID 1.2.840.113549.1.1.11 (Sha256WithRSAEncryption)
Cryptographic key generation algorithm OID 1.2.840.113549.1.1.1 (RSA)

7.1.4 Name forms

ECB PKI Issuer and Subject Distinguished Names are set in the following order if applicable:
CN=[common name],O=[organization],C=[country] (inverse LDAP order)

7.1.5 Name constraints

ECB RSA Sub CA 01 SHALL add the " [VPN]" suffix to the subject CN of VPN user certificates.

7.1.6 Certificate policy object identifier

All certificates issued under this CP bear the Certificate Policies extension (OID 2.5.29.32) including

Document Reference	OID
This Certificate Policy document	1.3.6.1.4.1.41697.509.10.100.1.1.0
The ECB PKI Certification Practice Statement	1.3.6.1.4.1.41697.509.10.100.0.1