ISO/TS 17090-3:2002

TECHNICAL ISO/TS
SPECIFICATION 17090-3
First edition
2002-10-15
Health informatics — Public key
infrastructure —
Part 3:
Policy management of certification
authority
Informatique de santé — Infrastructure de clé publique —
Partie 3: Gestion politique d'autorité de certification

Reference number
©
ISO 2002
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 2002
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 copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2002 – All rights reserved

Contents Page
Foreword . iv
Introduction. v
1 Scope. 1
2 Normative references. 1
3 Terms and definitions. 1
4 Abbreviations . 2
5 Requirements for PKI policy management in a healthcare context . 2
5.1 General . 2
5.2 Need for a high level of assurance. 2
5.3 Need for a high level of infrastructure availability. 2
5.4 Need for a high level of trust. 3
5.5 Need for Internet compatibility . 3
5.6 Need to facilitate evaluation and comparison of CPs . 3
6 Structure of healthcare CPs and healthcare CPSs. 3
6.1 General requirements for CPs . 3
6.2 General requirements for CPSs. 4
6.3 Relationship between a CP and a CPS . 4
6.4 Applicability . 4
7 Minimum requirements for a healthcare PKI CP. 4
7.1 General requirements . 4
7.2 CA-RA requirements. 4
7.3 Identification and authentication. 14
7.4 Operational requirements. 17
7.5 Physical, procedural and personnel security controls . 21
7.6 Technical security controls. 21
7.7 Certificate and CRL profiles. 25
7.8 Specific administration. 25
8 Model PKI disclosure statement. 26
8.1 Introduction . 26
8.2 Structure of PKI disclosure statement. 26
Bibliography. 28

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 3.
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.
In other circumstances, particularly when there is an urgent market requirement for such documents, a technical
committee may decide to publish other types of normative document:
 an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in an
ISO working group and is accepted for publication if it is approved by more than 50 % of the members of the
parent committee casting a vote;
 an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting a
vote.
An ISO/PAS or ISO/TS is reviewed after three years with a view to deciding whether it should be confirmed for a
further three years, revised to become an International Standard, or withdrawn. In the case of a confirmed ISO/PAS
or ISO/TS, it is reviewed again after six years at which time it has to be either transposed into an International
Standard or withdrawn.
Attention is drawn to the possibility that some of the elements of this part of ISO/TS 17090 may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 17090-3 was prepared by Technical Committee ISO/TC 215, Health informatics.
ISO/TS 17090 consists of the following parts, under the general title Health informatics — Public key infrastructure:
 Part 1: Framework and overview
 Part 2: Certificate profile
 Part 3: Policy management of certification authority

iv © ISO 2002 – All rights reserved

Introduction
The healthcare industry is faced with the challenge of reducing costs by moving from paper-based processes to
automated electronic processes. New models of healthcare delivery are emphasizing the need for patient
information to be shared among a growing number of specialist healthcare providers and across traditional
organizational boundaries.
Healthcare information concerning individual citizens is commonly interchanged by means of electronic mail,
remote database access, electronic data interchange and other applications. The Internet provides a highly cost-
effective and accessible means of interchanging information, but is also an insecure vehicle that demands
additional measures be taken to maintain the privacy and confidentiality of information. Threats to the security of
health information through unauthorized access (either inadvertent or deliberate) are increasing. It is essential to
have available to the healthcare system reliable information security services that minimize the risk of unauthorized
access.
How does the healthcare industry provide appropriate protection for the data conveyed across the Internet in a
practical, cost-effective way? Public key infrastructure (PKI) technology seeks to address this challenge.
PKI is a blend of technology, policy and administrative processes that enable the exchange of sensitive data in an
unsecured environment by the use of “public key cryptography” to protect information in transit and “certificates” to
confirm the identity of a person or entity. In healthcare environments, PKI uses authentication, encipherment and
digital signatures to facilitate confidential access to, and movement of, individual health records to meet both
clinical and administrative needs. The services offered by a PKI (including encipherment, information integrity and
digital signatures) are able to address many of these security issues. This is especially the case if PKI is used in
conjunction with an accredited information security standard. Many individual organizations around the world have
started to apply PKI for this purpose.
Interoperability of PKI technology and supporting policies, procedures and practices is of fundamental importance if
information is to be exchanged between organizations and between jurisdictions in support of healthcare
applications (for example between a hospital and a community physician working with the same patient).
Achieving interoperability between different PKI schemes requires the establishment of a framework of trust, under
which parties responsible for protecting an individual’s information rights may rely on the policies and practices
and, by extension, the validity of digital certificates issued by other established authorities.
Many countries are adopting PKIs to support secure communications within their national boundaries.
Inconsistencies will arise in policies and procedures between the certification authorities (CAs) and registration
authorities (RAs) of different countries if PKI standards development activity is restricted to within national
boundaries.
PKI technology is still rapidly evolving in certain aspects that are not specific to healthcare. Important
standardization efforts and, in some cases, supporting legislation are ongoing. On the other hand, healthcare
providers in many countries are already using or planning to use PKI. This Technical Specification seeks to
address the need for guidance of these rapid international developments.
This three-part document is being issued in the Technical Specification series of publications (according to the
ISO/IEC Directives, Part 1, 3.1.1.1) as a prospective standard for the use of PKI in the field of healthcare because
there is an urgent need for guidance on how standards in this field should be used to meet an identified need. This
document is not to be regarded as an International Standard. It is proposed for provisional application so that
information and experience of its use in practice may be gathered. ISO/TC 215 intends to revise it into a full
International Standard after a three-year period.
This Technical Specification describes the common technical, operational and policy requirements that need to be
addressed to enable PKI to be used in protecting the exchange of healthcare information within a single domain,
between domains and across jurisdictional boundaries. Its purpose is to create a platform for global interoperability.
It specifically supports PKI enabled communication across borders, but could also provide guidance for the
establishment of healthcare PKIs nationally or regionally. The Internet is increasingly used as the vehicle of choice
to support the movement of healthcare data between healthcare organizations and is the only realistic choice for
cross-border communication in this sector.
This Technical Specification should be approached as a whole, with the three parts all making a contribution to
defining how PKIs can be used to provide security services in the health industry, including authentication,
confidentiality, data integrity and the technical capacity to support the quality of digital signature.
ISO/TS 17090-1 defines the basic concepts of a healthcare public key infrastructure (PKI) and provides a scheme
of interoperability requirements to establish a PKI enabled secure communication of health information.
ISO/TS 17090-2 provides healthcare specific profiles of digital certificates based on the International Standard
X.509 and the profile of this specified in IETF/RFC 2459 for different types of certificates.
ISO/TS 17090-3 deals with management issues involved in implementing and operating a healthcare PKI. It
defines a structure and minimum requirements for certificate policies (CPs) and a structure for associated
certification practice statements. This part is based on the recommendations of the IETF/RFC 2527 Internet X.509
Public Key Infrastructure Certificate Policy and Certification Practices Framework and identifies the principles
needed in a healthcare security policy for cross border communication. It also defines the minimum levels of
security required, concentrating on the aspects unique to healthcare.
Comments on the content of this document, as well as comments, suggestions and information on the application
of these technical specifications may be forwarded to the ISO/TC 215 secretariat: tsandler@astm.org and the WG4
secretariat w4sec215@medis.or.jp.
vi © ISO 2002 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 17090-3:2002(E)

Health informatics — Public key infrastructure —
Part 3:
Policy management of certification authority
1 Scope
This part of ISO/TS 17090 gives guidelines for certificate management issues involved in implementing and
operating a healthcare public key infrastructure (PKI). It specifies a structure and minimum requirements for
certificate policies, as well as a structure for associated certification practice statements.
This part of ISO/TS 17090 also identifies the principles needed in a healthcare security policy for cross-border
communication and defines the minimum levels of security required, concentrating on aspects unique to
healthcare.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/TS 17090. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this part of ISO/TS 17090 are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO/TS 17090-1:2002, Health informatics — Public key infrastructure — Part 1: Framework and overview
ISO/TS 17090-2:2002, Health informatics — Public key infrastructure — Part 2: Certificate profile
ISO/IEC 17799:2000, Information technology — Code of practice for information security management
IETF/RFC 2511, Internet X.509 Certificate Request Message Format
IETF/RFC 2527, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
U.S. government standard FIPS-140-1, level 1 and level 2
3 Terms and definitions
For the purposes of this part of ISO/TS 17090, the terms and definitions given in ISO/TS 17090-1:2002 apply.
4 Abbreviations
AA attribute authority
CA certification authority
CP certificate policy
CPS certification practice statement
CRL certificate revocation list
OID object identifier
PKC public key certificate
PKI public key infrastructure
RA registration authority
TTP trusted third party
5 Requirements for PKI policy management in a healthcare context
5.1 General
A healthcare PKI shall meet the following objectives in order to be effective in securing the communication of
personal health information:
 the reliable and secure binding of unique and distinguished names to individuals, organizations, applications
and devices that participate in the electronic exchange of personal health information;
 the reliable and secure binding of professional roles in healthcare to individuals, organizations and applications
that participate in the electronic exchange of personal health information, insofar as those roles may used as
the basis of role-based access control to such health information;
 (optionally) the reliable and secure binding of attributes to individuals, organizations, applications and devices
that participate in the electronic exchange of personal health information, insofar as those attributes may
further the secure communication of health information.
The above objectives shall be accomplished in a manner that maintains the trust of all who rely upon the integrity
and confidentiality of the personal health information that is securely communicated by means of a healthcare PKI.
To do this, each CA in a healthcare PKI shall operate according to an explicit set of publicly stated policies that
promote the above objectives.
5.2 Need for a high level of assurance
Security services required for health applications are specified in clause 6 of ISO/TS 17090-1:2002. For each of
these security services (authentication, integrity, confidentiality, digital signature, authorization, access control), a
high level of assurance is required.
5.3 Need for a high level of infrastructure availability
Emergency healthcare is a round-the-clock endeavour and the ability to obtain certificates, revoke certificates and
check revocation status is in no way bound by the normal working hours of most businesses. Unlike e-commerce,
2 © ISO 2002 – All rights reserved

healthcare imposes high availability requirements on any PKI that will be relied upon to secure the communication
of personal health information.
5.4 Need for a high level of trust
Unlike electronic commerce (where a vendor and a customer are often the only parties to an electronic transaction
and are reliant upon its security and integrity), healthcare applications that store or transmit personal health
information may implicitly require the trust of the patients whose information is being exchanged, as well as that of
the general public. It is unlikely that either healthcare providers or patients will cooperate in the electronic exchange
of personal health information if such exchanges are believed to be insecure.
5.5 Need for Internet compatibility
As the purpose of this Technical Specification is to define the essential elements of a healthcare PKI to support the
secure transmission of healthcare information across national boundaries, it is based as much as possible upon
Internet standards so as to effectively span those boundaries.
5.6 Need to facilitate evaluation and comparison of CPs
Approaches for using PKI to facilitate the secure exchange of health information across national boundaries are
discussed in 9.2 of ISO/TS 17090-1:2002. These approaches (such as cross-recognition and cross-certification)
are greatly facilitated if healthcare PKI CPs follow a consistent format so that comparisons may be readily drawn
between the provisions of one CP and another.
Healthcare CPs also constitute a basis for accreditation of CAs (a CA being accredited to support one or more CPs
which it proposes to implement). While accreditation criteria are beyond the scope of this part of ISO/TS 17090, the
entire process of accreditation of healthcare CAs is expedited by the consistency of format and the minimum
standards which this Technical Specification promotes.
6 Structure of healthcare CPs and healthcare CPSs
6.1 General requirements for CPs
When a CA issues a certificate, it provides a statement to a relying party that a particular public key is bound to a
particular certificate holder. Different certificates are issued following different practices and procedures, and may
be suitable for different applications and/or purposes.
PKI certificates contain a registered CP OID, which identifies the CP under which the certificate was issued, and
may be used to decide whether or not a certificate is trusted for a particular purpose. The registration process
follows the procedures specified in ISO/IEC and ITU standards. The party that registers the OID also publishes the
CP for examination by certificate holders and relying parties.
Because of the importance of a CP in establishing trust in a PKC, it is fundamental that the CP be understood and
consulted not only by certificate holders but by any relying party. Certificate holders and relying parties shall
therefore have ready and reliable access to the CP under which a certificate was issued.
The following requirements apply to all CPs specified in accordance with this part of ISO/TS 17090.
a) Each PKI certificate issued in accordance with this part of ISO/TS 17090 shall contain a registered CP OID,
which identifies the CP under which the certificate was issued.
b) The structure of CPs shall be in accordance with IETF/RFC 2527.
c) CPs shall be accessible to certificate holders and relying parties.
While CP documents are essential for describing and governing CPs and practices, many PKI certificate holders,
especially consumers, find these detailed documents difficult to understand. These certificate holders and other
relying parties may benefit from access to a concise statement of the elements of a CP that require emphasis and
disclosure and a model PKI disclosure statement is given in clause 8 for this purpose.
6.2 General requirements for CPSs
A CPS is a comprehensive description of such details as the precise implementation of service offerings and
detailed procedures of certificate life-cycle management and will generally be more detailed than the associated
CP.
The following requirements apply to all CPSs specified in accordance with this part of ISO/TS 17090.
a) CPSs shall be in accordance with IETF/RFC 2527.
b) A CA with a single CPS may support multiple CPs (used for different application purposes and/or by different
groups of relying parties).
c) A number of CAs with non-identical CPSs may support the same CP.
d) A CA may choose not to make its CPS accessible to certificate holders or relying parties.
6.3 Relationship between a CP and a CPS
A CP states what assurance can be placed in a certificate (including restrictions on certificate use and limitations
on liability). A CPS states how a CA establishes that assurance. A CP may apply more broadly than to just a single
organization, whereas a CPS applies only to a single CA. CPs best serve as the vehicle on which to base common
interoperability standards and common assurance criteria industry-wide (or possibly more global). A detailed CPS
alone does not form a suitable basis for interoperability between CAs operated by different organizations.
6.4 Applicability
This part of ISO/TS 17090 applies to CPs and CPSs that are used for the purpose of issuing healthcare certificates
as specified in clause 4 of ISO/TS 17090-2:2002.
7 Minimum requirements for a healthcare PKI CP
7.1 General requirements
A CP shall meet all the following requirements in order to comply with this part of ISO/TS 17090.
The numbers in brackets beneath the headings in clause 7 indicate the corresponding section in IETF/RFC 2527.
7.2 CA-RA requirements
7.2.1 Obligations
(2.1)
7.2.1.1 CA obligations
(2.1.1)
7.2.1.1.1 General
The CA is responsible for all aspects of the issuance and management of a certificate, including control over the
registration process, verification of information contained in a certificate, the certificate manufacture, publication,
4 © ISO 2002 – All rights reserved

revocation, suspension and renewal. The CA is responsible for ensuring that all aspects of the CA services and
operations are performed in accordance with the requirements, representations and warrantees of this CP and with
the CA’s CPS.
A CA within a healthcare PKI shall have policies and procedures available for the services they provide. They shall
cover:
 procedures for registering potential certificate holders prior to certificate issuance, including, where applicable,
the certificate holder’s role in accordance with clause 6 of ISO/TS 17090-2:2002;
 procedures for authenticating the identity of potential certificate holders prior to certificate issuance;
 procedures to maintain the privacy of any personal information held about the people to whom certificates are
given;
 procedures for distribution of certificates to certificate holders and to directories;
 procedures for accepting information about possible private key compromise;
 procedures for distribution of certificate revocation lists (frequency of issue, and how and where to publish
them);
 other key management issues, including key size, key generation process, certificate lifespan, rekeying, etc.;
 procedures for cross-certifying with other CAs;
 security controls and auditing.
In order to perform these functions, each CA within the infrastructure will need to provide some basic services to its
certificate holders and relying parties. These CA services are listed below.
7.2.1.1.2 Notification of certificate issuance, suspension and revocation
An issuing CA shall notify each certificate holder when a certificate bearing the certificate holder’s distinguished
name is issued.
An issuing CA shall notify any certificate holder when a certificate bearing the certificate holder’s distinguished
name is revoked or suspended (notification shall be made to the responsible individual or organization in the case
of device or application certificates).
An issuing CA shall make CRLs available to relying parties in accordance with 7.4 of this part of ISO/TS 17090.
7.2.1.1.3 Accuracy of CA representations
When an issuing CA publishes a certificate, it certifies that it has issued a certificate to a certificate holder and that
the information stated in the certificate was verified in accordance with the CA’s CP. Publication of the certificate in
a repository to which the certificate holder has access shall constitute notice of such verification.
A CA shall provide to each certificate holder notice of the certificate holder’s rights and obligations under this CP.
Such notice may be in the form of a certificate holder agreement and shall include a description of the permitted
uses of certificates issued under this CP; the certificate holder’s obligations concerning key protection and
procedures for communication between the certificate holder and the CA or LRA, including communication of
changes in service delivery or changes to this policy. A CA shall notify certificate holders as to procedures for
dealing with suspected key compromise, certificate or key renewal, service cancellation and dispute resolution.
7.2.1.1.4 Time between certificate request and issuance
It is recommended that the CA state a maximum period of time that a certificate holder has to complete the key
activation process after the generation of the key activation material.
7.2.1.1.5 Certificate revocation and renewal
The issuing CA shall ensure that any procedures for the expiration, revocation and renewal of a certificate shall
conform to the relevant provisions of this CP. It is recommended that the address of the CRL distribution points be
defined in the certificate in accordance with 7.2.8 of ISO/TS 17090-2:2002.
7.2.1.1.6 Protection of private keys
A CA shall ensure that the private keys and activation data that it holds or stores are protected in accordance with
7.6.2, 7.6.3 and 7.6.4 of this part of ISO/TS 17090.
A CA shall ensure that any private decipherment keys of a certificate holder that it has backed up or archived are
protected in accordance with 7.6.2 of this part of ISO/TS 17090. The CA shall not disclose private decipherment
keys to any other party without the prior consent of the certificate holder, unless required to do so by law. Despite
the foregoing, CA’s may offer a private key backup service for the purposes of data recovery of encrypted data. In
such a case, because a non-regulated health professional or a supporting organization employee receives a
certificate in order to conduct the business of his/her employer, the CA may, for the purposes of data recovery,
disclose private decipherment keys to the employer of a non-regulated health professional or a supporting
organization employee, where such arrangements have been agreed to prior to certificate issuance.
7.2.1.1.7 Restrictions on CA’s private key use
The CA shall ensure that its certificate signing private key is used only to sign certificates and certificate revocation
lists. The CA shall ensure that private keys issued to its personnel to access and operate CA applications are used
only for such purposes.
7.2.1.2 RA obligations
(2.1.2)
7.2.1.2.1 General
The CA may delegate identification and authentication functions, for which it is responsible, to an RA. The prime
function that a healthcare organization RA performs is verification of a certificate holder’s identity and healthcare
role during initial registration. The RA shall follow the same set of rules and methods of authentication as the CA
uses itself. RAs may be separately accredited, independently of a particular CA.
In order to be assured of the authenticity and integrity of a certificate and public keys contained within it, the
certificate holders shall have their certificates created by a trusted source. As RAs perform authentication functions
for CAs, they shall be trusted to follow the CA’s certificate holder authentication policies and to pass the correct
certificate holder information to the CA. Similarly, the RAs shall be trusted to pass certificate revocation requests to
a CA in an accurate and timely fashion.
It is recommended that RAs be individually accountable for actions performed on behalf of the CA. The RA shall:
 ensure that its signing private key is used only to sign certificate requests, if the RA is performing its duties
on-line;
 certify to the CA that it has authenticated the identity of the certificate holder;
 securely transmit and store certificate application information and records of registration;
 initiate a revocation request (where applicable) according to 7.3.4.2 of this part of ISO/TS 17090.
6 © ISO 2002 – All rights reserved

7.2.1.2.2 Certification revocation request
RAs can be instrumental in the handling of certificate revocation requests. In some health PKI implementations,
RAs may be used to initiate or authenticate certificate revocation requests. Where applicable, they shall forward
authenticated requests to the appropriate CA. The RA itself may initiate a revocation request (for example, if a
regulated health professional is suspended for misconduct and the RA is a health profession registration board or
licensing board). In either event, it is then the responsibility of the RA to authenticate the report. If, by applying the
same criteria as the CA would have used, the RA is satisfied that the report is authentic, the RA shall send a
signed message to the CA containing certificate identification information and, optionally, the stated reason for
revoking that certificate.
7.2.1.2.3 Auditing
To provide assurance of the trusted nature of RAs and to provide information to personnel conducting internal
audits, the actions of each RA shall be auditable. Audit records and audit trails shall be generated for events in
accordance with the relevant policy.
7.2.1.2.4 Archiving
It may be important in the future to know how or why a certificate was produced. The RAs within healthcare PKIs or
their CAs shall archive such events as requests for the creation or revocation of certificates.
7.2.1.3 Certificate holder obligations
(2.1.3)
A certificate holder in a healthcare PKI shall:
 ensure the accuracy of representations in the certificate application and, by accepting the certificate,
acknowledge that all information included in the certificate is true;
 protect their private keys and key tokens (if applicable) and take all reasonable measures to prevent their loss,
disclosure, modification or unauthorized use;
 make every effort to prevent the loss, disclosure or unauthorized use of his/her private key;
 immediately notify the CA and/or RA of any actual or suspected loss, disclosure, or other compromise of
his/her private key;
 notify the RA and/or CA of any change in certificate information, role or status in the healthcare organization;
 read either the CP or a PKI disclosure document that clearly sets out in plain language the responsibilities of
the certificate holder;
 use key pairs in accordance with the CP;
 formally agree to these obligations by signing a certificate holder agreement.
It is recommended that a certificate holder in a healthcare PKI also attest to receipt of security training appropriate
to the health information functions for which the certificate will be used.
7.2.1.4 Relying party obligations
(2.1.4)
A relying party to healthcare PKIs has a right to rely on a healthcare certificate only if:
 the purpose for which the certificate is used was appropriate under this policy;
 the reliance is reasonable and in good faith in light of all the circumstances known to the relying party at the
time of reliance;
 the relying party confirmed the current validity of the certificate by checking that the certificate was not revoked
or suspended;
 the relying party confirmed the current validity of digital signatures, where applicable;
 applicable limitations of liability and warranties are acknowledged.
7.2.1.5 Repository obligations
(2.1.5)
Certificates and CRLs shall be available to relying parties in accordance with the requirements of 7.4.4.9 of this
part of ISO/TS 17090.
7.2.2 Liability
(2.2)
7.2.2.1 General
The extent of the liability in the situations listed in 7.2.2.2 below is part of an overall policy under which the CAs
operate in the healthcare domains of their respective countries. These domains are, in turn, subject to government
regulations and international agreements. Requirements follow for CA liability and RA liability. If used, attribute
authority liability shall either be subsumed by the former liability or explicitly delineated.
7.2.2.2 CA liability
(2.2.1)
The liability of the CA in a healthcare PKI may be limited to acts of negligence on the part of the CA as follows.
a) A CA may assume no liability associated with the loss by the certificate holder of the private keys.
b) A CA may assume no liability associated with certificate holder generated keys, unless they were generated in
full accordance with the guidelines of a healthcare PKI.
c) A CA may assume no liability associated with the compromise of the private keys it produces, unless it can be
proved that the keys were compromised at the CA or that documented policies and procedures were not
followed during the key generation process, resulting in a private key that is more susceptible to compromise
or the actual revelation of the private key.
d) A CA may assume no liability associated with forged signatures, unless the forgery resulted from the
documented policies and procedures of a healthcare PKI not being followed, or could be shown to permit the
forgery.
e) A CA may limit its liability to the extent of the direct damages sustained by the relying party and caused by the
failure of the CA to comply with the terms of this policy.
The liability of the CA in a healthcare PKI shall not be limited in regard to the following.
a) A CA shall be liable for the compromise of a private key during the key distribution process.
8 © ISO 2002 – All rights reserved

b) A CA shall be liable for the wrongful binding of an individual’s identity with an associated digital signature and
other accreditation information, unless it can be proved that the documented policies and procedures for
identification and authentication were followed. This liability shall extend to circumstances where a CA knew or
suspected, or should have known or suspected, that the binding might be wrongful.
c) A CA shall be liable for not revoking certificates according to its revocation policy.
d) A CA shall be liable for revoking a certificate for a reason not specified in its revocation policy.
7.2.2.3 RA liability
(2.2.2)
The liability of an RA in a healthcare PKI may be limited to acts of negligence on the part of the RA.
The liability of an RA in a healthcare PKI shall not be limited in regard to the following.
a) An RA is liable for the wrongful binding of an individual’s identity and other accreditation information with an
associated digital signature, unless it can be proved that the documented policies and procedures for
identification and authentication were followed. This liability shall extend to circumstances where an RA knew
or suspected, or should have known or suspected, that the subject information on which the binding was made
might be wrongful.
b) An RA is liable for not revoking certificates according to its revocation policy.
c) A RA is liable for revoking a certificate for a reason not specified in its revocation policy.
7.2.3 Financial responsibility
(2.3)
7.2.3.1 Indemnification by relying parties
Indemnification by relying parties shall be in accordance with 2.3.1 of IETF/RFC 2527.
7.2.3.2 Fiduciary relationships
Fiduciary relationships shall be in accordance with 2.3.2 of IETF/RFC 2527.
7.2.3.3 Administrative processes
Administrative processes shall be in accordance with 2.3.3 of IETF/RFC 2527.
7.2.4 Interpretation and enforcement
(2.4)
7.2.4.1 Governing law
(2.4.1)
Healthcare PKIs shall comply with local and international legal requirements in accordance with ISO 17799-1:2000
(or its equivalent) or approved accreditation or licensing criteria.
7.2.4.2 Severability, survival, merger, notice
(2.4.2)
The healthcare CP shall stipulate that, should it be determined that one section of the CP is incorrect or invalid,
other sections shall remain in effect until the policy is updated.
If the CA or RA merges with another organization, the new organization remains liable for the course of the original
agreement.
7.2.4.3 Dispute resolution procedures
Dispute resolution procedures shall be in accordance with 2.4.3 of IETF/RFC 2527.
7.2.5 Fees
(2.5)
Fees shall be in accordance with 2.5 of IETF/RFC 2527.
7.2.6 Publication and repository
(2.6)
7.2.6.1 Publication of CA information
(2.6.1)
All CAs within healthcare PKIs shall make available to their certificate holders and relying parties:
 the URL of an available web site maintained by, or on behalf of, the CA, containing its certificate policies;
 each certificate issued under this policy;
 the current status of each certificate issued under this policy;
 the accreditation or licensing criteria under which the CA operates, where such accreditation or licensing is
applicable in the jurisdiction in which the CA operates.
7.2.6.2 Frequency of publication
(2.6.2)
CAs shall publish information, whenever such information has been modified. Information on certificate revocation
shall be in accordance with 7.4.4 of this part of ISO/TS 17090.
7.2.6.3 Access controls
(2.6.3)
Published information such as policies, practices, certificates and the current status of such certificates shall be
read-only.
7.2.6.4 Repositories
(2.6.4)
Information maintained about certificate holders in RA or CA repositories shall be:
 kept current and up to date (within one day of changes being verified and earlier depending on circumstances);
10 © ISO 2002 – All rights reserved

 be managed in accordance with ISO 17799:2000 (or its equivalent) or approved accreditation or licensing
criteria.
7.2.7 Compliance audit
(2.7)
Compliance audit is an essential component of many PKI interoperability models (see, for example, 9.2.4 of
ISO/TS 17090-1).
7.2.7.1 Frequency of CA compliance audit
(2.7.1)
A CA issuing certificates pursuant to a healthcare PKI policy shall establish to the satisfaction of any relying party
that it fully complies with the requirements of this policy. A CA compliance audit shall be carried out by a qualified
independent third party within intervals that are no more than one year apart.
7.2.7.2 Identity/Qualifications of auditor
(2.7.2)
The auditor shall be a qualified information systems auditor to the extent necessary for admission to the relevant
professional body (such as accreditation to ISO 9000). The auditor shall possess significant PKI experience. Where
a formal accreditation body exists, the auditor shall meet that body’s requirements.
7.2.7.3 Auditor's relationship to audited party
(2.7.3)
The auditor shall be comple
...