ISO 21188:2006

Public key infrastructure for financial services - Practices and policy framework

ISO 21188:2006 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. ISO 21188:2006 draws a distinction between PKI systems used in open, closed and contractual environments. It further defines the operational practices relative to financial services industry accepted information systems control objectives. ISO 21188:2006 is intended to help implementers to define PKI practices that can support multiple certificate policies that include the use of digital signature, remote authentication and data encryption. ISO 21188:2006 facilitates the implementation of operational, baseline PKI control practices that satisfy the requirements for the financial services industry in a contractual environment. While the focus of ISO 21188:2006 is on the contractual environment, application of this document to other environments is not specifically precluded. For the purposes of this document, the term "certificate" refers to public key certificates. Attribute certificates are outside the scope of ISO 21188:2006.

Infrastructure de clé publique pour services financiers — Pratique et cadre politique

General Information

• Status: Withdrawn
• Publication Date: 20-Apr-2006
• Withdrawal Date: 20-Apr-2006
• 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 - Financial Services, security
• 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: 24-Nov-2012

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21188
First edition
2006-05-01
Public key infrastructure for financial
services — Practices and policy
framework
Infrastructure de clé publique pour services financiers — Pratique
et cadre politique
Reference number
©
ISO 2006
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 2006
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 2006 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 2
4 Abbreviated terms . 8
5 Public key infrastructure (PKI) . 9
5.1 General. 9
5.2 What is PKI? . 9
5.3 Business requirement impact on PKI environment . 10
5.4 Functional perspectives. 14
5.5 Business perspectives. 19
5.6 Certificate policy (CP). 21
5.7 Certification practice statement (CPS) . 23
5.8 Relationship between certificate policy and certification practice statement . 24
5.9 Agreements . 25
5.10 Time-stamping . 26
6 Certificate policy and certification practice statement requirements. 27
6.1 Certificate policy (CP). 27
6.2 Certification practice statement (CPS) . 29
7 Certification authority control objectives. 29
7.1 General. 29
7.2 CA environmental control objectives . 30
7.3 CA key life cycle management control objectives . 32
7.4 Subject key life cycle management control objectives . 33
7.5 Certificate life cycle management control objectives. 34
7.6 CA certificate life cycle management controls. 36
8 Certification authority control procedures. 36
8.1 General. 36
8.2 CA environmental controls. 36
8.3 CA key life cycle management controls.51
8.4 Subject key life cycle management controls . 55
8.5 Certificate life cycle management controls . 60
8.6 CA certificate life cycle management controls. 67
Annex A (informative) Management by certificate policy . 69
Annex B (informative) Elements of a certification practice statement . 78
Annex C (informative) Object identifiers (OID). 94
Annex D (informative) CA key generation ceremony . 96
Annex E (informative) Mapping of RFC 2527 to RFC 3647. 100
Bibliography . 106

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 21188 was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 2,
Security management and general banking operations.
iv © ISO 2006 – All rights reserved

Introduction
Institutions and intermediaries are building infrastructures to provide new electronic financial transaction
capabilities for consumers, corporations and government entities. As the volume of electronic financial
transactions continues to grow, advanced security technology using digital signatures and authority systems
can become part of the financial transaction process. Financial transaction systems incorporating advanced
security technology have requirements to ensure the privacy, authenticity and integrity of financial transactions
conducted over communications networks.
The financial services industry relies on several time-honoured methods of electronically identifying,
authorizing and authenticating entities and protecting financial transactions. These methods include, but are
not limited to, Personal Identification Numbers (PINs) and Message Authentication Codes (MACs) for retail
and wholesale financial transactions, user IDs and passwords for network and computer access, and key
management for network connectivity. Over the last twenty years the financial services industry has
developed risk management processes and policies to support the use of these technologies in financial
applications.
The expanded use of Internet technologies by the financial services industry and the needs of the industry in
general to provide safe, private and reliable financial transaction and computing systems have given rise to
advanced security technology incorporating public key cryptography. Public key cryptography requires a
business-optimized infrastructure of technology, management and policy (a public key infrastructure or PKI, as
defined in this document) to satisfy requirements of electronic identification, authentication, message integrity
protection and authorization in financial application systems. The use of standard practices for electronic
identification, authentication and authorization in a PKI ensures more consistent and predictable security in
these systems and confidence in electronic communications. Confidence (e.g. trust) can be achieved when
compliance to standard practices can be ascertained.
Applications serving the financial services industry can be developed with digital signature and PKI
capabilities. The safety and the soundness of these applications are based, in part, on implementations and
practices designed to ensure the overall integrity of the infrastructure. Users of authority-based systems that
electronically bind the identity of individuals and other entities to cryptographic materials (e.g. cryptographic
keys) benefit from standard risk management systems and the base of auditable practices defined in this
International Standard.
Members of the International Organization of Standardization Technical Committee 68 have made a
commitment to public key technology by developing technical standards and guidelines for digital signatures,
key management, certificate management and data encryption. ISO 15782 parts 1 and 2 define a certificate
management system for financial industry use, but does not include certificate policy and certification
practices requirements. This International Standard complements ISO 15782 parts 1 and 2 by providing a
framework for managing a PKI through certificate policies, certification practice statements, control objectives
and supporting procedures. For implementers of these International Standards, the degree to which any entity
in a financial transaction can rely on the implementation of public key infrastructure standards and the extent
of interoperability between PKI-based systems using these International Standards will depend partly on
factors relative to policy and practices defined in this document.
INTERNATIONAL STANDARD ISO 21188:2006(E)

Public key infrastructure for financial services — Practices and
policy framework
1 Scope
This International Standard 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.
This International Standard draws a distinction between PKI systems used in open, closed and contractual
environments. It further defines the operational practices relative to financial services industry accepted
information systems control objectives. This International Standard is intended to help implementers to define
PKI practices that can support multiple certificate policies that include the use of digital signature, remote
authentication and data encryption.
This International Standard facilitates the implementation of operational, baseline PKI control practices that
satisfy the requirements for the financial services industry in a contractual environment. While the focus of this
International Standard is on the contractual environment, application of this document to other environments is
not specifically precluded. For the purposes of this document, the term “certificate” refers to public key
certificates. Attribute certificates are outside the scope of this International Standard.
This International Standard is targeted for several audiences having dissimilar needs and therefore the use of
this document will have a different focus for each.
Business Managers and Analysts are those who require information regarding using PKI technology in their
evolving businesses (e.g., electronic commerce) and should focus on Clauses 1 to 6.
Technical Designers and Implementers are those who are writing their certificate policy(ies) and
certification practice statement(s) and should focus on Clauses 6 to 8 and Annexes A to F.
Operational Management and Auditors are those who are responsible for day-to-day operations of the PKI
and validating compliance to this document and should focus on Clauses 6 to 8.
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 7810, Identification cards — Physical characteristics
ISO/IEC 7811, Identification cards — Recording technique (parts 1 to 5)
ISO/IEC 7813, Identification cards — Financial transaction cards
ISO/IEC 7816, Identification cards — Integrated circuit cards (parts 1 to 12 and 15)
ISO/IEC 9594-8:1995, Information Technology — Open Systems Interconnection — The Directory:
Authentication Framework
ISO/IEC 9834-1:1993, Information technology — Open Systems Interconnection — Procedures for the
operation of OSI Registration Authorities: General procedures — Part 1
ISO 10202, Financial transaction cards — Security architecture of financial transaction systems using
integrated circuit cards (eight parts)
ISO/IEC 10646-1, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1:
Architecture and Basic Multilingual Plane
ISO/IEC 15408, Information technology — Security techniques — Evaluation criteria for IT security (three
parts)
ISO 15782-1:2003, Certificate management for financial services — Part 1: Public key certificates
ISO 15782-2, Banking — Certificate Management — Part 2: Certificate Extensions
ISO/IEC 17799, Information technology — Security techniques — Code of practice for information security
management
ISO 18014-2, Information technology — Security techniques — Time-stamping services — Part 2:
Mechanisms producing independent tokens
ISO 18014-3, Information technology — Security techniques — Time-stamping services — Part 3:
Mechanisms producing linked tokens
ISO/IEC 18032, Information technology — Security techniques — Prime number generation
ISO 18033, Information technology — Security techniques — Encryption algorithms (parts 1 to 4)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
activation data
data values, other than keys, which are required to operate cryptographic modules and which need to be
protected (e.g. a PIN, a pass phrase, a biometric, or a manually held key share)
3.2
authentication
verification of an individual's claimed identity:
a) at registration, the act of evaluating end entities' (i.e., subscribers') credentials as evidence for their
claimed identity;
b) during use, the act of comparing electronically submitted identity and credentials (i.e., user ID and
password) with stored values to prove identity
3.3
authentication data
information used to verify the claimed identity of an entity, such as an individual, defined role, corporation or
institution
3.4
card bureau
agent of the CA (3.18) or RA (3.46) that personalizes an ICC (3.32) containing the subscriber’s private key (as
a minimum)
2 © ISO 2006 – All rights reserved

3.5
cardholder
subject to whom the integrated circuit card containing private and public key pairs and certificates (3.6) has
been issued
3.6
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.7
certificate hold
certificate suspension
suspension of the validity of a certificate (3.6)
3.8
certificate issuer
organization whose name appears in the issuer field of a certificate (3.6)
3.9
certificate manufacturer
agent who performs the tasks of applying a digital signature to a certificate signing request on behalf of the
certificate (3.6) issuer
3.10
certificate policy
CP
named set of rules that indicates the applicability of a certificate to a particular community and/or class of
application with common security requirements
3.11
certificate profile
specification of the required format (including requirements for the usage of standard fields and extensions)
for a particular type of certificate (3.6)
3.12
certificate re-key
process whereby an entity with an existing key pair and certificate (3.6) receives a new certificate for a new
public key, following the generation of a new key pair
3.13
certificate renewal
rollover
process whereby an entity is issued a new instance of an existing certificate with a new validity period
3.14
certificate revocation list
CRL
list of revoked certificates (3.6)
3.15
certificate validation service
service provided by the CA (3.18) or its agent which performs the task of confirming the validity of a
certificate (3.6) to a relying party (3.49)
3.16
certificate validation service provider
CVSP
entity (3.29) that provides certificate validation services to its relying party customers
3.17
certification
process of creating a public key certificate for an entity (3.29)
3.18
certification authority
CA
entity trusted by one or more entities to create, assign and revoke or hold public key certificates
3.19
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.20
certification practice statement
CPS
statement of the practices which a certification authority (3.18) employs in issuing certificates and which
defines the equipment, policies and procedures the CA uses to satisfy the requirements specified in the
certificate policies that are supported by it
3.21
certification request
submission of a validated registration request by an RA (3.46), its agent or a subject to a CA (3.18) to register
a subject's public key to be placed in a certificate (3.6)
3.22
certification response
message sent, following certification, from a CA (3.18) in response to a certificate request
3.23
certificate validity
validity
applicability (fitness for intended use) and status (live, suspended, revoked or expired) of a certificate (3.6)
3.24
compromise
violation of the security of a system such that an unauthorized disclosure of sensitive information may have
occurred
3.25
cross certification
process by which two CAs (3.18) mutually certify each other’s public keys
NOTE This process may or may not be automated.
3.26
cryptographic hardware
cryptographic device
hardware security module
hardware cryptographic module
3.27
digital signature
cryptographic transformation that, when associated with a data unit, provides the services of origin
authentication, data integrity and signer non-repudiation
3.28
end entity
certificate subject that uses its private key for purposes other than signing certificates
4 © ISO 2006 – All rights reserved

3.29
entity
CA (3.18), RA (3.46) or end entity (3.28)
3.30
event journal
audit journal
audit log
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.31
functional testing
portion of security testing in which the advertised features of a system are tested for correct operation
3.32
integrated circuit card
ICC
card into which has been inserted one or more electronic components in the form of microcircuits to perform
processing and memory functions
3.33
issuing certification authority
issuing CA
in the context of a particular certificate, the issuing CA (3.18) is the CA that issued the certificate
3.34
key escrow
management function that allows access by an authorized party to a replicated private encipherment key
NOTE This may be a legal requirement to allow law enforcement officials to gain access to an entity and/or CA’s
private confidentiality key.
3.35
key recovery
ability to restore an entity’s private key or a symmetric encipherment key from secure storage in the event that
such keys are lost, corrupted or otherwise become unavailable
3.36
multiple control
condition under which two (dual) or more parties separately and confidentially have custody of components of
a single key that, individually, convey no knowledge of the resultant cryptographic key
3.37
object identifier
OID
unique series of integers that unambiguously identifies an information object
3.38
online certificate status mechanism
mechanism that allows relying parties (3.49) to request and obtain certificate status information without
requiring the use of CRLs (3.14)
3.39
online certificate status protocol
OCSP
protocol for determining the current status of a certificate in lieu of or as a supplement to checking against a
periodic CRL (3.14) and which specifies the data that need to be exchanged between an application checking
the status of a certificate and the server providing that status
3.40
operating period
period of a certificate beginning on the date and time it is issued by a CA (3.18) (or on a later date and time, if
stated in the certificate), and ending on the date and time it expires or is revoked
3.41
PKI disclosure statement
document that supplements a CP (3.10) or CPS (3.20) by disclosing critical information about the policies and
practices of a CA (3.18)/PKI (3.45)
NOTE A PKI disclosure statement is a vehicle for disclosing and emphasizing information normally covered in detail
by associated CP and/or CPS documents. Consequently, a PDS is not intended to replace a CP or CPS.
3.42
policy authority
PA
party or body with final authority and responsibility for specifying certificate policies (3.10) and ensuring CA
(3.18) practices and controls as defined by the CPS (3.20) fully support the specified certificate policies
3.43
policy mapping
recognition that, when a CA (3.18) in one domain certifies a CA in another domain, a particular certificate
policy (3.10) 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
NOTE See 3.25, cross certification.
3.44
policy qualifier
policy-dependent information that accompanies a certificate policy (3.10) identifier in an X.509 certificate
3.45
public key infrastructure
PKI
structure of hardware, software, people, processes and policies that employs digital signature technology to
facilitate a verifiable association between the public component of an asymmetric public key pair with a
specific subscriber that possesses the corresponding private key
NOTE The public key may be provided for digital signature verification, authentication of the subject in
communication dialogues, and/or for message encryption key exchange or negotiation.
3.46
registration authority
RA
entity that is responsible for identification and authentication of subjects of certificates, but is not a CA (3.18),
and hence does not sign or issue certificates
NOTE An RA may assist in the certificate application process or revocation process or both. The RA does not need
to be a separate body, but can be part of the CA.
3.47
registration request
submission by an entity to an RA (3.46) [or CA (3.18)] to register the entity’s public key in a certificate
3.48
registration response
message sent by an RA (3.46) [or CA (3.18)] to an entity in response to a registration request
6 © ISO 2006 – All rights reserved

3.49
relying party
RP
recipient of a certificate who acts in reliance on that certificate, digital signatures verified using that certificate,
or both
3.50
repository
system for storage and distribution of certificates and related information (i.e., certificate storage, certificate
distribution, certificate policy (3.10) storage and retrieval, certificate status, etc.)
3.51
root CA
CA (3.18) at the apex of the CA hierarchy
3.52
signature verification
〈in relation to a digital signature〉 accurate determination:
a) that the digital signature was created during the operational period of a valid certificate by the private key
corresponding to the public key listed in the certificate (3.6);
b) that the message has not been altered since its digital signature was created.
3.53
subject
entity whose public key is certified in a public key certificate
3.54
subject CA
CA (3.18) that is certified by the issuing CA and hence complies with the certificate policy (3.10) of the
issuing CA
3.55
subject end entity
end entity that is the subject of a certificate (3.6)
3.56
subordinate CA
sub-CA
CA (3.18) that is lower relative to another CA in the CA hierarchy
3.57
subscriber
entity subscribing with a certification authority (3.18) on behalf of one or more subjects
3.58
superior CA
CA (3.18) that is higher relative to another [subordinate CA (3.56)] in the CA hierarchy, but is not a root CA
3.59
tamper evident
possessing a characteristic that provides evidence that an attack has been attempted
3.60
tamper resistant
possessing a characteristic that provides passive physical protection against an attack
3.61
trusted role
job function that performs critical functions which, if performed unsatisfactorily, may have an adverse impact
upon the degree of trust provided by the CA (3.18)
3.62
trust services provider
TSP
approved organization (as determined by the contractual participants) providing trust services, through a
number of certification authorities (3.18), to their customers who may act as subscribers or relying parties
(3.49)
NOTE A trust services provider may also provide certificate validation services.
3.63
validation service request
enquiry by the relying party (3.49) to a validation service to check the validity of a certificate (3.6)
4 Abbreviated terms
Abbreviation Meaning
ASN.1 Abstract Syntax Notation One
CA Certification Authority
CM Certificate Manufacturer
CP Certificate Policy
CPS Certification Practice Statement
CRL Certificate Revocation List
CVSP Certificate Validation Service Provider
EMV Eurocard MasterCard Visa
FI Financial Institution
FIPS Federal Information Processing Standard
FTP File Transfer Protocol
HSM Hardware Security Module
HTTP Hypertext Transfer Protocol
ICC Integrated Circuit Card
ID Identifier
IEC International Electrotechnical Commission
IETF Internet Engineering Task Force
ISO International Organization for Standardization

8 © ISO 2006 – All rights reserved

Abbreviation Meaning
ITU International Telecommunications Union
LDAP Lightweight Directory Access Protocol
MAC Message Authentication Code
OCSP Online Certificate Status Protocol
OID Object Identifier
PA Policy Authority
PIN Personal Identification Number
PKI Public Key Infrastructure
PKIX Public Key Infrastructure (X.509) (IETF Working Group)
POS Point Of Sale
RA Registration Authority
RFC Request For Comment
RP Relying Party
SSL Secure Sockets Layer
TLS Transport Layer Security
TSA Time stamping Authority
TSP Trust Services Provider
TTP Trusted Third Party
URL Uniform Resource Locator
5 Public key infrastructure (PKI)
5.1 General
Before addressing the details of PKI policy and practices requirements, this International Standard provides
some background information in order for the reader to better understand the context in which these policies
and practices are used within a PKI.
5.2 What is PKI?
This subclause describes the components of a PKI and illustrates the roles with responsibilities undertaken by
the various entities within the PKI. The rapid growth of electronic commerce has brought with it the desire to
conduct business-to-business, business-to-consumer, and government-to-consumer transactions across open
networks such as the Internet. The design of the network transmission protocols creates problems for financial
institutions and their customers conducting business transactions, who require the electronic identification and
authentication of the transacting parties, proof of origin, message integrity protection and confidentiality
services. Electronic authentication also raises significant issues with respect to evidence and contract, liability,
privacy, consumer protection and trade.
PKIs are a practical technical solution to the problems posed by open networks. Financial institutions are
becoming trust services providers (TSPs), to take advantage of the growing market for security and
authentication in online communications. Relying parties, as recipients of information, use TSPs to validate
certificates used to authenticate on-line communications. A TSP is a recognized authority trusted by one or
more relying parties to create and sign certificates. A TSP may also revoke certificates it has created and
issued. A TSP operates one or more certification authorities (CAs) whose core functions are certificate issuing,
manufacturing and certificate validation. Within a financial institution, a CA is not necessarily a business entity
but may be a unit or a function providing CA functions that may be trusted by relying parties and subscribing
parties.
Public key technology is used to support confidentiality, integrity and authentication requirements. With public
key cryptography, two keys are created (private and public). The private key is kept secret and the public key
can be made publicly available in a certified form which protects its authenticity. The subject’s public key and
identifying data are signed by the CA’s private key to create a certificate. Certificates are created under
certificate policies. Revealing the public key does not compromise the private key.
Financial institutions may use a PKI to service their business needs in the following environments depending
upon their relationship with the relying party. Examples of each are provided in Tables 1 to 3.
1)
a) Closed environment: all entities (certificate subjects and relying parties) adhere to a single financial
institution’s trust service, and must share at least one certificate policy. See Figure 1 and Table 1.
b) Contractual environment: certificate subjects and relying parties may have separate TSPs. TSPs are
bound by differing forms of contract covering certificate use. These forms comprise:
1) multilateral, under agreed rules, with a single certificate policy;
2) bilateral cross certification that may use different certificate policies;
3) accreditation bridge that may recognize different certificate policies through central organization or
entity.
See Figure 2 and Table 2.
c) Open environment: the financial institution may act as a TSP issuing certificates to the public and
permits validation of certificates in an open network environment. TSPs may operate under voluntary TSP
accreditation schemes or within an indigenous regulatory framework. Typically, there is no formal contract
between the subscriber's TSP and the relying party. See Figures 3 and 4 and Table 3.
A PKI is comprised of technical, process and people components that must harmonize into an effective
infrastructure. As with any infrastructure, the business requirements must be initially determined. These
requirements may be met by the deployment of a PKI.
5.3 Business requirement impact on PKI environment
5.3.1 General
This clause uses business scenarios to illustrate the key differences between the closed, open and
contractual environments. Tables 1 to 3 describe typical business scenarios, sample (security) requirements,
and the associated PKI operations that would be performed if PKI was utilized to address the requirements.
5.3.2 Illustration of certificate application in a closed environment
This subclause describes several scenarios where the financial institution may use PKI for internal purposes
and to support its services and communications internally or to its customers.

1) An entity adhering to a trust service may act as a relying party or subscriber for certificates for itself or on behalf of
other certificate subjects. In this case, subscribers and certificate subjects may be distinct entities bound by a business
relationship which is outside the scope of this International Standard.
10 © ISO 2006 – All rights reserved

Figure 1 — Two entities in a closed environment
Table 1 — Certificate application scenarios in a closed environment
Typical scenarios Sample requirements PKI operations
• Authentication of sender for • Sender creates digital signature.
recipient.
The financial institution (FI) sends
• Recipient validates sender’s
1 an e-mail to a customer (e.g.
• Message integrity for sender certificate.
notification of deposit rate change).
and recipient.
• Recipient verifies digital signature.
• Authentication of sender for • Recipient validates sender’s
recipient. certificate.
• Message integrity for sender • Sender creates digital signature.
and recipient.
• Recipient verifies digital signature.
Exchange of sensitive e-mails
• Confidentiality protection for • Sender fetches recipient’s certificate
2 between employees contained
within the FI’s network boundaries. message contents. from directory.
• Sender encrypts message with
recipient’s public key.
• Recipient decrypts message with
recipient’s private key.
• Mutual authentication of • Provision of employee identification
employee by the FI and server certificates.
Travelling sales force with FI
by employee.
laptops need to exchange
• Provision of server ID certificate.
customer and sales information
• Confidentiality protection for
• Invoke SSL encryption.
with centralized support systems.
data.
• Invoke SSL encryption.
• Proof that the software that is • FI digitally signs software
being loaded into the device applications.
The internal network distribution of
comes from an authentic
4 the FI’s software to customer
• Recipient verifies digital signature
source.
facing devices (e.g. ATM software).
• Recipient validates FI’s certificate.
• Mutual authentication of client • Customer authenticates to service
(customer) by the FI and using client certificate.
Customer using a remote banking
server by customer software.
service where the server and
5 • Server authenticates to customer
browser application are provided
• Confidentiality protection for using server certificate.
by the FI.
customer data.
• Invoke SSL encryption.
5.3.3 Illustration of certificate application in a contractual environment
This subclause describes the financial institution using the PKI for support transactions to its customers within
a scheme or where a contract with rules has been established between the parties. It will provide either
certificate issuance or certificate validation services, or both services, to its customers.

Figure 2 — Four entities in a contractual environment
Table 2 — Certificate application scenarios in a contractual environment
Typical scenario Sample requirements PKI operations
• Authentication of sender for • Recipient validates sender’s
recipient. certificate.
• Message integrity. • Customer checks digital signature.
FI employee sends an e-mail via
• Confidentiality protection for • Sender fetches recipient’s certificate
1 the Internet to a customer that uses
message contents. from directory.
another TSP.
• Sender encrypts message using
recipient’s public key.
• Recipient decrypts message using
recipient’s private key.
• Customer authorizes purchase • Customer digitally signs purchase
order. order using certificate demonstrating
mandated authority.
Customer submits a purchase • Authentication of customer by
order to a merchant. merchant.
• Recipient validates sender’s
certificate.
• Transaction message integrity.
• Merchant verifies digital signature.
Customer receives invoice from
• Message authentication. • Check digital signature and validate
merchant. certificate.
• Strong mutual authentication. • Customer validates FI's server
certificate.
• Message integrity.
• FI validates customer's certificate.
• Confidentiality.
• FI verifies digital signature.
An existing customer using an
• Sender fetches recipient’s certificate
4 e-banking service to send high
from directory.
value payment instructions to FI.
• Sender encrypts message using
recipient’s public key.
• Recipient decrypts message using
recipient’s private key.
12 © ISO 2006 – All rights reserved

Table 2 (continued)
Typical scenario Sample requirements PKI operations
• Authentication of sender • Clearing house validates customer's
(account holder) for recipient. certificate.
• Message integrity and non- • Clearing house verifies digital
repudiation proof.
signature.
• Confidentiality protection for
• Customer fetches clearing house’s
message contents.
certificate from directory.
Corporate customer sends
• Dual customer authorization.
• Sender encrypts message using
payment files directly to an
recipient’s public key.
automated clearing house.
• Recipient decrypts message using
recipient’s private key.
• Two individuals digitally sign the
payment files.
• Clearing house verifies both digital
signatures.
• Authentication of ICC by • ICC creates digital signature.
terminal off-line.
EMV purchase by a cardholder at
• Terminal checks ICC authenticity
point of sale.
using ICC issuer public key certified
by scheme CA.
5.3.4 Illustration of certificate application in an open environment
This subclause describes the financial institution’s possible use of PKI to enable open external communication
for itself, its own customers and external trading partners. The financial institution may offer trust services to
its customers.
Figure 3 — FI acting as certificate validation service provider in an open environment
Figure 4 — FI acting as certificate issuer in an open environment
Table 3 — Certificate application scenarios in an open environment
Scenario Sample requirements PKI operations
Web site visitor downloads
• Authentication of FI. • User validates FI's certificate.
executable code while browsing a
• Integrity of FI executable code. • User verifies FI’s digital signature.
financial institution’s Web site.
• Authentication of an official FI • User validates FI's server certificate.
2 A customer visits an FI Web site.
Web site (i.e., not spoofed).
• Authentication of sender for • Each FI employee validates the
recipient. sender's certificate.
Exchange of e-mails between two
employees from different FIs via
• Message integrity and non- • Each FI employee verifies digital
the Internet where there is no
repudiation proof. signature.
formal agreement in place.
• Confidentiality protection for • Each FI employee fetches recipient’s
message contents. certificate from directory.
• Authentication of source and • The user validates the FI's
integrity of content. certificate.
An important electronic document
(e.g. financial results) is published.
• The user verifies the digital
signature.
• Authentication of sender for • Each customer validates the
recipient. sender's certificate.
Exchange of sensitive e-mails
• Message integrity. • Each customer verifies the digital
5 between two customers using
signature on the message received.
different TSPs.
• Confidentiality protection for • Each customer fetches the
message contents. recipient’s certificate from the
directory.
5.4 Functional perspectives
PKI may be viewed from a number of different perspectives. The hardware, software and security procedures
provide a rich set of PKI functions that can be logically grouped into PKI roles that are specified below. The
subclauses that follow describe the policy authority (a), the components of a certification authority (b to g),
subjects (h) and relying parties (i). A typical allocation of functions to roles is provided below though specific
functions may be undertaken by different roles. Multiple roles may be undertaken by the same organization.
Figure 5 is a high-level representation of the functional elements within a PKI and their relationships.
14 © ISO 2006 – All rights reserved

--------------
...

MЕЖДУНАРОДНЫЙ ISO
СТАНДАРТ 21188
Первое издание
2006-05-01
Инфраструктура открытых ключей для
сферы финансовых услуг.
Практические приемы и структура
политики
Public key infrastructure for financial services — Practices and
policy framework
Ответственность за подготовку русской версии несёт GOST R
(Российская Федерация) в соответствии со статьёй 18.1 Устава ISO
Cсылочный номер
©
ISO 2006
Отказ от ответственности при работе в PDF
Настоящий файл PDF может содержать интегрированные шрифты. В соответствии с условиями лицензирования, принятыми
фирмой Adobe, этот файл можно распечатать или смотреть на экране, но его нельзя изменить, пока не будет получена
лицензия на интегрированные шрифты и они не будут установлены на компьютере, на котором ведется редактирование. В
случае загрузки настоящего файла заинтересованные стороны принимают на себя ответственность за соблюдение
лицензионных условий фирмы Adobe. Центральный секретариат ISO не несет никакой ответственности в этом отношении.
Adobe — торговый знак фирмы Adobe Systems Incorporated.
Подробности, относящиеся к программным продуктам, использованные для создания настоящего файла PDF, можно найти в
рубрике General Info файла; параметры создания PDF были оптимизированы для печати. Были приняты во внимание все
меры предосторожности с тем, чтобы обеспечить пригодность настоящего файла для использования комитетами-членами
ISO. В редких случаях возникновения проблемы, связанной со сказанным выше, просьба проинформировать Центральный
секретариат по адресу, приведенному ниже.

ДОКУМЕНТ ЗАЩИЩЕН АВТОРСКИМ ПРАВОМ

© ISO 2006
Все права сохраняются. Если не указано иное, никакую часть настоящей публикации нельзя копировать или использовать в
какой-либо форме или каким-либо электронным или механическим способом, включая фотокопии и микрофильмы, без
предварительного письменного согласия ISO, которое должно быть получено после запроса о разрешении, направленного по
адресу, приведенному ниже, или в комитет-член ISO в стране запрашивающей стороны.
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
Опубликовано в Швейцарии
ii © ISO 2006 — Все права сохраняются

Содержание Страница
1 Область применения .1
2 Нормативные ссылки .1
3 Термины и определения .2
4 Сокращенные термины .10
5 Инфраструктура открытых ключей (PKI).11
5.1 Общие положения .11
5.2 Что такое PKI? .11
5.3 Влияние деловых требований на среду RKI.12
5.4 Функциональные перспективы .16
5.5 Деловые перспективы.21
5.6 Политика в области сертификатов (CP) .24
5.7 Положение о практике сертификации (CPS) .26
5.8 Взаимосвязь между политикой в области сертификатов и положением по практике
сертификации.27
5.9 Соглашения.28
5.10 Отметка времени .29
6 Требования к политике в области сертификатов и положению по практике
сертификации.30
6.1 Политика в области сертификатов (CP) .30
6.2 Положение по практике сертификации (CPS).32
7 Задачи контроля органа по сертификации .33
7.1 Общие положения .33
7.2 Задачи контроля CA в области среды .33
7.3 Задачи контроля управления жизненным циклом ключей СА .36
7.4 Задачи контроля управления жизненным циклом ключа субъектов.37
7.5 Задачи контроля управления жизненным циклом сертификатов .38
7.6 Средства контроля управления жизненным циклом сертификатов CA.39
8 Процедуры контроля, используемые органом по сертификации.39
8.1 Общие положения .39
8.2 Средства контроля среды СА.40
8.3 Средства контроля менеджмента жизненного цикла ключа CA .55
8.4 Средства контроля менеджмента для жизненного цикла ключей субъекта.59
8.5 Средства контроля менеджмента жизненного цикла сертификата .64
8.6 Средства контроля менеджмента жизненного цикла сертификата CA .71
(Приложение А (информативное) Менеджмент с помощью политики в области
сертификации.73
Приложение B (информативное) Элементы положения по практике сертификации.82
Приложение C (информативное) Идентификаторы объектов (OID) .100
Приложение D (информативное) Процедура генерации ключа CA.102
Приложение E (информативное) Соответствие документа RFC 2527 документу RFC 3647 .106
Библиография.112

Предисловие
Международная организация по стандартизации (ISO) является всемирной федерацией национальных
организаций по стандартизации (комитетов-членов ISO). Разработка международных стандартов
обычно осуществляется техническими комитетами ISO. Каждый комитет-член, заинтересованный в
деятельности, для которой был создан технический комитет, имеет право быть представленным в этом
комитете. Международные правительственные и неправительственные организации, имеющие связи с
ISO, также принимают участие в работах. ISO осуществляет тесное сотрудничество с международной
электротехнической комиссией (IEC) по всем вопросам стандартизации в области электротехники.
Проекты международных стандартов разрабатываются согласно правилам, привёденным в Директивах
ISO/IEC, Часть 2.
Основной задачей технических комитетов является подготовка международных стандартов. Проекты
международных стандартов, принятые техническими комитетами, рассылаются комитетам-членам на
голосование. Для публикации в качестве международного стандарта требуется одобрение не менее
75 % комитетов-членов, принявших участие в голосовании.
Следует иметь в виду, что некоторые элементы настоящего документа могут быть объектом патентных
прав. ISO не несет ответственность за определение некоторых или всех таких патентных прав.
ISO 21188 был подготовлен Техническим Комитетом ISO/TC 68, Финансовые услуги, Подкомитетом
SC 2, Управление безопасностью и общие банковские операции.
iv © ISO 2006 — Все права сохраняются

Введение
Организации и посредники создают специальные инфраструктуры с целью предоставления
потребителям, корпорациям и государственным органам новых возможностей для проведения
электронных финансовых операций. Поскольку объем электронных финансовых операций продолжает
расти, новейшие технологии обеспечения безопасности с использованием цифровых подписей и
систем полномочий могут стать частью процесса финансовых операций. Системы финансовых
операций, включающие в себя новейшие технологии обеспечения безопасности, имеют свои
требования по защите секретности, аутентичности и целостности финансовых операций, проводимых
в сетях связи.
Индустрия финансовых услуг полагается на некоторые проверенные временем методы электронной
идентификации, санкционирования и опознания объектов и защиты финансовых операций. Эти
методы включают, но не ограничиваются ими, Персональные Идентификационные Номера (PIN) и
Коды Аутентификации Сообщений (MAC) для розничных и оптовых финансовых операций,
Идентификационные Данные (ID) пользователей и пароли для доступа к сети и компьютеру, а также
распределение ключей для связности узлов сети. За последние двадцать лет в индустрии финансовых
услуг разработаны процессы управления рисками и методики для поддержки использования этих
процессов для финансовых применений.
Широкое использование Интернет-технологий в индустрии финансовых услуг и потребности этой
индустрии в обеспечении безопасности, конфиденциальности и надежности финансовых операций и
компьютерных систем привели к возникновению новейших технологий обеспечения безопасности,
включающих криптографию с открытым ключом. Криптография с открытым ключом требует
оптимизированной относительно бизнеса инфраструктуры технологии, менеджмента и политики
(инфраструктуры с открытым ключом или PKI, как определено в этом документе) для удовлетворения
требований электронной идентификации, опознания и санкционирования в финансовых системах.
Использование стандартных методов электронной идентификации, опознания и санкционирования в
PKI обеспечивает более устойчивую и предсказуемую систему безопасности и доверие к электронным
сетям связи. Доверие может быть достигнуто тогда, когда можно установить соответствие
стандартным методам.
Прикладные программы, обслуживающие индустрию финансовых услуг, можно разработать с
цифровой подписью и возможностями PKI. Безопасность и отсутствие дефектов в этих прикладных
программах базируются, в частности, на реализациях и методах, предназначенных для обеспечения
общей целостности инфраструктуры. Пользователи основанных на полномочии систем, которые
электронным способом связывают идентичность отдельных лиц и других объектов с
криптографическими материалами (например, криптографическими ключами), выигрывают от
стандартных систем управления рисками и главных, доступных проверке, методов, установленных в
этом стандарте.
Члены Технического комитета 68 Международной организации по стандартизации взяли на себя
обязательства в области технологий с открытым ключом и разрабатывают технические стандарты и
инструкции, касающиеся цифровых подписей, управления ключами, управления сертификатами и
кодированию данных. ISO 15782, Части 1 и 2, определяет систему управления сертификатами для
финансовой индустрии, но не включает политику в этой области и требования к практике
сертификации. Настоящий стандарт дополняет ISO 15782, Части 1 и 2, предоставляя структуру
управления PKI через политику сертификации, операторов практики сертификации, контрольные цели
и поддерживающие процедуры. Для тех, кто внедряет эти стандарты, степень, в которой любой объект
финансовой операции может полагаться на реализацию стандартов, касающихся инфраструктуры с
открытым ключом, и степень взаимодействия систем на базе PKI, использующих эти стандарты,
частично будут зависеть от факторов, относящихся к политике и практике, установленных в настоящем
документе
МЕЖДУНАРОДНЫЙ СТАНДАРТ ISO 21188:2006(R)

Инфраструктура открытых ключей для сферы финансовых
услуг. Практические приемы и структура политики
1 Область применения
Этот международный стандарт устанавливает систему требований с целью управления PKI с помощью
политики сертификатов и операторов практики сертификации и содействия использованию
сертификатов с открытым ключом в индустрии финансовых услуг. Он также определяет контрольные
цели и поддерживающие процедуры управления рисками.
Этот международный стандарт проводит различие между системами PKI в открытой, закрытой и
контрактной средах. Далее, он определяет рабочие методы с контрольными целями в
информационных системах индустрии финансовых услуг. Стандарт предназначен помочь тем, кто его
реализует, определить практические методы PKI, которые могут поддерживать политику сертификатов,
включающую использование цифровой подписи, удаленного аутентификации и шифрования данных.
Этот международный стандарт способствует реализации рабочих базовых методов управления PKI,
которые удовлетворяют требованиям индустрии финансовых услуг в контрактной среде. Хотя стандарт
ориентирован на контрактную среду, его применение в других средах не возбраняется. Применительно
к этому документу термин «сертификат» относится к сертификатам открытого ключа. Сертификаты
атрибутов не рассматриваются в этом стандарте.
Этот международный стандарт обращен к нескольким категориям пользователей, имеющим несхожие
интересы, так что для каждой категории документ будет представлять различный интерес.
Менеджеры в бизнесе и аналитики — это те пользователи, которым нужна информация
относительно использования технологии PKI в их развивающемся бизнесе (например, при электронной
торговле), и им следует сосредоточиться на пунктах с 1 по 6.
Технические проектировщики и конструкторы — это те пользователи, которые создают свои
политики сертификатов и положение(я) практики сертификации, и им следует сосредоточиться на
пунктах от 6 до 8 и Приложениях с A до F.
Оперативное руководство и аудиторы — это те пользователи, которые отвечают за каждодневные
операции PKI и подтверждение их соответствия этому документу, и им следует сосредоточиться на
пунктах с 6 до 8.
2 Нормативные ссылки
Следующие ссылочные документы необходимы для использования данного документа. Для жестких
ссылок применимо только указанное издание. Для плавающих ссылок применимо последнее издание
ссылочного документа (включая все изменения).
Следующие ссылочные документы необходимы для использования данного документа. Для жестких
ссылок применимо только указанное издание. Для плавающих ссылок применимо последнее издание
ссылочного документа (включая все изменения).
ISO/IEC 7810, Карточки идентификационные. Физические характеристики
ISO/IEC 7811, Карточки идентификационные. Методы записи (Части 1—5)
ISO/IEC 7813, Карточки идентификационные. Карточки финансовых операций
ISO/IEC 7816, Карточки идентификационные. Карточки на микросхемах (Части 1—12 и 15)
ISO/IEC 9594-8:1995, Информационные технологии. Взаимосвязь открытых систем. Директория:
система понятий аутентификации
ISO/IEC 9834-1:1993, Информационные технологии. Взаимосвязь открытых систем. Процедуры для
работы регистрационных органов в системе OSI: Часть 1. Общие процедуры и высшие разряды
дерева идентификаторов объекта ASN.1
ISO 10202, Карточки банковские для финансовых операций. Архитектура безопасности систем
финансовых операций, использующих смарт-карты. (восемь частей)
ISO/IEC 10646-1, Информационные технологии. Универсальный многооктетный набор
кодированных знаков. Часть 1. Архитектура и основная многоязычная матрица
ISO/IEC 15408, Информационные технологии. Методы защиты. Критерии оценки для
информационных технологий (три части)
ISO 15782-1:2003, Менеджмент сертификатов для финансовых услуг. Часть 1. Сертификаты с
открытым ключом
ISO 15782-2, Банковское дело. Менеджмент сертификатов. Часть 2. Расширения сертификата
ISO/IEC 17799, Информационные технологии. Методы защиты. Свод правил по менеджменту
информационной безопасностиt
ISO 18014-2, Информационные технологии. Методы защиты. Услуги по созданию метки
даты/времени. Часть 2. Механизмы создания независимых маркеров
ISO 18014-3, Информационные технологии. Методы защиты. Услуги по созданию метки
даты/времени. Часть 3. Механизмы создания связанных маркеров
ISO/IEC 18032, Информационные технологии. Методы защиты. Генерация простых чисел
ISO 18033, Информационные технологии. Методы защиты. Алгоритмы шифрования (Части 1—4)
3 Термины и определения
В данном документе используются следующие термины и определения.
3.1
данные активизации
activation data
значения данных, кроме ключей, которые нужны для функционирования криптографических модулей и
которые должны быть защищены (например, PIN, фразой паролем, биометрической или
поддерживаемой вручную частью ключа)
3.2
аутентификация
authentication
подтверждение идентичности, заявляемой лицом
a) при регистрации, акт оценивания мандатов конечных объектов (например, подписчиков), как
свидетельство заявленной ими идентичности;
b) во время использования, акт сравнения электронного представления идентичности и мандатов
(например, ID и пароль пользователя) с хранящимися значениями для доказательства идентичности
2 © ISO 2006 — Все права сохраняются

3.3
данные аутентификации
authentication data
информация, используемая для подтверждения заявленной идентичности объекта, например,
личности, определенного ролевого имени, корпорации или организации
3.4
бюро карточек
card bureau
представитель органа по сертификации (CA) (3.18) или органа по регистрации (RA) (3.46) который
персонализирует карточку на микросхеме (ICC) (3.32), содержащую (как минимум) личный ключ
подписчика
3.5
владелец кредитной карточки
cardholder
субъект, которому была выдана карточка на микросхеме, содержащая пары секретных и открытых
ключей и сертификаты (3.6)
3.6
сертификат
certificate
открытый ключ и идентичность объекта вместе с некоторой другой информацией, которую, как
считается, нельзя подделать путем подписи информации в сертификате секретным ключом органа по
сертификации, который выдал этот сертификат открытого ключа
3.7
приостановление сертификата
certificate hold
certificate suspension
приостановление действия сертификата (3.6)
3.8
эмитент сертификата
certificate issuer
организация, чье название находится в поле эмитента сертификата (3.6)
3.9
изготовитель сертификата
certificate manufacturer
агент, который выполняет задачи применения цифровой подписи в сертификате , подписывая
требование от имени эмитента сертификата (3.6)
3.10
политика в области сертификатов
certificate policy
CP
определенный набор правил, который указывает применяемость сертификата к конкретному
сообществу и/или классу применения с общими требованиями безопасности
3.11
профиль сертификата
certificate profile
спецификация требуемого формата (включая требования к использованию стандартных полей и
расширений) для данного типа сертификата (3.6)
3.12
повторный ключ для сертификата
certificate re-key
процесс, с помощью которого объект с существующей парой ключей и сертификатом (3.6) получает
новый сертификат для нового открытого ключа после генерирования новой пары ключей
3.13
возобновление сертификата
продление
certificate renewal
rollover
процесс, с помощью которого объекту выдается новый экземпляр существующего сертификата с
новым сроком действия
3.14
перечень отмены сертификатов
certificate revocation list
CRL
перечень отмененных сертификатов (3.6)
3.15
услуга по подтверждению сертификата
certificate validation service
услуга, предоставляемая CA (3.18) или его агентом, который выполняет подтверждение срока
действия сертификата (3.6) стороне (3.49), использующей сертификат
3.16
провайдер услуг по подтверждению сертификата
certificate validation service provider
CVSP
организация (3.29), которая предоставляет услугу по подтверждению сертификата потребителям со
стороны, использующей сертификат
3.17
сертификация
certification
процесс создания сертификата с открытым ключом для организации (3.29)
3.18
орган по сертификации
certification authority
CA
организация, которой одна или несколько других организаций поручают создавать, присваивать,
отзывать или оставлять у себя сертификат с открытым ключом
3.19
цепочка сертификации
certification path
заданная последовательность сертификатов организаций, которая, вместе с открытым ключом
начальной организации в цепочке, может быть обработана с целью получения открытого ключа
конечной организации в цепочке
3.20
положение по практике сертификации
certification practice statement
CPS
положение по практике, которое орган по сертификации (3.18) применяет при выдаче сертификатов,
и в котором определяются оборудование, методика и процедуры, используемые CA для
удовлетворения требований, заданных в заявлениях о политике сертификатов, поддерживаемых им
3.21
запрос о сертификации
certification request
представление запроса о подтверждении регистрации органом по регистрации (RA) (3.46), его
агентом или подчиненным ему органом в CA (3.18) для регистрации открытого ключа подчиненного
органа, помещаемого в сертификате (3.6)
4 © ISO 2006 — Все права сохраняются

3.22
ответ на запрос о сертификации
certification response
сообщение от CA (3.18), посылаемое после сертификации в ответ на запрос о сертификате
3.23
пригодность сертификата
certificate validity
validity
применяемость (годность к предназначенному использованию) и статус (действителен, приостановлен,
отозван или истек) сертификата (3.6)
3.24
компрометация
compromise
нарушение безопасности системы, после которого может произойти несанкционированное раскрытие
информации
3.25
перекрестная сертификация
cross certification
процесс согласно которому два CA (3.18) взаимно сертифицируют открытые ключи друг друга
ПРИМЕЧАНИЕ. Этот процесс может быть автоматическим.
3.26
криптографическое устройство
cryptographic hardware
cryptographic device
hardware security module
механический криптографический модуль
3.27
цифровая подпись
digital signature
криптографическое преобразование, при котором, когда он соединяется с блоком данных,
обеспечиваются услуги по первоначальной аутентификации, интеграции данных и не отказу от
подписавшего
3.28
конечная организация
end entity
субъект сертификата, который использует его секретный ключ не в целях подписи
3.29
организация
entity
CA (3.18), RA (3.46) или конечная организация (3.28)
3.30
журнал событий
контрольный журнал
event journal
audit journal
audit log
хронологические записи деятельности системы, которых достаточно, чтобы реконструировать,
проанализировать и проверить последовательность условий и действий, происходивших вокруг или
приведших к каждому событию на пути операции, начиная от ее отправной точки и кончая конечным
результатом
3.31
функциональные испытания
functional testing
часть испытаний безопасности, при которых заявленные характеристики системы испытываются на
правильность функционирования
3.32
карточка на микросхеме
integrated circuit card
ICC
карточка, в которую вставлен один или несколько электронных компонентов в виде микросхем для
выполнения функций обработки и памяти
3.33
выпускающий орган сертификации
выпускающий CA
issuing certification authority
issuing CA
в контексте данного сертификата, выпускающий CA (3.18) — это CA, который выпускает сертификат
3.34
условное депонирование ключа
key escrow
управленческая функция, которая позволяет санкционированной стороне получить доступ к
тиражированному секретному ключу шифрования
ПРИМЕЧАНИЕ. Может быть законным требование дать возможность официальным лицам
правоприменительных органов получить доступ к секретному конфиденциальному ключу организации и/или CA.
3.35
восстановление ключа
key recovery
возможность восстановить секретный ключ или ключ симметричного шифрования организации из
безопасного хранения в случае их потери, порчи или в том случае, когда по какой-либо другой причине
они стали недоступными
3.36
многостороннее управление
multiple control
условие, при котором две или несколько сторон отдельно и конфиденциально владеют компонентами
единственного ключа, так что, не будучи соединены, они не позволяют узнать полный
криптографический ключ
3.37
идентификатор объекта
object identifier
OID
уникальная последовательность целых чисел, которая однозначно идентифицирует информационный
объект
3.38
онлайновый механизм выяснения статуса сертификата
online certificate status mechanism
механизм, который позволяет зависимым сторонам (3.49) запрашивать и получать информацию о
статусе сертификата без требования использовать CRL (3.14)
6 © ISO 2006 — Все права сохраняются

3.39
онлайновый протокол статуса сертификата
online certificate status protocol
OCSP
протокол для определения текущего статуса сертификата вместо проверки или в дополнение к ней по
периодическому CRL (3.14), который устанавливает данные, подлежащие обмену между прикладной
программой, проверяющей статус, и сервером, обеспечивающим этот статус
3.40
срок действия
operating period
период действия сертификата, начинающийся со дня и времени его выпуска в CA (3.18) (или, если
указано в сертификате, с более позднего дня и времени), и заканчивающийся днем и временем его
истечения или аннулирования
3.41
заявление о раскрытии информации PKI
PKI disclosure statement
документ, который дополняет CP (3.10) или CPS (3.20) путем раскрытия критической информации о
политике и практике CA (3.18)/PKI (3.45)
ПРИМЕЧАНИЕ Заявление о раскрытии информации PKI является средством для раскрытия и подчеркивания
информации, обычно подробно охватываемой связанными с ней документами CP и/или CPS. Следовательно, PDS
не предназначено заменять CP или CPS.
3.42
орган по разработке политики
policy authority
PA
сторона или орган с конечными полномочиями определять политику в области сертификатов (3.10),
обеспечивать практику и средства управления CA (3.18), как определено CPS (3.20), и полностью
поддерживать установленную политику в области сертификатов
3.43
составление схемы политики
policy mapping
признание того факта, что, когда CA (3.18) одного домена сертифицирует CA другого домена,
конкретная политика в области сертификатов (3.10) второго домена может быть рассмотрена
полномочным органом первого домена, чтобы сделать ее эквивалентной (но необязательно
идентичной во всех аспектах) конкретной политике в области сертификатов первого домена
ПРИМЕЧАНИЕ См. 3.25, перекрестная сертификация.
3.44
квалификатор политики
policy qualifier
зависимая от политики информация, которая сопровождает идентификатор политики в области
сертификатов (3.10) в сертификате X.509
3.45
инфраструктура открытых ключей
public key infrastructure
PKI
структура, состоящая из аппаратного обеспечения, программного обеспечения, персонала, процессов
и политики, которая использует технологию цифровой подписи для поддержки проверяемой связи
между открытым компонентом пары асимметричных ключей и данным подписчиком, который владеет
соответствующим секретным ключом
ПРИМЕЧАНИЕ Открытый ключ может быть предоставлен для проверки цифровой подписи, аутентификации
субъекта коммуникационного диалога и/или обмена или согласования шифровального ключа для сообщений.
3.46
орган по регистрации
registration authority
RA
организация, которая несет ответственность за идентификацию и отождествление держателей
сертификатов, но не является CA (3.18), и, следовательно, не подписывает и не выпускает
сертификаты
ПРИМЕЧАНИЕ RA может оказывать помощь в процессе применения сертификата или в процессе отмены его
или в том и другом случае. RA может не быть отдельным органом, а может быть частью CA.
3.47
запрос о регистрации
registration request
представление организацией в RA (3.46) [или CA (3.18)] для регистрации ее открытый ключ
организации в сертификате
3.48
ответ на запрос о регистрации
registration response
сообщение, посылаемое RA (3.46) [или CA (3.18)] организации в ответ на ее запрос о регистрации
3.49
зависимая сторона
relying party
RP
получатель сертификата, который действует, будучи уверен в этом сертификате, цифровых подписях,
проверяемых с использованием этого сертификата, или в том и другом случае
3.50
репозиторий
repository
система хранения и распределения сертификатов и относящейся к ним информации (то есть,
хранение сертификатов, распределение сертификатов, политика в области сертификатов (3.10),
статус сертификатов и т.д.)
3.51
корневой CA
root CA
CA (3.18) на вершине иерархии CA
3.52
сигнатурная верификация
signature verification
〈в привязке к цифровой подписи〉 точное определение: проверка того, что
a) цифровая подпись была создана в рабочий период действия сертификата секретным ключом,
соответствующим открытому ключу, имеющемуся в сертификате (3.6);
b) сообщение не было изменено с момента создания цифровой подписи.
3.53
субъект
subject
организация, чей открытый ключ сертифицирован в сертификате
3.54
CA субъект
subject CA
CA (3.18), который сертифицирован выпускающим CA, и потому соответствует политике в области
сертификатов (3.10) выпускающего CA
8 © ISO 2006 — Все права сохраняются

3.55
конечная организация — субъект
subject end entity
конечная организация, которая является субъектом сертификата (3.6)
3.56
подчиненный CA
subordinate CA
sub-CA
CA (3.18), который в иерархии CA стоит ниже другого CA
3.57
подписчик
subscriber
организация (3.18), оформившая подписку в органе по сертификации от имени одного или нескольких
субъектов
3.58
вышестоящий CA
superior CA
CA (3.18), который в иерархии CA стоит выше другого [подчиненного CA (3.56)], но не корневой CA
3.59
свидетельствующий о попытке подделки
tamper evident
обладающий характеристикой, которая обеспечивает свидетельство о том, что была сделана попытка
подделки
3.60
стойкий к попыткам подделки
tamper resistant
обладающий характеристикой, которая обеспечивает пассивную физическую защиту от попытки
подделки
3.61
доверительная роль
trusted role
рабочая служба, выполняющая критические функции, которые, в случае их неудовлетворительного
выполнения могут оказать отрицательное влияние на степень доверия, обеспечиваемого CA (3.18)
3.62
провайдер доверительных услуг
trust services provider
TSP
утвержденная организация (определенная сторонами контракта), обеспечивающая доверительные
услуги с помощью ряда органов по сертификации (3.18) своим потребителям, которые могут
действовать как подписчики или зависимые стороны (3.49)
ПРИМЕЧАНИЕ Провайдер доверительных услуг может также предоставлять услуги по проверке
достоверности сертификата.
3.63
запрос службе подтверждения
validation service request
запрос зависимой стороны (3.49) в службу проверки юридической силы сертификата (3.6)
4 Сокращенные термины
Сокращение Значение
ASN.1 Система обозначений абстрактного синтаксиса один
CA Орган по сертификации
CM Изготовитель сертификата
CP Политика в области сертификатов
CPS Положение по практике сертификации
CRL Лист аннулирования сертификата
CVSP Провайдер услуг по подтверждению сертификата
EMV Еврокарта Master Card Visa
FI Финансовое учреждение
FIPS Федеральный стандарт обработки информации
FTP Протокол передачи файла
HSM Модуль аппаратного защиты
HTTP Протокол передачи гипертекста
ICC Карточка на микросхеме
ID Идентификатор
IEC Международная электротехническая комиссия
IETF Рабочая группа по проектированию Интернета
ISO Международная организация по стандартизации
ITU Международный союз телекоммуникаций
LDAP Упрощенный протокол доступа к директории
MAC Код аутентификации сообщения
OCSP Онлайновый протокол статуса сертификата
OID Идентификатор объекта
PA Орган по разработке политики
PIN Личный идентификационный номер
PKI Инфраструктура открытых ключей
PKIX Инфраструктура открытых ключей (X.509) (Рабочая группа IETF)
POS Пункт продажи
RA Орган по регистрации
RFC Запрос для комментария
10 © ISO 2006 — Все права сохраняются

Сокращение Значение
RP Зависимая сторона
SSL Протокол защищенных сокетов
TLS Протокол защиты транспортного уровня
TSA Орган по отметке времени
TSP Провайдер доверительных услуг
TTP Доверительная третья сторона
URL Унифицированный указатель информационного ресурса
5 Инфраструктура открытых ключей (PKI)
5.1 Общие положения
Перед тем, как обратиться к подробностям требований к политике и практике PKI, следует рассмотреть
представленную в этом международном стандарте некоторую базовую информацию, лучше понять
контекст, в котором эти политика и практика используются в рамках PKI.
5.2 Что такое PKI?
В этом подпункте описаны компоненты PKI и показаны функции и обязанности, которые выполняют
различные организации в рамках PKI. Быстрый рост электронной торговли вызвал желание проводить
операции между предприятиями, предприятием и потребителем и правительственным агентом и
потребителем через открытые сети типа Интернет. Разработка сетевых протоколов передачи создает
проблемы для финансовых институтов и их клиентов, ведущих деловые операции. Они требуют
электронной идентификации и аутентификации сторон операции, доказательства происхождения,
защиты целостности сообщений и конфиденциальности услуг. Электронная аутентификация поднимает
также важные вопросы по доказательству и контракту, ответственности, конфиденциальности, защиты
потребителя и торговли.
PKI являются практическим техническим решением проблем, которые представляют открытые сети.
Финансовые учреждения становятся провайдерами доверительных услуг (TSP), чтобы получить выгоду
от растущего рынка для обеспечения безопасности и аутентификации в онлайновых коммуникационных
сетях. Зависимые стороны, как получатели информации, используют TSP для проверки срока действия
сертификата, применяемого для аутентификации онлайновых коммуникаций. TSP представляет собой
признанный орган, которому одна или несколько зависимых сторон поручают создавать и подписывать
сертификаты. TSP может также отзывать созданные и выпущенные им сертификаты. TSP управляет
одним или несколькими органами по сертификации (CA), основными функциями которых являются
выпуск, изготовление сертификата и подтверждение сертификата. В рамках финансового учреждения
CA необязательно является деловой организацией, но может быть отделением или службой,
обеспечивающей функции CA, поручаемые зависимыми сторонами или подписчиками.
Технология открытого ключа используется для поддержки требований к конфиденциальности,
целостности и идентичности. При криптографии с открытым ключом, создаются два ключа (секретный
и открытый). Секретный ключ держится в тайне, а открытый ключ может стать известным в
сертифицированном виде, который защищает его идентичность. Открытый ключ субъекта и
идентифицирующие данные подписываются секретным ключом CA, чтобы создать сертификат.
Сертификаты создаются в соответствии с политикой в области сертификатов. Раскрытие открытого
ключа не создает угрозы раскрытия секретного ключа.
Финансовые учреждения могут использовать PKI для обслуживания своих деловых потребностей в
указанных ниже средах, в зависимости от их отношений с зависимой стороной. Примеры даны в
Таблицах 1—3.
1)
a) Закрытая среда: все организации (субъекты сертификата и зависимые стороны) пользуются
доверительными услугами одного финансового учреждения и руководствуются, по меньшей мере,
одной политикой в области сертификатов. См. Рисунок 1 и Таблицу 1.
b) Контрактная среда: субъекты сертификата и зависимые стороны могут иметь разные TSP. TSP
связаны разными формами контракта, покрывающего использование сертификата. Эти формы бывают:
1) многосторонними контрактами, в соответствии с согласованными правилами, с одной
политикой в области сертификатов;
2) двусторонними контрактами, с перекрестной сертификацией, с различными политиками в
области сертификатов;
3) мостом аккредитации, при котором могут признаваться различные политики в области
сертификатов в одной центральной организации.
См. Рисунок 2 и Таблицу 2.
c) Открытая среда: финансовое учреждение может действовать как TSP, выпускающий сертификаты
и позволяет проверять срок их действия в среде открытых сетей. TSP могут работать по схемам
добровольной аккредитацииTSP или в рамках местного регламента. Как правило, между TSP
подписчика и зависимой стороной не заключается официального контракта. См Рисунки 3 и 4 и
Таблицу 3.
PKI состоит из технического, процессуального и кадрового компонентов, которые должны образовать
эффективную инфраструктуру. Как у любой инфраструктуры, сначала должны быть определены
деловые требования. Эти требования могут быть соблюдены путем развертывания PKI.
5.3 Влияние деловых требований на среду RKI
5.3.1 Общие положения
В этом разделе используются деловые сценарии для иллюстрации основных различий между закрытыми,
открытыми и контрактными средами. В Таблицах 1—3 описаны типовые сценарии, примеры требований
безопасности и связанные с ними операции PKI, выполняемые в случае ее использования.
5.3.2 Иллюстрация применения сертификата в закрытой среде
В этом разделе описаны некоторые сценарии, где финансовое учреждение может использовать PKI
для внутренних целей и для поддержки своих услуг и связей, внутренних и со своими заказчиками.

Рисунок 1 — Две организации в закрытой среде

1)
Организация, придерживающаяся доверительной услуги, может действовать как зависимая сторона или
подписчик для сертификатов от себя или от имени других субъектов сертификатов. В этом случае, зависимые
стороны или подписчики могут быть различными организациями, связанными деловыми отношениями, которые
здесь не рассматриваются.
12 © ISO 2006 — Все права сохраняются

Таблица 1 — Сценарии применения сертификата в закрытой среде
Типовые сценарии Примерные требования PKI Операции
• Аутентификация • Отправитель создает цифровую
отправителя для получателя. подпись.
Финансовое учреждение (FI)
посылает e-mail потребителю
• Целостность сообщения для • Получатель проверяет
1 (например, извещение об
отправителя и получателя. сертификат отправителя.
изменении тарифной ставки
• Получатель подтверждает
депозита).
цифровую подпись.
• Аутентификация • Получатель проверяет
отправителя для получателя. сертификат отправителя.
• Целостность сообщения для • Отправитель создает цифровую
отправителя и получателя. подпись.
• Получатель подтверждает
цифровую подпись.
Обмен личными электронными
2 сообщениями между
• Защита • Отправитель берет сертификат
сотрудниками внутри сети FI.
конфиденциальности получателя из директории.
содержания сообщений.
• Отправитель шифрует сообщение
открытым ключом получателя.
• Получатель расшифровывает
сообщение своим секретным
ключом.
• Взаимная аутентификация • Обеспечение
служащего FI и сервера идентификационными
Коммивояжеры с портативными
служащим. сертификатами служащих.
компьютерами FI должны
• Защита • Обеспечение идентификационным
обмениваться информацией о
конфиденциальности сертификатом сервера.
потребителях и продажах с
данных.
центральными системами
• Вызвать шифрование SSL.
поддержки.
• Вызвать шифрование SSL.
• Доказательство того, что • FI цифровым способом
Внутреннее сетевое
загружаемое в устройство подписывает прикладные
распределение программного
программное обеспечение программы.
обеспечения внешних устройств
приходит из аутентичного
4 • Получатель подтверждает
FI (например, программное
источника.
цифровую подпись.
обеспечение кассовых
аппаратов). • Получатель проверяет
сертификат FI.
• Взаимная аутентификация • Потребитель устанавливает свою
клиента (потребителя) идентичность службе, используя
Потребитель использует
программным обеспечением клиентский сертификат.
удаленную банковскую службу, в
FI и сервера программным
• Сервер устанавливает свою
5 которой применение сервера и
обеспечением потребителя.
идентичность, используя
визуализатора обеспечивается
• Защита сертификат сервера.
FI.
конфиденциальности данных
• Вызвать шифрование SSL.
потребителя.
5.3.3 Иллюстрация применения сертификата в контрактной среде
Здесь описывается финансовое учреждение, использующее PKI для поддержки операций со своими
клиентами в рамках системы или при заключении контракта между сторонами. Оно обеспечит своим
клиентам либо услугу по выпуску сертификатов, либо услугу по подтверждению сертификатов, либо
обе эти услуги.
Рисунок 2 — Четыре организации в контрактной среде
Таблица 2 — Сценарии применения сертификата в контрактной среде
Типовой сценарий Примерные требования Операции PKI
• Аутентификация • Получатель проверяет
отправителя для получателя. сертификат отправителя
• Целостность сообщения. • Клиент проверяет цифровую
подпись.
• Защита
Служащий FI посылает e-mail по • Отправитель берет сертификат
конфиденциальности
получателя из директории.
Интернету клиенту,
содержания сообщения.
использующему другой TSP.
• Отправитель шифрует сообщение
открытым ключом получателя.
• Получатель расшифровывает
сообщение своим секретным
ключом.
• Клиент санкционирует заказ • Покупатель подписывает
на покупку. цифровой подписью заказ,
используя сертификат,
• Аутентификация клиента
демонстрирующий полномочия.
продавцом.
Клиент представляет заказ на
• Получатель проверяет
покупку продавцу. • Целостность операции

покупки. достоверность сертификата
отправителя.
• Продавец проверяет подпись.
Клиент получает счет-фактуру от • Аутентификация сообщения. • Проверка цифровой подписи и
продавца.
проверка сертификата.
• Строгое взаимное • Клиент проверяет срок действия
установление идентичности. сертификата сервера FI.
• Целостность сообщения. • FI проверяет достоверность
сертификата клиента.
• Конфиденциальность.
• FI подтверждает цифровую
подпись.
Клиент использует электронную
почту банка для того, чтобы
• Отправитель берет сертификат
послать инструкции о крупном
получателя из директории.
платеже в FI.
• Отправитель зашифровывает
сообщение открытым ключом
получателя.
• Получатель расшифровывает
сообщение своим секретным
ключом.
14 © ISO 2006 — Все права сохраняются

Таблица 2 (продолжение)
Типовой сценарий Примерные требования Операции PKI
• Аутентиф
...