ISO 17090-2:2008

INTERNATIONAL ISO
STANDARD 17090-2
First edition
2008-02-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 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 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 . 7
6.4 Requirements for each healthcare certificate type . 11
7 Use of certificate extensions . 14
7.1 Introduction . 14
7.2 General extensions. 14
7.3 Special subject directory attributes. 15
7.4 Qualified certificate statements extension .17
7.5 Requirements for each health industry certificate type . 17
Annex A (informative) Certificate profile examples . 19
Bibliography . 26

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-2 was prepared by Technical Committee ISO/TC 215, Health informatics.
This first edition cancels and replaces the Technical Specification (ISO/TS 17090-2: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.
This part of ISO 17090 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.
ISO 17090-3 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. ISO 17090-3 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-2:2008(E)

Health informatics — Public key infrastructure —
Part 2:
Certificate profile
1 Scope
This part of ISO 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 digital certificates in the health industry and focuses, in particular, on specific healthcare issues
relating to certificate profiles.
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, Health informatics — Public key infrastructure — Part 1: Overview of digital certificate services
ISO 17090-3, Health informatics — Public key infrastructure — Part 3: Policy management of certification
authority
IETF/RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile
IETF/RFC 3281, An Internet Attribute Certificate Profile for Authorization
IETF/RFC 3739, Internet X.509 Public Key Infrastructure Qualified Certificates Profile
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
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 certificate 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 to issue certificates to relying parties, including subordinate CAs. The basic constraints field indicates
whether the certificate is a CA.
5.2.2 Subordinate CA certificates
Subordinate CA certificates are issued for a CA that is itself certified by another CA higher up in the hierarchy
to be able to issue certificates either for other CAs lower down the hierarchy or for end entities.
2 © ISO 2008 – All rights reserved

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” shall be provided in each health industry domain,
based on speciality, jurisdiction, setting or geography which 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
5.4.1 General
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.2 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 17090-1:2008); these certificates may
be qualified certificates (see 8.2 of ISO 17090-1:2008 and 7.3 below);
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 17090-1:2008); 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 a person employed by a healthcare organization or a
supporting organization; 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.3 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 3647, provision is made in this part of ISO 17090 for an
organizational unit name.
5.4.4 Device identity certificate
A device can be a computer server, a 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.5 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 17090 concentrates on the providers, but recognizes that patients/consumers will increasingly
require the security services that digital certificates can provide in managing their own healthcare.
5.4.6 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 IETF/RFC 3281.
4 © ISO 2008 – All rights reserved

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 specification still needs to be more widely implemented in the software industry.
The syntax of an AC is specified in IETF/RFC 3281.
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 names, RFC 822 (electronic mail) addresses, and (for role names) object identifiers.
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.4 of ISO 17090-1:2008.
5.4.7 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;
⎯ 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 17090.
⎯ Certificates shall be X.509 version 3 certificates.
⎯ Certificates shall be in accordance with IETF/RFC 3280. Deviations from IETF/RFC 3280 are only
allowed if they are aligned with proposed solutions to known problems with IETF/RFC 3280.
⎯ For individual identity, certificates should be in accordance with the IETF/RFC 3739. Deviations should
only be allowed if they are aligned with proposed solutions to known problems.
⎯ The signature field shall identify the signature algorithms used.
⎯ The certified public key shall have a minimum key-length field depending on the algorithm used. Key
sizes shall be in accordance with those specified in section 7.6.1.5 of ISO 17090-3:2008.
⎯ dataEncipherment key usage shall not be combined with either non-repudiation or digitalSignature key
usage (see 7.2.3).
The common elements in all healthcare digital certificates identified in Figure 1 are described below. These
are the common elements upon which the different kinds of certificates are built.
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber  CertificateSerialNumber,
signature  AlgorithmIdentifier,
issuer   Name,
validity   Validity,
subject   Name,
subjectPublicKeyInfo  SubjectPublicKeyInfo,
issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,
extensions [3] Extensions MANDATORY,
version is the version of the encoded certificate. The certificate version shall be v3.
6 © ISO 2008 – All rights reserved

6.2 Common fields for each certificate type
1. serialNumber is an integer assigned by the CA to each certificate. Its intention is to uniquely identify
each certificate.
The value of serialNumber shall be unique for each certificate issued by a given CA (i.e. the issuer name
and serial number identify a unique certificate).
2. signature contains the algorithm identifier for the algorithm used by the CA to sign the certificate.
3. issuer identifies the name of the entity that has signed and issued the certificate. The field shall be
populated with an appropriate ISO name structure according to the object class Organizational Role,
located under an organization or under an organizational unit.
4. validity is the time interval during which the CA warrants that information contained within the certificate
is valid. For regulated health professionals, the CA shall ensure that the validity period of the certificate
does not exceed the validity period of the professional licence. To accomplish this, the CA shall either set
the certificate validity so as not to exceed the period for the professional licence or else reliably confirm
the renewal of the professional license prior to the license expiry date and revoke or suspend the
certificate if the professional license has not been renewed.
Note on time format:
The Distinguished Encoding Rules (DER) allow several methods for formatting UTCTime and
GeneralizedTime. It is important that all implementations use the same format to minimize signature
verification problems. Where the year is greater or equal to 2050, the time shall be encoded using
GeneralizedTime. To ensure that UTCTime encodings are consistently formatted, UTCTime should be
encoded using the “Z” format and the seconds field shall not be omitted, even if it is 00 (i.e. the format shall be
YYMMDDHHMMSSZ). Where so encoded, the year field YY shall be interpreted as 19YY when YY is greater
than or equal to 50 and as 20YY when YY is less than 50. When GeneralizedTime is used, it should be
encoded in the “Z” format and the seconds field should be included (i.e. the format should be
YYYYMMDDHHMMSSZ).
5. subject identifies the name of the entity associated with the public key found in the subject public key
field.
6. subjectPublicKeyInfo is used to carry the public key and identify the algorithm with which the key is
used.
7. issuerUniqueIdentifier is an optional bit string used to uniquely identify an issuer.
(In accordance with IETF/RFC 3280, this part of ISO 17090 recommends that this field not be used.)
8. subjectUniqueIdentifier is an optional bit string used to uniquely identify a subject.
(In agreement with IETF/RFC 3280, this part of ISO 17090 recommends that this field not be used.)
9. extensions — a SEQUENCE of one or more extensions shall be present.
The signature of the certificate is appended to the certificate data type by means of the standard signed data
type defined in X.509.
6.3 Specifications for common fields
6.3.1 General
Specific requirements for information content in basic certificate fields, which are not already specified by
[11]
IETF/RFC 3280 or IETF/RFC 3279 , are as follows.
6.3.2 Signature
It is recommended that the signature field contain one of the following values:
1. md5WithRSAEncryption (1.2.840.113549.1.1.4)
2. sha1WithRSAEncryption (1.2.840.113549.1.1.5)
3. dsa-with-sha1 (1.2.840.10040.4.3)
4. md2WithRSAEncryption (1.2.840.113549.1.1.2)
5. ecdsa-with-SHA1 (1.2.840.10045.4.1)
6. ecdsa-with-SHA224 (1.2.840.10045.4.3.1)
7. ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
8. ecdsa-with-SHA384 (1.2.840.10045.4.3.3)
9. ecdsa-with-SHA512 (1.2.840.10045.4.3.4)
10. id-RSASSA-PSS (1.2.840.113549.1.1.10)
11. sha256WthRSAEncryption 1.2.840.113549.1.1.11
12. sha384WithRSAEncryption 1.2.840.113549.1.1.12
13. sha512WithRSAEncryption 1.2.840.113549.1.1.13
6.3.3 Validity
Validity dates shall be in accordance with IETF/RFC 3280. This part of ISO 17090 has adopted reasonable
constraints for health certificate validity periods as specified in section 7.6.3.2 of ISO 17090-3:2008.
Certificate’s notBefore time expresses the exact moment from which the CA will maintain and publish
accurate information about the status of the certificate.
6.3.4 Subject public key information
The algorithm identifier shall be identified, e.g.
1. RSA
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}
2. Diffie-Hellman
The Diffie-Hellman OID supported by this profile is defined by ANSI
X9.42 [X9.42].
dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
8 © ISO 2008 – All rights reserved

3. DSA
The DSA OID supported by this profile is
id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
x9cm(4) 1 }
4. Elliptic Curve
Ecdsa [1, 2, 840, 10045, 2, 1]}
Refer to ISO 17090-3, 7.6.1.5, for specification of key sizes.
6.3.5 Issuer name field
The issuer name, stored in the issuer name field, shall, with the amendments and constraints specified below,
be consistent with an appropriate ISO name structure according to the object class Organizational Role,
located under an organization or under an organizational unit.
Contents of the issuer name field for each certificate type is specified in 6.4.
1. countryName: The countryName shall contain the two-character ISO country identifiers.
EXAMPLE countryName = “US”.
This field is mandatory, as it is critical in the healthcare field to know the country of origin of a certificate
presented with a request for access to personal health information. Different countries have varying privacy
laws and practices to protect client/consumer policy and knowing the country from which a request has
originated will assist any decision on whether to grant it.
2. localityName: localityName may be used to store at least one locality name value. The specification will
specify use of two levels of locality name. The top level specifies the country followed by a geographic locality
name value. Within the certificate issuer name the localityName may be omitted and only the geographic
localityName may be used.
EXAMPLE localityName = “California”.
3. organizationName: The organizationName field, which refers to the name of the sponsoring healthcare
organization in the case of end entities and the organization name of the CA in the case of CA certificates,
shall contain the full registered name of the organization.
EXAMPLE organizationName = “California Hospital Authority”.
4. organizationalUnitName: The organizationalUnitName field may, when present, be used to store a
name of an organizational unit/department under the specified organization. Organizational units may be
specified in several levels by including more than one field value. When present, the organizationalUnitName
shall be selected in a way that prevents name ambiguity within the CA domain.
EXAMPLE organizationalUnitName = “Midtown Hospital Radiology”.
5. commonName: The purpose of this field is to describe the name by which the subject is commonly
known. This field is often used, together with subject commonName, by standard software components when
presenting a certificate to a user. The presented name shall therefore be informative, providing a good
understanding of the certificate issuer and the purpose of the certificate. It is further recommended to include
a name of the governing CP in the commonName field value. This is in addition to referring to the policy using
the OID.
EXAMPLE commonName = “Patient Health Information Policy”.
6.3.6 The subject name field
The subject name, stored in the subject name field, shall, with the amendments and constraints defined below,
be consistent with an appropriate ISO name structure according to the object class Organizational Role,
located under an organization or under an organizational unit.
Qualifications and titles of healthcare actors will be reflected in the certificate extension — HCRole field.
Contents of the subject name field for each certificate type are specified in 6.4. Additional advice and
[10]
guidance can be found in ISO/TS 21091 .
1. countryName: The countryName shall contain the two-character ISO country identifier.
EXAMPLE countryName = “US”.
The population of this field should reflect the particular country’s practice.
This field is mandatory for CAs, regulated and non-regulated health professionals, sponsored healthcare
providers, supporting organization employees and organizations, as it is critical in the healthcare field to know
the country of origin of an entity that is the subject of a certificate presented with a request for access to
personal health information. Different countries have varying privacy laws and practices to protect
client/consumer policy and knowing from which country the request has originated will assist any decision on
whether to grant it.
2. localityName: localityName may be used to store at least one locality name value. Two levels of locality
name are specified, with the top level being the country. This is followed by a geographic locality name value.
Within the certificate subject name the localityName may be omitted and only the geographic localityName
may be used.
EXAMPLE localityName = “California”.
3. organizationName: The organizationName field, which refers to the name of the sponsoring healthcare
organization in the case of end entities and the organization name of the CA in the case of CA certificates,
shall contain the full registered name or the organization or its registered trademark.
EXAMPLE organizationName = “Midtown General Hospital”.
4. organizationalUnitName: The organizationalUnitName field may, when present, be used to store a
name of an organizational unit/department under the specified organization. Organizational units may be
specified in several levels by including more than one field value. When present, the organizationalUnitName
shall be selected in a way that prevents name ambiguity.
In some local healthcare implementations – for example, in Japan – organizational unit is used to store a
healthcare role. This may also be useful in Virtual Private Network implementations, as some vendor VPN
routers/firewalls can access OU and use it to apply rules to grant or restrict access. It also makes it easy for a
relying party to read role information directly from the certificate. The organizationalUnitName field may, when
present, be used to store a healthcare role.
EXAMPLE organizationalUnitName = “Midtown Hospital Radiology”.
EXAMPLE organizationalUnitName = “Licensed Physician”.
5. commonName: The purpose of this field is to describe the name by which the subject is commonly
known. It shall be present and shall clearly identify the subject as it is known within the healthcare system.
EXAMPLE commonName = “Bruce Wayne”.
This field is mandatory for persons and organizations that are the subject of certificates. It is essential to be
able to identify the common name by which a person is known in the health system, if decisions are to be
made on whether to allow them to access personal health information.
10 © ISO 2008 – All rights reserved

6. surName: This field is used to describe the surname by which the subject is known. It may be present. If
present, it shall clearly identify the subject as it is known within the healthcare system.
EXAMPLE commonName = “Wayne”.
7. givenName: The purpose of this field is to describe the given name by which the subject is commonly
known. It may be present. It shall clearly identify the subject as it is known within the healthcare system.
EXAMPLE givenName = “Bruce”.
8. e-mail: The primary recommended usage of this field is to record the subject’s electronic mail address.
EXAMPLE e-mail = “jsmith@network.com.au”.
Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy
implementations is deprecated by IETF/RFC 3280 but permitted. This part of ISO 17090 recommends that
e-mail not be used in the subject name field, but rather in the subjectAltName field.
9. serialNumber: The serialNumber field may be used to ensure uniqueness of subjectDN. For example, it
may be used to store a health care provider license number. The field is optional.
6.4 Requirements for each healthcare certificate type
6.4.1 Issuer fields
Issuer field requirements for each healthcare certificate type are given in Table 1.
6.4.2 Subject fields
Subject field requirements for each healthcare certificate type are given in Table 2
12 © ISO 2008 – All rights reserved
Table 1 — Issuer field requirements for each healthcare certificate type
CA certificates Identity certificates
Certification Cross/ Regulated Non- Consumer Organization Device Application
Attribute
authority bridge health regulated certificate certificate certificate certificate
Certificate elements
certificate
b
certificate certificate professional healthcare
certificate professional
c
certificate
a
Issuer fields
CountryName Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Optional
LocalityName Optional Optional Optional Optional Optional Optional Optional Optional Optional
Organization_Name Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Optional
Organizational_Unit Name Optional Optional Optional Optional Optional Optional Optional Optional Optional
CommonName Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Not applicable
a
This table refers to issuer ID field elements that may vary between certificate types.
b
Certification authority certificates refer to those issuing certificates to end entities.
c
The values for non-regulated health professional certificates also apply to sponsored healthcare provider certificates and supporting healthcare employee certificates.

Table 2 — Subject field requirements for each healthcare certificate type
CA certificates Identity certificates
Certification Cross/ Regulated Non- Consumer Organization Device Application
Attribute
authority bridge health regulated certificate certificate certificate certificate
Certificate elements
b certificate
certificate certificate professional healthcare
certificate professional
c
certificate
a
Subject fields
CountryName Mandatory Mandatory Mandatory Mandatory Optional Mandatory Optional Optional Optional
LocalityName Optional Optional Optional Optional Optional Optional Optional Optional Optional
Organization_Name Mandatory Mandatory Optional Optional Optional Mandatory Optional Optional Optional
Organizational_UnitName Optional Optional Optional Optional Optional Optional Optional Optional Optional
CommonName Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Optional Optional Optional
GivenName Not applicable Not applicable Optional Optional Optional Not applicable Not applicable Not applicable Optional
SurName Not applicable Not applicable Optional Optional Optional Not applicable Not applicable Not applicable Optional
Electronic mail Optional Optional Optional Optional Optional Optional Optional Optional Optional
a
This table refers to subject ID field elements that may vary between certificate types.
b
Certification authority certificates refer to those issuing certificates to end entities.
c
The values for non-regulated health professional certificates also apply to sponsored healthcare provider certificates and supporting healthcare employee certificates.

7 Use of certificate extensions
7.1 Introduction
Requirements that implementations shall have of certificate extensions in X.509 version 3 certificates for
healthcare are given below. More detailed information about these extensions is given in IETF/RFC 3280 and
IETF/RFC 3739.
7.2 General extensions
7.2.1 authorityKeyIdentifier
This extension shall identify the public key to be used to verify the signature of the certificate. It enables
distinct keys, used by one CA, to be distinguished (e.g. as key updating occurs).
Only the keyIdentifier element of the authorityKeyIdentifier extension shall be used.
This is a non-critical extension. If used, it is recommended that the extension be configured as mandatory.
7.2.2 subjectKeyIdentifier
This extension is used to identify the public key held in the subjectPublicKeyInfo field of the
...