ISO 17090-3:2008

INTERNATIONAL ISO
STANDARD 17090-3
First edition
2008-02-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 2008
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 2008
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.org
Web www.iso.org
Published in Switzerland
ii © ISO 2008 – 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 digital certificate 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 .3
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. 5
6.4 Applicability. 5
7 Minimum requirements for a healthcare CP . 5
7.1 General requirements. 5
7.2 Publication and repository responsibilities. 5
7.3 Identification and authentication . 6
7.4 Certificate life-cycle operational requirements . 10
7.5 Physical controls . 19
7.6 Technical security controls . 20
7.7 Certificate, CRL and OCSP profiles . 25
7.8 Compliance audit. 25
7.9 Other business and legal matters . 27
8 Model PKI disclosure statement . 33
8.1 Introduction . 33
8.2 Structure of PKI disclosure statement . 33
Bibliography . 35

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 17090-3 was prepared by Technical Committee ISO/TC 215, Health informatics.
This first edition cancels and replaces the Technical Specification (ISO/TS 17090-3:2002), which has been
revised and brought to the status of International Standard.
ISO 17090 consists of the following parts, under the general title Health informatics — Public key
infrastructure:
⎯ Part 1: Overview of digital certificate services
⎯ Part 2: Certificate profile
⎯ Part 3: Policy management of certification authority
iv © ISO 2008 – 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 it 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) and digital certificate technology seek to address
this challenge.
The proper deployment of digital certificates requires 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, this technology 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 the deployment of digital certificates (including encipherment, information
integrity and digital signatures) are able to address many of these security issues. This is especially the case if
digital certificates are used in conjunction with an accredited information security standard. Many individual
organizations around the world have started to use digital certificates for this purpose.
Interoperability of digital certificate 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 digital certificate implementations 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 deploying digital certificates to support secure communications within their national
boundaries. Inconsistencies will arise in policies and procedures between the certification authorities (CAs)
and the registration authorities (RAs) of different countries if standards development activity is restricted to
within national boundaries.
Digital certificate technology is still 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 digital certificates. ISO 17090 seeks to
address the need for guidance of these rapid international developments.
ISO 17090 describes the common technical, operational and policy requirements that need to be addressed to
enable digital certificates 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 digital certificate-enabled communication across borders, but could
also provide guidance for the national or regional deployment of digital certificates in healthcare. 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.
ISO 17090 should be approached as a whole, with the three parts all making a contribution to defining how
digital certificates 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 17090-1 defines the basic concepts underlying the use of digital certificates in healthcare and provides a
scheme of interoperability requirements to establish digital certificate-enabled secure communication of health
information.
ISO 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 3280 for different types of certificates.
This part of ISO 17909 deals with management issues involved in implementing and using digital certificates
in healthcare. It defines a structure and minimum requirements for certificate policies (CPs) and a structure for
associated certification practice statements. This part of ISO 17090 is based on the recommendations of the
informational IETF/RFC 3647, 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 standards, may be forwarded to the ISO/TC 215 secretariat at adickerson@himss.org or
WG4 convenor, Ross Fraser, and WG4 secretariat at w4consec@medis.or.jp.

vi © ISO 2008 – All rights reserved

INTERNATIONAL STANDARD ISO 17090-3:2008(E)

Health informatics — Public key infrastructure —
Part 3:
Policy management of certification authority
1 Scope
This part of ISO 17090 gives guidelines for certificate management issues involved in deploying digital
certificates in healthcare. It specifies a structure and minimum requirements for certificate policies, as well as
a structure for associated certification practice statements.
This part of ISO 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 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 17090-1:2008, Health informatics — Public key infrastructure — Part 1: Overview of digital certificate
services
ISO 17090-2:2008, Health informatics — Public key infrastructure — Part 2: Certificate profile
ISO/IEC 27002, Information technology — Security techniques — Code of practice for information security
management
IETF/RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices
Framework
IETF/RFC 4211, Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17090-1 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 digital certificate policy management in a healthcare context
5.1 General
Deployment of digital certificates in healthcare 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 be 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 personal health information that is securely communicated by use of digital
certificates.
To do this, each CA issuing digital certificates for use in healthcare 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 17090-1:2008. For each of
these security services (authentication, integrity, confidentiality, digital signature, authorization, access control),
a high level of assurance is required.
2 © ISO 2008 – All rights reserved

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, healthcare imposes high availability requirements on any deployment of digital certificates 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 part of ISO 17090 is to define the essential elements of a healthcare digital certificate
deployment to support the secure transmission of healthcare information across national or regional
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 digital certificates to facilitate the secure exchange of health information across national
boundaries are discussed in 9.2 of ISO 17090-1:2008. These approaches (such as cross-recognition and
cross-certification) are greatly facilitated if healthcare 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 the 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 17090, the entire process of accreditation of healthcare CAs is expedited by the consistency of format
and the minimum standards which this part of ISO 17090 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.
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, 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 issuing digital certificates for healthcare use shall have policies and procedures available for the
services they provide. These policies and procedures shall cover:
⎯ registering potential certificate holders prior to certificate issuance, including, where applicable, the
certificate holder’s role in accordance with Clause 6 of ISO 17090-2:2008;
⎯ authenticating the identity of potential certificate holders prior to certificate issuance;
⎯ maintaining the privacy of any personal information held about the people to whom certificates are given;
⎯ distributing certificates to certificate holders and to directories;
⎯ accepting information about possible private key compromise;
⎯ distributing CRLs (frequency of issue, and how and where to publish them);
⎯ other key management issues, including key size, key generation process, certificate lifespan, re-keying,
etc.;
⎯ 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 in the CP.
Digital certificates contain one or more registered CP OIDs, which identify 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 OIDs 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 17090.
a) Each digital certificate issued in accordance with this part of ISO 17090 shall contain at least one
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 3647.
c) CPs shall be accessible to certificate holders and relying parties.
While CP and CPS documents are essential for describing and governing CPs and practices, many digital
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 17090.
a) CPSs shall be in accordance with IETF/RFC 3647.
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 or may choose
to make portions of its CPS available.
4 © ISO 2008 – All rights reserved

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 17090 applies to CPs and CPSs that are used for the purpose of issuing healthcare
certificates as specified in Clause 5 of ISO 17090-2:2008.
7 Minimum requirements for a healthcare CP
7.1 General requirements
A CP shall meet all the following requirements in order to comply with this part of ISO 17090.
The numbers in parentheses beneath the headings in this clause indicate the corresponding section in
IETF/RFC 3647.
7.2 Publication and repository responsibilities
7.2.1 Repositories
(2.1)
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);
⎯ be managed in accordance with ISO/IEC 27002 (or its equivalent) or approved accreditation or licensing
criteria.
7.2.2 Publication of certification information
(2.2)
All CAs issuing digital certificates for use in healthcare 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 or renewed 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.
An electronic copy of the CP document, digitally signed by an authorized representative of the CA, is to be
made available:
⎯ on a web site available to all relying parties or
⎯ via an electronic mail request.
As the CPS precisely details the implementation of a CA service as well as the procedures for key life-cycle
management and is more detailed than the CP, it contains information that may therefore need to remain
confidential to ensure the CA’s security.
7.2.3 Frequency of publication
(2.3)
CAs shall publish information, whenever such information has been modified.
7.2.4 Access controls on repositories
(2.4)
Published information such as policies, practices, certificates and the current status of such certificates shall
be read-only.
7.3 Identification and authentication
7.3.1 Initial registration
7.3.1.1 Types of name
(3.1.1)
The subject names used for certificates issued under this policy shall be in accordance with ISO 17090-2.
7.3.1.2 Need for names to be meaningful
(3.1.2)
The effective use of certificates requires that the relative distinguished names that appear on the certificate
can be understood and used by a relying party. Names used in these certificates shall identify the certificate
holder to which they are assigned in a meaningful way. See also 7.3.1.3.
In the case of certificate holders who are regulated health professionals, non-regulated health professionals,
sponsored healthcare providers, supporting organization employees or patients/consumers, the name should
match the name authenticated in 7.3.2.
7.3.1.3 Anonymity or pseudonymity
(3.1.3)
The need for names to be meaningful (see 7.3.1.2 above) does not preclude the use of pseudonyms in
certificates issued to patients/consumers.
6 © ISO 2008 – All rights reserved

7.3.1.4 Rules for interpreting various name forms
(3.1.4)
A CP shall have a name claim dispute resolution procedure to apply and a convention to be used in
interpreting name forms used in those situations where name claim disputes arise.
7.3.1.5 Uniqueness of names
(3.1.5)
The subject distinguished name listed in a certificate shall be unambiguous and unique to distinct certificate
holders of a CA.
Where necessary, the inclusion of the distinguished name attribute type “serial number” in the distinguished
entity (as described in IETF/RFC 3280) may be used to guarantee uniqueness. Where possible, it is
recommended that the serial number be meaningful (e.g. the license number of a regulated health
professional). See 7.3.1.2.
7.3.1.6 Recognition, authentication and role of trademarks
(3.1.6)
A CA shall not knowingly issue certificates containing trademarks that do not belong to the subject of the
certificate.
7.3.2 Initial identity validation
7.3.2.1 Method to prove possession of private key
(3.2.1)
In those cases where the CA does not generate the key pair, key holders shall be required to prove
possession of their private key [e.g. by the key holder submitting a Certificate Signing Request (CSR)]. Key
holders may also be periodically required to sign a challenge from the CA.
7.3.2.2 Authentication of identity of organizations
(3.2.2)
Healthcare organizations, supporting organizations, or persons acting on behalf of organizations or devices
shall present to the RA evidence of their existence and healthcare role by presenting documentation
appropriate to their country, state or provincial government. The CA, the RA and, where applicable, the AA
shall verify this information, as well as the authenticity of the requesting representative and the
representative’s authorization to act in the name of the organization.
7.3.2.3 Authentication of identity of individuals
(3.2.3)
Individuals, including regulated health professionals, non-regulated health professionals, sponsored
healthcare providers, supporting organization employees and patients/consumers shall authenticate their
identity to an RA prior to certificate issuance. This part of ISO 17090 recommends the same proof of identity
that would be necessary for such individuals to be issued a passport, or a procedure of equivalent rigour.
Regulated health professionals, in order that they authenticate their healthcare license, role and medical
speciality (if any), shall present to the RA proof of their professional credentials established by the
professional regulatory or accrediting body in their jurisdiction.
Non-regulated health professionals, in order that they establish their employment and authenticate their
healthcare role, shall present to the RA proof of sponsorship or employment from their sponsoring health
organizations or sponsoring (regulated) health professionals.
Sponsored healthcare providers, in order that they establish that they are active in their healthcare community
and in order that they authenticate their healthcare role, shall present to the RA proof of sponsorship from
their sponsoring health organizations or sponsoring (regulated) health professionals.
Supporting organization employees, in order that they establish their employment and authenticate their
healthcare role, shall present to the RA proof of employment by their supporting health organizations.
7.3.2.4 Non-verified subscriber information
(3.2.4)
Non-verified subscriber information shall be specified in accordance with 3.2.4 of IETF/RFC 3647.
7.3.2.5 Validation of authority
(3.2.5)
Validation of authority shall be specified in accordance with 3.2.5 of IETF/RFC 3647.
7.3.2.6 Criteria for interoperation
(3.2.6)
Criteria for interoperation shall be specified in accordance with 3.2.6 of IETF/RFC 3647 and ISO 17090-2.
7.3.3 Identification and authentication for re-keying requests
7.3.3.1 Identification and authentication for routine re-key
(3.3.1)
7.3.3.1.1 CA routine re-keying
Routine re-keying or re-issue of CA certificates shall be carried out based on the original documentation used
when the original record was created.
7.3.3.1.2 RA routine re-keying
Routine re-keying or re-issue of RA certificates shall be carried out based on the original documentation used
when the original record was created.
7.3.3.1.3 Certificate holder routine re-keying
Routine re-keying of certificate holder information shall be carried out by referring back to the original
documentation or records used when the original record was created, including reliance on a current valid
unexpired key.
If the original documentation has lapsed or been discarded, substitute documentation may be used.
8 © ISO 2008 – All rights reserved

7.3.3.2 Re-key after revocation
(3.3.2)
7.3.3.2.1 CA re-key after revocation
Re-keying of information after a certificate has been revoked shall require presentation again of the original
information originally used to accredit the CA.
7.3.3.2.2 RA re-key after revocation
Re-keying of information after a certificate has been revoked shall require presentation again of the original
information originally used to accredit the RA.
7.3.3.2.3 Certificate holder re-key after revocation
Routine re-keying of certificate holder information shall require either presentation of the original
documentation used when the original record was created or reference to the original records used. If the
original documentation has lapsed or been discarded, substitute documentation may be used.
7.3.4 Identification and authentication for revocation request
(3.4)
7.3.4.1 CA
A CA, when making a revocation request under a healthcare CP to another CA, shall:
⎯ identify the certificate;
⎯ state the reasons why the certificate should be revoked;
⎯ sign the request with its private key, encrypt the message and send it to the relevant domain CA.
7.3.4.2 RA
An RA, when making a revocation request to a CA for a digital certificate issued under a healthcare CP, shall:
⎯ identify the certificate that it is requesting to have revoked;
⎯ state the reasons why the certificate should be revoked;
⎯ sign the request with its private key, encrypt the message and send it to the relevant domain CA.
7.3.4.3 Certificate holder
A certificate holder of a digital certificate issued under a healthcare CP, when making a revocation request to
a CA, shall:
⎯ identify the certificate that the certificate holder is requesting to have revoked;
⎯ state the reasons why the certificate should be revoked;
⎯ securely send the revocation request to the relevant domain CA.
If the token containing the private key has been lost or stolen (and the certificate holder cannot therefore
initiate a digitally signed request for revocation) the revocation request shall be accompanied by equivalent
evidence of identity to that originally provided to obtain the certificate.
7.4 Certificate life-cycle operational requirements
7.4.1 Certificate application
7.4.1.1 Who can submit a certificate application
(4.1.1)
Criteria for who can submit a certificate application shall be specified in accordance with 4.1.1 of
IETF/RFC 3647.
7.4.1.2 Enrollment process and responsibilities
(4.1.2)
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, independent 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, revocation requests, and other
authenticated communications with certificate holders, 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) in accordance with 7.3.4.2.
A certificate holder in a healthcare deployment of digital certificates 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.
7.4.2 Certificate application processing
7.4.2.1 Performing identification and authentication functions
(4.2.1)
Criteria for performing identification and authentication functions shall be specified in accordance with 4.2.1 of
IETF/RFC 3647.
7.4.2.2 Approval or rejection of certificate applications
(4.2.2)
Criteria for approval or rejection of certificate applications shall be specified in accordance with 4.2.2 of
IETF/RFC 3647.
10 © ISO 2008 – All rights reserved

7.4.2.3 Time to process certificate applications
(4.2.3)
It is recommended that the CA state a maximum period of time by which a certificate holder has to complete
the key activation process after the initiation of the certificate issuance process.
7.4.3 Certificate issuance
7.4.3.1 CA actions during certificate issuance
(4.3.1)
Certificate re-key procedures shall be specified in accordance with 4.7 of IETF/RFC 3647.
7.4.3.2 Notifications to certificate holders by the CA of issuance of the certificate
(4.3.2)
An issuing CA shall notify each certificate holder when a certificate bearing the certificate holder’s
distinguished name is issued.
7.4.4 Certificate acceptance
7.4.4.1 Conduct constituting certificate acceptance
(4.4.1)
A certificate holder in a healthcare deployment of digital certificates shall:
⎯ read either the CP or a PKI disclosure document that clearly sets out in plain language the responsibilities
of the certificate holder;
⎯ formally agree to these obligations by signing a certificate holder agreement.
7.4.4.2 Publication of the certificate by the CA
(4.4.2)
See 7.2.2.
7.4.4.3 Notification of certificate issuance by the CA to other entities
(4.4.3)
Criteria for notification of certificate issuance by the CA to other entities shall be specified in accordance with
4.4.3 of IETF/RFC 3647.
7.4.5 Key pair and certificate usage
7.4.5.1 Certificate holder private key and certificate usage
(4.5.1)
A certificate holder in a healthcare deployment of digital certificates shall:
⎯ 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;
⎯ use key pairs in accordance with the CP.
It is recommended that a certificate holder of a healthcare digital certificate also attest to the receipt of security
training appropriate to the health information functions for which the certificate will be used.
7.4.5.2 Relying party public key and certificate usage
(4.5.2)
A relying party 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.4.6 Certificate renewal
(4.6)
The issuing CA shall ensure that any procedures for the renewal of a certificate shall conform to the relevant
provisions of this CP.
7.4.6.1 Circumstances for certificate renewal
(4.6.1)
Circumstances for certificate renewal shall be specified in accordance with 4.6.1 of IETF/RFC 3647.
7.4.6.2 Who may request renewal
(4.6.2)
Criteria for who may request renewal shall be specified in accordance with 4.6.2 of IETF/RFC 3647.
12 © ISO 2008 – All rights reserved

7.4.6.3 Processing certificate renewal requests
(4.6.3)
Criteria for processing certificate renewal requests shall be specified in accordance with 4.6.3 of
IETF/RFC 3647.
7.4.6.4 Notification to certificate holder of certificate renewal
(4.6.4)
An issuing CA shall notify each certificate holder when a certificate bearing the certificate holder’s
distinguished name is renewed.
7.4.6.5 Conduct constituting acceptance of a renewal certificate
(4.6.5)
Conduct constituting acceptance of a renewal certificate shall be in accordance with the provisions of 7.4.4.1.
7.4.6.6 Publication of the renewal certificate by the CA
(4.6.6)
See the provisions of 7.2.2.
7.4.6.7 Notification of certificate renewal by the CA to other entities
(4.6.7)
See the provisions of 7.4.4.3.
7.4.7 Certificate re-key
(4.7)
Certificate re-key procedures shall be in accordance with 7.3.3.
7.4.8 Certificate modification
7.4.8.1 Circumstances for certificate modification
(4.8.1)
The issuing CA shall modify a certificate:
⎯ if relevant subject information contained in the certificate is no longer accurate;
⎯ if a certificate holder’s organizational affiliation changes, e.g. a regulated health professional resigning
from a particular organization;
⎯ for any reason, upon request of a certificate holder or sponsor of a sponsored healthcare provider.
Certificate holders, RAs and sponsors have a duty to inform the CA if they become aware of inaccur
...