Electronic Submission of Medical
Documentation (esMD)
Identity Proofing Sub-Workgroup
October 3, 2012
Sub Workgroup: Identity Proofing
Deliverable: “Summary White Paper”
– Define required process for identity proofing of
– Assumptions
healthcare individuals and organizations for esMD
– Statement of Problem
Requirements
– Recommended Solution(s)
– NIST SP 800-63-1 Level 3 authentication (December
• Review of Standards (e.g. NIST, FICAM,
2011)
FBCA)
– Federal Bridge Certification Authority Medium Level
• Certification requirements for RAs
In-Scope
• Proof of identity requirements for
– RA qualifications and certification
– Entities
– Combining RA process with other healthcare identity
– Individuals
proofing (e.g. credentialing)
• Allowed proofing processes (e.g. as part of
– Policy issues regarding identity proofing
credentialing?)
Out-of-Scope
• Frequency of Identity review
– Digital Credential Management
• Appeals process for denial
– Digital Signatures
• Variation based on specific
– Delegation of Rights
credentials/use?
• Revocation (triggers and process)
– Identify gaps in current policy impacting Identity
Proofing
– References
Goal
2
Schedule for Identity Proofing SWG
Date
Topic
Deliverable(s)
September 26, 2012
Standards
(NIST/FBCA)
List and review of standards
October 3, 2012
Industry examples
List and review industry examples
October 10, 2012
Requirements for
identity
Requirements for individuals and
organizations
October 17, 2012
RA requirements
“Certification” process for RAs
October 24, 2012
RA processes
Combine with, frequency, appeals,
revocation
October 31, 2012
Gaps in policy and
standards
Identify gaps in standards, process
and policy and make
recommendations
November 7, 2012
Review SWG
recommendation
Review final report
Definitions
Identity (NIST)
A set of attributes that uniquely describe a person within a given context.
Identity (Proposed)
A set of attributes that uniquely describe a person or legal entity within a
given context.
Identity Proofing (NIST)
The process by which a Credential Service Provider (CSP) and a Registration
Authority (RA) collect and verify information about a person for the purpose of
issuing credentials to that person.
Identity Proofing (Proposed)
The process by which a Credential Service Provider (CSP) and a Registration
Authority (RA) collect and verify information about a person or legal entity
for the purpose of issuing credentials to that person or legal entity.
4
General Requirements
 Solution must
 be implementable for pilot in Q1/Q2 2013
 scale to all providers and payers
 minimize the operational impact required to establish , maintain
or use a digital identity
 provide for non-repudiation without resorting to audit logs or
validation of system configuration
 Standards -- required
 NIST 800-63-1 Level 3/$ (December 2011)
 NIST 800-57 Part 1 (Revision 3 July 2012)
 Federal Bridge Certification Authority Medium Level
 X.509v3+ Digital Certificates
Standards for Identity Proofing
Document Link
Title & Version / Notes
Date
NIST SP 800-63-1
FBCA X.509 Certificate Policy
Electronic Authentication Guideline
X.509 Certificate Policy for the Federal Bridge Certification Authority,
Version 2.25
Federal Identity, Credential, and Access Management Roadmap and
Implementation Guidance, Version 2.0
Internet X.509 Public Key Infrastructure Certificate Policy and Certification
Practices Framework
and
X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework,
Version 3647 – 1.17
Personal Identity Verification of Federal Employees and Contractors
Dec 2011
Dec 9 2011
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List Profile
An IANA Registry for Level of Assurance (LoA) Profiles
May 2008
FICAM Roadmap and Implementation
Guidance
IETF RFC 3647
and
FPKIPA
FIPS PUB 201-1
IETF RFC 5280
IETF RFC 6711
ISO Standards Catalogue webpage
ISO standards publications are proprietary. Subcommittee/WG structure
can be found here.
Dec 2 2011
Nov 2003
and
Dec 9 2011
Mar 2006
Aug 2012
NIST 800-63-1 Separation of RA and CSP functions
•
A common reason for breaking up the registration process as described
above is to allow the subscriber to register or obtain tokens for use in two or
more environments. This is permissible as long as the tokens individually
meet the appropriate assurance level. However, if the exact number of
tokens to be issued is not agreed upon early in the registration process,
then the tokens should be distinguishable so that Verifiers will be able to
detect whether any suspicious activity occurs during the first few uses of a
newly issued token.
•
If a valid credential has already been issued, the CSP may issue another
credential of equivalent or lower assurance. In this case, proof of
possession and control of the original token may be substituted for
repeating the identity proofing steps. (This is a special case of a derived
credential. See Section 5.3.5 for procedures when the derived credential is
issued by a different CSP.) Any requirements for credential delivery at the
appropriate Level shall still be satisfied.
NIST 800-63-1 Level 2 Identity Proofing Requirements
In Person
Remote
Basis for
issuing
credentials
Possession of a valid current primary government picture
ID that contains Applicant’s picture, and either address of
record or nationality of record (e.g., driver’s license or
Passport)
Possession of a valid current government ID (e.g., driver’s license or Passport)
number and financial or utility account number (e.g. checking account savings
account, utility account, loan or credit cared, or tax ID) confirmed via records of
either the government ID or account number. Note that confirmation for the
financial or utility account may require supplemental information rom the applicant.
RA and CSP
actions
RA inspects photo-ID,; compares picture to Applicant and
records the ID number, address and date of birth (DoB).
(RA optionally reviews personal information in records to
support issuance process “a” below)
RA inspects both ID number and account number supplied by Applicant (e.g., for
correct number of digits). Verifies information provided by Applicant including ID
number OR account number through record checks either with the applicable
agency or institution or through credit bureaus or similar databases, and confirms
that: name, DoB, address and other personal information in records are on balance
consistent with the application and sufficient to identify a unique individual. For
utility account numbers, confirmation shall be performed by verifying knowledge of
recent account activity. (This technique may also be applied to some financial
accounts.)
If the photo-ID appears valid and the photo matches
Applicant then:
a) If personal information in records includes a
telephone number or e-mail address, the CSP issues
credentials in a manner that confirms the ability for
the Applicant to receive telephone communication or
text messages a t phone number or e-mail address
associated with the applicant in records. Any secret
sent over an unprotected session shall be reset upon
first use: or
b) If ID confirms address so f record, RA authorizes or
CSP issues credentials. Notices is sent to address of
record, or;
c) If ID does not confirm address of record, CSP issues
credentials in manner that confirms the claimed
address.
Address/phone number confirmation and notification:
a) CSP issues credentials in a manner that confirms the ability of the applicant to
receive mail at a physical address associated with the Applicant in records; or
b) If personal information in records includes a telephone number or e-mail
address, the CSP issues credentials in a manner that confirms the ability of the
Applicant to receive telephone communications or text message at phone
number or e-mail address associated with the Applicant in records. Any secret
sent over an unprotected session shall be reset upon first use; or
c) CSP issues credentials. RA or CSP sends notice to an address of record.
NIST 800-63-1 Level 3 Identity Proofing Requirements
In Person
Remote
Basis for
issuing
credentials
Possession of a verified current primary government picture
ID that contains Applicant’s picture, and either address of
record or nationality of record (e.g., driver’s license or
Passport)
Possession of a valid Government ID (e.g., a driver’s license or Passport) number
and a financial or utility account number (e.g., checking account, savings
account, utility account, loan or credit card) confirmed via records of both
numbers. Note that confirmation of the financial or utility account may require
supplemental information from the applicant.
RA and CSP
actions
RA inspects photo-ID and verifies via the issuing government
agency or through credit bureaus or similar databases.
Confirms that: name, DoB, address and other personal
information in record are consistent with the application.
Compares picture to Applicant and records ID number.
RA verifies information provided by Applicant including ID number AND account
number through record checks either with the applicable agency or institution
or through credit bureaus or similar databases, and confirms that: name, DoB,
address and other personal information in records are consistent with the
application and sufficient to identify a unique individual. For utility account
numbers, confirmation shall be performed by verifying knowledge of recent
account activity. (This technique may also be applied to some financial
accounts.)
If ID is valid and photo matches Applicant, then:
a) If personal information in records includes a telephone
number, the CSP issues credentials in a manner that
confirms the ability of the Applicant to receive telephone
communications at a number associated with the
Applicant in records, while recording the Applicant’s voice
or using alternative means that establish an equivalent
level of non-repudiation; or
b) If ID confirms address of record, RA authorizes or CSP
issues credentials. Notice is sent to address of record, or;
c) If ID does not confirm address of record, CSP issues
credentials in a manner that confirms the claimed
address.
Address confirmation:
a)
CSP issues credentials in a manner that confirms the ability of the applicant
to receive mail at a physical address associated with the Applicant in
records; or
b) If personal information in records includes a telephone number, the CSP
issues credentials in a manner that confirms the ability of the Applicant to
receive telephone communications at a number associated with the
Applicant in records. CSP records the Applicant’s voice or using alternative
means that establish an equivalent level of non-repudiation.
NIST 800-63-1 Level 4 Identity Proofing Requirements
In Person
Remote
Basis for
issuing
credentials
In-person appearance and verification of:
a) a current primary Government Picture ID that contains Applicant’s picture, and either address of
record or nationality of record (e.g., driver’s license or passport), and;
b) either a second, independent Government ID document that contains current corroborating
information (e.g., either address of record or nationality of record), OR verification of a financial
account number (e.g., checking account, savings account, loan or credit card) confirmed via records.
Not Applicable
RA and CSP
actions
Primary Photo ID:
RA inspects photo-ID and verifies via the issuing government agency or through credit bureaus or similar
databases. Confirms that: name, DoB, address, and other personal information in record are consistent
with the application. Compares picture to Applicant and records ID number.
Secondary Government ID or financial account
a) RA inspects secondary Government ID and if apparently valid, confirms that the identifying
information is consistent with the primary Photo-ID, or;
b) RA verifies financial account number supplied by Applicant through record checks or through credit
bureaus or similar databases, and confirms that: name, DoB, address, and other personal information
in records are on balance consistent with the application and sufficient to identify a unique individual.
Not Applicable
[Note: Address of record shall be confirmed through validation of either the primary or secondary ID.]
Current Biometric
RA records a current biometric (e.g., photograph or fingerprints) to ensure that Applicant cannot
repudiate application.
Credential Issuance
CSP issues credentials in a manner that confirms address of record.
FBCA Identification Requirements by Assurance Level
Level
Identification Requirements
Basisc
Identity may be established by in-person proofing before a Registration Authority or Trusted Agent; or remotely verifying
information provided by applicant including ID number and account number through record checks either with the applicable
agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal
information in records are consistent with the application and sufficient to identify a unique individual.
Address confirmation:
a) Issue credentials in a manner that confirms the address of record supplied by the applicant; or
b) Issue credentials in a manner that confirms the ability of the applicant to receive telephone communications at a number
associated with the applicant in records, while recording the applicant’s voice.
Medium
(all
policies)
Identity shall be established by in-person proofing before the Registration Authority, Trusted Agent or an entity certified by a
State or Federal Entity as being authorized to confirm identities; information provided shall be verified to ensure legitimacy. A
trust relationship between the Trusted Agent and the applicant which is based on an in-person antecedent may suffice as meeting
the in-person identity proofing requirement. Credentials required are one Federal Government-issued Picture I.D., one REAL ID
Act compliant picture ID1, or two Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Non-REAL ID Act
compliant Drivers License). Any credentials presented must be unexpired.
Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent
identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document.
For PIV-I, credentials required are two identity source documents in original form. The identity source documents must come
from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one
document shall be a valid State or Federal Government-issued picture identification (ID). For PIV-I, the use of an in-person
antecedent is not applicable.
High
Identity established by in-person appearance before the Registration Authority or Trusted Agent; information provided shall be
checked to ensure legitimacy
Credentials required are either one Federal Government-issued Picture I.D., or two Non-Federal Government I.D.s, one of which
shall be a photo I.D. (e.g., Drivers License)
PIV
For compliance with the PIV-I control objectives, departments and agencies shall follow an identity proofing and registration
process that meets the requirements defined below when issuing identity credentials.
5 PERSONAL IDENTITY VERIFICATION (PIV) OF FEDERAL EMPLOYEES AND CONTRACTORS
+ The organization shall adopt and use an approved identity proofing and registration process.
+ The process shall begin with initiation of a National Agency Check with Written Inquiries (NACI) or other Office of Personnel
Management (OPM) or National Security community investigation required for Federal employment. This requirement may
also be satisfied by locating and referencing a completed and successfully adjudicated NACI. At a minimum, the FBI
National Criminal History Check (fingerprint check) shall be completed before credential issuance. Beginning with Part 2,
Identity credentials issued to individuals without a completed NACI or equivalent must be electronically distinguishable from
identity credentials issued to individuals who have a completed investigation. Appendix C, Background Check Descriptions,
provides further details on NAC and NACI.
+ The applicant must appear in-person at least once before the issuance of a PIV credential.
+ During identity proofing, the applicant shall be required to provide two forms of identity source documents in original form. The
identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136,
Employment Eligibility Verification. At least one document shall be a valid State or Federal government-issued picture
identification (ID).
+ The PIV identity proofing, registration and issuance process shall adhere to the principle of separation of duties to ensure that no
single individual has the capability to issue a PIV credential without the cooperation of another authorized person.
The identity proofing and registration process used when verifying the identity of the applicant shall be accredited by the
department or agency as satisfying the requirements above and approved in writing by the head of the Federal department
or agency. Two examples of processes that meet these requirements are provided in Appendix A, PIV Processes.
DEA Example
•
Physicians have the option of e-prescribing controlled substances as of June
1, 2010, if they comply with specific requirements, as described below.
• Physicians must first undergo a verification process (either in person or
remotely) in order to receive authorization to e-prescribe controlled
substances.
• Access controls must be established prior to e-prescribing controlled
substances.
• Physicians must use a two-factor credential to e-prescribe controlled
substances.
• Physicians must comply with notification requirements if they lose their
hard token or if they discover that their security controls have been
compromised.
• Physicians must use a compliant e-prescribing application in order to eprescribe controlled substances.
Source: http://www.ama-assn.org/ama1/pub/upload/mm/399/dea-eprescriptions-final-rule-summary.pdf
DEA Example
•
Identity Proofing
• Authentication must occur by an authorized third party (federally approved credential
service provide (CSP) or CAs)
• CSPs and CAs are required to conduct identity proofing at NIST SP 800-63-1 Assurance
Level 3 (requiring either in-person or remote identity proofing)
• Logical access controls are set after authentication credentials are issued, which verifies that
the authenticated user has the authority to perform the requested operation (may be rolebased).
•
Someone other than the prescriber needs to authenticate the prescriber
• Credentialing can also be completed in-house within a hospital credential office, but two
people must be responsible for this
•
Verification of identity is required via two-factor authentication
• If a hard token is used, it must be a cryptographic device or meet the Federal Information
Processing Standard 140-2 Security Level 1
•
Physicians can use their own digital certificate to sign eRxs for controlled substances,
and can be used as part of the two-factor authentication as long as the certificate is
from a CA cross-certified with the FBCA at the basic assurance level (this is being
confirmed)
Sec. 1311.20 Coordinators for CSOS digital certificate holders.
(a) Each registrant, regardless of number of digital certificates issued, must designate one or more responsible
persons to serve as that registrant's CSOS coordinator regarding issues pertaining to issuance of, revocation of,
and changes to digital certificates issued under that registrant's DEA registration. While the coordinator will be
the main point of contact between one or more DEA registered locations and the CSOS Certification Authority, all
digital certificate activities are the responsibility of the registrant with whom the digital certificate is associated.
Even when an individual registrant,i.e. , an individual practitioner, is applying for a digital certificate to order
controlled substances a CSOS Coordinator must be designated; though in such a case, the individual practitioner
may also serve as the coordinator.
(b) Once designated, coordinators must identify themselves, on a one-time basis, to the Certification Authority. If
a designated coordinator changes, the Certification Authority must be notified of the change and the new
responsibilities assumed by each of the registrant's coordinators, if applicable. Coordinators must complete the
application that the DEA Certification Authority provides and submit the following:
(1) Two copies of identification, one of which must be a government-issued photographic identification.
(2) A copy of each current DEA Certificate of Registration (DEA form 223) for each registered location for which
the coordinator will be responsible or, if the applicant (or their employer) has not been issued a DEA registration,
a copy of each application for registration of the applicant or the applicant's employer.
(3) The applicant must have the completed application notarized and forward the completed application and
accompanying documentation to the DEA Certification Authority.
(c) Coordinators will communicate with the Certification Authority regarding digital certificate applications,
renewals and revocations. For applicants applying for a digital certificate from the DEA Certification Authority,
and for applicants applying for a power of attorney digital certificate for a DEA registrant, the registrant's
Coordinator must verify the applicant's identity, review the application package, and submit the completed
package to the Certification Authority.
DEA Example
• Under the IFR, e-prescribers must prove their identities using two of
the three following factors:
• Something you know, such as a password or response to a
challenge question;
• Something you have, such as a hard token or device separate
from the computer; or
• Something you are, such as biometric data.
DIRECT
•
Key Concepts of the DIRECT project (from presentation by John Hall)
• Direct enables push-based transport – a sender pushes information to
one or more recipients
• Direct Messages act as containers of health information
• Direct Addresses are used to route Direct Messages
• Digital certificates are used to protect Direct Messages in transit and to
express trust relationships
• SMTP is used to transport Direct Messages
• Security/Trust Agents (STAs) such as Health Information Service
Providers (HISPs) are responsible for providing the services necessary
for exchange using Direct
DIRECT
•
Each Direct Address must have at least one X.509v3 digital certificate
associated with it
–
–
•
•
•
Address-bound certificate – certificate tied to a specific Direct Address
Domain-bound certificate – certificate tied to the Domain that is part of a Direct
Address (also known as organizationally-bound certificate)
Digital certificates are used within Direct to secure Direct Messages in
transit and to express trust relationships
Certificates in Direct are not intended to be used to protect data at rest or to
provide legal non-repudiation through signing of content.
Certificates in Direct are used for both encryption and signing
–
–
Encryption protects data from access by attackers and restricts access to data
to receiving STA
Signing provides integrity protection and “good enough” non-repudiation for
transport (signature ties sending STA to transaction)
DIRECT
•
Trust relationships are expressed using digital certificates. A party may
choose to trust a specific certificate, as well as any certificate that
cryptographically chains to a trust anchor.
•
Certificates are issued only to parties that agree to abide by specified trust
policies. These policies often cover:
– Certificate applicability (i.e., purposes for which certificates are issued)
– Identity verification of parties
– Security requirements of parties
•
Setting trust policy is outside the domain of the Direct Project.
– For health information exchange, policy originates with the HITPC and ONC
– Communities may further build upon those policies
DIRECT
Direct Project does not require particular policies or processes for
identity proofing
– Matter of policy that is outside scope of Direct Project
All states, implementing communities, and national HISPs do require
entities seeking to enroll to provide identifying information.
Information required is based on:
– What is needed to obtain a certificate
– What is needed to establish a foundation of trust between exchange
participants
Individual
• In-person proofing before a Registration Authority,
trusted agent, or an entity such as a notary public
• Requires one of: Federal Government-issued photo
ID, READ ID Act compliant photo ID, or two nonfederal IDs (one of which must be a photo ID
Organization
• Requires organization name, postal address,
documentation proving existence of the organization
• Organization must be HIPAA covered or a BA, or a
healthcare-related organization that protects PHI
with HIPAA-equivalent protections
• Also requires identity validation of the requesting
organizational representative
20
• Organizations further identity proof their agents
Electronic Submission of Medical
Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 3, 2012
Schedule for Identity Proofing SWG
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 Document validation process with
non-repudiation
assurance of non-repudiation of
review
signer and delegation(s)
October 31, 2012
Gaps in policy and
standards
Identify gaps in standards, process
and policy and make
recommendations
November 7, 2012
Review SWG
recommendation
Review final report
Definitions
Digital Signature (NIST)
The result of a cryptographic transformation of data that, when properly
implemented, provides a mechanism for verifying origin authentication, data
integrity and signatory non-repudiation.
Data Integrity (NIST)
Data integrity is 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.
Non-repudiation (NIST)
Non-repudiation is 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 entity from successfully denying
involvement in a previous action.
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. Must include the digital identity of the
grantor, the digital identity of the grantee, the rights granted, duration of grant in
a format that is usable in transaction and AoR signature events and is verifiable
by a third party for non-repudiation purposes.
General Requirements
 Solution must
 be implementable for pilot in Q1/Q2 2013
 scale to all providers and payers
 minimize the operational impact required to establish , maintain
or use a digital identity
 provide for non-repudiation without resorting to audit logs or
validation of system configuration
 Standards -- required
 NIST 800-63-1 Level 3/4 (December 2011)
 NIST 800-57 Part 1 (Revision 3 July 2012)
 Federal Bridge Certification Authority Medium Level
 X.509v3+ Digital Certificates
Sub Workgroup: Digital Signatures
Goal
–
Define process, artifacts and standards for
transaction and document bundle digital
signatures for esMD
Requirements
– Must provide for non-repudiation as part of the
credentials and artifacts
– Must ensure data integrity
In-Scope
– Use Case 1 and 2 transactions
– AoR L1 (Signature binding to aggregated
document bundle)
– Signature workflow
– Signature artifacts
– Identification of relevant standards
Out-of-Scope
– AoR L2
– AoR L3
25
Deliverable: “Summary White Paper”
– Assumptions
– Statement of Problem
– Recommended Solution(s)
• Review of Standards (e.g. OASIS,
IHE, HL7, …)
• Transaction signature process
• Transaction artifacts to meet Use Case
1 and 2 requirements
• Document Bundle signature process
• Artifacts to meet AoR L1 requirements
• Data Integrity requirements
• Non-repudiation assurance
– Identify gaps in current policy impacting
Digital Signatures
– References
Sub Workgroup: Delegation and Proxy
Goal
–
Define credentials, artifacts and process for
Delegation of Rights for esMD
Requirements
– Must provide for non-repudiation (NIST definition)
as part of the credentials and artifacts
– Revocable
In-Scope
– Use Case 1 and AoR L1 Delegation of Rights
requirements
– Delegation/Proxy workflow
– Delegation/Proxy artifacts
– Identification of relevant standards
Out-of-Scope
– AoR L2
– AoR L3
26
Deliverable: “Summary White Paper”
– Assumptions
– Statement of Problem
– Recommended Solution(s)
• Review of Standards (e.g. OASIS,
IHE, HL7, …)
• Proxy/Delegation Credential/Artifact(s)
• Operational consideration for
Proxy/Delegation Creation
• Scope/Content of Proxy/Delegation
• Revocation of Proxy
• Credential Transaction proxy
requirements
• Transaction artifacts to meet Use Case
1 requirements
• Document Bundle proxy signature
process
• Artifacts to meet AoR L1 signature
proxy requirements
• Data Integrity requirements
• Non-repudiation assurance
– Identify gaps in current policy impacting
Delegation & Proxy
– References
Standards for Digital Signature and
Delegation of Rights
Document Link
ITI TF-1
Title & Version / Notes
IHE IT Infrastructure Technical Framework: Volume 1: Integration Profiles, Revision 9.0
ITI TF-2a
IHE IT Infrastructure Technical Framework: Volume 2a: Transactions Part A – Sections 3.1-3.28, Revision 9.0 Aug 31 2012
ITI TF-2b
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
Aug 31 2012
NIST SP 800-63-1
OASIS DSS Core Spec
Electronic Authentication Guideline
Digital Signature Service Core Protocols, Elements, and Bindings, Version 1.0
Dec 2011
Apr 11 2007
XML DigSig
All DSS Standards
XML Signature Syntax and Processing (Second Edition), W3C Recommendation W3C
Jun 10 2008
FIPS PUB 186-3
IETF RFC 6277
Digital Signature Standard
Online Certificate Status Protocol Algorithm Agility
Jun 2009
Jun 2011
IETF RFC 6283
Extensible Markup Language Evidence Record Syntax
Jul 2011
IETF RFC 5698
Data Structure for the Security Suitability of Cryptographic Algorithms
Nov 2009
IETF RFC 5280
IETF RFC 5276
IETF RFC 4998
IETF RFC 3851
Internet X.509 Public Key Infrastructure Certificate 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
Internet X.509 Public Key Infrastructure Proxy Certificate Profile
May 2008
Aug 2008
Aug 2007
July 2004
ITI TF-3
IETF RFC 3820
FBCA X.509 Certificate Policy X.509 Certificate Policy for the Federal Bridge Certification Authority, Version 2.25
Date
Aug 31, 2012
Aug 31 2012
Jun 2004
Dec 9 2011
Assumptions
AoR Level 1
• Source record for episode of care exists and has been finalized
• Need to address externally provided records (e.g. from another
provider) that are the basis for a decision
• Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
W3C XMLdigsig
This document specifies XML digital signature processing rules and syntax. XML
Signatures provide integrity, message authentication, and/or signer authentication
services for data of any type, whether located within the XML that includes the
signature or elsewhere.
Integrity "The property that data has not been changed, destroyed, or lost in an unauthorized or
accidental manner." [SEC] A simple checksum can provide integrity from incidental changes in the
data; message authentication is similar but also protects against an active attack to alter the data
whereby a change in the checksum is introduced so as to match the change in the data. Object
Authentication, Message The property, given an authentication code/protected checksum, that
tampering with both the data and checksum, so as to introduce changes while seemingly
preserving integrity, are still detected. "A signature should identify what is signed, making it
impracticable to falsify or alter either the signed matter or the signature without detection." [Digital
Signature Guidelines, ABA].
Authentication, Signer The property that the identity of the signer is as claimed. "A signature should
indicate who signed a document, message or record, and should be difficult for another person to
produce without authorization." [Digital Signature Guidelines, ABA] Note, signer authentication is
an application decision (e.g., does the signing key actually correspond to a specific identity) that is
supported by, but out of scope, of this specification.
FIPS – 186 (Digital Signature Standards)
INTRODUCTION .................................................................................................................................. 1
2. GLOSSARY OF TERMS, ACRONYMS AND MATHEMATICAL SYMBOLS ....................................... 2
2.1 TERMS AND DEFINITIONS ................................................................................................................ 2
2.2 ACRONYMS ................................................................................................................................... 5
2.3 MATHEMATICAL SYMBOLS................................................................................................................6
3. GENERAL DISCUSSION....................................................................................................................... 9
3.1 INITIAL SETUP ............................................................................................................................... 11
3.2 DIGITAL SIGNATURE GENERATION.................................................................................................. 12
3.3 DIGITAL SIGNATURE VERIFICATION AND VALIDATION ....................................................................... 13
THE DIGITAL SIGNATURE ALGORITHM (DSA) ............................................................................... 15
4.1 DSA PARAMETERS........................................................................................................................ 15
4.2 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA ................................................ 15
4.3 DSA DOMAIN PARAMETERS........................................................................................................... 16
4.3.1 Domain Parameter Generation......................................................................................17
4.3.2 Domain Parameter Management...................................................................................17
4.4 KEY PAIRS ............................................................................................................... ................... 17
4.4.1 DSA Key Pair Generation..............................................................................................17
4.4.2 Key Pair Management ...................................................................................................18
4.5 DSA PER-MESSAGE SECRET NUMBER........................................................................................... 18
4.6 DSA SIGNATURE GENERATION ...................................................................................................... 19
4.7 DSA SIGNATURE VERIFICATION AND VALIDATION............................................................................ 19
5. THE RSA DIGITAL SIGNATURE ALGORITHM.................................................................................. 22
5.1 RSA KEY PAIR GENERATION ......................................................................................................... 22
5.2 KEY PAIR MANAGEMENT ................................................................................................................ 23
5.3 ASSURANCES...............................................................................................................................23
5.4 ANS X9.31 ................................................................................................................................ 23
5.5 PKCS #1 ................................................................................................................................... 24
6. THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA).............................................26
6.1 ECDSA DOMAIN PARAMETERS...................................................................................................... 26
6.1.1 Domain Parameter Generation......................................................................................26
6.1.2 Domain Parameter Management...................................................................................28
6.2 PRIVATE/PUBLIC KEYS .................................................................................................................. 28
6.2.1 Key Pair Generation.......................................................................................................28
6.2.2 Key Pair Management ...................................................................................................29
6.3 SECRET NUMBER GENERATION...................................................................................................... 29
6.4 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION ........................................................ 29
6.5 ASSURANCES...............................................................................................................................30
APPENDIX A: GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS ........................... 31
Review of W3C XMLdigsig
•
•
XML Signatures are applied to arbitrary digital content (data objects) via an
indirection.
• Data objects are digested, the resulting value is placed in an element (with other
information) and that element is then digested and cryptographically signed.
XML digital signatures are represented by the Signature element which has the
following structure (where "?" denotes zero or one occurrence; "+" denotes one or
more occurrences; and "*" denotes zero or more occurrences):
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI? >
(<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo>)?
( <Object ID?>)*
</Signature>
Review of W3C XML DigSig
• Signatures are related to data objects via Uniform Resource
Identifiers (URIs)
• Within an XML document, signatures are related to local data
objects via fragment identifiers
• Local data can either be within an enveloping signature (parent) or
be an enclosed enveloped signature (child)
• Detached signatures can be utilized over external network resources
or local data objects residing within the same XML document as
sibling elements
• Care should be taken to avoid collisions violating the ID
uniqueness validity constraint by choosing different names for
the signature element and other elements such as the ID
W3C XML DigSig
Required
element consists
of two
processes:
Validation of
Signature and
Validation of
Each Reference
Indicates the
key to be
used to
validate the
signature
W3C XML DigSig
[s02-12] The required SignedInfo element is the information that is actually signed. Core validation of
SignedInfo consists of two mandatory processes: validation of the signature over SignedInfo and
validation of each Reference digest within SignedInfo. Note that the algorithms used in calculating the
SignatureValue are also included in the signed information while the SignatureValue element is outside
SignedInfo.
[s03] The CanonicalizationMethod is the algorithm that is used to canonicalize the SignedInfo element
before it is digested as part of the signature operation. Note that this example, and all examples in this
specification, are not in canonical form.
[s04] The SignatureMethod is the algorithm that is used to convert the canonicalized SignedInfo into the
SignatureValue. It is a combination of a digest algorithm and a key dependent algorithm and possibly
other algorithms such as padding, for example RSA-SHA1. The algorithm names are signed to resist
attacks based on substituting a weaker algorithm. To promote application interoperability we specify a
set of signature algorithms that MUST be implemented, though their use is at the discretion of the
signature creator. We specify additional algorithms as RECOMMENDED or OPTIONAL for
implementation; the design also permits arbitrary user specified algorithms.
[s05-11] Each Reference element includes the digest method and resulting digest value calculated over the
identified data object. It also may include transformations that produced the input to the digest
operation. A data object is signed by computing its digest value and a signature over that value. The
signature is later checked via reference and signature validation.
[s14-16] KeyInfo indicates the key to be used to validate the signature. Possible forms for identification
include certificates, key names, and key agreement algorithms and information -- we define only a few.
KeyInfo is optional for two reasons. First, the signer may not wish to reveal key information to all
document processing parties. Second, the information may be known within the application's context
and need not be represented explicitly. Since KeyInfo is outside of SignedInfo, if the signer wishes to
bind the keying information to the signature, a Reference can easily identify and include the KeyInfo as
part of the signature.
Review of Proxy Certificate
Standards
• IETF 3280
• Proxy Certificate: A certificate that is derived from, and signed
by, a normal X.509 Public Key End Entity Certificate or by
another Proxy Certificate to provide restricted proxying and
delegation within a PKI based authentication system
Proxy Certificate (PC) Standards
•
A Proxy Certificate is an X.509 public key certificate with the following properties:
• It is signed by either an X.509 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 independent identity from the identity
of the issuing EEC, for example in conjunction with attribute assertions as defined
in [i3].
• It contains a new X.509 extension to identify it as a PC and to place policies on the
use of the PC. This new extension, along with other X.509 fields and extensions,
are used to enable proper path validation and use of the PC.
Proxy Certificate
•
•
•
The process of creating a PC is as follows:
• A new public and private key pair is generated.
• That key pair is used to create a request for a Proxy Certificate that
conforms to the profile described in this document.
• A Proxy Certificate, signed by the private key of the EEC or by
another PC, is created in response to the request. During this
process, the PC request is verified to ensure that the requested PC
is valid (e.g., it is not an EEC, the PC fields are appropriately set,
etc).
When a PC is created as part of a delegation from entity A to entity B,
this process is modified by performing steps #1 and #2 within entity B,
then passing the PC request from entity B to entity A over an
authenticated, integrity checked channel, then entity A performs step #3
and passes the PC back to entity B.
Path validation of a PC is very similar to normal path validation, with a
few additional checks to ensure, for example, proper PC signing
constraints.
Review of SAML 2.0
Security Assertion Markup Language:
• 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].
• They are typically embedded in other structures for transport, such as HTTP
POST requests or XML-encoded SOAP messages.
• The SAML bindings specification [SAMLBind] provides frameworks for the
embedding and transport of SAML protocol messages.
• The SAML profiles specification [SAMLProf] provides a baseline set of
profiles for the use of SAML assertions and protocols to accomplish specific
use cases or achieve interoperability when using SAML features.
SAML 2.0
•
•
•
•
The components primarily permit transfer of identity, authentication,
attribute, and authorization information between autonomous organizations
that have an established trust relationship.
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.
The means by which lower-level communication or messaging protocols
(such as HTTP or SOAP) are used to transport SAML protocol messages
between participants is defined by the SAML bindings.
SAML 2.0
•
•
•
SAML profiles are used to satisfy issues such as Web Browser SSO profiles
• Profiles typically define constraints on the contents of SAML assertions, protocols, and
bindings in order to solve the business use case in an interoperable fashion.
• There are also Attribute Profiles, which do not refer to any protocol messages and
bindings, that define how to exchange attribute information using assertions in ways
that align with a number of common usage environments (e.g. X.500/ LDAP directories,
DCE).
Metadata defines a way to express and share configuration information between SAML
parties. For instance, an entity's supported SAML bindings, operational roles (IDP, SP, etc),
identifier information, supporting identity attributes, and key information for encryption and
signing can be expressed using SAML metadata XML documents. SAML Metadata is
defined by its own XML schema.
In a number of situations, a service provider may need to have detailed information
regarding the type and strength of authentication that a user employed when they
authenticated at an identity provider.
• A SAML authentication context is used in (or referred to from) an assertion's
authentication statement to carry this information. An SP can also include an
authentication context in a request to an IdP to request that the user be authenticated
using a specific set of authentication requirements, such as a multi-factor
authentication. There is a general XML schema that defines the mechanisms for
creating authentication context declarations and a set of SAML-defined Authentication
Context Classes, each with their own XML schema, that describe commonly used
methods of authentication.
SAML 2.0
Additional Material – esMD AoR
Reference from prior AoR call materials
esMD Initiative Overview
Provider
Directories
Registration
Authority
Payer Entity
Certificate
Authority
Provider Entity
esMD UC 1: Provider Registration
Contractors /
Intermediaries
Agent
Payer
Payer
Internal
System
Gateway
esMD UC 2: Secure eMDR Transmission
esMD AoR Level 1
Digital Identities Bundle Signatures
Provider
(Individual or
Organization)
AoR -- Phased Scope of Work
Level 1 – Current Focus
Digital signature on
aggregated documents
(bundle)
•
•
•
Focus is on signing a bundle of documents prior to transmission to
satisfy an eMDR
Define requirements for esMD UC 1 and UC 2 Signature Artifacts
May assist with EHR Certification criteria in the future
Level 2 - TBD
Digital signature on an
individual document
•
•
Focus is on signing an individual document prior to sending or at
the point of creation by providers
Will inform EHR Certification criteria for signatures on patient
documentation
Level 3 - TBD
Digital signature to allow
traceability of individual
contributions to a document
•
•
Focus is on signing documents and individual contributions at
the point of creation by providers
Will inform EHR Certification criteria for one or multiple
signatures on patient documentation
44
Topics for Digital Identities and AoR Workgroup Effort
1.
2.
3.
4.
5.
6.
Identity proofing
Digital identity management
Encryption
Digital signatures and artifacts
Delegation of Rights
Author of Record
45
Initiative Requirement Summary
Encryption
Delegation
of Rights
Author
of
Record
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Org/Individual
Yes
Yes
Yes
Yes
Yes
Healthcare
Directories
Org/Individual
Yes
Yes
Yes
Yes
No
LCC
Org/Individual
Yes
Yes
Yes
Yes
Yes
Query Health
Org/Individual
Yes
Yes
Yes
No
No
Transitions of
Care
Org/Individual
Yes
Yes
Yes
Yes
Yes
Identify Proofing
Digital Identity
Management
Signing
(Exchange Artifact)
DS4P
Org/Individual
Yes
Direct Project
Address/Server
esMD
Initiative
Mandatory
Optional with consequences
Optional
Future Uses
46
esMD Requirements
Topics
UC1: Registration
UC2: eMDR
AoR L1 Bundle
Identity Proofing
Required
Required
Required
Digital Credential
Management
Required
Required
Required
Digital Signatures &
Signature Artifacts
Required
Required
Required
Delegation of Rights*
Required
Required
Required
Required
Required
Required
Required
Required
Required
Other
Characteristics of solution
Non-Repudiation
Characteristics of solution
Data Integrity
* Required if the action of the responsible party is being represented by a third party
Scope for AoR (L1)
•
•
•
•
•
•
•
In Scope
Identify Proofing as part of Non-Repudiation of
Actor Identity
Digital Credential Management required for NonRepudiation Actions (Signing and Delegation),
Data Integrity and Encryption
Digital Signatures and Signature Artifacts for
Identity and Non-Repudiation
Digital Credentials and Artifacts for NonRepudiation of Delegation as required by UC1
and AoR L1
Data Integrity requirement actions and artifacts
Encryption of PHI requirements
Interactions with External Provider Directories
•
•
•
•
Out of Scope
Interactions between:
• Payer and Payer Contractors
• Provider and Agent
• Payer or Payer Contractor and Gateway
Transaction level encryption
Document level signatures and individual
contribution signatures
Defining delegation of rights within and between
Providers and other authors
User Story / Workflow
Overall User Story Components
1) All Actors obtain and maintain a non-repudiation digital identity
2) Provider registers for esMD (see UC1)*
3) Payer requests documentation (see UC2)*
4) Provider submits digitally signed document (bundle) to address
request by payer
5) Payer validates the digital credentials, signature artifacts and,
where appropriate, delegation of rights
*User Stories for UC 1 and 2 have already been defined.
Workgroup will help define bullets 1) and 4)
Sub-Workgroups
1. Identity Proofing
•Wednesday 1-2 pm
•Robert Dieterle (Lead)
•Proof of identity
requirements
•Allowed proofing
processes
2. Digital Credentials
• Wednesday 10-11 am
• Debbie Bucci (Lead)
• Credential Life Cycle
(issuance, maintenance
and revocation)
• Credential uses
(Identity, Signing, Proxy,
Encryption, Data
Integrity)
• Specific use credentials
(e.g. Direct)
3. Signing and Delegation
• Wednesday 2-3 pm
• Robert Dieterle (Lead)
• Signature and
Delegation artifacts
• Workflow issues
• Delegation process