ECB PKI Certification Practice Statement (OID:1.3.6.1.4.1.41697.509.10.100.0.1)

This document is the Certification Practice Statement for the European Central Bank certification service Public Key Infrastructure.

It is a statement of the practices, which Certification Authorities operated by the ECB PKI employ in issuing certificates and is applicable to all entities that have relationships with the ECB PKI CAs and PKI components, including end users-, cross-certified CAs, and Registration Authorities (RAs). The Certification Practice Statement helps the user of certification services to determine the level of trust that he can put in the certificates that are issued by the ECB PKI CAs and connected infrastructure services.

The ECB PKI CPS therefore covers all relevant preconditions, regulations, processes and measures within the ECB PKI certification service as a compact information source for current and potential participants. The ordering of topics in this document follows IETF rfc3647, thereby facilitating comparisons and mappings among the corresponding documents of other PKIs.

The European Central Bank PKI (ECB PKI) consists of a set of root level policy CAs, each providing the anchor for the associated trust chains subscriber certificates are issued under by subordinate issuing CAs in a strict two tier flat hierarchy.

All ECB PKI trust chains inherit the set of up to date cryptographic algorithms and key lengths requirements provided by the corresponding policy CA thus offering consistent cryptographic reliability and avoiding vulnerbilities of hybrid algorithmic setups.
Cryptoagility is maintained by the ability to duplicate the entire CA hierarchy using future algorithms and key lengths for the entire trust chain under the otherwise identical policies instead of introducing risk of hybrid chains during re-key transition periods.

All certificates, regardless of CA or subscriber / end-entity, within either underlying cryptographic technology trust chain are required to reflect both the trust cryptographic class definition and governing issuance policy by unambigous reference to the associated certificate policy.

The implementation of the ECB PKI trust chain model is reflected in OID namespaces of the issuance policy and document identifiers according to the IANA based PEN namespace model of ECB reference to in the related documents section of this document.

Implementation of the ECB PKI certificate authority hierarchy

The following section is a brief overview of the implemented ECB PKI trust chain model and the CA hierarchy for the ECB PKI trust chain including the ECB PKI certification services provided by this architecture.
The ECB PKI CA hierarchy is built on a 2-tier model, rooted in trusted ECB root CAs, and issuing subordinate CAs certified by them.

The ECB PKI environment is comprised of a set of policy root CAs as the trust anchors and, on the subordinate level, the associated issuing sub CAs providing certificate issuance for different purposes.

This document is the “ECB PKI Certification Practice Statement” for the ECB PKI services. The Object Identifier (OID) representing this document is 1.3.6.1.4.1.41697.509.10.100.0.1. Object Identifier(s) (OID) for specific certificate policies are specified in their respective CPs and used within the ECB PKI hierarchy when issuing certificates for those requirement profiles. For details on OID namespaces please refer to the ECB PKI IANA PEN namespace document referenced in the related documents section.

European Central Bank operates a two-tier CA hierarchy which issues machine and user certificates to ECB employees and ECB partners. The two-tier CA hierarchy is built upon:

• Policy root CAs (Trust Anchors)
  • ECB RSA Root CA 01
  • ECB RSA AV Root CA 01
• Issuing sub CAs
  • ECB RSA Sub CA 01
  • ECB RSA Sub CA 02
  • ECB RSA AV Sub CA 01
  • ECB RSA AV Sub CA 02

The certificate services hierarchy does not reflect any ECB organizational hierarchy.

ECB PKI recognizes several specialized Registration Authorities interfacing with the ECB PKI CAs to evaluate submitted certificate singning requests or create them on behalf of the PKI subscribers. ECB PKI RAs MAY either be partially or fully automated systems, evaluationg CSRs based on deterministic business rule sets or inherited trust from upstream systems, or MAY be infrastructures that include human Registration Officers evaluating CSRs as part of different certification workflows according to the certificate policies of the desired certificate's assertions and trust levels. See the Certificate Policy document corresponding to the desired certificate type for more information on the responsible RAs.

End-entities in this PKI are ECB employees and contractors, computers, network devices, and identities as well as machines of approved ECB partners. All end-entities are certified by the ECB PKI certification authorities and as such are certificate subscribers. The subscriber holds a private key that corresponds to the public key listed in that certificate. Subscribers of the ECB PKI are internal users, machines as well as approved partners with their machines and users according to ECB identity management and security policy.

A relying party is any entity that acts in reliance of a certificate and /or a digital signature that is issued by an Issuing CA or Root CA and that is used in a manner consistent with the corresponding CP. 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. For instance a Web Client that checks the validity of a Web Server certificate within the ECB organization or in terms of secure email, using the recipient certificate for encrypting emails to the recipient. Relying parties implicitly agree to the terms of this CPS documentation, the associated CPs documentation and referenced general ECB security policies in their respective latest version.

There are no other participants in the ECB PKI

Certificates issued by the ECB PKI are suitable for internal applications to the extent set forth in the Certificate Policy corresponding to a specific type of certificate or a group of certificates issued under the same CP. Suitable applications and level of assurance are governed by the specific policy the issued certificate refers to by it's associated CP Object ID included in the certificate. Partners and other external entities should not assume any higher level of trust than assigned internally within European Central Bank.

All certificates issued by the ECB PKI are used for ECB internal business purposes by ECB and approved ECB partners only. ECB PKI certificates for users are issued to ECB employees either for authentication, digital signature or encryption with only one purpose per certificate. ECB PKI machine certificates may only be used for authentication purposes and to ensure the confidentiality of communication channels. Further provisions on permissible uses are regulated individually for each type of certificate by the respective CP.

Any usage not covered in the appropriate certificate uses section of the CP covering the particular certificate is prohibited. In general certificates signed by the subordinate tier 2 issuing CAs MUST NOT:

• be able to sign lower tier CA certificates,
• be used for other applications than outlined in the certification request,
• be used outsid their given validity period or after revocation (exceptions for archived encryption certifictes MAY apply),
• be issued for non-ECB and on non-certified partner subjects,
• be used for non-ECB internal and partner purposes.

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

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

For questions regarding the ECB PKI please contact:

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

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.

Approval of this CPS and subsequent amendments shall be made by the PMA. Amendments SHALL be in the form of a document containing an amended form of the CPS. The PMA shall determine whether changes to the CPS require a change in the Certificate policy object identifiers of the Certificate policies corresponding to each type of certificate.

Term	Alias	Definition
Administrative Card Set	ACS	Set of administrator authentication smart card protected private keys to perform actions on HSMs. Usually requires a quorum n out of m cards.
Authority Information Access	AIA	Certificate extension containing information about how to get the issuer of this certificate and the address of the OCSP responder from where revocation of this certificate can be checked.
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 Revocation List	CRL	A list of certificates which are no longer valid
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.
Decryption		Cryptographic transformation that restores encrypted data to its original state.
Directory		A database containing information and data related to identities, certificates and CAs.
Distinguished Name	DN	A unique identifier for an end entity, can consist of multiple parts like common name, organization, etc.
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.
ESCB Certificate Acceptance Framework	CAF	The criteria established by the ESCB ITC to identify the certification authorities, both internal and external to the ESCB, which can be trusted in relation to ESCB and Eurosystem electronic applications, systems, platforms and service.
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.
Heating, Ventilation and Air Conditioning	HVAC	HVAC is the use of various technologies to control the temperature, humidity, and purity of the air in an enclosed space.
Identity Governance and Administration Management	IGAM	enables security administrators to efficiently manage user identities and access across the enterprise.
Intellectual Property Rights	IPR	Rights on a category of property that includes intangible creations of the human intellect like patents, copyrights, trademarks, and trade secrets.
Internal Auditors Committee	IAC	is a committee in charge of ESBC annual internal audit program.
Internet Assigned Numbers Authority	IANA	A standards organization that oversees global Internet Protocol–related symbols and Internet numbers.
Internet Engineering Task Force	IETF	is a standards organization for the Internet and is responsible for the technical standards that make up the Internet protocol suite.
Key Escrow		The purpose of escrow is to allow a third party (such as an organization or government) to obtain the private key without the cooperation of the subscriber.
Machine Readable Zone	MRZ	The visual part of an official identity or travel document designed to be interpreted using optical character recognition.
Master Backup Key	MBK	Crytographic encrytion key required to decipher HSM key material backups into new or recovered PKI systems. Cryptographically divided into key shards to enforce a n out of m multi person control scheme.
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.
Online Certification Status Protocol	OCSP	A protocol that can be used by relying parties to check the validity of certificates
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.
Re-Key		Certificate re-key means duplicating unaltered identifying information from a valid certificate into a new certificate except a new public key and updated validity period.
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.
Renewal		Certificate renewal means duplicating all identifying information and the public key from the old certificate into a new certificate except for an updated validity period.
Security Information and Event Management	SIEM	is a security solution that helps recognize and address potential security threats and vulnerabilities before they may disrupt operations.
Subject		Entity identified in a certificate as the holder of the private key associated with the public key given in the certificate.
Subject Alternative Name	SAN	The SAN is an extension to X.509 that allows various values to be associated with a security certificate using a subjectAltName field.
Subscriber		Entity subscribing with a Certification Authority on behalf of one or more subjects.
Uninterruptible Power Supply	UPS	A type of continual power system that provides automated backup electric power to a load when the input power source or mains power fails.

ECB PKI is responsible for the repository functions for its own CAs.
The PKI publishes certificates it issues to subscribers in the corresponding issuig CA repository.
Upon revocation of a subscriber’s certificate, ECB PKI publishes notice of such revocation in the corresponding CA repository.
ECB PKI issues CRLs for its own CAs pursuant to the provisions of this CPS.

The PKI is reponsible for publishing information regarding its practices, certificates and the current satus of such certificates. ECB PKI maintains a web-based repository that permits relying parties to make online inquiries regarding revocation and other certificate status information. It provides relying parties with information on how to find the associated repository to check a given certificate's status and how to query the related OCSP responder. CA certificates, Certificate Policy documents and the Certification Practice Statement MUST be publicly accessible using an unencrypted HTTP webservice. Certificate status inforamtion MUST be available by publishing Certificate Revocation Lists over unencrypted HTTP. It MUST additionally be avaible via publicly accessible OCSP service. Certificate issuer certificate information and the address of the OCSP service SHALL be incoporated in each issued certificate's Authoritiy Information Access extension. In addition such information MAY be published to one ore more appropriate ECB repositories.

Minor updates of the ECB PKI CP and CPS documents MAY be published collectively during the annual review of the documents. Critical changes of these documents MUST be published within 24 hours of approval. CRLs and CA certificates MUST be published no later than 24 hours after creation or alteration.

Information relevant for subscribers and relying parties (CA certificates, CRLs, CPs and CPS) MUST be published to be anonymously and unencrypted accessible via HTTP over the Internet. Additionally an OCSP service MUST be accessible both ECB internally and publicly on the internet. Any of the above mentioned information MAY as well be published to internal repositories, internal access only web servers and directories or trusted third party directory services at the PKI mainainer's sole discretion.

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

Names are REQUIRED to be meaningful in the term that the name form has commonly understood semantics to determine the identity of a person or organizational unit (e.g. in group mailboxes). Directory names SHOULD be meaningful in the term that the name form has commonly understood semantics to determine the identity of a system or functional item.

Anonymous users as well as pseudonyms for users are not supported by the ECB PKI. Machine/device and functional (e.g. group mailbox) subjects of certificates MUST NOT be anonymous, but MAY use pseudonymous unique names and aliases as long as these names are unique throughout the whole ECB internal namespace / network while pseudonym and alternative names need to be matched to a responsible administrative contact / person during the registration process.

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.

For user certificates the subject attribute must be unique over the lifetime of the issuing CA, and the subject alternative names MUST be unique at any given point in time. For machine certificates the subject distinguished name and subject alternative names of the certificates SHOULD be unique at any given point in time. Exceptions MAY be allowed for environments with technical requirements to have multiple certificates issued with indentical SAN due to high availability implementations.

Certificate applicants are prohibited from using names in their certificate applications that infringe upon the intellectual property rights of others. ECB, however, will not conduct explicit checks whether a certificate applicant has IPR in the name appearing in an application or arbitrate, mediate, or otherwise resolve any dispute concerning the ownership of any domain name, trade name, trademark, or service mark. ECB PKI is entitled, without liability to any subscriber, to reject or suspend any certificate signing request because of such dispute.

The certificate subscriber MUST demonstrate that it rightfully holds the private key corresponding to the public key to be listed in the Certificate. This is achieved by digitally signing the PKCS #10 or CMC certificate request with the corresponding private key. This requirement does not apply where a key pair is generated by a CA on behalf of a Subscriber.

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.

The authentication of the identity of the entity requesting a certificate depends on the type of entity, and as such on the sub CA which will issue the certificate. In any case certificate requests to the ECB PKI are restricted to subscribers with a valid machine or user account in the ECB Directory or to IT staff enrolling on behalf of registered corporate or approved partner hardware and devices. Authentication of the individual identity is established as follows:

1. Certificates for individual subscribers (users) rely on the HR, physical security, and identity management processes which provide a relation between identity, corporate badge and user account in Active Directory. When users are on-boarded a badge is issued to them based on pre-entered HR and contract information which was obtained and recorded during the hiring process. During the ECB’s badge issuing process the user’s identity is verified by ECB’s physical security officers against a national ID document, i.e. verifying the national ID document for authenticity, checking the person against the document and then issuing the badge which includes a photograph of the user. Thereby the badge is a representation of the positive outcome of this identity verification process.
   The following scenarios apply, following the decision to employ 2-factor authentication using smart cards:
   1. Users are subscribed as part of the on-boarding process when they join the organization. The smart card with certificates is produced by the registration officer on behalf of the user and protected by a randomly generated PIN. The smart card and the PIN letter are separately delivered to the new user on the first day, at least one of them after verifying the subscriber’s identity using the badge (or a photo ID if the badge is not yet ready). The users are instructed to change the initial PIN at first use, and are handed over the terms & conditions. Certificate acceptance is corroborated by use of the smart card (see section 4.4).
   2. A guided enrolment procedure is possible as backup procedure. The registration officer verifies the existence of the user account (and thus the user’s eligibility) and the user identity, and subsequently triggers the enrolment. The PKI system sends an email with a one-time-password to the user. The user then finalizes the enrolment of the smart card in the PKI system using the one-time password. Finally, the user reviews the certificates (and accepts them by this action, see section 4.4) and sets the activation data (PIN) for the smart card.
   3. When a user has lost or forgotten the smart card, or it is defective, the user needs to appear at the service desk, where the user’s badge or photo ID is checked, and a new smart card is issued with new certificates, with a random PIN, which the user is instructed to change on next use. The old certificates are revoked as per section 4.8. Certificate acceptance is corroborated by use of the smart card and the containing certificates (see section 4.4).
   4. For the initial rollout (first-time issuance of certificates) of the smart cards and their respective PINs to the existing users the users are subscribed^* centrally by an registration agent who prepares the smart card, prints the PIN letter (with a randomly generated PIN), and places both in separate envelopes, with a tamper-evident seal applied to the PIN letter. The smart cards and PIN letters are handed out via an organizational entity’s management assistant who verifies the user’s identity using the badge. Users are handed over the terms & conditions, and are educated about the properties of the tamper-evident seal, and are instructed to look for an unbroken seal, report if tampered with, and otherwise change the PIN on first use. Certificate acceptance is corroborated by use of the smart card (see section 4.4).
2. Certificates for machine or device subscribers requested online or offline via the ECB PKI certificate enrolment process can only be requested by users with a valid Directory user account.
   The authentication is performed by
   1. A successful logon to the ECB LDAP directory,
   2. A valid corporate ECB email address and addition information to verify the requestor during the enrolment and approval process, or
   3. On behalf of an approved partner user or devices by authorized ECB internal staff.

In the cases of item 1.a., 1.b., and 1.d. the terms & conditions handed over to the subscriber serve as a reminder of already existing and contractually agreed-to obligations as stated in the ECB internal rules. Explicit certificate acceptance does not apply as per section 4.4.

Any enrolment request that holds non verifiable information and / or information that cannot be validated as a valid ECB contact responsible for enrolment of the corresponding end-entity certificate is discarded without any further notice.

Users are eligible for enrolling with the ECB PKI for user certificates if they are ECB employees or ECB contractors. This is validated by establishing a unique mapping between the user’s identity, his/her smart card and his/her Active Directory user account. Enrolment requests are invalid if the user account is disabled, which indicates that the user is, at that point in time, no longer eligible to enrol. 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.

n/a

Automated re-key procedures ensure that the person requesting to rekey a subscriber certificate is in fact the subscriber of the certificate. The only acceptable procedure is by proof of possession of the private keyt hrough signing the re-key request with the existing private key corresponding to the to be replaced public key of the still valid certificate about to expire. Upon re-key of a certificate, if a subscriber correctly submits the signed request with the subscriber’s reenrollment information, and the enrollment information has not changed, a re-keyed Certificate is automatically issued.

After revocation the initial identity validation process (see 3.2) MUST be followed to obtain a replacement certificate.

In order to avoid delay in disabling compromised credentials, temporary revocation requests can be raised by any ECB employee with minimal validation requirements (e.g. known telephone number, known email address or personal knowledge). Any temporary revocation request will trigger a process to either invoke or cancel the permanent revocation which includes appropriate identification and authentication mechanisms.
For details see section 4.9

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.

Enrolment process

• User Authentication, Signature and Encryption certificates to subscribers are enrolled on the a smart card of the user according 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 have a smart card a new one is issued.
• Client Authentication certificates to machine subscribers are enrolled automatically via Directory Group Policies based on computer object group membership.
• OCSP Responder certificates to machine subscribers are enrolled automatically via OCSP responder machine and OCSP responder array configuration.

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

1. generates a certificate signing request for ECB internal machine and device or
2. 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

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 and the user’s account in the Active Directory.
• (for offline activities, such as initial on-boarding) to establish the mapping between the user’s account in Active Directory and the smart card, and later on ensure that the smart card is delivered via the predetermined processes through which the user’s identity is verified during hand-over.

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.

Applications for user certificates are processed via the standard ECB identity management processes.
For new users the certificates are requested as part of user account creation, for existing users the process is conducted by the service desk with user presence, and the initial certificate creation of existing users is processed as part of the introduction of the smart cards for 2-factor authentication.
In any case the core ECB PKI user certificate process is being followed.
Applications for machine/device certificates are part of the standard ECB IT change management process where the ECB change management policies and regulations apply.

Identification and authentication of users is done by an RA operator verifying the requester’s identity in person by

• checking the user’s badge with photograph, relying on the fact that the physical security officer issued the badge only after verification of an official picture ID document, and
• establishing the unique mapping between the user’s identity, the smart card and the Directory-based user account.

On a technical level identification and authentication is performed by the ECB Directory. All requesting entities REQUIRE a valid Directory account for authentication or an appropriate administrative contact Directory account is REQUIRED for enrolment on behalf of non-Directory-integrated devices.

Certificate applications SHALL be accepted upon meeting certificate criteria set forth in the respective CP.
The issuing authority MAY accpet a certificate application not meeting the criteria by replacing, adding or deleting information in the request according to the respective CP.
Certificate applications MUST be rejected if the request must not or can not be amended to meet the criteria set forth within the corresponding CP.

Certificate requests for existing certificate profiles including a defined enrolment process will be processed according to the

• ECB IT Certificate Services Operational Level Agreement, or
• ECB IT change management Operational Level Agreement (machine/device certificates).

Requests for new certificate types will be processed under the release management in place for Certificate Services.

During the issuance of the certificate, the ECB PKI Issuing CAs perform the following actions:

• validate the RA signature
• validate RA authority on the desired certificate profile
• validate the request subject DN and extensions against the target certificate profile
• if the certificate type permits, the CA MAY add, remove or alter certificate information to match the profile
• evaluate the public key to enforce an unique public key constraint throughout ECB PKI
• evaluate the subject DN to enforce an unique name constraint throughout ECB PKI
• for certificate profiles stipulating key backup, the CA will generate the key pair and escrow the private key
• store or update the subscriber end entity object in the CA database
• sign the (OPTIONALLY amended) certificate signing request and issue the subscriber certificate
• store issued certificates in the CA database

Notifications of certificate issuance to the subscriber MAY be provided by e-mail in case the process itself does not include an implicit confirmation like being offered to download the certificate.
Automated issuance processes SHOULD NOT cause notifications to the subscriber.
Deviations from this default behaviour MAY be defined on the corresponding CP for the certificate issued.

In the standard case of user enrolment on behalf, the certificate subscriber is handed out the smart card containing the certificates (in case of production of a new token) or handed back his/her existing token (in case of certificate modification with re-key). When receiving a new smart card the user is also handed out the terms & conditions. The use of the certificates establishes the corroboration of the acceptance of the certificates as well as the terms and conditions. In any case the user has accepted the general rules for user conduct in place at the ECB as part of the work contract.
For guided user enrolment the user directly reviews the created certificates and sets the activation data for the token for future use, thereby accepting the certificates. (see also section 4.5.1)
Explicit acceptance does not apply to subscribers with automatically enrolled certificates.

User certificates on smart cards

Receiving the certificate is integrated into a workflow which

• Generates new key pairs,
• Generates a random PIN for the protection of the private key against unauthorized use,
• Informs the user about the terms and conditions set out in the ECB internal rules, and about the requirement to change the initial generated PIN,
• Requests the actual issuance of the certificate, and
• Generates the certificate package on the smart card.

Completion of this process and handover of smart card and the PIN plus terms and conditions (via different channels) to the user constitutes acceptance of the certificate(s).

Manual enrolled machine certificates

After receiving the certificate, the administrative contact responsible for the service or application the certificate was requested on behalf of, has to verify the certificates. If the certificate contains invalid information or if the key or the certificate is faulty, the administrative contact has to notify the ECB PKI operations staff immediately. In case of proper keys and certificates, a certificate acceptance is constituted.

All auto-enrolled machine certificates

After successful automatic certificate enrolment on the requesting machine a certificate acceptance is constituted.

The certificates of ECB PKI certification authorities are published in the ECB Directory and on the ECB PKI website. ECB PKI end-entity certificates MAY be published in the central repositories depending on appropriate end-entity purposes according to certificate profiles in their most current version and / or technical requirements depending on the desired use case.

Notification of other entities is not supported.

The ECB-internal rules for user conduct contain the general security obligations which apply to all users. These guidelines can be found on the ECB intranet. They state in particular that the user is responsible for

• the secure use of his/her personal user ID and of his/her workstation and the information therein;
• protecting and regularly changing passwords assigned to him/her, as well as protecting other security devices and tools at his/her disposal (e.g. encryption keys and smart cards);
• using individually granted access to systems and data stores solely for the purpose of the tasks he/she is instructed to perform;
• complying with legal requirements regarding, inter alia, privacy and copyright restrictions; and
• notifying local management and the IT Service Desk of any detected or suspected information security incidents, problems or shortcomings.

In case of a discovered or believed private key compromise or violation of any other requirements mentioned above and connected ECB security policies, the subscriber must immediately notify ECB Service Desk, request certificate revocation, discontinue any further use and take appropriate measures in connection with ECB PKI processes to mitigate any security risk arising from key compromise.

Relying parties must assess if a given certificate is appropriate for the specific purpose.
In particular they must verify that a certificate is used in accordance with the private key and certificate usage set forth by the associated CP. Certificates may only be relied upon if the following verification steps are successful

• Identifying a certificate chain up to the explicitly trusted ECB PKI Root CA (trust anchor) including its subordinate CAs
• Verifying the certificate chain and end-entity certificates, including
  • Verifying that the claimed identity is identical to the identity corroborated by the presented certificate
  • Validation of each digital signature
  • All certificate extensions including key usage and extended key usage extension matching to the appropriate and approved purposes
  • Validation of validity period at the time of checking
  • Conduct certificate revocation checking either by CRL or OCSP while systems supporting OCSP should prefer OCSP as the primary method for revocation checking and may fall back to CRL if the OCSP responder service is unavailable. This fall back method does not apply to an OCSP response stating the certificate as invalid.

Relying parties may not compromise the ECB PKI security measures, policies and verification steps and neither disrupt or interfere with ECB PKI certification services. In case of any security violation the relying parties must discontinue any further usage, notify ECB Service Desk immediately and apply countermeasures as advised by ECB PKI operations team without question or delay.

The ECB PKI does not support certificate renewal. Certificates with identical information and updated validity period MUST NOT use the key pair of any existing certificate.

Certificate re-key is not supported by ECB PKI. Instead a new certificate request with updated public key MUST follow the initial certificate application process. The certificate request MAY contain identical information as the superseded/expired/revoked otherwise.

ECB PKI does not support certificate modification, as generation of a new key pair is MANDATORY on any certificate data update. During the issuing process for the amended replacement certificate, the existing certificate MAY stay valid up to the not before validity date of the replacement certificate. It MUST be revoked upon start of validity of the new certificate to meet the single active certificate requirement.

A certificate MUST be revoked when

• the ECB PKI Certification Authority which issued the certificate ceases operations for any reason
• the private key associated with the public key listed in the certificate or the media holding such private key is suspected or known to have been stolen, disclosed in an unauthorized manner or otherwise compromised
• the key, the smart card and/ or device is stolen / lost / retired and the certificate is still in its validity period
• violation by the subscriber of any of its material and essential obligations under the ECB PKI CP and CPS or the subscriber agreement
• a given determination, in the ECB PKI Authority's sole discretion, that the certificate was not issued in accordance with the terms and conditions of the ECB CP and CPS
• a determination by the ECB PKI authority that continued use of the certificate is inappropriate or injurious to the proper functioning or intent of the ECB PKI
• the subscriber is no longer authorized to have an ECB PKI Certificate
• Devices and/ or Machines are reinstalled and the respective end-entity certificate is still in its validity period
• The certificate has undergone modification with re-key, and thus the old one shall no longer be valid.

Certificate revocation may be requested by

• ECB PKI certificate subscribers
• ECB PKI associated RAs
• ECB PKI CAs
• European Central Bank's authorized administrators or security officers

A revocation request can be raised by

• visiting ECB IT Service Desk office
• calling ECB IT Service Desk
• sending an email to the ECB IT Service Desk
• using another written or electronic form, for instance via ECB IT Service Desk Portal
• ECB IT change request tools

If the identity of the requestor cannot be fully established^*, a certificate SHALL be suspended (i.e. revoked with revocation reason 'Certificate hold'), so that erroneous requests can be corrected.
With subsequent proper subscriber authentication a suspended certificate can be revoked permanently.
In all such cases a ticket linked to the subscriber (for user certificates identical with the subject) is created in the IT service management tool.
The subscriber is informed about status changes of the ticket via email, which includes the processing of the revocation request.

The revocation request grace period is the maximum period between when a subscriber suspects compromise or loss of control of the Private Key has occurred and when the incident is reported to ECB IT Service Desk. This period MUST NOT exceed 3 hours.

Revocation requests will be processed according to the incident management service level agreement in combination with the certificate type of the desired certificate.

ECB PKI relying parties MUST check the certificate revocation status prior to making decisions based on the information derived from the certificate. This revocation status check MUST be performed during initial authentication and SHOULD be repeated for session time extension according to the underlying business and security requirements.

ECB PKI base CRL issuance frequency

Certificate Authority	Publication	Lifetime
Offline Root CAs	6 months	8 months
Online Issuing Sub CAs	6 hours	5 days

Online CAs issue an additional CRL upon revocation of a certificate.

The maximum latency for publishing ECB PKI CRLs is within 60 minutes following certificate revocation. Certificate status information available via OCSP is updated immediately.

On-line revocation/status checking SHALL be available at http://ocsp.ecb.europa.eu using OCSP via HTTP. Where Security considerations demand it, this service may OPTIONALLY be available via HTTPS in addition.

OCSP revocation checking is MANDATORY for any user authentication requirement. It is RECOMMENDED for all certificate validity checking due to its near real time accuracy and lower traffic requirements compared to CRL publishing latencies and repetitive full CRL downloads.

n/a

no stipulation

ECB PKI does not support certificate suspension. Once added to the CRL, a certificate MUST NOT be deleted from it for the certificate's remaining validity period.

CRL and OCSP subscription ends when the ECB PKI CA certificate is expired or the ECB PKI CA and connected PKI service is terminated.

• All CRL and OCSP subscription ends, when the ECB PKI root CA certificate in question is expired or the respective root CA service is terminated.
• CRL and OCSP of ECB PKI sub CAs subscriptions end, when the respective ECB PKI sub CA certificate is expired or the ECB PKI sub CA service is terminated.

Private key escrow is available for encryption certificates only. policies and practices for key escrow and recovery are set forth in the European Central Bank Cryptographic Key Escrow Policy.

no stipulation

The central components of the ECB PKI are hosted in the ECB secure data centres conforming to the general ECB standards for physical and environmental security and are operated by authorised personnel of the ECB’s IT department under the terms of its general regulations and (security) policies. The buildings hosting ECB PKI infrastructure are equipped with access control systems that permit only authorized personnel to enter; all critical ECB PKI operations are being carried out inside physically secure facilities. In particular the following physical security measures are implemented:

• Surveillance cameras,
• Guards,
• Absence of windows,
• Physical access control based on badge and biometrics,
• Fire detection and prevention systems: detectors and extinguishing systems,
• UPS,
• Cooling.

All central infrastructure components of the ECB PKI, such as CA servers and HSMs, are located in those data centres. The CA limits access to hardware and software to those personnel performing a trusted role. The CA controls access to its components by sufficient access control mechanisms.
The CA components are operated in a secure environment, where only trusted and authorized staff can access these components.
Furthermore, the components of the RA are operated by the ECB DG-IS IT department under the terms of its general regulations and policies as well as dedicated procedures.

The ECB’s data centre locations are designed to provide sufficient protection for the hosted components of the ECB PKI from physical and environmental impact.
This includes a physical perimeter designed to integrate with physical access control measures to ensure that only authorised personnel can physically access to the central infrastructure components of the ECB PKI as well as supporting systems.
For redundancy two physically separate sites are used with sufficient distance between them.

ECB PKI critical components are located inside a protected security perimeter with alarms and physical protection against intrusion.
Physical access of individuals to the building is controlled at the entry and exit, with authorisation provided only in case of a need to access. Access authorisations are reviewed periodically and corrected where necessary. The deployed access control measures require a badge and biometrics for authentication before physical access is granted based on proper authorization.

ECB PKI infrastructure systems are located in data center rooms fed by redundant power supplies, connected to an UPS. An HVAC system provides cooling and atmospheric control within the data center rooms.

Water detectors are in place, and constructive measures have been taken to limit the impact of water leakage.

ECB PKI components are located in data centre rooms with fire detectors and fire extinguishing systems.

ECB PKI systems are redundant and distributed over separate protected ECB datacenter location which protect against unauthorised access, theft and physical deterioration or destruction of storage media from environmental impact.

ECB Confidentiality Regime information storage and disposal requirements apply. Waste management measures are in place to guarantee secure destruction of critical material and removable media accordingly.

Backups of online systems are saved onto network storage in separate redundant ECB datacenter locations. Encrypted offline system backups are saved onto encrypted portable media and stored in a fireproof safe outside the datacenter on secure ECB premises.

The ECB PKI recognizes the following trusted roles associated to its operations:

• PKI Administrators (also HSM Smart Card Custodians)
• PKI Operators (also HSM Smart Card Custodians)
• Certification Authority Administrators
• Registration Authority Officers
• System Administrators
• Security Officers
• System Auditors

Whereas the ECB PKI is designed lightweight and streamlined for automation and single operator safety, crucial PKI tasks REQUIRE multi person control:

Task	Role(s)	Quorum
Restoring PKI master backup secret	PKI Administrators	3 of 5
Root CA key generation/re-key	PKI Operators	3 of 3
Root CA key activation	PKI Operators	3 of 3
Root CA CRL creation	PKI Operators	3 of 3
Root CA OCSP responder certificate signing	PKI Operators	3 of 3
Sub CA certificate signing	PKI Operators	3 of 3
Sub CA revocation	PKI Operators	3 of 3

Role	Identification	Authentication
PKI Administrators	holding a personally assigned smart card of the MBK card set	smart card PIN entry
PKI Operators	holding a personally assigned smart card of the ACS	smart card PIN entry
Certification Authority Administrators	in posession of the private key to an authorized administrator certificate	TLS client certificate presentation within enhanced security administration enviroment
Registration Authority Officers	member of the IGAM group for RA officers	smart card and PIN protected authentication certificate presentation
System Administrators	member of the IGAM group for System Adminstrators	PAM authentication within enhanced security administration enviroment
Security Officers	member of the IGAM group for Security Officers	smart card and PIN protected authentication certificate presentation
System Auditors	member of the IGAM group for System Auditors	presentation of TLS client certificate or PAM authentication within enhanced security administration environment

For any HSM operation requiring multi-person control the necessary quorum to perform the operation must be divided between teams performing security advisory, operations support and engineering for the ECB PKI system.
The role of an RA Operator must be assigned to separate personnel than PKI operations. The roles of system administrators and security advisor are mutually exclusive.
The auditor and security testing roles must be assigned outside the ECB PKI operations team.

Persons bestowed with trusted tasks within ECB PKI operations MUST have proven competence and experience that is appropriate for the respective tasks. Persons holding a trusted ECB PKI role REQUIRE a level B ECB security clearance and confidentiality agreements must be in place.

Performed background checks and clearance procedures for staff selection are set forth in the European Central Bank Introduction to Security Clearance and confidential internal HR candidate screening procedures.

ECB ensures that employees receive the required training to perform their job responsibilities competently and satisfactorily.
ECB periodically reviews its training program.

Re-training must be scheduled as deemed necessary for the personnel to maintain the skills required for the job profile and responsibilities.

no stipulation

In case of unauthorized actions or violation of ECB corporate policies and procedures appropriate disciplinary actions shall be sought in line with ECB human resources procedures.

The same requirements SHALL apply to ECB certified independent contractors and IT service partners.

All ECB PKI personnel will be supplied with CP and CPS documents, process documentation, operation manuals, technical/operational concept/documentation and accompanying information during training and for reference and re-training.

The security audit log logs important events such as "Certificate issued", "Certificate Profile edited", "Administrator accessed resource". It does not log events that do not happen like for example invalid requests that the system rejects, because the PKI system did not perform any important auditable event.

Audit log events mirrored to the external syslog device provide a continuous monitoring opportunity. The audit log is archived during daily online system backup procedures. Offline CAs are backed up manually at least every 6 months during CRL signing. Manual log processing occurs following alarms or anomalous events.

Recorded events SHALL be retained in the audit log for at least 3 months. The components of the ECB offline Root CAs SHALL keep recorded events for at least 6 months.

Audit logs are accessible by authenticated administrators and auditors only.
They are recorded in an integrity protected log device in the CA database. Database integrity protection consists of an additional rowProtection column in all protected tables.
Each log event records an indetification of the CA appliance node and a monotone sequence number that is part of the integrity protected data.
Audit logs are enclosed in the periodic PKI backup procedures.

Audit logs are backed up included in the CA integrity protected database backup. An automated backup is scheduled daily for online CAs and manual backups are done at least semi annually for offline CAs during shutdown after CRL signing or other Root CA related tasks.

The ECB PKI audit logs SHALL store audit log events internally to the hardware appliances CA database. In addition audit log events mirrored to the appliances syslog is forwarded to an external syslog server for continuous evaluation and archival.

no stipulation

Audit events exported to external syslog devices SHOULD be continuously monitored by a SIEM for potential attempts to breach ECB PKI system security.

ECB PKI archives all audit data and certificate application information.

The retention period of the archive MUST adhere to or exceed the standard ECB PKI and ECB change management archival retention period.

Archive access MUST be limited to trusted auditors only.
The archive SHALL be protected against modification by securely storing it to write once media that SHOULD be kept in a fireproof safe to protect it from deletion and destruction.
To prevent media deterioration during the retention period of the archive, archive data MAY periodically be migrated to fresh media.
Log entries are stored in hardware and software independant formats like XML to protect audit logs against obsolescence of hardware, operating systems, and other software.

n/a

All archived information SHALL contain NTP synchronized timestamp information.

n/a

n/a

Following a ECB PKI CA re-key, the new public key SHALL be provided to its users by the same procedure for providing the current key.

ECB has implemented a high security environment according to commonly accepted best practices to minimize the risk and potential impact of a key compromise or disaster. The main goal is to restore ECB PKI operations within a reasonable period of time in the event of a CA key compromise or disaster or any failure to related PKI components.

To manage all operational processes, the ECB PKI operations teams and the ECB internal IT department has adopted the ITIL best practice model. In particular the ECB operates a Service Desk which receives and processes all service calls including ECB PKI related processes and procedures. Further ITIL processes like incident and problem management are implemented. The ECB PKI is part of Technical Service “Certificate Services” which is on-boarded in the ECB Service Portfolio and is compliant with ECB ITSCM process performing regular test exercises on RTC for the service. ECB PKI system is configured to use redundancy for most critical components, procedures for backup and restore scenarios have been prepared to describe steps to be taken in case of a disaster, regular restore tests are taking place periodically to ensure completion and accuracy of the procedures and backups.

The ECB PKI Root CAs and their subordinate online issuing certification authorities and related PKI online service components are implemented as a 24x7 high availability cluster solution. The ECB PKI Root certification authorities are implemented using a cold standby solution, providing fast replacement of required Hardware and Software components in case of failure or data corruption. The issuing certification authority servers and online PKI service components underlie a daily backup process. The backup for the ECB PKI Root certification authorities is conducted on occasion in a reasonable timeframe, at least before any changes to these systems within 6 months. In the event of suspected or evident corruption of computing resources, software, and/or data, downstream ECB PKI operations SHALL cease until a secure environment has been re-established by wiping/replacing affected hardware and setting up from known good backups or from scratch following the ECB PKI installation and configuration documentation.
Any certificate that cannot transparently tracked back to its authorized issuance (e.g. due to audit log or subscriber/application data corruption) MUST be revoked. The new public key (if applicable) SHALL be provided to its users by the same procedure for providing the current key.
Subjects affected by this event SHALL be re-certified according to the initial certification process.

If an ECB PKI entity private key compromise is suspected or discovered, the affected entity certificate MUST be revoked and re-keyed.
It SHALL revoke all downstream certificates issued using the compromised key and inform their respective subscribers.
The re-keyed entity MAY choose to re-issue otherwise unaltered downstream entities certificates signed by the new replacement key. Such replacement certificates and the new public key distribution and provisioning of the new public key SHOULD be provided to the subscribers by the same procedures for providing the compromised key and existing certificates.

The general disaster recovery procedures are defined as part of the general ECB Business Continuity Plans including the ECB PKI Operations Guide. ECB PKI systems are redundantly distributed over failover clusters spanning to a remote hot-site to seamlessly recover operations.
Additional cold spare systems are available to replace failing/lost hardware appliances and master backup keys can be restored using the redundant sharded MBK smart card set held by the ECB PKI administrators and site redundant backups.

Upon termination of ECB PKI CAs, users will be notified of the termination taking into account the aim to minimize the disruption to subscribers and relying parties. Such notification SHOULD include:

• what type of support services will be continued, migrated, and/or discontinued and how authorizations, related process and systems will change accordingly
• if and how revocation and the CRL issuance will continue
• the rmaining retention period for CA records and archives
• decisions if valid certificates of subscribers and subordinate CAs will be revoked
• possible issuance of replacement certificates by a successor CA
• destruction or withdrawal of the CA’s private keys
• provisions needed for the transition of the CA’s services to a successor CA

Cryptographic keys of ECB PKI components including Root CA and all subordinate issuing CAs, SHALL be generated in hardware security modules with the FIPS 140-2 Level 3 certification. It is assured that trustworthy hardware appliance systems are used for the generation of CA key pairs. The process to assure this trustworthiness and required procedures, as well as the detailed definitions of the key generation procedures is not part of this document and outlined in the Key ceremony documentation that can be provided upon request. Generation of subscriber key pairs is performed at the time of registration where using at least a software cryptographic module meeting the requirement of FIPS 140-2 Level 2 is MANDATORY. For user key pairs/certificates the key generation MUST meet the following criteria:

• Strong user authentication (e.g. logon) key pairs MUST be generated in smart cards with FIPS 140-2 level 3 certification or better.
• User signature (e.g. document/mail signing) key pairs MUST be generated in smart cards with FIPS 140-2 level 3 certification or better.
• Data encryption (e.g. to encrypt data sent between systems or users) key pairs MUST be generated in secure environments at least meeting the requirement of FIPS 140-2 Level 2 and imported into smart cards with FIPS 140-2 level 3 certification or better. A copy of the imported keys MAY be stored for approved private key archival/backup/escrow scenarios and REQUIRE encryption where the decryption key material MUST be under the issuing CA's control and been generated in a HSM.
• Remote access authentication (e.g. VPN client authentication) key pairs MUST be generated on the user’s computer, with MANDATORY not exportable private key.
• Code signing key pairs (for code signing) are generated on user’s computer.

Private keys for ECB PKI subscribers are generated and protected locally (in particular keys for user certificates for authentication and signatures) or are generated remote to the subscriber within a secured environment using the ECB PKI certificate management application (in particular keys for user certificates for encryption).
For user certificates the delivery and transport of private keys is thus avoided where possible (for authentication and signature keys), and conducted in secured form where necessary (encryption key pairs) to provide end to end confidentiality and mutual authentication of all related parties and PKI components.
For other subscribers (in case of machine certificates) the delivery and transport of private keys to subscribers is discouraged, and in case it is needed conducted in secured form (e.g. PKCS12 secured by a passphrase) to provide end to end confidentiality and mutual authentication of all related parties and PKI components.

All public keys provided by the subscriber SHALL be delivered electronically to the ECB PKI issuing CAs by CSRs in CMC or PKCS #10 format.

If not provided enclosed in the subject certificate's certificate chain in an encrypted TSL session upon issuance, the CA public key MAY be obtained by querying the ECB LDAP directory or ECB PKI web site AIA section for CA certificates. The respective URI is provided in the subscriber certificate's AIA extension.
Where this is not feasible, the certificate chain incling the CAs' certificates MAY be delivered to the trusting party via e-mail which SHOULD be cryptographically signed.

ECB PKI CA key size is MANDATORY 4096 Bit RSA.

No stipulation

No stipulation

Cryptographic keys certified by the ECB PKI SHOULD be generated using modules compliant with FIPS 140-2 at level 1 or above.
All ECB PKI CA and OCSP HSM modules MUST at least be FIPS 140-2 Level 3 compliant.
ECB PKI advanced subscriber user key pairs (authentication, signature) SHALL only be generated in FIPS 140-2 level 2 or above compliant hardware smart cards.
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.
Other ECB PKI subscriber user key pairs (e.g. remote access) MUST be generated in at least FIPS 140-2 level 1 compliant software cryptographic providers and MUST NOT be exportable.
ECB PKI machine subject key pairs SHOULD be generated in at least FIPS 140-2 level 1 compliant software cryptographic providers and SHOULD NOT be exportable.

On ECB PKI root CA components cryptographic operations and private key access REQUIRES multi person based authorization. This is cryptographically enforced on HSM access by requiring a quorum of 3 out of 5 keys on an ACS spread over multiple secure authorization smart cards issued to multiple trusted persons.

no stipulation

no stipulation

no stipulation

Private Key transfer from a cryptographic module protected storage is PROHIBITED. Private keys stored in software cryptographic storages (e.g. certstore/keyring) MUST NOT be exportable. For key archival/backup/escrow purposes on user encryption certificates, private keys MAY be generated in a trusted secure environment and transfered into approved smart cards via encrypted transfer channels.

• ECB PKI root CA private keys are protected by a Hardware Security Module (HSM) in conjunction with a multi-person control key access authorization implementation.
• ECB PKI sub CA and OCSP private keys are protected by a Hardware Security Module (HSM).
• All ECB PKI advanced subscriber (user) key pairs (authentication, encryption, signature) are protected on smart cards at least FIPS 140-2 level 2 compliant.

ECB PKI Root CA private keys MUST be activated by presenting a full multi person control ACS including individual PIN entry to unlock the HSM slot containing the desired private key. Activation lasts until the HSM slot is locked by administrator command or upon returning the CA appliance into offline mode or power it down.
ECB PKI Sub CA private keys are aktivated automatically on boot to enable PKI automation and redundant fail over cluster operations for high availability.
Subscriber keys issued into smart card tokens MUST be activated by PIN entry. Activation expired upon withdrawal of the smart card, power off or a timeout stipulated by the respective operating system or application software.

ECB PKI Root CA private keys are deactivated by returning the CA appliance to its offline mode after maintenance.
ECB PKI Sub CA and OCSP responder private keys are deactivated by locking the HSM slot on or powering down the hardware appliance.

CA key destruction is performed by a PKI Operator by deleting the key from its HSM slot on the CA appliance.
Subscriber keys MAY be destroyed by the subscriber surrendering the token or deleting the key from its certificate store. If the private key cannot be overwritten or deleted from a hardware token, the token MUST be physically shredded to destroy the key.

All ECB PKI CA and OCSP HSM modules are FIPS 140-2 Level 3 compliant.
User certificate smart cards MUST comply to FIPS 140-2 level 2.
Software cryptographic tokens Shall be FIPS 140-2 level 1 compliant.

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

For ECB PKI the CA certificate operational period equals the key pair usage period as it is going to superseded by a re-keyed certificate well within its validity pariod. Certificate validity extension MUST be performed by re-keying, certificates SHALL NOT be renewed. The following certificate operational periods are defined within ECB PKI certification services.

Certificate Type	Validity Period	Re-key Period
ECB PKI root CAs	20 years	14 years
ECB PKI sub CAs	10 years	7 years

For end entity certificates, operational periods and key usage periods are specified in the corresponding CP document.

Activation data generation for machine subscriber keys is performed automatically during machine setup by the local security subsystem. Only local system access is granted to the key store.
Activation data generation for user subscriber keys for VPN client authentication on ECB
is performed automatically after user logon and activation of relevant Group Policy Object settings. Activation data generation for user subscriber keys for Code Signing is done upon certificate installation (password is provided during this process).
Activation data generation for Subscriber’s private key (PIN) on smart cards is performed via the smart card enrolment process during which a random PIN is set at the time of generating a cryptographic key on user’s smart card. They are mostly used for individual authentication. Activation Data is either handed over immediately or delivered later on to the user, via a different channel than the smart card token.
In case of guided enrolment of a subscriber the activation data is chosen and set by the subscriber and does not need transport or transmission.
Shared secrets used for the protection of the CA private keys are generated using HSM devices and are protected by a HSM operator card set quorum for data activation. ACS and OCS smart cards are PIN protected.
Activation data for network devices or user subscriber keys must at least follow the ECB internal IT Department’s password policy and regulations.

ECB PKI subscribers are required to assert that any activation data is kept secret and is never disclosed to a third party. CA private key activation REQUIRES the presence of 2 out of 3 OCS quorum cards assigned to HSM Operators. Smart cards with components of a shared secret are distributed to HSM Operators. Non personalised smart cards are stored in facilities protected by an access control system. PIN codes protecting the cards MUST NOT be stored at the same place as the cards.

Hardening procedures of the ECB PKI CA servers and relevant PKI components have been performed, which includes the implementation of up to date security patches. Server and component hardening is conducted on general ECB guidelines and common best-practices.

Specific computer security technical requirements at ECB include:

• Access to these systems is limited to trusted persons who need access to perform their trusted roles.
• Every system has anti-virus software installed. Further, ECB monitors the systems to detect malicious software on a continuous basis
• Regulations are in place regarding email. In particular, all incoming and outgoing emails are checked by a central anti-virus system.
• Use of passwords to authenticate users. Guidelines are put in place concerning password handling. Passwords are required to have a minimum character length and a combination of alphanumeric and special characters. Periodic password change is required.
• All computer systems are locked or shut down if not used or in idle mode depending on the period of time.

ECB PKI certification services are built on hardware appliances bundling hardened operating system servers and integrated FIPS 140-2 Level 3-certified HSMs.

n/a

Monitoring and auditing mechanisms are used to ensure that systems and networks are operated in compliance with the ECB internal IT Department and ECB PKI specific security policies.

Quality assurance processes were employed during the system deployment.
A set of three complete separated test and staging environments was configured to provide testing and quality assurance according to ECB standards.

Network protection is applied according to best practices and ECB security policies based on a defined network communication matrix outlining the required protocols and communicating systems within the ECB PKI implementation.
ECB PKI systems run in dedicated separated network segments protected from any foreign traffic by VLANs and firewalls. Network traffic is subject to continuous monitoring for vulnerability scanning and threat assessment.

ECB PKI certificates and CRLs bear an issuance timestamp.
The time source is the CA hardware appliance NTP synchronized local clock. The local clock of the offline ECB Root CAs SHALL be synchronized manually when brought online for maintenance.
ECB PKI does not offer trusted timestamping capabilities.

See applicable certificate policy document.

ECB PKI issues X.509 Version 2 CRLs

ECB PKI uses the following CRL extensions:

• 2.5.29.35 Authority Key Identifier (non critical)
• 2.5.29.20 CRL Number (non critical)

ECB PKI uses OCSP v1

ECB PKI populates the following OCSP extensions:

• 1.3.6.1.5.5.7.48.1.2 OCSP NONCE (non critical)
• 1.3.6.1.5.5.7.48.1.6 Archive Cutoff (non critical)

Audits of the ECB PKI and related infrastructure components will be performed along with regular ECB internal IT Department and Security Audits. Additionally ECB PKI will be audited by an auditor with proven track record in PKI audits at least once every 3 years, in accordance with the ESCB/SSM Certificate Acceptance Framework, to check for compliance with the CP. The audit report will be shared with the PKI AB.

Compliance audits are performed by ECB internal resources or the ESCB Internal Auditors Committee (IAC) according to the annual audit program.
Compliancy Audit for the ECB PKI is conducted by the PKI-AB.
Security audit on ECB PKI must have knowledge, appropriate training and experience in PKI, security, cryptographic technology and audit procedures.

The ECB auditors are organizationally independent to ECB PKI certification service responsible parties.

The ECB PKI will be audited by the PKI-AB at least once every 3 years, in accordance with the ESCB Certificate Acceptance Framework, compliancy to CAF requirement will be provided to SRM-WG by written procedure within the defined time frame.
The audit verifies ECB PKI compliance with its CP and CPS documents including verification of existing processes, procedures and disaster recovery plans.

If an audit detects deficiencies, an action plan for remediation is initiated.
ECB PKI operations staff and / or ECB internal DG-IS IT Department management is responsible for developing and implementing of such action plan. Actions are prioritized depending on the severity of the deficiencies which have been discovered. After implementation of the action plan, it is verified that the deficiencies have been successfully corrected.
ECB internal DG-IS IT Department management and ECB PKI operations team including responsible Security Officers are informed of the results.
Additional communication must be provided to PKI-AB in writing within the defined time frame.

Audit results are considered confidential information until remediation has been implemented.

Following section applies to business, legal and data privacy matters of ECB PKI certification services. The current PKI and related infrastructure is designed for internal and approved ECB business partner use only. Therefore following topics are regarded as not applicable while no guarantees or warranties are accepted in any case besides the standard ECB internal and approved ECB Business Partner Service Level Agreements.

n/a

In accordance with Article 35.3 of the Statute of the ECB and ESCB, the ECB shall be subject to the liability regime provided for in Article 340 of the Treaty on the Functioning of the European Union.

No liability accepted.

ECB general Information Security Policies and Privacy Statements in their latest versions apply.

Any information exceeding PUBLIC or UNRESTRICTED classification under the European Central Bank general Information Security Policies is considered confidential under this policy.

Any inforation in pusblished documents like this policy document and accompanying regulations are not within the scope of confidentiality. Information contained within certificate signing requests sent to the ECB PKI are supposed to be publicly available on the resulting certificates within their respective application environment and thus considered public information. So certificate applicants MUST NOT provide confidential information as part of CSRs, as the resulting certificate MAY become publicly available.

Subscribers and all relying parties should treat any ECB PKI related information to be covered by applicable ECB general Information Security Policies unless otherwise stated. This does not apply to publicly available information or general means in terms of industry standards.

ECB general Information Security Policies and Privacy Statement in their latest version apply.

Any personal information on subscribers stored or processed in ECB PKI systems including its log records and meta information is treated as private information.

Owed to the nature of a public key infrastructure, personal information on certificates issued by the ECB PKI SHALL be considered published as this data is potentially available to all PKI participants and especially its trusting parties when evaluating presented certificates.

All ECB PKI participants that receive private information are responsible to secure it, refrain from using it for any other purpose than its intended usage or disclose it to third parties.

ECB general Information Security Policies and Privacy Statement in their latest version apply.

ECB general Information Security Policies and Privacy Statement in their latest version apply.

ECB general Information Security Policies and Privacy Statement in their latest version apply.

no stipulation

Not applicable

Not applicable

ECB PKI is operated under ECB general DG-IS IT Department operations policies including Service Level Agreements with / to business partners consuming ECB PKI services. In accordance with Article 35.3 of the Statute of the ECB and ESCB, the ECB shall be subject to the liability regime provided for in Article 340 of the Treaty on the Functioning of the European Union.

This CPS shall come into force from the moment it is published in the ECB PKI repository. Amendments to this CPS become effective upon publication in the ECB PKI repository. This CPS shall remain valid until such time as it is expressly terminated by issuance of a new version or upon re-key of the Root CA keys, at which time a new version may be created.

If this CPS is substituted, it SHALL be substituted for a new and updated version, regardless of the importance of the changes carried out therein. If the CPS is terminated, it shall be withdrawn from the ECB PKI repository, though a copy hereof SHALL be held available for 10 years.

The obligations established under this CPS, referring to audits, confidential information, possible ESB PKI obligations and liabilities that came into being whilst it was in force shall continue to prevail following its termination or substitution, in the latter case only with respect to those terms which are not contrary to the new version.

All notifications, demands, applications or any other type of communication required in the practices described in this CPS shall be carried out by electronic message or in writing, by registered post addressed to any of the addresses in section 1.5 Policy Administration. Electronic notifications shall be effective upon receipt by the recipients to which they are addressed.

Amendments or special agreements need to be laid out in written form with compliance to existing ECB PKI and / or applicable general ECB legal policies. The authority empowered to carry out and approve amendments to this CPS and the referenced CP is the Policy Management Authority (PMA). The PMA's contact details can be found in section 1.5 “Policy Administration”.

Should ECB PKI PMA deem that the amendments to this CPS or the referenced CP could affect the acceptability of the certificates for specific purposes, it shall request the ECB PKI and related infrastructure services to notify the users of the certificates corresponding to the amended CP or CPS that an amendment has been carried out and that possibly affected these parties should consult the new CPS in the relevant ECB PKI repository. When, in the opinion of the PMA, the changes do not affect the acceptance of certificates, the changes shall not be disclosed to the users of the certificates.

In case of amendment, when numbering the new version of the CPS or the relevant CP:

• If the PMA deems that the amendments could affect the acceptability of the certificates for specific purposes, the major version number indicated under the respective ECB PKI IANA PEN document OID namespace of the document shall be changed and its lowest number if applicable reset to zero.
• If the PMA deems that the amendments do not affect the acceptability of the certificates for specific purposes, the lowest version number or an added version index of the document based on the existing ECB PKI IANA PEN document OID namespace will be increased maintaining the major version number of the document, as well as the rest of the associated OID.

Resolution of any dispute between users and the ECB PKI that may arise shall be submitted to the ECB Security Board or ECB PKI DG-IS Security Governance Team for resolution. As outlined before ECB PKI in general accepts no liability for ECB PKI certificates or any related PKI service beyond regulations and circumstances laid out in the existing ECB DG-IS IT Service Level Agreements.

The Laws of the European Economic Community apply to the ECB PKI. The ECB processes personal data in accordance with Regulation (EU) 2018/1725 of the European Parliament and of the Council of 23 October 2018 on the protection of natural persons with regard to the processing of personal data by the Union institutions, bodies, offices and agencies and on the free movement of such data, and repealing Regulation (EC) No 45/2001 and Decision No 1247/2002/EC of the European Parliament .

ECB PKI participants are responsible for existing compliance with applicable jurisdiction.

This CPS extended by the relevant associcated CP and the documents referred to herein constitute the entire agreement among the ECB PKI participants and no party shall be liable or bound to any other party in any manner by any warranties, representations or covenants except as specifically set forth herein or therein.