esMD Author of Record Sub Workgroup Report
DRAFT Digital Signatures and Delegation of Rights
Electronic Submission of
Medical Documentation
Author of Record Level 1
Sub Workgroup Report
Digital Signatures and Delegation of Rights
1
12/14/12
1
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
2
3
Table of Contents
4
1.0
Summary ........................................................................................................................................... 5
5
2.0
Statement of Problem and Background........................................................................................... 6
6
3.0
Requirements .................................................................................................................................... 7
7
4.0
Assumptions ...................................................................................................................................... 7
8
5.0
Review of Standards ......................................................................................................................... 8
9
6.0
Evaluation of Alternative Solutions for Delegation of Rights ......................................................... 10
0.
Terms.................................................................................................................................................... 3
10
6.1
Proxy Certificates ........................................................................................................................ 10
11
6.2
SAML 2.0 Assertion .................................................................................................................... 11
12
6.3
Custom Assertion ....................................................................................................................... 11
13
6.4
Issues with Assertions ................................................................................................................ 11
14
6.5
Summary of Alternatives ........................................................................................................... 12
15
7.0
Recommended Solution for Digital Signatures ............................................................................... 12
16
7.1.
Recommended Standards .......................................................................................................... 13
17
7.2.
Digital Signature Artifacts for esMD Transactions and AoR Level 1 .......................................... 13
18
7.3 Verification of Digital Signature and Data Integrity ......................................................................... 13
19
7.4 Non-Repudiation ............................................................................................................................... 14
20
8.0 Recommended Solution for Delegation of Rights................................................................................. 16
21
8.1 Recommended Standards ................................................................................................................. 16
22
8.2 Delegation of Rights Artifact for Transaction and AoR Level 1 ......................................................... 16
23
8.3 Verification of Delegation of Rights .................................................................................................. 17
24
8.4 Non-Repudiation ............................................................................................................................... 18
25
9.0 Gaps ...................................................................................................................................................... 19
26
10.0 Risks, Issues and Obstacles ................................................................................................................. 19
27
Appendices.................................................................................................................................................. 20
28
Appendix A: Glossary ............................................................................................................................. 20
29
Appendix B: References .......................................................................................................................... 21
30
Appendix C: Copyright Acknowledgement ............................................................................................. 21
31
32
12/14/12
2
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
33
List of Figures:
34
35
36
37
Figure 1: Signature Artifact Example .......................................................................................................... 14
Figure 2: Delegation of Rights Example 1 ................................................................................................... 17
Figure 3: Delegation of Rights Example 2 ................................................................................................... 18
38
List of Tables:
39
40
41
42
43
44
45
Table 1: SWG Meeting Schedule ................................................................................................................... 7
Table 2: Digital Signatures Standards ........................................................................................................... 8
Table 3: Delegation of Rights Standards ....................................................................................................... 9
Table 4: Summary of Alternative Delegation of Rights Options ................................................................. 12
Table 5: Recommended Standards for esMD Digital Signatures ................................................................ 13
Table 6: Recommended Standards for esMD Delegation of Rights............................................................ 16
46
47
48
0. Terms
49
esMD – electronic submission of Medical Documentation
50
51
esMD Program – the program established by CMS for the electronic submission of Medical
Documentation
52
53
54
55
esMD Phase 1 – the first phase of the esMD Program focused on the electronic submission of PDF(s)
containing medical documentation in a C62 wrapper using the NwHIN Exchange. The primary source of
the submission is through certified Health Information Handlers (HIHs). esMD Phase 1 started pilot
production submission of documents in September of 2011
56
57
esMD Phase 1 Transaction – the transaction specified in the Implementation Guide for Electronic
Submission of Medical Documentation Project (esMD) Version 2.9 (4/17/2012)
58
esMD Gateway – the CMS NwHIN Connect instance that receives esMD Phase 1 transactions for CMS
59
60
61
62
63
esMD Initiative – the current esMD Program effort in conjunction with the ONC S&I Framework is
focused on three specific use cases: 1) Provider registration, 2) secure transmission of the electronic
Medical Documentation Requests, and 3) Author of Record, digital identities and digital signatures.
With this initiative, the esMD Program is soliciting participation by commercial payers and including
specific support for both CMS and commercial payers.
64
65
esMD Initiative Transactions – the specific transactions defined by the esMD Initiative use cases and the
subsequent implementation guides
The following are definitions of specific terms used in this document. For a full list of definitions see
Appendix A: Glossary.
12/14/12
3
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
66
Individual – in this document, any reference to an Individual is intended for a natural person only.
67
68
69
70
71
Organization or Entity – in this document, any reference to an organization or entity is to a legal entity
other than an Individual. In some cases, an Individual may also be the sole individual that is the
owner/subject of a professional corporation (PC) or limited liability corporation (LLC); in which case, the
Individual is the live person and PC or LLC is an organization or entity. Note: The term Organization will
be used in this document.
72
12/14/12
4
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
73
74
75
76
77
78
79
80
81
82
83
84
1.0
Summary
The Author of Record Sub Workgroup (SWG) on Digital Signatures and Delegation of Rights (DS/DR)
recognizes that healthcare payers using the esMD Initiative Implementation Guides require the ability to
create Public Key Infrastructure (PKI) based digital signatures and delegation of rights artifacts to
perform the following actions:
A. Establish identity of the provider to allow transmission of Protected Health Information (see
HIPAA) as part of an electronic Medical Documentation Request (eMDR).
B. Replace the “wet signature” on the document bundle submitted in response to an eMDR.
C. Determine authorship of medical documentation to support claims for payment for services
delivered by providers.
D. Prove delegation of rights where the originator of the above action is not the responsible
Individual or Organization (e.g., the originator is acting as an authorized agent).
85
86
87
88
All providers (Individuals and Organizations), as well as their designated agents, that register for the
esMD Program will be required to authenticate the above actions with digital signatures created using
X.509v3 signing certificates compliant with Federal Bridge Certification Authority (FBCA) Medium
Assurance and issued by Credential Service Providers (CSP) that are cross-certified with the FBCA.
89
The SWG recommends that the esMD Initiative identify and require:
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
A. A standard for digital signatures in the esMD transaction that clearly supports the transmission
of the public certificate and the basic message signature artifact (signed digest of the message)
as part of the esMD Initiative Transaction Implementation Guides (see Section 7.0).
B. A standard for digital signatures on document bundles that clearly supports the transmission of
the public certificate and the expanded signature artifact (minimum required: digest of
message, timestamp, and purpose of signature) for the Author of Record Level 1
Implementation Guide (see Section 7.0).
C. A standard for delegation of rights assertions for both messages and document bundle
signatures that include as part of the assertion, at a minimum, the certificate ID of both parties,
the purpose of the delegation, the effective date range, and an optional Uniform Resource
Identifier (URI) of a revocation list. Any transaction using the delegation of rights assertion must
include the public certificate of the delegator (see Section 8.0).
D. Long-term (21+ years) access to CSP/CA root certificates and revocation lists or a transaction
that can confirm that a certificate was valid (and not revoked) on a particular date/time.
The immediate need to provide digital signatures and delegation of rights artifacts can be met with
existing standards and implemented by providers, payers, agents and contractors. The capability may
be provided as a service by third parties or incorporated directly into or provided in conjunction with
EHRs and payer systems. Support for long-term access to certificate revocation lists will need to be
addressed by the industry. The ability to support validation or revocation of delegation assertions will
depend on the nature of the implementation and the specific delegation assertion and specific options
may be added as part of the pilots.
111
12/14/12
5
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
112
113
114
115
2.0
Statement of Problem and Background
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
On September 15, 2011, the esMD Program launched a pilot to accept electronic submissions from
providers via Health Information Handlers (HIHs). The current esMD initiative will enable Medicare
Review Contractors to send electronic Medical Documentation Requests, eliminating the need to send
the paper letters via mail. The next release will also implement the replacement of wet signatures with
Digital Signatures on the bundle of documents requested by CMS or the appropriate commercial
requestor.
133
134
135
136
The workgroup recommendations are constrained by two primary factors; (1) the solution must be
implemented within the first two quarters of calendar year 2013, and (2) the systems that support the
esMD Initiative (including esMD Phase 1) would have to meet standards established by the Federal
Information Security Management Act of 2002 (FISMA).
137
138
139
The workgroup identified a number of relevant standards. However, considering the FISMA
requirements, special emphasis was placed on NIST SP 800-63-1 and X.509 Certificate Policy for the
FBCA version 2.25 in determining the core requirements for their recommendations.
140
141
142
143
144
145
146
147
148
149
150
151
152
153
The overall recommendation is that all Individuals, Organizations and their agents must use a digital
certificate to sign esMD Initiative transactions and document bundles (as defined in the esMD Initiative
Author of Record Level 1 Use Case). The certificate’s root Certificate Authority (CA) must be crosscertified with the FBCA at Medium Assurance or above. Additionally, the provider should authenticate
to the signing module or application with at least one additional authentication factor prior to the actual
signing event. Adding the additional factor meets NIST Level of Assurance (LOA) 3 and supports the nonrepudiation assurances necessary for valid digital signatures. As technology options for both
authentication and digital signing continue to evolve, the esMD Initiative should continue to monitor
and update policies as appropriate to reflect improved technological capabilities.
Define the required process for issuing and managing digital credentials for the electronic submission of
Medical Documentation to the Centers for Medicare and Medicaid Services (CMS) and commercial
payers that adopt the esMD Initiative Implementation Guides.
There is a need on CMS’s part to: 1) verify the identification of the individual or organization receiving
Protected Health Information (PHI) contained in the eMDR and 2) to ensure authenticity of the
documents submitted in response to the eMDR. These are requirements for participation in the esMD
Program.
Three separate work groups were assembled to address Identity Proofing, Digital Credentials, Digital
Signatures, and Delegation of Rights issues associated with Digital Signatures. The Digital Signatures /
Delegation of Rights workgroup focused specifically on standards, policies and operational issues related
to digital signatures on Document Bundles and delegation of rights assertions for both message and
document bundle signatures.
The meetings to review the current standards, policies, alternatives and operational issues were
conducted on the schedule outlined in the table below:
12/14/12
6
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
154
155
Table 1: SWG Meeting Schedule
Date
Topic
Deliverable(s)
September 26, 2012
Standards
List and review of standards
October 3, 2012
Standards and industry examples
List and review of additional standards
industry examples
October 10, 2012
Transaction and AoR digital
signature and delegation process
Document digital signature and
delegation of rights process
October 17, 2012
Transaction and AoR signature and
delegation artifacts
Document digital signature and
delegation of rights artifacts
October 24, 2012
Validation process for nonrepudiation review
Document validation process with
assurance of non-repudiation of signer
and delegation(s)
October 31, 2012
Gaps in policy and standards
Identify gaps in standards, process and
policy and make recommendations
November 7-28, 2012
Review SWG report
SWG report
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
3.0
173
174
175
4.0
Requirements
The following specific requirements were provided by the esMD Initiative Author of Record workgroup:
1) Solution must
a. be implementable for pilot in Q1/Q2 of calendar year 2013.
b. scale to all providers (any Individual or Organization that may submit a claim to a healthcare
payer), healthcare payers, and agents for either party.
c. minimize the operational impact required to establish, maintain or use a digital identity and
digital signature.
d. provide for validation and non-repudiation of the digital signature without resorting to audit
logs or validation of system configuration.
2) Appropriate portions of the following standards must be supported
a. NIST 800-63-1 Level 3/4 (December 2011)
b. NIST 800-57 Part 1 (Revision 3 July 2012)
c. Federal Bridge Certification Authority Medium Assurance Level
d. X.509v3+ Digital Certificates
Assumptions
The following assumptions were made by the DS/DR SWG as part of their consideration of the esMD
AoR Use Case:
12/14/12
7
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
A. All esMD Initiative transactions must be digitally signed and non-repudiable by their author.
B. Document bundles must be digitally signed and non-repudiable by the responsible provider (the
subject of the eMDR) or their designated agent.
C. All delegation of rights to an agent must be cryptographically verifiable and non-repudiable.
D. Multiple architectural solutions may exist for implementation of DS/DR that include:
o National network – National services for authentication or complete AoR Level 1
o Federated method – Local (e.g., EHR)
E. Must comply with US government standards and regulations.
F. All certificates must be issued to Individuals or Organizations and include their unique
identification number (examples: Provider NPI, Health Plan HPID, Other Entity OEID, or EIN).
G. The esMD Initiative Implementation Guides require digital signatures and delegation of rights
artifacts for provider registration (UC 1), secure transmission of eMDRs (UC 2) and Author of
Record Level 1.
5.0
Review of Standards
The following standards, industry implementations, white papers and federal requirements were
reviewed by this SWG as part of their review and deliberation.
Digital Signatures
Table 2: Digital Signatures Standards
Standards
Document Link
ITI TF-1
ITI TF-2a
ITI TF-2b
ITI TF-3
IHE DSG
NIST SP 800-63-1
OASIS DSS Core Spec
XML DigSig
FIPS PUB 186-3
IETF RFC 6277
IETF RFC 6283
IETF RFC 5698
IETF RFC 5280
12/14/12
Title & Version / Notes
IHE IT Infrastructure Technical Framework: Volume
1: Integration Profiles, Revision 9.0
IHE IT Infrastructure Technical Framework: Volume
2a: Transactions Part A – Sections 3.1-3.28,
Revision 9.0
IHE IT Infrastructure Technical Framework: Volume
2b: Transactions Part B – Sections 3.29-3.51,
Revision 9.0
IHE IT Infrastructure Technical Framework: Volume
3: Cross-Transaction Specifications and Content
Specifications, Revision 9.0
IHE IT Infrastructure (ITI) Technical Framework
Supplement Document Digital Signature, Trial
Implementation Supplement
Electronic Authentication Guideline
Digital Signature Service Core Protocols, Elements,
and Bindings, Version 1.0
All DSS Standards
XML Signature Syntax and Processing (Second
Edition), W3C Recommendation
Digital Signature Standard
Online Certificate Status Protocol Algorithm Agility
Extensible Markup Language Evidence Record
Syntax
Data Structure for the Security Suitability of
Cryptographic Algorithms
Internet X.509 Public Key Infrastructure Certificate
Date
Aug 31, 2012
Aug 31 2012
Aug 31 2012
Aug 31 2012
Aug 10 2009
Dec 2011
Apr 11 2007
Jun 10 2008
Jun 2009
Jun 2011
Jul 2011
Nov 2009
May 2008
8
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
IETF RFC 5276
IETF RFC 4998
IETF RFC 3851
Industry
Implementations
White Papers /
Industry Reports
Federal Requirements
FBCA X.509 Certificate
Policy
21 CFR Parts 1305 and
1311, (DEA)
CertiPath X.509 Certificate
Policy
ABA IDM Task Force
Submission to UNCITRAL
Delegation of Rights
197
Table 3: Delegation of Rights Standards
Document Link
OASIS SAML Assertions
IETF RFC 3820
Federal Register, Vol 76,
No 8742 CFR Part 482 and
485
Industry
Implementations
Version 3.18
Overview of Identity Management. Additional
information found at the ABA’ Federated Identity
Management Legal Task Force page.
Digital Identity Management – Enabling Innovation and Trust in the Internet
Economy (OECD). This paper is summarized here and includes the following
reports:

Guidance on Digital Identity Management for Enabling Innovation and
Trust in the Internet Economy (Nov 23, 2011)

National Strategies and Policies for Digital Identity Management in
OECD Countries (Mar 31, 2010)

Role of Digital Identity Management in the Internet Economy: A Primer
for Policy Makers (June 11, 2009)

OECD Workshop on Digital Identity Management (May 8-9, 2007)
Action Plan
EU Qualified Signatures (eSignatures)
RMH Vol III Standard 3-1
CMS Risk Management Handbook Volume III,
Authentication
Standard 3.1: CMS Authentication Standards,
Version 1.2
195
196
Standards
and Certificate Revocation List Profile
Using the Server-Based Certificate Validation
Protocol to Convey Long-Term Evidence Records
Evidence Record Syntax
Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1
Message
Specification
X.509 Certificate Policy for the Federal Bridge
Certification Authority, Version 2.25
Electronic Orders for Controlled Substances
TJC Hospital Record of
Care
IGTF OID Proxy Delegation
Tracing
HIPAA Business Associate
Agreement (BAA)
Title & Version / Notes
Assertions and Protocols for the OASIS
Security Assertion Markup Language
(SAML), Version 2.0
All SAML v2.0 files
Internet X.509 Public Key Infrastructure Proxy
Certificate Profile
Medicare and Medicaid Programs:
Changes Affecting Hospital and
Critical Access Hospital Conditions of
Participation: Telemedicine
Credentialing and Privileging
TJC standards are proprietary.
International Grid Trust Federation OID Proxy
Delegation Tracing
HHS - Sample Business Associate Contract
Provisions, Aug 14 2002
Aug 2008
Aug 2007
July 2004
Dec 9 2011
Apr 1 2005
Apr 16 2012
Winter 2011
Feb 23 2011
Jul 31 2012
Date
Mar 15 2005
Jun 2004
Feb 28 2008
OCR HIPAA Privacy - Business Associates, Apr 3,
12/14/12
9
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
AFIS (Automated
Fingerprint Identification
System)
Daon, Inc (Biometrics)
42 CFR Part 493 –
Laboratory Requirements
Federal Requirements
Unsorted
FEMA First Responder
Program
No reference
RMH Vol III Standard 3-1
Authentication
Safe-BioPharma
CMS – Pilot
Study Report on
Biometrics in EAuthentication
198
199
200
201
202
6.0
2003
NIST SP 500-290, American National Standard for
Information Systems Data Format for the Interchange of Fingerprint,
Facial& Other Biometric Information, Nov 2011
Site requires registration. Knowledgebase contains
white papers, data sheets and case studies.
Current CLIA Regulations (html)
CLIA requirements for agents or authorized
individuals
(webpage only)
Power of attorney / limited power of attorney
CMS Risk Management Handbook Volume III,
Standard 3.1: CMS Authentication Standards,
Version 1.2
Safe-BioPharma – Interoperable Digital Identity
Management in the Electronic Exchange of Health
Information
CMS – Pilot Testing of Initial Electronic Prescribing
Standards
Study Report on Biometrics in E-Authentication,
International Committee for Information
Technology Standards, Information Technology
Industry Council
Jul 31 2012
Mar 30 2007
Evaluation of Alternative Solutions for Delegation of Rights
The SWG reviewed a number of potential solutions to address the Delegation of Rights, including:
A. Proxy Certificates,
B. SAML Assertions, and
C. Custom Assertions.
6.1
Proxy Certificates
203
204
205
206
Based on IETF 3280, a Proxy Certificate is derived from and signed by a normal X.509v3 public key or by
another Proxy Certificate to provide restricted proxying and delegation within a PKI based
authentication system. The following is excerpted from IETF 3280.
207
A Proxy Certificate is an X.509v3 public key certificate with the following properties:
208
209
210
211
212
213
214
215
216
217
•
•
•
•
•
It is signed by either an X.509v3 End Entity Certificate (EEC), or by another PC. This EEC or PC is
referred to as the Proxy Issuer (PI).
It can sign only another PC. It cannot sign an EEC.
It has its own public and private key pair, distinct from any other EEC or PC.
It has an identity derived from the identity of the EEC that signed the PC. When a PC is used for
authentication, in may inherit rights of the EEC that signed the PC, subject to the restrictions
that are placed on that PC by the EEC.
Although its identity is derived from the EEC's identity, it is also unique. This allows this identity
to be used for authorization as an identity independent from the identity of the issuing EEC, for
example in conjunction with attribute assertions.
12/14/12
10
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
218
219
220
221
222
223
The Proxy Certificate contains a new X.509v3 extension to identify it as a PC and to place policies on the
use of the PC. This new extension, along with other X.509v3 fields and extensions, is used to enable
proper path validation and use of the PC.
6.2
The following is a review of SAML 2.0 Security Assertion Markup Language:
224
225
226
227
228
229
230
231
232
233
234
•
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
6.3
251
252
253
254
255
SAML 2.0 Assertion
•
•
•
•
SAML defines the syntax and processing semantics of assertions made about a subject by a
system entity.
SAML assertions and protocol messages are encoded in XML [XML] and use XML namespaces
[XMLNS].
The components primarily permit transfer of identity, authentication, attribute, and
authorization information between autonomous organizations.
The core SAML specification defines the structure and content of both assertions and protocol
messages used to transfer this information.
Assertions are usually created by an asserting party based on a request of some sort from a
relying party, although under certain circumstances, the assertions can be delivered to a relying
party in an unsolicited manner.
Custom Assertion
Creation of a custom assertion is an effective but non-standard solution for the Delegation of Rights. A
custom assertion has the benefit of including only the required information for the delegation and may
be considered an acceptable solution for some implementations of the esMD Initiative Transactions
where the standard allows for the extension of transaction-associated metadata. The required assertion
information consists of at least the following:
A.
B.
C.
D.
E.
A globally unique ID for this assertion
Issuer and X.509v3 serial number for both the originator and the recipient of the delegation
Effective dates
Purpose (from a defined code set)
Optional URI of revocation list
If the server countersigning approach is utilized to ensure the assertion is valid at the time of a signature
event by the recipient of the delegation of rights (see section 8.5), the specific encapsulation of the
assertion, in addition to its contents, is also important.
6.4
Issues with Assertions
Unlike Proxy Certificates which may potentially utilize CRLs to indicate Proxy Certificates that have been
revoked before they have expired, there is no equivalent solution for assertions. This is a potential
concern, since the assertion allows the holder to sign on behalf of the grantor of the right until the
expiration date. Solutions to this “problem” are discussed in section 8.5 below.
12/14/12
11
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
256
257
258
259
260
6.5
Summary of Alternatives
The following table summarizes the benefits, limitations and challenges with the above options for
conveying Delegation of Rights as required by the esMD initiative.
Table 4: Summary of Alternative Delegation of Rights Options
Benefits
Proxy Certificate
Understood form and use
Does not require
additional delegation
artifacts (i.e., selfcontained)
Limitations
Must be generated from
End-user Certificate
Challenges
Generation of Proxy Certificate is not
supported by FBCA. No general support
for trust chain from Proxy Certificates to
antecedent Proxy Certificate or Enduser Certificate
Requires the delegation activity to be
done with the specific Proxy Certificate
Holds information for
active date, purpose
Revocation process – who and how is it
handled?
SAML Assertion
Understood form and use
Easy to use (sign with own
certificate and provide
assertion as proof of right)
May not hold all required
information without
modification of standard
Revocation process – how is it handled?
Requires the inclusion of
custom metadata or the
extension of existing
metadata to support
Not an accepted standard
Uses certificate
verification to ensure
identity of grantor and
grantee
Custom Assertion
Contains only the
information required for
the delegation of rights
assertion
261
262
263
264
265
266
267
268
269
270
271
272
273
274
7.0
Recommended Solution for Digital Signatures
275
276
277
The digital signature is provided to the intended verifier along with the signed data. The verifying
entity verifies the signature by using the claimed signatory’s public key and the same hash function
that was used to generate the signature.
This SWG recommends a Digital Signature signing process compliant with FIPS PUB 186-3 using X.509v3
signing certificates with the non-repudiation bit set and issued according to the current X.509 Certificate
Policy for the Federal Bridge Certification Authority and compliant with Medium Assurance
requirements. The SWG also recommends that the signature artifact include at a minimum the
information specified in section 7.2 below and verification of the signature by the recipient is
conformant with the process described in section 7.3.
A hash function is used in the signature generation process to obtain a condensed version of the data
to be signed; the condensed version of the data is often called a message digest. The message digest is
input to the digital signature algorithm to generate the digital signature. The hash functions to be
used are specified in the Secure Hash Standard (SHS), FIPS 180-3. FIPS approved digital signature
algorithms shall be used with an appropriate hash function that is specified in the SHS.
12/14/12
12
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
7.1.
Recommended Standards
278
279
The following standards are recommended as appropriate for esMD Digital Signatures.
280
Table 5: Recommended Standards for esMD Digital Signatures
Standard and Link
Issued by
Version / Date
FBCA X.509 Certificate Policy
X.509 Certificate Policy for the Federal
Bridge Certification Authority, Version 2.25
Dec 9 2011
FIPS PUB 186-3
Digital Signature Standard
Jun 2009
281
7.2.
Digital Signature Artifacts for esMD Transactions and AoR Level 1
282
283
Digital signatures must conform to the requirements of FIPS 186-3.
284
When signing an esMD Initiative Transaction, the Implementation Guide shall specify:
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
A.
B.
C.
D.
the portion of the transaction that must be signed
the method used to create the digest of the signed portion
the use of the X.509v3 private key to encrypt the digest
how to include the following elements in the transaction:
i.
the encrypted digest, and
ii.
the public X.509v3 digital certificate corresponding to the X.509v3 private key used to
encrypt the digest
When signing an esMD AoR Level 1 Document Bundle, the Implementation Guide shall specify:
A. that all documents included in the Document Bundle shall be included in creating the digest to
be signed the method used to create the digest of the complete Document Bundle
B. the creation of a signing artifact that at a minimum must include
i.
the digest of the Document Bundle
ii.
the signature Date/Time (GMT), and
iii.
the purpose of the signature (from an appropriate standard code set)
C. to include the following elements in the transaction
i.
the AoR Level 1 Document Bundle,
ii.
the signature artifact, and
iii.
the public X.509v3 digital certificate corresponding to the X.509v3 private key used to
encrypt the digest
7.3 Verification of Digital Signature and Data Integrity
The recipient of the esMD Initiative Transaction or the esMD AoR Level 1 Document Bundle shall
perform the following validation to authenticate the signer and the signed information:
A. Validate the X.509v3 Digital Certificate(s) by verifying that:
i.
the certificate is current
12/14/12
13
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
309
310
311
312
313
314
315
316
317
318
319
320
321
ii.
iii.
B.
C.
D.
E.
it has been issued for a purpose acceptable to esMD
the trust anchor is acceptable for esMD by verifying the complete chain to a CA root
certificate or Federal common policy CSP
iv.
the altName field includes the required NPI or Alternative Payer ID identification
v.
it has not been revoked by verifying that the certificate is not on the certificate
revocation list
Decrypt the signed digest or signature artifact with public key
Compute the digest of transaction or document bundle
Verify that the signed digest matches computed digest
For the document bundle, verify that
i.
the signature date is appropriate
ii.
the signature purpose is appropriate
322
323
Figure 1: Signature Artifact Example
324
325
326
327
328
7.4 Non-Repudiation
All X.509v3 signing certificates issued by CSPs/CAs cross-certified with the FBCA for use with esMD must
have the non-repudiation bit set. Management and use of these signing certificates in conformance
with the FBCA Medium Assurance requirements and recommendations in NIST 800-57 and the
recommendations of the esMD AoR SWG white papers permits the recipient of the appropriately signed
12/14/12
14
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
329
330
transaction and document bundle, once verified as described in section 7.3 of this document, to
consider the signatures and content non-repudiable as established by standards cited in Section 7.1.
331
12/14/12
15
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
332
333
334
335
8.0 Recommended Solution for Delegation of Rights
336
337
8.1 Recommended Standards
338
Table 6: Recommended Standards for esMD Delegation of Rights
339
340
341
342
To convey, to a third party, the delegation of rights between the holder of a right and the Individual or
Organization that has been delegated the right by the holder, this SWG recommends the use of an
assertion conformant with the SAML Assertion Version 2.0.
The following standard is recommended as appropriate for esMD Delegation of Rights.
Standard and Link
Issued by
Version / Date
OASIS SAML Assertions
Assertions and Protocols for the OASIS
Security Assertion Markup Language
(SAML), Version 2.0
Mar 15 2005
8.2 Delegation of Rights Artifact for Transaction and AoR Level 1
The SAML Assertion should be created at the time the delegation of the right (e.g., the ability to register
the provider for a healthcare payer service) is made by the holder of the right and contain at a minimum
the following information:
343
344
345
346
347
348
349
350
351
352
A. A globally unique ID for this assertion
B. The issuer and serial number of the current X.509v3 signing certificate of the right grantor (the
private key of which must be used to sign the assertion)
C. The issuer and serial number of the current X.509v3 signing certificate of the recipient of the
right (the recipient must use the private key of this certificate to sign transactions and
documents when acting under the authority of the delegation of rights assertion)
D. The valid dates for the grant
E. The right that is granted (note: SWG recommends that an appropriate, computable list of rights
should be created and used for this purpose)
F. A URI to an assertion revocation list (if the assertion will not be countersigned)
353
A digest of the entire assertion must be signed by the grantor of the right.
354
355
When transmitting information to a third party that includes an assertion for the grant of a right, the
sending system must include in the transaction:
356
357
358
359
360
361
362
A. The public X.509v3 signing certificate of the grantor of the right
B. The signed assertion
C. The public X.509v3 signing certificate of the Individual or Organization to whom the right was
granted (as defined in the assertion)
D. Optionally but recommended,
a. Public X.509v3 signing certificate of the system that verified that the assertion is
currently valid
12/14/12
16
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
363
364
365
366
367
b. the method used to create the digest of the complete Document Bundle
c. the creation of a signing artifact that at a minimum must include
i. the digest of the signed assertion
ii. the signature Date/Time (GMT) and
iii. the purpose of signature (validation of the assertion)
368
369
Figure 2: Delegation of Rights Example 1
370
371
372
8.3 Verification of Delegation of Rights
373
374
375
376
377
378
379
380
381
382
The recipient of the esMD Initiative Transaction or the esMD AoR Level 1 Document Bundle that
includes a delegation of rights shall perform the following validation:
A. Validate the X.509 Digital Certificate of the assertion signer by verifying that:
a) the certificate is current
b) it has been issued for a purpose acceptable to esMD
c) the trust anchor is acceptable for esMD by verifying the complete chain to a CA root
certificate or Federal common policy CSP
d) the altName field includes the required NPI or Alternative Payer ID identification
e) it has not been revoked by verifying that the certificate is not on the certificate
revocation list
B. Decrypt the signed digest or signature artifact with public key
C. Compute the digest of assertion
12/14/12
17
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
383
384
385
386
387
388
389
390
391
392
393
394
395
396
D.
E.
F.
G.
Verify that the signed digest matches the computed digest
Verify that the assertion was valid when used
Verify that the right(s) delegated in the assertion are appropriate
Verify that one of the following is true
a) The assertion is for a one time purpose
b) The assertion is valid only for the date/time of the signature
c) The assertion has a valid URI for a revocation list and the assertion is not on the list
d) The assertion and its signature are countersigned by a trusted system (e.g. via a server
certificate associated with the grantor of the right that includes in the countersigned
signature artifact
i.
the digest of signed assertion (verify as above)
ii.
the signature Date/Time (GMT) (same as the signature date/time by the holder
of the right), and
iii.
the purpose of the signature (validation of the assertion)
397
398
399
400
401
402
403
404
Figure 3: Delegation of Rights Example 2
8.4 Non-Repudiation
By using X.509v3 signing certificates issued by CSPs/CAs cross-certified with the FBCA for use with esMD
that have the non-repudiation bit set, all assertion message digests signed with the private key allow the
recipient to consider the signatures and assertion non-repudiable as established by standards cited in
this document.
405
12/14/12
18
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
9.0 Gaps
Gaps exist in current standards, policies and operational processes that must be addressed to
implement the recommendations from this SGW. Satisfying these gaps is work that should be
undertaken during 2013 to support the digital signature and delegation of rights requirements of esMD
Use Case 1 (Provider Registration), Use Case 2 (secure transmission of the eMDR) and the Author of
Record implementation guides. These gaps include:
A. Selecting appropriate standards for digital signatures in the esMD transaction that clearly
support the transmission of the public certificate and the message signature artifact (signed
digest of the message).
B. Selecting appropriate standards for digital signatures on document bundles that, ideally, provide
transport-independent support for public certificates and document signature artifacts (signed
digest of message, timestamp, and purpose of signature).
C. Selecting appropriate standards for delegation of rights assertions for both messages and
document bundle signatures that include, at a minimum, issuer and certificate serial number of
both parties, the purpose of the delegation, the effective date range, and the optional location
of a revocation list. Any transaction must include the public certificate of the delegator.
D. Validation via pilots for the appropriate verification of the currency of a delegation of rights
artifact (e.g. one time use, countersigned by the system on use or a CRL equivalent revocation
process).
E. Providing for long-term access to CSP/CA root certificates and revocation lists or a transaction
that can confirm that a certificate was valid (and not revoked) on a particular date/time.
F. Support by provider, payers and agents for the recommended signature and delegation of rights
standards.
10.0 Risks, Issues and Obstacles
The following potential risks, issues and obstacles with regard to the DS/DR recommended were
identified by this SWG:
A. Time and cost to support DS/DR for providers, payers, agents and contractors
B. Transaction overhead to send the public certificate, signature artifact(s) and delegation of
rights artifact(s)
C. Processing time to validate digital signatures and delegation of rights
D. Long-term storage of public certificate, signature artifact(s) and delegation of rights
E.
F.
G.
H.
I.
artifact(s) by all involved parties
Long-term ability to validate that a certificate was not revoked when it was used in a signing
event
Limited adoption by the current provider and payer community
Limited use of current standards of digital signatures and delegation of rights in healthcare
Limited adoption by providers and payers
Use of the SAML assertion for delegation of rights, while supported by the SAML
architecture, is not currently employed in the healthcare industry.
12/14/12
19
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
433
Appendices
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
Appendix A: Glossary
A. Authentication (NIST) - Security measure designed to establish the validity of a transmission,
message, or originator, or a means of verifying an individual's authorization to receive specific
categories of information. [NS4009]
B. Author (of Record) - The individual that creates a record.
C. Certificate Authority (NIST) - An authority trusted by one or more users to issue and manage
X.509 Public Key Certificates and CARLs or CRLs.
D. Credential (NIST) - An object or data structure that authoritatively binds an identity (and,
optionally, additional attributes) to a token possessed and controlled by a Subscriber.
E. Credentialing – the process by which personal or professional information about an Individual
or Organization is verified by a third party.
F. Data Integrity (NIST) - A property whereby data has not been altered in an unauthorized
manner since it was created, transmitted or stored. Alteration includes the insertion, deletion
and substitution of data.
G. Decryption - The reverse process of encryption, i.e., to make the encrypted information
readable again.
H. Delegation of Rights - The ability to delegate rights or authority to another to act in a specific
capacity on behalf of the grantor of the right.
I. Digest – The result of applying a hash function to a message. Also known as “hash value.” A
hash function is a function that maps a bit string of arbitrary length to a fixed length bit string.
Approved hash functions are specified in FIPS 180-3 and are designed to satisfy the following
properties: (1) (One-way) it is computationally infeasible to find any input that maps to any new
pre-specified output, and (2) (Collision resistant) it is computationally infeasible to find any two
distinct inputs that map to the same output.
J. Digital Certificate (NIST) - A digital representation of information which at least (1) identifies
the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the
subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the
certification authority issuing it.
K. Digital ID Management - A trusted authority is responsible for creating the key pair,
distributing the private key, publishing the public key and revoking the keys as necessary. The
“Passport Office” of the Digital World. The keys and their associated information (e.g. Digital
Certificate) are typically stored as software tokens, browser certificate stores, and hardware
tokens (Smart Cards, USB Tokens).
L. Digital Signatures - An artifact appended to a record as a result of a user’s intended action
wherein that memorializes a signing event by a process that digitally signs a document or
transaction using the private key component of his certificate. (From NIST - The result of a
transformation of a message by means of a cryptographic system using keys such that a Relying
Party can determine: (1) whether the transformation was created using the private key that
corresponds to the public key in the signer’s digital certificate; and (2) whether the message
has been altered since the transformation was made.) (From 800-63-1 an asymmetric key
operation where the private key is used to digitally sign data and the public key is used to verify
the signature. Digital signatures provide authenticity protection, integrity protection, and nonrepudiation).
12/14/12
20
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
M. Encryption - In cryptography, encryption is the process of transforming information (referred to
as plaintext) using an algorithm (called a cipher) to make it unreadable to anyone except those
possessing special knowledge, usually referred to as a key.
N. Identity - A unique name of an Individual or Organization. Since the legal names of an Individual
or Organization are not necessarily unique, the ID must include sufficient additional
information (for example an address and NPI number) to make the complete name unique.
O. Identity Proofing - The process by which the credential issuer validates sufficient information
to uniquely identify an Individual or Organization applying for the credential. It proves that the
ID exists, proves the applicant is entitled to that ID, and addresses the potential for fraudulent
issuance of credentials based on collusion.
P. Non-repudiation (NIST) - A service that is used to provide assurance of the integrity and origin
of data in such a way that the integrity and origin can be verified by a third party. This service
prevents an Individual or Organization from successfully denying involvement in a previous
action.
Q. Public Key Infrastructure - A set of policies, processes, server platforms, software and
workstations used for the purpose of administering certificates and public-private key pairs,
including the ability to issue, maintain, and revoke public key certificates.
R. Registration Authority (NIST) - An entity that is responsible for identification and
authentication of certificate subjects, but that does not sign or issue certificates.
S. X.509v3+ - Includes X.509 version 3 and all subsequent versions [RFC 5280 and its
predecessors]
Appendix B: References





CMS Internet Only Manuals (IOM)
ELECTRONIC SIGNATURES IN GLOBAL AND NATIONAL COMMERCE ACT
Recommendation for Obtaining Assurances for Digital Signature Applications
OMB 04-04
Records Management Guidance For PKI Digital Signature Authenticated and Secured
Transaction Records
505
506
Appendix C: Copyright Acknowledgement
507
508
509
510
511
512
513
514
515
516
517
518
519
520
Copyright (C) The Internet Society (2002). All Rights Reserved.
Excerpts from Internet Society documents included above are allowed based on the following:
This document and translations of it may be copied and furnished to others, and derivative works that comment
on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in
whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this document itself may not be modified in any way,
such as by removing the copyright notice or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its
successors or assigns.
12/14/12
21
Summary White Paper
DRAFT Author of Record Subworkgroup on Digital Signatures and Delegation of Rights
521
522
523
524
525
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12/14/12
22