ECB Advanced Encryption CP (OID:1.3.6.1.4.1.41697.509.10.100.2.1.3)

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 AV 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 AV Sub CA 01 trust chain based on the ECB RSA AV Root CA 01 trust anchor.

European Central Bank Private Key Infrastructure overview diagram

1.2 Document name and identification

This document is the “ECB Advanced Encryption CP” for the ECB PKI services. The Object Identifier (OID) representing this document is 1.3.6.1.4.1.41697.509.10.100.2.1.3. 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 Advanced Encryption CP are:

Policy root CA

ECB RSA AV Root CA 01

Issuing sub CA

ECB RSA AV Sub CA 01

1.3.2 Registration authorities

User encryption certificates issued under this policy MUST be approved by upstream HR systems and procedures including ECB security clearance and background checks. Thus the RA role is delegated to the IT service division in charge of producing and issuing the smart card tokens bearing the resulting certificates in conjunction with the inherited assertions attached to the subject by upstream HR procedures.

1.3.3 Subscribers

Subscribers for certificates governed by this CP are ECB employees and contractors having an active account on the ECB diretory.
All subscribers MUST as well be the subject for the personal certificates issued under this CP.
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

Advanced Validation user encryption certificates MUST only be used for smart card based key/data encryption purposes including secure e-mail.

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.
FIPS 140		FIPS 140 is the (US) Federal Information Processing Standard that outlines security requirements for cryptographic modules. FIPS 140 is one of several cryptographic standards maintained by the Computer Security Division of NIST (National Institute for Standards and Technology).
Hardware Security Module	HSM	A hardware encryption device that is connected to a server at the device level via direct physical interfaces.
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.
Personal Identification Number	PIN	In practice a (chiefly numeric) password to authenticate an user upon smard card access.
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 AV user encryption 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.

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

AV User encryption certificate applications MUST be submitted by the smart card management RA acting on behalf of the subscriber from within the smart card issuance 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.

4.1.2 Enrollment process and responsibilities

Enrolment process

User Encryption certificates to subscribers MUST be enrolled on a cryptographic smart card token issued to the user according to ECB PKI certificate enrolment processes and procedures in combination with the ECB Registration Authority Operator using the certificate management portal.
If the user does not possess a cryptographic smart card token a new one SHALL be issued.

Responsibilities

For user certificates the RA operator is responsible (see also section 3.2.3 for an overview of the overall process)

(for in-person interaction, user present) to verify the user’s identity against the user’s badge and establish the mapping between the user’s identity, the smart card token and the user’s account in the ECB directory.
(for offline activities, such as initial on-boarding) to establish the mapping between the user’s account in ECB directory and the smart card token, and later on ensure that the smart card token is delivered via the predetermined processes through which the user’s identity is verified during hand-over.

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 AV Sub CA 01 by CSRs in CMC or PKCS #10 format.

6.1.4 CA public key delivery to relying parties

The ECB RSA AV 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 AV Root CA 01	4096 Bit RSA
ECB RSA AV Sub CA 01	4096 Bit RSA
Subscriber	2048 Bit RSA 3072 Bit RSA 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 AV Sub CA 01 under this CP:

keyEncipherment

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic module standards and controls

ECB PKI advanced subscriber key pairs for encryption SHALL be generated in FIPS 140-2 Level 3 compliant HSMs and MUST be imported into FIPS 140-2 level 2 or above compliant hardware smart cards.

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

no stipulation

6.2.3 Private key escrow

The private key is escrowed encrypted by one of the corresponding CA's HSM protected public keys. The escrow system requires a 2 out of 3 OCS quorum acting as the escrow agent to decipher the corresponding Escrow Agent certificate private key.

6.2.4 Private key backup

The private key is backed up encrypted by one of the corresponding CA's HSM protected public keys. The backup system allow an automated restore onto the subscriber's smart card with the smart card RA acting as the backup agent on the subscriber's behalf.

6.2.5 Private key archival

The private key is archived encrypted by one of the corresponding CA's HSM protected public keys. The archive retrieval system allows a conditional automated restore onto the subscriber's smart card with the smart card RA acting as the retrieval agent on the subscriber's behalf. If the subscriber assigned smart card cannot hold additional historic encryption certificate private keys, ECB PKI MAY chose to supply encrypted keystore container formats to the subscriber. Such soft-token MUST NOT be issued for the newest certificates that can be stored in cryptographic hardware smart cards. The usage of dedicated cryptographic smart cards or other HSM to hold revoked/invalid encryption certificates is RECOMMENDED.

6.2.6 Private key transfer into or from a cryptographic module

Private Key transfer from a cryptographic module protected storage is PROHIBITED.
Private keys MAY be generated in a trusted secure environment and transfered into approved smart cards via encrypted transfer channels.

6.2.7 Private key storage on cryptographic module

The private key is stored encrypted.

6.2.8 Method of activating private key

The private key MUST be activated by inserting the smart card token and entering the PIN upon access by an application.
Activation expired upon withdrawal of the smart card, power off or a timeout stipulated by the respective operating system or application software.

6.2.9 Method of deactivating private keys

The private key is deactivated by logging out of the operating system, turning off the power of the equipment, removing the smart card token and when then cryptographic context the key has been activated in times out.

6.2.10 Method of destroying private keys

The private key is destroyed by overwriting the key, token surrender or in case of failure on overwriting the key physically destroying the token.

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 AV User encryption certificates	no stipulation	3 years

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

Extension	OID	critical	Value
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
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.4.1.311.80.1 Document Encryption 1.3.6.1.4.1.311.67.1.1 BitLocker Drive Encryption 1.3.6.1.5.5.7.3.4 Email Protection 1.3.6.1.4.1.311.10.3.4 MS Encrypted File System (EFS)
CRL Distribution Points	2.5.29.31	-	http://cpki.ecb.europa.eu/cdp/ECB-RSA-AV-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-AV-Sub-CA-01-2033.cer http://ocsp.ecb.europa.eu

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)
For this certificate type the subject CN will be suffixed by ' [ENC]'.

7.1.5 Name constraints

ECB RSA AV Sub CA 01 SHALL add the " [ENC]" suffix to the subject CN of AV User encryption 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.2.1.3
The ECB PKI Certification Practice Statement	1.3.6.1.4.1.41697.509.10.100.0.1