ISO/TS 17090-2:2002

Health informatics — Public key infrastructure — Part 2: Certificate profile

ISO/TS 17090-2 specifies the certificate profiles required to interchange healthcare information within a single organization, between different organizations and across jurisdictional boundaries. It details the use made of public key infrastructure (PKI) digital certificates in the health industry and focuses, in particular, on specific healthcare issues relating to certificate profiles.

Informatique de santé — Infrastructure de clé publique — Partie 2: Profil de certificat

General Information

• Status: Withdrawn
• Publication Date: 02-Oct-2002
• Withdrawal Date: 02-Oct-2002
• ICS: 35.240.80 - IT applications in health care technology
• Technical Committee: ISO/TC 215 - Health informatics
• Drafting Committee: ISO/TC 215/WG 4 - Security, Safety and Privacy
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 07-Feb-2008

Relations

• Revised: ISO 17090-2:2008 - Health informatics — Public key infrastructure — Part 2: Certificate profile
• Effective Date: 15-Apr-2008

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 17090-2
First edition
2002-10-15

Health informatics — Public key
infrastructure —
Part 2:
Certificate profile
Informatique de santé — Infrastructure de clé publique —
Partie 2: Profil de certificat




Reference number
ISO/TS 17090-2:2002(E)
©
ISO 2002

---------------------- Page: 1 ----------------------
ISO/TS 17090-2:2002(E)
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 [e-mail]
Web www.iso.ch
Printed in Switzerland

ii © ISO 2002 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/TS 17090-2:2002(E)
Contents Page
Foreword . iv
Introduction. v
1 Scope. 1
2 Normative references. 1
3 Terms and definitions. 1
4 Abbreviations . 2
5 Healthcare CPs . 2
5.1 Certificate types required for healthcare. 2
5.2 CA certificates . 2
5.3 Cross/Bridge certificates. 3
5.4 End entity certificates. 3
6 General certificate requirements . 6
6.1 Certificate compliance. 6
6.2 Common fields for each certificate type. 7
6.3 Specifications for common fields. 8
6.4 Requirements for each healthcare certificate type. 10
7 Use of certificate extensions . 13
7.1 Introduction . 13
7.2 General extensions . 13
7.3 Special subject directory attributes . 14
7.4 Qualified certificate statements extension. 16
7.5 Requirements for each health industry certificate type.16
Annex A (informative) Certificate profile examples . 18
Bibliography. 25

© ISO 2002 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/TS 17090-2:2002(E)
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-2 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
Annex A of this part of ISO/TS 17090 is for information only.
iv © ISO 2002 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/TS 17090-2:2002(E)
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.
© ISO 2002 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/TS 17090-2:2002(E)
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: [e-mail] and the WG4
secretariat [e-mail].
vi © ISO 2002 – All rights reserved

---------------------- Page: 6 ----------------------
TECHNICAL SPECIFICATION ISO/TS 17090-2:2002(E)

Health informatics — Public key infrastructure —
Part 2:
Certificate profile
1 Scope
This part of ISO/TS 17090 specifies the certificate profiles required to interchange healthcare information within a
single organization, between different organizations and across jurisdictional boundaries. It details the use made of
public key infrastructure (PKI) digital certificates in the health industry and focuses, in particular, on specific
healthcare issues relating to certificate profiles.
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-3:2002, Health informatics — Public key infrastructure — Part 3: Policy management of certification
authority
IETF/RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile
IETF/RFC 2527, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
IETF/RFC 3039, Internet X.509 Public Key Infrastructure Qualified Certificates Profile
INTERNET-DRAFT October 1999 4.1, X.509 Attribute Certificate
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.
© ISO 2002 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/TS 17090-2:2002(E)
4 Abbreviations
AA attribute authority
AC attribute certificate
CA certification authority
CP certificate policy
CPS certification practice statement
CRL certificate revocation list
PKC public key certificate
PKI public key infrastructure
RA registration authority
TTP trusted third party
5 Healthcare CPs
5.1 Certificate types required for healthcare
Identity certificates shall be issued to:
 individuals (regulated health professionals, non-regulated health professionals, sponsored healthcare
providers, supporting organization employees and patients/consumers);
 organizations (healthcare organizations and supporting organizations);
 devices;
 applications.
The roles of individuals and organizations are to be captured; either in the identity certificate itself (in a certificate
extension) or in an associated AC. The different kinds of certificates and the way they interrelate are shown in
Figure 1.
5.2 CA certificates
5.2.1 Root CA certificates
Root CA certificates are used when the subject of the certificate is itself a CA, they are self-signed and are used in
a healthcare PKI to issue certificates to relying parties, including subordinate CAs. The basic constraints field
indicates whether the certificate is a CA, as well as the maximum allowable depth of a certification path through
that CA.
5.2.2 Subordinate CA certificates
Subordinate CA certificates are issued for a CA that is in itself certified by another CA higher up in the hierarchy to
be able to issue certificates for either other CAs lower down the hierarchy or for end entities.

2 © ISO 2002 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/TS 17090-2:2002(E)

Figure 1 — Healthcare certificate types
5.3 Cross/Bridge certificates
In an Internet environment, it is not feasible to expect the health industry in cross border and jurisdictional
situations to trust a top level CA. Instead, “islands of trust” are to be provided in each health industry domain,
based on speciality, jurisdiction, setting or geography that trust a particular CA. Each central root CA for each
“island of trust” can then cross-certify another root. In these situations, a group of CAs may agree on a minimum
set of standards to be embodied in their policies and associated practice statements. When this occurs, a relying
party may accept a certificate from a CA outside its own domain. This could be particularly useful for organizations
such as state or provincial health authorities to enable the transfer of information across boundaries.
Cross/Bridge certificates are certificate types that cross-certify different CA domains. This supports the large-scale
deployment of public key applications, such as secure electronic mail and others required in the health industry.
5.4 End entity certificates
End entity certificates are issued to entities that may include individuals, organizations, applications or devices.
They are called end entity certificates because there are no further entities beneath them relying on that certificate.
5.4.1 Individual identity certificates
Individual identity certificates are a particular subtype of end entity certificates that are issued to individual persons
for the purpose of authentication. The following five types of healthcare actors are recognized as being individuals:
a) regulated health professional:
 each certificate holder is a health professional who, in order to practice his/her profession requires a
license or registration from a government body (see 5.1 of ISO/TS 17090-1:2002). These certificates may
be qualified certificates (see 8.2 of ISO/TS 17090-1:2002 and 7.3 below);
© ISO 2002 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/TS 17090-2:2002(E)
b) non-regulated health professional:
 each certificate holder is a health professional who is not subject to registration or licensing from a
government body (see 5.1 of ISO/TS 17090-1:2002). These certificates may be qualified certificates;
c) sponsored healthcare provider:
 each certificate holder is an individual who is active in his/her healthcare community and is sponsored by
a regulated healthcare organization or professional. These certificates may be qualified certificates;
d) supporting organization employee:
 each certificate holder is an individual who is active in his/her community and is sponsored by a regulated
healthcare organization or professional. These certificates may be qualified certificates;
e) patient/consumer:
 each certificate holder is an individual person who, at some stage, is about to receive, is receiving or has
received the services of a regulated or non-regulated health professional. These may be qualified
certificates.
5.4.2 Organization identity certificate
An organization that is involved in the health industry may hold a certificate to identify itself or to use for encryption
purposes. In accordance with IETF/RFC 2527, provision is made in this part of ISO/TS 17090 for an organizational
unit name.
5.4.3 Device identity certificate
A device can be a computer server, medical machine, such as a radiology machine, a vital signs monitoring device
or a prosthetic device that needs to be individually identified and authenticated.
5.4.4 Application certificate
An application is a computer information system, such as a hospital patient administration system, that needs to be
individually identified and authenticated.
This part of ISO/TS 17090 concentrates on the providers, but recognizes that patients/consumers will increasingly
require the services of a PKI in managing their own healthcare.
5.4.5 AC
An AC is a digitally signed (or certified) set of attributes. An AC is a structure similar to a PKC; the main difference
being that it contains no public key. An AC may contain attributes that specify group membership, role, security
clearance and other information associated with the AC holder that could be used for access control. The AC shall
be in accordance with the specifications given in INTERNET-DRAFT October 1999 4.1, X.509 Attribute Certificate.
Within the health industry context, ACs can fulfil the valuable role of communicating authorization information.
Authorization information is distinct from information on healthcare roles or licences, which may be appropriately
included in a PKC. Role or licence implies an authorization level, but they are not necessarily authorization
information in themselves. It is important to note that the detailed specification for ACs is still evolving and that this
Technical Specification still needs to be more widely implemented in the software industry.
The syntax of an AC is specified in X.509:
4 © ISO 2002 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/TS 17090-2:2002(E)
AttributeCertificate ::= SIGNED { AttributeCertificateInfo }

AttributeCertificateInfo ::= SEQUENCE {
version  Version DEFAULT v1,
  owner           SEQUENCE {
    baseCertificateId [0] IssuerSerial OPTIONAL,
    entityName        [1] GeneralNames OPTIONAL,
    objectDigestInfo    [2] ObjectDigestInfo OPTIONAL },
  issuer          SEQUENCE {
    baseCertificateId      IssuerSerial OPTIONAL,
    issuerName        [0] GeneralNames OPTIONAL },
  signature         AlgorithmIdentifier,
  serialNumber       CertificateSerialNumber,
  attCertValidityPeriod AttCertValidityPeriod,
  attributes        SEQUENCE OF Attribute,
  issuerUniqueID     UniqueIdentifier OPTIONAL,
  extensions        Extensions OPTIONAL }

Version ::= INTEGER { v1(0), v2(1) }

IssuerSerial ::= SEQUENCE {
issuer  GeneralNames,
serialNumber CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL }

CertificateSerialNumber ::= INTEGER

UniqueIdentifier ::= BIT STRING

ATTRIBUTE ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&singleValued BOOLEAN DEFAULT FALSE,
&Syntax }

Attribute ::= SEQUENCE {
attrType ATTRIBUTE.&id ({SupportedAttrs}),
attrValues ATTRIBUTE.&Syntax ({SupportedAttrs} {@attrType}) }

ObjectDigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
objectDigest OCTET STRING }

AttCertValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime }

The components of the AC are used as follows.
The version number differentiates between different versions of the AC. If objectDigestInfo is present or if issuer
is identified with baseCertificateID, version shall be v2.
The owner field conveys the identity of the AC's holder. Use of the issuer name and serial number of a specific
PKC is required; use of the general name(s) is optional and use of the object digest is prohibited. There is a risk
with use of GeneralNames by itself to identify the holder, in that there is insufficient binding of a name to a public
key to enable the authentication process of the owner's identity to be bound to the use of an AC. In addition, some
of the options in GeneralNames (e.g. IPAddress) are inappropriate for use in naming an AC holder which is a role
rather than an individual entity. General name forms should be restricted to distinguished name, RFC 822
(electronic mail) address, and (for role names) object identifiers.
© ISO 2002 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO/TS 17090-2:2002(E)
The issuer field conveys the identity of the AA that issued the certificate. Use of the issuer name and serial number
of a specific PKC is required, and use of the general name(s) is optional.
The signature identifies the cryptographic algorithm used to digitally sign the AC.
The serialNumber is the serial number that uniquely identifies the AC within the scope of its issuer.
The attrCertValidityPeriod field conveys the time period during which the AC is considered valid, expressed in
GeneralizedTime format.
The attributes field contains the certificate holder’s attributes that are being certified (e.g. the privileges).
The issuerUniqueID may be used to identify the issuer of the AC in instances where the issuer name is not
sufficient.
The extensions field allows addition of new fields to the AC.
Details on the use of ACs in healthcare are specified in 8.3 of ISO/TS 17090-1:2002.
5.4.6 Role certificates
A user’s AC may contain a reference to another AC that contains additional privileges. This provides an efficient
mechanism for implementing privileged roles.
Many environments that have authorization requirements require the use of role-based privileges (typically in
conjunction with identity-based privileges) for some aspect of their operation. Thus, a claimant may present
something to the verifier demonstrating only that the claimant has a particular role (e.g. “manager” or “purchaser”).
The verifier may know a priori, or may have to discover by some other means, the privileges associated with the
asserted role in order to make a pass/fail authorization decision.
The following are all possible:
 any number of roles can be defined by any AA;
 the role itself and the members of a role can be defined and administered separately, by separate AAs;
 the privileges assigned to a given role may be placed into one or more ACs;
 a member of a role may be assigned only a subset of the privileges associated with a role, if desired;
 role membership may be delegated; and
 roles and membership may be assigned any suitable lifetime.
An entity is assigned an AC containing an attribute asserting that the entity occupies a certain role. That certificate
has an extension pointing to another AC that defines the role (i.e. this role certificate specifies the role as holder
and contains a list of privileges assigned to that role). The issuer of the entity certificate may be independent of the
issuer of the role certificate and these may be administered (expired, revoked and so on) entirely separately.
Not all forms of GeneralName are appropriate for use as role names. The most useful choices are object identifiers
and distinguished names.
6 General certificate requirements
6.1 Certificate compliance
The following requirements shall apply for all certificates specified in this part of ISO/TS 17090.
a) Certificates shall be X.509 version 3 certificates.
6 © ISO 2002 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/TS 17090-2:20
...