ISO 15782-1:2009

Certificate management for financial services - Part 1: Public key certificates

ISO 15782-1:2009 defines a certificate management system for financial industry use for legal and natural persons that includes credentials and certificate contents, Certification Authority systems, including certificates for digital signatures and for encryption key management, certificate generation, distribution, validation and renewal, authentication structure and certification paths, and revocation and recovery procedures. ISO 15782-1:2009 also recommends some useful operational procedures (e.g. distribution mechanisms, acceptance criteria for submitted credentials). Implementation of ISO 15782-1:2009 will also be based on business risks and legal requirements. ISO 15782-1:2009 does not include the protocol messages used between the participants in the certificate management process, requirements for notary and time stamping, Certificate Policy and Certification Practices requirements, or Attribute Certificates. While ISO 15782-1:2009 provides for the generation of certificates that could include a public key used for encryption key management, it does not address the generation or transport of keys used for encryption.

Gestion de certificats pour les services financiers — Partie 1: Certificats de clé publique

General Information

• Status: Withdrawn
• Publication Date: 12-Oct-2009
• Withdrawal Date: 12-Oct-2009
• ICS: 35.240.40 - IT applications in banking
• Technical Committee: ISO/TC 68/SC 2 - Financial Services, security
• Drafting Committee: ISO/TC 68/SC 2/WG 8 - Public key infrastructure management for financial services
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 09-Apr-2018
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 21188:2018 - Public key infrastructure for financial services - Practices and policy framework
• Effective Date: 05-Nov-2015
• Revises: ISO 15782-1:2003 - Certificate management for financial services - Part 1: Public key certificates
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15782-1
Second edition
2009-10-15
Certificate management for financial
services —
Part 1:
Public key certificates
Gestion de certificats pour les services financiers —
Partie 1: Certificats de clé publique

Reference number
©
ISO 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2009 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.2
3 Terms and definitions .2
4 Symbols and abbreviations.8
5 Public key infrastructure .8
5.1 Overview.8
5.2 Public key management infrastructure process flow.9
5.3 Certification Authority (CA).9
5.4 Registration Authority (RA).10
5.5 End entities .10
6 Certification Authority systems .10
6.1 General .10
6.2 Responsibilities in CA systems .12
6.3 Certificate life cycle requirements.15
6.4 Security quality assurance and audit requirements.29
6.5 Business continuity planning .30
7 Data elements and relationships .30
8 Public key certificate and Certificate Revocation List extensions.30
Annex A (normative) Certification Authority audit journal contents and use .31
Annex B (informative) Alternative trust models.34
Annex C (informative) Suggested requirements for the acceptance of certificate request data .40
Annex D (informative) Multiple algorithm certificate validation example .42
Annex E (informative) Certification Authority techniques for disaster recovery.44
Annex F (informative) Distribution of certificates and Certificate Revocation Lists .47
Bibliography.48

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 15782-1 was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 2,
Security management and general banking operations.
This second edition cancels and replaces the first edition (ISO 15782-1:2003), which has been technically
revised.
ISO 15782 consists of the following parts, under the general title Certificate management for financial
services:
⎯ Part 1: Public key certificates
⎯ Part 2: Certificate extensions

iv © ISO 2009 – All rights reserved

Introduction
This part of ISO 15782 adopts ISO/IEC 9594-8 for the financial services industry and defines certificate
management procedures and data elements.
Detailed requirements for the financial industry for the individual extensions are given in ISO 15782-2.
While the techniques specified in this part of ISO 15782 are designed to maintain the integrity of financial
messages and support the service of non-repudiation, this part of ISO 15782 does not guarantee that a
particular implementation is secure. It is the responsibility of the financial institution to put an overall process in
place with the necessary controls to ensure that the process is securely implemented, with these controls
including the application of appropriate audit tests in order to validate compliance.
The binding association between the identity of the owner of a public key and that key is documented in order
to prove the ownership of the corresponding private key. This binding is called a public key certificate. Public
key certificates are generated by a trusted entity known as a Certification Authority (CA).
The proper implementation of this part of ISO 15782 is intended to provide assurances of the binding of the
identity of an entity to the key used by that entity to sign documents, including wire transfers and contracts.
This part of ISO 15782 defines a certificate management framework for authentication, including the
authentication of keys for encryption. The techniques specified by this part of ISO 15782 can be used when
initiating a business relationship between legal entities (entities).

INTERNATIONAL STANDARD ISO 15782-1:2009(E)

Certificate management for financial services —
Part 1:
Public key certificates
1 Scope
This part of ISO 15782 defines a certificate management system for financial industry use for legal and natural
persons that includes
⎯ credentials and certificate contents,
⎯ Certification Authority systems, including certificates for digital signatures and for encryption key
management,
⎯ certificate generation, distribution, validation and renewal,
⎯ authentication structure and certification paths, and
⎯ revocation and recovery procedures.
This part of ISO 15782 also recommends some useful operational procedures (e.g. distribution mechanisms,
acceptance criteria for submitted credentials).
Implementation of this part of ISO 15782 will also be based on business risks and legal requirements.
This part of ISO 15782 does not include
⎯ the protocol messages used between the participants in the certificate management process,
⎯ requirements for notary and time stamping,
⎯ Certificate Policy and Certification Practices requirements, or
⎯ Attribute Certificates.
While this part of ISO 15782 provides for the generation of certificates that could include a public key used for
encryption key management, it does not address the generation or transport of keys used for encryption.
Implementers wishing to comply with ISO/IEC 9594-8 can utilize the certificate structures defined by that
International Standard. Those wishing to implement compatible certificate and certificate revocation structures
but without the overhead associated with the X.500 series can utilize the ASN.1 structures defined in
ISO 15782-2. ISO 15782-2 can also be referred to for a financial services profile of certificate and CRL
extensions.
ISO 21188 provides additional information for implementers on Certificate Policies, Certification Practice
Statements, and PKI controls. ISO 21188 sets out a framework of requirements to manage a PKI through
Certificate Policies and Certification Practice Statements and to enable the use of public key certificates in the
financial services industry. It also defines control objectives and supporting procedures to manage risks.
NOTE The use of a bold sans serif font, such as CertReqData or CRLEntry, denotes the use of abstract syntax
notation (ASN.1), as defined in ISO/IEC 8824-1 to ISO/IEC 8824-4 and ISO/IEC 8825-1 and ISO/IEC 8825-2. Where it
makes sense to do so, the ASN.1 term is used in place of normal text. Refer to ISO 15782-2 for related ASN.1 modules.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation — Part 1
ISO/IEC 8824-2, Information technology — Abstract Syntax Notation One (ASN.1): Information object
specification — Part 2
ISO/IEC 8824-3, Information technology — Abstract Syntax Notation One (ASN.1): Constraint specification —
Part 3
ISO/IEC 8824-4, Information technology — Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1
specifications — Part 4
ISO/IEC 8825-1, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) — Part 1
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER) — Part 2
ISO/IEC 9594-8, Information Technology — Open Systems Interconnection — The Directory: Public-key and
attribute certificate frameworks — Part 8
ISO/IEC 15408 (all parts), Information technology — Security techniques — Evaluation criteria for IT security
ISO 15782-2:2001, Banking — Certificate Management — Part 2: Certificate extensions
ISO 16609, Banking — Requirements for message authentication using symmetric techniques
ISO 21188:2006, Public key infrastructure for financial services — Practices and policy framework
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
ASN.1 module
identifiable collection of ASN.1 types and values
3.2
attribute
characteristic of an entity
3.3
audit journal
chronological record of system activities which is sufficient to enable the reconstruction, review and
examination of the sequence of environments and activities surrounding or leading to each event in the path
of a transaction from its inception to the output of the final results
3.4
authorization
granting of rights
3.5
CA certificate
certificate whose subject is a CA, and whose associated private key is used to sign certificates
2 © ISO 2009 – All rights reserved

3.6
certificate hold
certificate suspension
temporary interruption of the validity of a certificate by the CA
3.7
certificate information
information in a certificate which is signed
3.8
certificate policy
named set of rules that indicates the applicability of a certificate to a particular community and/or class of
application with common security requirements
EXAMPLE A particular Certificate Policy might indicate the applicability of a type of certificate to the authentication of
electronic data interchange transactions for the trading of goods within a given price range.
NOTE 1 The Certificate Policy should be used by the user of the certificate to decide whether or not to accept the
binding between the subject (of the certificate) and the public key. Some of the components in the Certificate Policy
framework are given concrete values and represented by a registered object identifier in the X.509, Version 3 certificate.
The object owner also registers a textual description of the policy and makes it available to the Relying Parties.
NOTE 2 The Certificate Policy object identifier can be included in the following extensions in the X.509, Version 3
certificates: Certificate Policies, policy mappings, and policy constraints. The object identifier(s) may appear in none, some,
or all of these fields. These object identifiers may be the same (referring to the same Certificate Policy) or may be different
(referring to different Certificate Policies).
3.9
certificate policy framework
comprehensive set of security- and liability-related components that can be used to define a Certificate Policy
NOTE A subset of the components in the Certificate Policy framework are given concrete values to define a
Certificate Policy.
3.10
certificate re-key
process whereby an entity with an existing key pair and certificate receives a new certificate for a new public-
key, following the generation of a new key pair
3.11
certificate renewal
process whereby an entity is issued for a new instance of an existing certificate with a new validity period
3.12
certificate request data
credentials
signed information in a certificate request, including the entity's public key, entity identity and other information
included in the certificate
3.13
certificate revocation list
CRL
list of revoked certificates
3.14
certification
process of creating a public key certificate for an entity
3.15
certification authority
CA
entity trusted by one or more entities to create, assign, and revoke or hold public key certificates
3.16
certification authority system
set of entities, including a CA, that manages certificates throughout the life of the certificate
NOTE The entities are responsible for
⎯ generation,
⎯ submission,
⎯ registration,
⎯ certification,
⎯ distribution,
⎯ use,
⎯ renewal,
⎯ re-key,
⎯ revocation or hold, and
⎯ expiry.
3.17
certification path
ordered sequence of certificates of entities which, together with the public key of the initial entity in the path,
can be processed to obtain the public key of the final entity in the path
3.18
certification practice statement
CPS
statement of the practices which a Certification Authority employs in issuing and managing certificates through
their life cycle
3.19
compromise
violation of the security of a system such that an unauthorized disclosure or modification of sensitive
information may have occurred
3.20
confidentiality
property that information is not made available or disclosed to unauthorized individuals, entities, or processes
3.21
CRL distribution point
directory entry or other distribution source for CRLs
NOTE A CRL distributed through a CRL distribution point may contain revocation entries for only a subset of the full
set of certificates issued by one CA or may contain revocation entries for multiple CAs.
3.22
cross-certification
process by which two CAs mutually certify each other's public keys
cf. policy mapping (3.44)
3.23
(cryptographic) key
parameter that determines the operation of a cryptographic function
NOTE Cryptographic functions include the following:
⎯ the transformation from plain text to cipher text and vice versa;
⎯ synchronized generation of keying material;
⎯ digital signature generation or validation.
4 © ISO 2009 – All rights reserved

3.24
cryptographical hash
mathematical function which maps values from a large (possibly very large) domain into a smaller (fixed)
range
NOTE It satisfies the following properties:
⎯ it is computationally unfeasible to find any input which maps to a pre-specified output (i.e. pre-image resistant);
⎯ it is computationally unfeasible to find any two distinct inputs which map to the same output (i.e. collision-resistant).
3.25
cryptographic module
device wherein cryptographic functions (e.g. encryption, authentication, key generation) are performed
3.26
cryptography
discipline which embodies principles, means and methods for the transformation of data in order to hide its
information content, prevent its undetected modification, prevent its unauthorized use or a combination thereof
3.27
cryptoperiod
time span during which a specific key is authorized for use or in which the keys for a given system may remain
in effect
3.28
data integrity
property whereby data has not been altered or destroyed
3.29
delta-CRL
subset of a CRL indicating changes since the prior CRL update
3.30
(digital) signature
cryptographic transformation of data which, when associated with a data unit, provides the services of origin
authentication and data integrity, and may support signer non-repudiation
3.31
directory
repository
method for distributing or making available certificates or CRLs
EXAMPLE A database or an X.500 Directory.
3.32
distinguished name
globally unique name for an entity
NOTE 1 Methods for determining global uniqueness are outside the scope of this part of ISO 15782.
NOTE 2 An entity may be issued for more than one certificate with the same distinguished name.
3.33
dual control
process of utilizing two or more separate entities (usually persons), who are operating in concert, to protect
sensitive functions or information
NOTE 1 Both entities are equally responsible for the physical protection of materials involved in vulnerable transactions.
No single person is able to access or to utilize the materials (e.g. cryptographic key).
NOTE 2 For manual key and certificate generation, conveyance, loading, storage, and retrieval, dual control requires
split knowledge of key among the entities. Also see split knowledge (3.52).
3.34
end entity
certificate subject, other than a CA, which uses its private key for purposes other than signing certificates
3.35
entity
legal (e.g. a corporation, labour union, state or nation) or natural person
EXAMPLE CA, RA or end entity.
3.36
financial message
communication containing information which has financial implications
3.37
key agreement
method for negotiating a key value without transferring the key, even in an encrypted form
EXAMPLE The Diffie-Hellman technique.
3.38
key fragment
part of a private key which has been divided into pieces (also called shares) that are distributed amongst
entities such that the pooled fragments of specific subsets of entities can reconstitute the key
3.39
key management
handling of keying material throughout its life cycle in accordance with a security policy
3.40
key pair
〈public key cryptography〉 public key and its corresponding private key
3.41
keying material
data, such as keys, certificates and initialization vectors, necessary to perform cryptographic operations
3.42
non-repudiation
service which provides proof of the integrity and origin of data which can be verified by a third party
NOTE The non-repudiation service protects against the signing entity falsely denying the action and can provide
rebuttable presumption. It requires that appropriate processes and procedures (registration, audit journals, contractual
arrangements, personnel, etc.) be in place.
3.43
out-of-band notification
notification using a communication means independent of the primary communications means
3.44
policy mapping
recognition that, when a CA in one domain certifies a CA in another domain, a particular Certificate Policy in
the second domain may be considered by the authority of the first domain to be equivalent (but not
necessarily identical in all respects) to a particular Certificate Policy in the first domain
cf. cross-certification (3.22)
3.45
policy qualifier
policy-dependent information that accompanies a Certificate Policy identifier in an X.509 certificate
3.46
private key
〈asymmetric (public) key cryptosystem〉 key of an entity's key pair which is known only by that entity
6 © ISO 2009 – All rights reserved

3.47
public key
〈asymmetric (public) key cryptosystem〉 key of an entity's key pair which is publicly known
3.48
public key certificate
public key and identity of an entity together with some other information, rendered unforgeable by signing the
certificate information with the private key of the certifying authority that issued that public key certificate
3.49
public key validation
PKV
process that does arithmetic tests on a candidate public key to provide assurance that it conforms to the
specifications of the standard
NOTE 1 Attacks may be possible on the owner and/or user if a non-conforming public key is used.
NOTE 2 Public key validation can include arithmetic property tests (range, order, primality, etc.), canonical generation
tests and consistency tests between components of a public key. Methods for public key validation are typically found in
financial industry signature standards.
3.50
registration authority
RA
entity that is responsible for identification and authentication of subjects of certificates, but is not a CA and
hence does not sign or issue certificates
NOTE An RA may assist in the certificate application process, revocation process or both.
3.51
relying party
user
recipient of a certificate who acts in reliance on that certificate
3.52
split knowledge
condition under which two or more entities separately have key fragments which, individually, convey no
knowledge of the resultant cryptographic key
3.53
subject
entity whose public key is certified in a public key certificate
3.54
subject CA
CA that is certified by the issuing CA
3.55
subscriber
entity subscribing with a Certification Authority on behalf of one or more subjects
3.56
trusted CA public key
public key used to validate the first certificate in a chain of certificates as a part of certification path processing
EXAMPLE The root key in a centralized trust model or a local CA key in a decentralized trust model (see Annex B).
NOTE If an end entity validates a chain of certificates from a trusted CA public key to the end certificate, then the end
certificate is considered valid.
3.57
zeroize
active destruction of electronically stored data, such as by degaussing, erasing or overwriting
4 Symbols and abbreviations
Symbols Meaning
X{information} Signing of “information” by X
X X's public key. (e.g. X is X 's public key)
p 1p 1
X X's private key
s
X «X» X 's certificate issued by the CA, X
1 2 2 1
X «X »X «X »X «X » Certificate path. Each item Xi in the path is the certificate for the CA which
1 2 2 3 n-1 n
produced the next item. This path is of arbitrary length and is functionally equivalent
to X «X ». Possession of X allows a user to extract the authenticated public key of
1 n 1p
X .
n
⋅
X X «X » Unwrapping of a certificate or path. The public key of the leftmost CA (X ) is used to
1p 1 2 1
extract the authenticated public key of the rightmost certificate (X «X ») by working
1 2
through the path of intervening certificates. This example extracts X .
2p
NOTE The notation used in this part of ISO 15782 is a variant of the X.509 notation for certificates, certification paths
and related information.
Abbreviations Meaning
ASN.1 Abstract syntax notation
BER Basic encoding rules
CA Certification Authority
CPS Certification Practice Statement
CRL Certificate Revocation List
DER Distinguished encoding rules
DSA Digital signature algorithm
ECDSA Elliptic curve digital signature algorithm
PKI Public key infrastructure
RA Registration Authority
RSA Rivest Shamir Adleman algorithm
SHA-1 Secure hash algorithm-1
URI Uniform resource identifier
5 Public key infrastructure
5.1 Overview
Public key infrastructure (PKI) is a term used to describe the technical, legal and commercial infrastructure
that enables the wide deployment of public key technology.
Public key technology is used for creating digital signatures and for managing symmetric keys. With public key
cryptography, two keys are used: one is kept private with the user, the other is made publicly available. That
which is signed or processed with one key (public or private) may be validated with its complement (public or
private). Revealing the public key does not in any way compromise the private key.
The authentication of public keys is an essential requirement and, for this reason, public keys are housed in
public key certificates. A certificate contains the public key and its identifying data and is digitally signed by a
8 © ISO 2009 – All rights reserved

Certification Authority (CA). This part of ISO 15782 is based on the ISO/IEC 9594-8 format for public key
certificates.
As described in ISO 21188, the term “Certification Authority” reflects the aggregate of the following PKI roles
including
⎯ Certificate Issuer,
⎯ Certificate Manufacturer,
⎯ Registration Authority,
⎯ Repository,
⎯ Certificate Validation Service Provider, and
⎯ Subject Cryptographic Mechanism Provider.
In this part of ISO 15782, we focus on the CA as a whole and on the RA function.
5.2 Public key management infrastructure process flow
The responsibilities, services and procedures required by a public key management infrastructure are as
follows:
⎯ key generation;
⎯ registration;
⎯ certification;
⎯ distribution;
⎯ usage;
⎯ revocation hold;
⎯ expiry;
⎯ renewal;
⎯ re-key.
The main steps involved in certification are shown in Figure 1.
5.3 Certification Authority (CA)
A CA has a public/private key pair and uses a digital signature algorithm to produce certificates.
The binding of the entity's public key to its identity is accomplished by having the CA generate the certificate,
thereby attesting to the relationship of the information therein and providing assurances of its integrity.
The binding of an entity's public key and identity is validated by using the public key of one or more CAs as
described in 6.3.1. The certificate(s) and proof of validation shall be maintained by the validator in an audit
journal. A CA may issue certificates to any entities, including CAs.
Entities (including CAs) can use these certificates to authenticate themselves to Relying Parties. Hence,
authentication may involve a chain of certificates. The verification of a chain of certificates begins with the
trusted CA public key and ends with the certificate being validated. The trusted CA public key shall be
obtained and authenticated by some means other than by the use of certificates. This is to ensure that the
process begins securely. See 6.3.1, Annex C and ISO/IEC 9594-8.
Once a certificate has been generated, the integrity of its contents is protected. This part of ISO 15782 does
not require that certificates be given confidentiality protection. A valid copy of the CA's public key is required
by the Relying Party in order to validate a certificate. Given that the CA is a trusted entity, this permits the
validation of the binding between an entity's public key, its identity, and other information needed.
Two general architectures may be configured for certification paths: hierarchical and non-hierarchical. In a
hierarchical architecture, authorities are arranged under a “root” CA that issues certificates to subordinate CAs.
These subordinate CAs may issue certificates to CAs subordinate to them or to end entities. In a hierarchical
architecture the public key of the root CA functions as the trusted CA public key and is known to every entity.
Any entity's certificate may be validated by validating the certification path of signature certificates that leads
from the certificate being validated back to the trusted CA public key of the root CA. In this architecture, the
root CA is a mutual point of trust for all entities.
To communicate outside the root CA's domain, the root CA shall cross-certify with the desired remote domain.
Certification path validation then involves building a chain of certificates from the remote entity to the root CA
by way of the cross-certified remote CA.
In a non-hierarchical architecture, independent CAs may cross-certify each other by issuing public key
certificates to each other. This results in a general network of trust relationships between CAs and allows each
group (such as a retail credit authorization network, a clearing house, a financial institution or a subgroup
thereof) to have its own CA. An entity uses the public key of a selected CA for its trusted CA public key. The
certification path consists of those certificates that chain back from the certificate being validated to the trusted
CA of the Relying Party.
In a bridge architecture, which is a common non-hierarchical architecture, a central CA cross-certifies to the
other CAs. The public key of the central bridge CA is known to all other trusted CAs and the public key of each
trusted CA is known to the bridge CA. The certification path consists of two certificate chains, Subject to
Subject's trusted CA and Relying Party to Relying Party's trusted CA, interconnected by the bridge CA-
certificates.
A compromise of the private key of a CA compromises all users of certificates of the CA, because the holder
of that private key can generate fraudulent certificates and then masquerade as one or more end entities.
Failure to provide compensating controls to deal with the possibility of compromise of transactions in a
financial network can have catastrophic effects on financial institutions and their customers.
Figure 1 summarizes the life cycle of an end-entity certificate.
5.4 Registration Authority (RA)
An RA is an entity that is responsible for identification and authentication of the subjects of certificates, but is
not a CA, and hence does not sign or issue certificates. An RA may assist in the certificate application process,
revocation process, or both. The RA does not need to be a separate body, but can be part of the CA.
5.5 End entities
An end entity is a certificate subject which uses its private key for purposes other than signing certificates.
6 Certification Authority systems
6.1 General
A CA and one or more RAs may be configured as a CA system, and the functional allocation between CAs
and RAs will vary, based on implementation.
10 © ISO 2009 – All rights reserved

RAs may be appointed to look after the secure registration of entities or this function may be part of the
services provided by the CA. Each RA is responsible for a specific RA domain.
When an RA is used, communications between the RA and the CA shall be authenticated. A digital signature
may be used for this process.
NOTE The numbers correspond to the process steps detailed in Figures 2 and 3.
Figure 1 — Typical public key management infrastructure process flow
6.2 Responsibilities in CA systems
6.2.1 Sole responsibilities and best practices of a CA
6.2.1.1 Sole responsibilities of a CA
The CA shall be solely responsible for
a) securing the private key associated with the public key contained in the CA's certificate,
b) ensuring that public keys certified by the CA are unique within the CA's domain,
c) ensuring that there is no duplication of the requester's distinguished name with that of any other entity
certified by the CA,
d) generating certificates by applying a signature to the certificate information,
e) maintaining a revocation-checking mechanism appropriate for Relying Parties,
f) creating, maintaining and distributing Certificate Revocation Lists (see Annex F),
g) generating key pairs in accordance with a detailed CA key generation ceremony script and CPS
requirements (see ISO 21188:2006, 7.3.1 “CA key generation” for more details),
h) producing the CPS and making it available to all appropriate parties,
i) ensuring it owns and controls its private keys, and
j) changing the CA's public/private key pair at intervals appropriate to the business risk.
A CA system shall ensure that the responsibilities of the CA and RA are assigned.
The operation of a CA shall be in accordance with prudent business practices, the CA's Certification Practice
Statement (CPS), and applicable Certificate Policies (CP).The CA shall be responsible for certification and
shall be able to print the information contained in certificates in human-readable form.
Certification path constraints are defined in ISO 15782-2. Examples of their use are given in Annex A of
ISO 15782-2:2001.
Distribution requirements for a CA's public key are defined in 6.3.5.
6.2.1.2 Best practices of a CA system
It is recommended that the CA system possess the following attributes.
a) It should have sufficient resources to maintain its operations in conformity with its duties.
b) It should be reasonably able to bear its risk of liability to end entities and persons relying on certificates
issued by the CA, as dictated by its policy.
c) It should employ personnel practices which provide reasonable assurance of trustworthiness.
d) It should use standardized (ISO or national) cryptographic techniques and cryptographic modules
designed to meet the requirements for financial institution use based on one of the four progressive
assurance levels of module security defined as follows.
12 © ISO 2009 – All rights reserved

1) Level 1 cryptographic module
Security Level 1 provides the lowest level of security. It specifies basic security requirements for a
cryptographic module, but it differs from the higher levels in several respects. No physical security
mechanisms are required in the module beyond the requirement for production-grade equipment.
Level 1 allows software cryptographic functions to be performed in a general purpose personal
computer (PC). Such implementations are often appropriate in low-level security applications. The
implementation of PC cryptographic software may be more cost-effective than hardware-based
mechanisms. This will enable organizations to avoid the situation that exists today whereby the
decision is often made not to cryptographically protect data because hardware is considered too
expensive.
2) Level 2 cryptographic module (tamper evident)
Level 2 provides physical security by including requirements for tampe-evident coatings or seals, or
for pick-resistant locks. Tampe-evident coatings or seals would be placed on a cryptographic module
so that the coating or seal would have to be broken in order to attain physical access to the plain-text
cryptographic keys and other critical security parameters within the module. Pick-resistant locks
would be placed on covers or doors to protect against unauthorized physical access. These
requirements provide a low cost means for physical security and avoid the cost of the higher level of
protection involving hard opaque coatings or significantly more expensive tamper detection and
zeroization circuitry.
3) Level 3 cryptographic module (tamper protected)
Level 3 attempts to prevent the intruder from gaining access to critical security parameters held
within the module. For example, a multiple-chip embedded module shall be contained in a strong
enclosure, and if a cover is removed or a door is opened, the critical security parameters are
zeroized. As another example, a module shall be enclosed in a hard, opaque potting material to deter
access to the contents.
4) Level 4 cryptographic module (tamper enveloped)
Level 4 physical security provides an envelope of protection around the cryptographic module.
Whereas the tamper-detection circuits of lower level modules may be bypassed, the intent of Level 4
protection is to detect a penetration of the device from any direction. For example, if one attempts to
cut through the enclosure of the cryptographic module, the attempt should be detected and all critical
security parameters should be zeroized. Level 4 devices are particularly useful for operation in a
physically unprotected environment where an intruder could possibly tamper with the device.
NOTE These levels are not to be confused with ISO/IEC 15408's common criteria evaluation assurance levels
(EALS) or security functional levels (FCNs), or with levels of trust that may be defined in a CA's Certificate Policy/CPS.
e) It should make its own certificates, public key and Certificate Revocation Lists (CRL) readily and reliably
available to Relying Parties.
f) It should utilize trustworthy systems in performing its services.
g) It should define and document internal operation policies for the CA system domain.
h) It should ensure that it complies with all appropriate regulations.
6.2.2 Responsibilities to be allocated to either a CA or an RA
The following requirements are applicable to the CA or RA.
a) It shall validate the identity of the entity requesting the certificate as being that of the subject of the
certificate.
b) It shall validate the identity of the entity requesting a certificate if the requesting entity will not be the
subject of the certificate.
c) It shall, if appropriate, advise the party identified in the certificate that a certificate has been issued.
d) A validated means shall be used to convey this advice, and that means shall be independent of any
method used to convey the certificate to the entity. Examples of validated means include normal mail for
low-risk (retail) systems and registered mail for private banking systems. The implementation of this
functionality is determined by business risk.
e) It shall keep records supporting the certificate issuance process for the length of time determined by
records-retention requirements.
f) It shall register authenticated entities securely.
g) It shall provide guidance to its end entities on the secure management of the end entity's private key.
h) It shall inform the end entity that the integrity of the end entity's operation will be considered compromised
if the private key of the end entity is ever revealed to, or used by, any unauthorized entity.
i) It shall use any appropriate means to ascertain that the end entity understands the responsibilities of
6.2.3. and is able to comply with them.
j) It shall inform Relying Parties in the domain when the CA private key has been compromised.
k) It shall manage certificate renewal, re-key, revocation, suspension and re-instatement requests from
entities.
Annex C contains suggested requirements for the acceptance of certificate request data. See 6.4 for security
quality assurance and audit requirements.
6.2.3 Responsibilities of an end entity
The following requirements are applicable to the end entity.
a) It shall ensure that the end entity's private key is
⎯ kept within the secure confines of a cryptographic module, and
⎯ used only by the authorized person with proper access controls (e.g. user password or PIN), in
accordance with the relevant CPS.
b) It shall understand the requirements for business continuity as specified in the CPS.
c) It shall ensure that the private key, when stored in a backup environment, is kept within the secure
confines of the cryptographic module, where the cryptographic modules are kept in secure storage.
Security requirements for the backup of private keys should be based on 6.3.1.2, except that Level 2
cryptographic modules may be used. In low-risk applications, a Level 1 cryptographic module may be
used. The private key shall be exported in a secure manner.
NOTE Both Levels 1 and 2 of key management allow a single individual access to an un-split encryption key.
This practice might be acceptable in certain perceived “low-risk” situations (such as home banking), but might not be
acceptable within commercial financial institutions, which have traditionally required dual control of keying material.
14 © ISO 2009 – All rights reserved

d) It shall undertake that the private key is kept under its exclusive control, with due care being exercised to
prevent unauthorized use throughout the life of the key.
e) It shall undertake that the CA System is notified as soon as possible if the end entity knows or suspects
that its private key has been lost, disclosed, revealed or otherwise compromised.
f) It shall ensure that, following the compromise or withdrawal of an end entity's private key, the use of that
private key is immediately and permanently discontinued.
g) It shall ensure that any end-entity private key, that has been previo
...