Health informatics — Public key infrastructure — Part 4: Digital Signatures for healthcare documents

ISO 17090-4:2014 supports interchangeability of digital signatures and the prevention of incorrect or illegal digital signatures by providing minimum requirements and formats for generating and verifying digital signatures and related certificates. Furthermore, it defines the provable compliance with a PKI policy necessary in the domain of healthcare. This part of ISO 17090 adopts long-term signature formats to ensure integrity and non-repudiation in long-term electronic preservation of healthcare information. This part of ISO 17090 conforms to ISO/ETSI standards for long-term signature formats to improve and guarantee interoperability in the healthcare field. There is no limitation regarding the data format and the subject for which the signature is created.

Informatique de la santé — Infrastructure clé publique — Partie 4: Signatures numériques pour les documents des soins médicaux

General Information

Status
Withdrawn
Publication Date
23-Sep-2014
Withdrawal Date
23-Sep-2014
Current Stage
9599 - Withdrawal of International Standard
Completion Date
07-Oct-2020
Ref Project

Relations

Buy Standard

Standard
ISO 17090-4:2014 - Health informatics -- Public key infrastructure
English language
24 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 17090-4
First edition
2014-10-01
Health informatics — Public key
infrastructure —
Part 4:
Digital Signatures for healthcare
documents
Informatique de la santé — Infrastructure clé publique —
Partie 4: Signatures numériques pour les documents des soins
médicaux
Reference number
ISO 17090-4:2014(E)
©
ISO 2014

---------------------- Page: 1 ----------------------
ISO 17090-4:2014(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO 2014
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
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 2014 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 17090-4:2014(E)

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definition . 1
4 Scope of application . 2
4.1 Target system . 2
4.2 Generation process . 3
4.3 Verification process . 4
4.4 CAdES specification .12
4.5 XAdES specification .16
Annex A (informative) .21
Bibliography .24
© ISO 2014 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 17090-4:2014(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.
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.
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
iv © ISO 2014 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 17090-4:2014(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 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 be 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.
This International Standard seeks to address the need for guidance to support 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 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 2014 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 17090-4:2014(E)

This International Standard can be approached as a whole, with the four parts all making a contribution
to defining how digital certificates can be used to provide security services in the healthcare industry,
including authentication, confidentiality, data integrity, and the technical capacity to support the quality
of digital signature.
ISO 17090-4 provides healthcare-specific profiles of digital signature based on the ETSI Standard and
the profile of the ETSI Standard specified in CAdES and XAdES.
vi © ISO 2014 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 17090-4:2014(E)
Health informatics — Public key infrastructure —
Part 4:
Digital Signatures for healthcare documents
1 Scope
This part of ISO 17090 supports interchangeability of digital signatures and the prevention of incorrect
or illegal digital signatures by providing minimum requirements and formats for generating and
verifying digital signatures and related certificates.
Furthermore, it defines the provable compliance with a PKI policy necessary in the domain of healthcare.
This part of ISO 17090 adopts long-term signature formats to ensure integrity and non-repudiation in
long-term electronic preservation of healthcare information.
This part of ISO 17090 conforms to ISO/ETSI standards for long-term signature formats to improve and
guarantee interoperability in the healthcare field.
There is no limitation regarding the data format and the subject for which the signature is created.
2 Normative references
The following 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:2008, 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
3 Terms and definition
For the purposes of this document, the terms and definitions given in ISO 17090-1 and the following
apply.
3.1
certification path
connection of a series of certificates binding the certificate which is to be validated to a trusted root
trust anchor
3.2
certification path validation
path to be validated to a trusted root trust anchor including revocation checking
3.3
hash function
computation method used to generate a random value of fixed length from the data of any optional
length
Note 1 to entry: The generated value is called a “hash value”, which has the properties of being uni-directional
(the original data cannot be back calculated from it) and of having a low probability of having been generated
from two different data (collision).
© ISO 2014 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO 17090-4:2014(E)

Note 2 to entry: Because of these properties, when sending/receiving data, if the hash value generated on the
sending side and the hash value of the data obtained by the receiving side match on comparison, it can be confirmed
with a high degree of confidence that the data were not tampered with during transmission.
4 Scope of application
4.1 Target system
The target systems of this part of ISO 17090 are as follows:
a) the digital signature library with the digital signature function and the digital signature verification
function for the medical treatment application;
b) the digital signature program and the digital signature verification program as the stand-alone
software or with the medical treatment application;
The following are out of scope:
a) the medical treatment application that does not process the digital signature data directly;
b) the medical treatment application that processes the digital signature and the result of signature
verification with the digital signature library, the specific digital signature program, or the specific
digital signature verification program;
c) the application interface and user interface; Figure 1 shows an example of the processing layer.
The digital signature application layer (the digital signature library, the digital signature program,
or the digital signature verification program) is the target scope of this example. Therefore, the
following layer, CSP, and PKCS#11, is not within the targeted scope of this International Standard.
In HPKI, it is assumed that ‘Storage modules of the end entity subscriber private key shall conform to
standards of levels equal to or higher than US FIPS 140-2 level 1’ by ISO 17090-3:2008, 7.6.2.12. Also, in
addition to the smart card, as illustrated, a system could use a USB token, software token, etc., as the
medium that stores the private key.
2 © ISO 2014 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 17090-4:2014(E)

The medical treatment application
The digital signature application layer
(the digital signature library,
the digital signature program)
CSP, PKCS#11
Card edge interface
PC/SC etc.
Connected device (USB etc.)
Smart Card reader/writer device
Smart Card
Figure 1 — Example of processing layer digital signature specification
4.2 Generation process
The digital signature format is based on ETSI advanced digital signatures, where CAdES (CMS Advanced
[5] [6]
Digital Signature) and XAdES (XML Advanced Digital signature) are described in this International
Standard.
These specifications define the various formats according to purpose of operation.
— ES: The format that has the digital signature value, data itself, and information about the signer.
— ES-T: The format that has the Signature Timestamp in addition to the ES format. Signature Timestamp
is a trusted timestamp provided by a timestamp authority to prove the existence of the signature.
— ES-C: The format that has validation data references in addition to the ES-T format.
— ES-X: The format that has ES-C Timestamp to protect validation data references.
— ES-X Long: The format that has the ES-C format and revocation information for verification.
© ISO 2014 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO 17090-4:2014(E)

— ES-A: The format that has an Archive Timestamp to protect the signature, the timestamps, and the
validation data.
See Figure 2 for the different format types of digital signature.
ES -A
ES -X Long
ES -C
ES -T
ES
Reference
Archive
Archive
to Validation AA
oonn
Sig nature
Content Signed Signature
Timestamp
Timestamp
Validation Data TTiimm
Timestamp
Information Attributes Value
Data
Figure 2 — Format types of digital signature
This specification only defines the profile of ES-T and ES-A. The other formats are considered to be
intermediate formats to generate ES-T or ES-A, and they are out of scope of this part of ISO 17090.
[5]
The digital signature format is based on ETSI advanced digital signatures, where CAdES based on a
[6]
CMS (Cryptographic Message Syntax) and XAdES based on an XML Advanced Digital signature are
described in this International Standard.
The CAdES profile that specifies elements required/allowed to generate ES-T and ES-A is described in
4.4; 4.5 describes the XAdES profile of ES-T and ES-A.
4.3 Verification process
This section describes an overview of the basic verification processes. This part of ISO 17090 does
not provide verification methods for optional attributes. If the signature data contains any optional
attributes, the optional attributes must be correctly verified in accordance with other specifications,
policies, or guidelines.
4.3.1 Verification of ES
4.3.1.1 Verification processes of ES
The verification processes of ES are described below, and the order of the processes should not be
changed. See Figure 3.
Veriication of ES
Ascertain correctness of format
Verify the signer ’s certiicate
Verify the signature value
and signer identiier
Figure 3 — Verification processes of ES
4 © ISO 2014 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 17090-4:2014(E)

a) Verify the format of the signing data.
Verify if the digital signature format is correct.
b) Verify the signer’s certificate.
The following steps are performed to ascertain the validity of the signer’s certificate.
1) Certification path validation described in RFC5280.
2) Verify signer’s certificate extensions regarding HPKI.
c) Verify the signature value of the signer.
The following steps are performed.
1) Verify the signature value using the signer’s public key.
2) Verify the identifier of the signer’s certificate.
The above processes are explained in Annex A.
4.3.1.2 Description of verification processes
Verification process Description
a) Ascertain correctness of format. The following conditions shall be checked.
— If the structure of the signature data complies
to the defined format.
— If the signature data contain all elements
required in the profile.
— If the version number of the signature data is
correct.
b) Verify the signer’s certificate. 1) Certification path validation described in
RFC5280.
— Build and verify the certification path for the
signer’s certificate.
2) Ascertain extensions regarding HPKI con-
tained in the signer’s certificate.
— Implementations are required to support
functions to check the following elements.
— HPKI certificate policy identifier.
— The value of the hcRole attribute in the
signer’s certificate.
— The ascertainment method is out of scope of
this part of ISO 17090. It is possible to choose suitable
methods for applications.
© ISO 2014 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO 17090-4:2014(E)

c) Verify the signature value and signer 1) Verify the signature value using the signer’s
identifier. public key.
The following steps shall be performed.
— Calculate the hash value of the content data
and ascertain that it matches the value of the mes-
sage digest contained in the signature.
— Verify the signature value with signed attrib-
utes using the signer’s public key.
2) Verify the correspondence of the identifier
information of the signer’s certificate.
— Ascertain that the signer identifier matches
the signer’s certificate attributes contained in the
signature data.
4.3.2 Verification of ES-T
4.3.2.1 Verification process of ES-T
This section describes the process to verify a signature in ES-T format.
The verification processes of ES-T are described below, and the order of the processes should not be
changed. See Figure 4.
Veriication of E-ST
Verify the Signature Timestamp
Ascertation that the signer’s signature was
valid at the time of the Signature Timestamp
Veriication of ES
Ascertain correctness of format
Verify the signer ’s certiicate
Verify the signature value
and signer identiier
Figure 4 — Verification processes of ES-T
a) Verify the Signature Timestamp.
1) Verify the certificate of the TSA that provides the Signature Timestamp.
2) Verify the signature value of the TSA that provides the Signature Timestamp.
3) Verify the message imprint of the timestamp token.
b) Verify the signer’s signature at the time of the signature timestamp.
1) Ascertain that the signer’s signature was valid at the time of the Signature Timestamp.
6 © ISO 2014 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 17090-4:2014(E)

2) Ascertain that the signer’s trust anchor is appropriate.
The above processes are explained in Annex A.
4.3.2.2 Description of a verification process
Verification process Description
a) Verify the Signature Timestamp. 1) Verify the certificate of the TSA that provides
the Signature Timestamp.
The following steps shall be performed for the TSA
certificate.
— Certification path validation as described in
RFC5280.
— Ascertain that the certificate contains
extended key usage for TSA purpose.
2) Verify the signature of the TSA that provides
the Signature Timestamp.
Verify the signature value of the timestamp token
using the public key of a TSA certificate.
3) Verify the message imprint of the timestamp
token.
— Calculate the hash value of the signer’s signa-
ture value and ascertain that it matches the value of
the message imprint within the timestamp token.
b) Verify the ES at the time of the Signa- 1) Verify the ES at the time of the Signature
ture Timestamp. Timestamp.
— Verify that the certificate of the signer was
valid at the time of the Signature Timestamp.
2) Verify that the trust anchor is appropriate.
— Verification could be performed in a long
period of time after the ES-T data were created. The
trust anchor that was valid at the time of signature
might be expired or compromised at the time of veri-
fication. In this case, the verifier must verify that the
trust anchor is appropriate.
— For example, the signer and the verifier spec-
ify an agreement about the trust anchor (for example,
the signature policy) and manage it under protection
against CA compromise, or the verifier refers to a
trusted third party that manages the history of veri-
fication information of certificates. Specific methods
are out of the scope of this part of ISO 17090.
4.3.3 Verification of ES-A
4.3.3.1 Verification process of ES-A
The verification processes of ES-A are described below, and the order of the processes should not be
changed. See Figure 5.
© ISO 2014 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO 17090-4:2014(E)

Veriication of ES-A
Verify the latest archive timestamp. Ascertain ordering of times.
Verify validation information for
Verify previous archive timestamps.
the signer ’s certiicate.
Verify the Signature Timestamp at the
time of irst Archive Timestamp.
Veriication of ES-T
Verify the Signature Timestamp
Ascertain that the signer’s signature was
valid at the time of the Signature Timestamp
Veriication of ES
Ascertain correctness of format
Verify the signer ’s certiicate
Verify the signature value
and signer identiier
Figure 5 — Verification processes of ES-A
a) Verify the latest Archive Timestamp.
Verify that the latest Archive Timestamp is valid at the time of verification.
1) Verify the certificate of the TSA that provides the latest Archive Timestamp.
2) Verify the signature of the TSA that provides the latest Archive Timestamp.
3) Verify the correspondence of the latest Archive Timestamp and the target data of the timestamp.
b) Verify the previous Archive Timestamps, if present.
Verify that the timestamp was valid at the time when the data was archived.
1) Verify the certificate of the TSA that provides the Archive Timestamp.
2) Verify the signature of the TSA that provides Archive Timestamp
3) Verify the correspondence of the Archive Timestamp and the target data of the timestamp.
4) Verify that the trust anchor of the Archive Timestamp is appropriate.
c) Verify the validation data of the signer’s certificate.
1) Verify the validity of the certificate chain archived in the validation data.
2) Verify that the trust anchor is appropriate.
3) Verify the validity of revoke information archived in the validation data.
8 © ISO 2014 – All rights reserved

---------------------- Page: 14 ----------------------
ISO 17090-4:2014(E)

4) Verify that the trust anchor of revoke information is appropriate.
d) Verify the Signature Timestamp.
Verify that the timestamp is appropriate.
1) Verify that the Signature Timestamp was valid at the time it was archived.
2) Verify that the trust anchor of the Signature Timestamp is appropriate.
e) Verify the ES at the time of the Signature Timestamp.
1) Verify that the ES was valid at the time of the Signature Timestamp.
2) Verify that the trust anchor is appropriate.
f) Verify the ordering of the times of timestamps and the issued time of validation data.
The above processes are explained in Annex A.
4.3.3.2 Description of Verification Process
Verification process Description
a) Verify the latest Archive Timestamp. 1) Verify the certificate of the TSA that provided
the latest Archive Timestamp.
The following steps shall be performed for the TSA
certificate.
— Verify the validity of the certificate at the
time of verification.
— Ascertain that the purpose of the key usage of
the TSA certificate is appropriate.
2) Verify the signature of the TSA that provides
the latest Signature Timestamp.
— Verify the signature value of the timestamp
token using the public key of the TSA certificate.
3) Verify the message imprint of the timestamp
token.
— Calculate the hash value of the target fields
for the archive and verify that it matches the value of
the message imprint within the timestamp token.
© ISO 2014 – All rights reserved 9

---------------------- Page: 15 ----------------------
ISO 17090-4:2014(E)

b) Verify the previous Archive Times- 1) Verify the certificate of the TSA that provides
tamp, if it is present. the Archive Timestamp.
— Verify the validity of the TSA certificate of the
archive timestamp at the time that is shown in the
next generation archive timestamp.
The relationship of time for verification is shown in
Figure 6.
2) Verify the signature of the TSA that issued the
archive timestamp.
3) Verify the correspondence between the
archive timestamp and the imprint data.
4) Verify that the trust anchor of the TSA certifi-
cate is appropriate.
— The validity of the certificate at the trust
point could be expired at the time of verification of
the TSA certificate for the archive timestamp.
— In order to verify the trust anchor of b) 1),
confirm that the certificate at the trust point is
appropriate. Specific methods are out of the scope of
this part of ISO 17090.
c) Verify validation data for the signer’s 1) Ascertain the validity of the certificate chain
certificate. archived in the validation data.
2) Ascertain that the trust anchor of the certifi-
cate is appropriate.
3) Ascertain the validity of revoke information
archived in the validation data.
— Compare the issued time of revoke informa-
tion with the time of archiving and confirm that the
revoke information is appropriate.
4) Ascertain that the trust point of the revoke
information is valid.
— Confirm that the trust point certificate is
appropriate at the time of verification of validity of
the certificate used for signing the revoke informa-
tion.
10 © ISO 2014 – All rights reserved

---------------------- Page: 16 ----------------------
ISO 17090-4:2014(E)

d) Verify the Signature Timestamp at the 1) Ascertain that the Signature Timestamp was
time of the first Archive Timestamp. valid at the time of the first Archive Timestamp.
— Execute 4.3.3.2 assuming the time of the first
archive timestamp. Verify that the TSA certificate
was valid at the time of the first archive timestamp.
2)
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.