ISO 17090-2:2015

INTERNATIONAL ISO
STANDARD 17090-2
Second edition
2015-11-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 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Healthcare CPs . 2
5.1 Certificate types required for healthcare . 2
5.2 CA certificates . 2
5.2.1 Root CA certificates . 2
5.2.2 Subordinate CA certificates . 2
5.3 Cross/Bridge certificates . 3
5.4 End entity certificates . 3
5.4.1 Individual identity certificates . 3
5.4.2 Organization identity certificate . 4
5.4.3 Device identity certificate . 4
5.4.4 Application certificate . 4
5.4.5 AC . 4
5.4.6 Role certificates . 5
6 General certificate requirements . 6
6.1 Certificate compliance . 6
6.2 Common fields for each certificate type . 6
6.3 Specifications for common fields . 7
6.3.1 General. 7
6.3.2 Signature . 8
6.3.3 Validity . 8
6.3.4 Subject public key information . 8
6.3.5 Issuer name field . 9
6.3.6 The subject name field .10
6.4 Requirements for each healthcare certificate type .11
6.4.1 Issuer fields .11
6.4.2 Subject fields .11
7 Use of certificate extensions .14
7.1 General .14
7.2 General extensions.14
7.2.1 authorityKeyIdentifier .14
7.2.2 subjectKeyIdentifier .14
7.2.3 keyUsage .14
7.2.4 privateKeyUsagePeriod .14
7.2.5 certificatePolicies .14
7.2.6 subjectAltName .14
7.2.7 basicConstraints .15
7.2.8 CRLDistributionPoints .15
7.2.9 ExtKeyUsage .15
7.2.10 Authority information access .15
7.2.11 Subject information access .15
7.3 Special subject directory attributes .15
7.3.1 hcRole attribute .15
7.3.2 subjectDirectoryAttributes .17
7.4 Qualified certificate statements extension .17
7.5 Requirements for each health industry certificate type.17
7.5.1 Extension fields .17
Annex A (informative) Certificate profile examples .19
Bibliography .31
iv © ISO 2015 – All rights reserved

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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT), see the following URL: Foreword — Supplementary information.
The committee responsible for this document is ISO/TC 215, Health informatics.
This second edition cancels and replaces the first edition (ISO 17090-2:2008), which has been
technically revised.
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
— Part 4: Digital Signatures for healthcare documents
The following document is under preparation:
— Part 5: Authentication using Healthcare PKI credentials
Annex A of this part of ISO 17090 is for information only.
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.
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 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.
This International Standard seeks to address the need for guidance of these rapid international
developments.
This International Standard 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 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.
vi © ISO 2015 – All rights reserved

This International Standard 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 5280 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. This part is based on the recommendations
of the IETF/RFC 3647 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 International Standard, as well as comments, suggestions and
information on the application of these standards may be forwarded to the ISO/TC 215 Secretariat:
Lisa.Spellman@ahima.org or WG4 PKI project leader Ross Fraser at RossFraser@SextantSoftware.com.
INTERNATIONAL STANDARD ISO 17090-2:2015(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, in whole or in part, are normatively referenced in this document
and are indispensable for its application. 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:2008, Health informatics — Public key infrastructure — Part 3: Policy management of
certification authority
IETF/RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17090-1 apply.
4 Abbreviated terms
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 to issue certificates to relying parties, including subordinate CAs. The basic constraints field
indicates whether the certificate is a CA. The Root CA certificate is used to establish a chain of trust by
Internet browsers and other applications that rely on PKI for entity identification and authentication.
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. The Subordinate CA certificate is used, along with other certificates, to establish a chain of trust
by Internet browsers and other applications that rely on PKI for entity identification and authentication.
2 © ISO 2015 – 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” 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 (ISO 17090-1:2013, 5.1); these
certificates may be qualified certificates (7.3 and ISO 17090-1:2013, 8.2);
b) non-regulated health professional:
— each certificate holder is a health professional who is not subject to registration or licensing
from a government body (ISO 17090-1:2013, 5.1); 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 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.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 3647, provision is made in this part of ISO 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 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.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 IETF/RFC 5755,
An Internet Attribute Certificate Profile for Authorization.
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, An Internet Attribute Certificate Profile for
Authorization
4 © ISO 2015 – All rights reserved

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.
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 ISO 17090-1:2013, 8.3.
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 17090.
a) Certificates shall be X.509 version 3 certificates.
b) Certificates shall be in accordance with IETF/RFC 5280. Deviations from IETF/RFC 5280 are only
allowed if they are aligned with proposed solutions to known problems with IETF/RFC 5280.
c) 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.
d) The signature field shall identify the signature algorithms used.
e) 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 ISO 17090-3:2008, 7.6.1.5.
f) 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.2 Common fields for each certificate type
6 © ISO 2015 – All rights reserved

a) 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).
b) signature contains the algorithm identifier for the algorithm used by the CA to sign the certificate.
c) 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.
d) 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 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).
e) subject identifies the name of the entity associated with the public key found in the subject
public key field.
f) subjectPublicKeyInfo is used to carry the public key and identify the algorithm with which
the key is used.
g) issuerUniqueIdentifier is an optional bit string used to uniquely identify an issuer.
(In accordance with RFC 5280, this International Standard recommends that this field should
not be used.)
h) subjectUniqueIdentifier is an optional bit string used to uniquely identify a subject.
(In agreement with RFC 5280, this International Standard recommends that this field should
not be used.)
i) 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 IETF/RFC 5280 or IETF/RFC 3279, are as follows.
6.3.2 Signature
It is recommended that the signature field contain one of the following values:
a) md5WithRSAEncryption (1.2.840.113549.1.1.4)
b) sha1WithRSAEncryption (1.2.840.113549.1.1.5)
c) dsa-with-sha1 (1.2.840.10040.4.3)
d) md2WithRSAEncryption (1.2.840.113549.1.1.2)
e) ecdsa-with-SHA1 (1.2.840.10045.4.1)
f) ecdsa-with-SHA224 (1.2.840.10045.4.3.1)
g) ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
h) ecdsa-with-SHA384 (1.2.840.10045.4.3.3)
i) ecdsa-with-SHA512 (1.2.840.10045.4.3.4)
j) id-RSASSA-PSS (1.2.840.113549.1.1.10).
k) sha256WthRSAEncryption 1.2.840.113549.1.1.11
l) sha384WithRSAEncryption 1.2.840.113549.1.1.12
m) sha512WithRSAEncryption 1.2.840.113549.1.1.13
NOTE MD2, MD5 and SHA1 hash algorithms [list items a) through e)] are included for backward compatibility
with legacy systems. These hashing algorithms have been superannuated by newer and more robust algorithms
in contemporary systems [see list items f) to m)].
6.3.3 Validity
Validity dates shall be in accordance with IETF/RFC 5280. This part of ISO 17090 has adopted
reasonable constraints for health certificate validity periods as specified in ISO 17090-3:2008, 7.6.3.2.
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.
a) RSA
pkcs-1 OBJECT IDENTIFIER:: = { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) 1 }
rsaEncryption OBJECT IDENTIFIER:: = { pkcs-1 1}
b) 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 2015 – All rights reserved

c) 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 }
d) Elliptic Curve
Ecdsa [ 1, 2, 840, 10045, 2, 1]}
Refer to ISO 17090-3:2008, 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.
a) countryName: The countryName shall contain the two character ISO country identifiers.
EXAMPLE 1 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
a request has originated from will assist any decision on whether to grant it.
b) 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 2 localityName = “California”
c) 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 3 organizationName = “California Hospital Authority”
d) 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 4 organizationalUnitName = “Midtown Hospital Radiology”
e) 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 certificate policy in the
commonName field value. This is in addition to referring to the policy using the OID.
EXAMPLE 5 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 guidance can be found in ISO/TS 21091 Health Informatics – Directory Services for security,
communications, and identification of professionals and patients.
a) countryName: The countryName shall contain the two character ISO country identifier.
EXAMPLE 1 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.
b) 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 2 localityName = “California”
c) 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 3 organizationName = “Midtown General Hospital”
d) org
...