1. Electronic Submission of Medical Documentation (esMD) Identity Proofing Sub-Workgroup October 17, 2012

2. Sub Workgroup: Identity Proofing Goal –Define required process for identity proofing of healthcare individuals and organizations for esMD Requirements –NIST SP 800-63-1 Level 3 authentication (December 2011) –Federal Bridge Certification Authority Medium Level In-Scope –RA qualifications and certification –Combining RA process with other healthcare identity proofing (e.g. credentialing) –Policy issues regarding identity proofing Out-of-Scope –Digital Credential Management –Digital Signatures –Delegation of Rights Deliverable: “Summary White Paper” –Assumptions –Statement of Problem –Recommended Solution(s) Review of Standards (e.g. NIST, FICAM, FBCA) Certification requirements for RAs Proof of identity requirements for –Entities –Individuals Allowed proofing processes (e.g. as part of credentialing?) Frequency of Identity review Appeals process for denial Variation based on specific credentials/use? Revocation (triggers and process) –Identify gaps in current policy impacting Identity Proofing –References 2

3. Schedule for Identity Proofing SWG DateTopicDeliverable(s) September 26, 2012Standards (NIST/FBCA) List and review of standards October 3, 2012Industry examplesList and review industry examples October 10, 2012Requirements for identity Requirements for individuals and organizations October 17, 2012RA requirements“Certification” process for RAs October 24, 2012RA processesCombine with, frequency, appeals, revocation October 31, 2012Gaps in policy and standards Identify gaps in standards, process and policy and make recommendations November 7, 2012Review SWG recommendation Review final report

4. Identity Proofing – Individual Provider 1)Individual provider fills our application for Identity Proofing 2)Individual provider assembles required documents and picture IDs 3)Verification of identity process as part of: a)CA/RA current level 4 defined process b)Provider organization in-person verification process a)Credentialing (e.g. for delivery of services in a hospital) b)HR process c)License process (State, DEA, other) d)FDA process e)Private Companies such as DAON c)Public Notary (?) 4)Records documents and biometric (picture / fingerprint) 5)Validates documents to primary source and verifies and compares demographic information 6)Verification of NPI or other Payer Identification (e.g., verify address associated with NPI or other Payer Identification) (Note: demographics / address must be maintained/updated prior to identity proofing as part of this process) 7)Issues confirmation to address of record 8)Issues Proof of Identity to CA

5. Identity Proofing – Organization Provider 1)Authorized representative fills out application for Identity Proofing 2)Authorized representative assembles required documents a.Papers of incorporation b.State license c.Federal tax ID d.Motion by board of directors for representative to act on organizations behalf 3)Authorized representative with prior identity proofing and digital credentials submits documents and personal ID as part of identity process: a)State licensing b)Payer review c)Accreditation by recognized organization (e.g. The Joint Commissions) d)Public Notary (?) 4)Records documents and biometric of representative (picture / fingerprint) 5)Validates document to primary source and verifies and compares demographic information 6)Verification of NPI or other Payer Identification 7)Issues verification to address of record 8)Issues Proof of Identity to CA

6. Federal PKI Policy Authority – Registration Authority Overview Registration Authority Overview Pursuant to the definition contained in the Federal Common Policy the Registration Authority is defined as an entity that is responsible for identification and authentication of certificate subjects but does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of an authorized CA).

7. Federal PKI Policy Authority – Registration Authority Overview Registration Authority Purpose The Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA)11 to collect and verify each Subscriber’s identity and information to be entered into his or her public key certificate. The RA performs its function in accordance with the Federal Common Policy and the approved CPS, and any other relevant agreements or policy documents such as those published by the SSPWG under the Authentication and Identity Policy Framework for Federal Agencies. Areas and activities overseen by the RA include, but are not limited to: – In person proofing – Verification and validation of identity documents – Enrollment and registration – Oversee Identity Issues related to (addition by SWG) Credential issuance Credential usage Credential revocation Post issuance updates and additions Credential re-issuance The RA may, at the discretion of the Contracting Federal Agency, delegate functional roles and duties within the organization to a LRA. Such delegation must be consistent with Federal Policy…

8. Federal PKI Policy Authority – Registration Authority Overview Functional Area Certification Authority Registratio n Authority Key management functions, such as the generation of CA key pairs, the secure management of CA private keys, and the distribution of CA public keysYESNO Establishing an environment and procedure for certificate applicants to submit their certificate applications (e.g., creating a web-based enrollment page)YES The identification and authentication of individuals or entities applying for a certificateYES The approval or rejection of certificate applicationsYES The signing and issuance of certificates in a repository, where certificates are made available for potential relying partiesYESNO The publication of certificates in a repository, where certificates are made available for potential relying partiesYESNO The initiation of certificate revocations, either at the subscriber’s request or upon the entity’s own initiativeYES The revocation of certificates, including by such means as issuing and publishing Certificate Revocation Lists (CRL) or providing revocation information via Online Certificate Status Protocol (OCSP) or other online methodsYESNO The identification and authentication of individuals or entities submitting requests to renew certificates or seeking a new certificate following a re-keying process, and processes set forth above for certificates issues in response to approved renewal or re-keying requestsYES

9. X.509 Certificate Policy For The U.S. Federal PKI Common Policy Framework Version 3647 - 1.17 December 9, 2011 1.3.1.6 Certification Authority The CA is the collection of hardware, software and operating personnel that create, sign, and issue public key certificates to subscribers. The CA is responsible for the issuing and managing certificates including: The certificate manufacturing process Publication of certificates Revocation of certificates Generation and destruction of CA signing keys Ensuring that all aspects of the CA services, operations, and infrastructure related to certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP 1.3.2. Registration Authorities The registration authorities (RAs) collect and verify each subscriber’s identity and information that is to be entered into the subscriber’s public key certificate. The RA performs its function in accordance with a CPS approved by the FPKIPA. The RA is responsible for: Control over the registration process relying party may use information in the certificate (such as CP identifiers) to determine the suitability of the certificate for a particular use. For this certificate policy, the relying party may be any entity that wishes to validate the binding of a public key to the name (or role) of a federal employee, contractor, or other affiliated personnel.

10. Federal PKI Policy Authority – Registration Authority Overview Registration Authority Roles and Responsibilities The following roles and responsibilities are identified, in addition to the provisions of traditional references used to define the roles and responsibilities of a RA. 3.1 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas, including policy development and management, and providing guidance where appropriate. – Acts in accordance with the FPKIPA Charter, as approved. – Determines the standards and evaluation criteria for PKI SSPs, and is the Federal entity responsible for conducting the Operational Capabilities Demonstration (OCD) used to validate the qualification and suitability of a perspective PKI SSP. This includes the ability to support Federal agency RA functions in the manner required to achieve compliance with Federal policy and guidance. The OCD is conducted with the participation of the SSPWG. – Establishes and oversees the subcommittees required to develop policy, procedures, and guidance for Federal agencies. 3.2 Federal PKI Policy Authority The FPKIPA acts to establish, monitor and evaluate the Federal common trust anchor, as provided for in the Federal Common Policy. – Responsible for the compliance audit for PKI SSP vendors, and the respective RA entities operating by the Contracting Federal Agencies. Provisions and controls related to compliance audit are contained in the Federal Common Policy. – Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common Policy. – Responsible for the implementation, operating, audit and oversight of the Federal Common Policy root CA, used to sign the subordinate CA operated by a PKI SSP vendor in support of a Contracting Federal Agency. This includes provisions for compliance audits and C&A of the Federal Common Policy root CA.

11. Federal PKI Policy Authority – Registration Authority Overview 3.3 PKI Shared Service Provider Each PKI SSP is responsible for the following areas, as it pertains to the RA function. – Each PKI SSP is responsible for working with the SSPWG, the FPKIPA, and the Contracting Federal Agency to provide for compliance audits, as provided for in the Federal Common Policy. – Each PKI SSP is responsible for the maintenance, and warranty communications with the vendors providing the RA components listed in the Registration Authority Component Requirements section. 3.4 Contracting Federal Agency Each Contracting Federal Agency is responsible for the following areas, as it pertains to the RA function. – Responsible for any Federal information security requirements, such as compliance audits or contracting for C&A services, where required. This includes creation of a System Security Plan, Risk Management Plan, Continuity of Operations Plan, and related documentation and processes required by the Federal government. – Identification and management of the authoritative data source used to create digital credentials. – The management, operational and technical controls over the RA, in compliance with the Federal Common Policy, the CPS, the RPS, and associated agreements. This includes any LRA delegated functions.

12. Federal PKI Policy Authority – Registration Authority Overview Registration Authority Practice Statement X.509 Certificate Policy for the Common Policy Framework (Federal Common Policy) Federal Smart Card Policy Federal Identity Assurance Policy Consideration of NIST policy FIPS PKI standards Other American Bar Association PKI Assessment Guide Industry Specific Reference ANS X9.79-1 PKI Practices and Policy Framework

13. Federal PKI Policy Authority – Registration Authority Overview Registration Authority Component Requirements The following component requirements comprise the RA function, and are evaluated during the Operational Capability Demonstration (OCD) conducted as part of the approval process for a PKI SSP candidate review. The PKI SSP must be able to demonstrate the ability to interoperate with the RA function and services as outlined in the Operational capability Demonstration Criteria. The PKI SSPs are encouraged to provide components that conform to the Common Criteria Certificate Issuance and Management Components (CIMC) Protection Profile, specifically the role separation considered in the CIMC. The PKI SSP is required to provide an automated end-to-end RA function, which the Contracting Federal Agency may or may not elect to utilize14. The automated RA function will be evaluated against the Identity and Authentication Policy Framework for Federal Agencies, which includes the Federal Common Policy; the Federal Smart Card Policy, and; the Federal Identity Assurance Policy. Specific components and functionality incorporated into the RA shall include: Automated certificate issuance and management software supporting: Certificate issuance where key pair generation is performed on a GSC-IS compliant smart card; Out-of-band management requests for issuance of digital credentials, and post issuance life cycle management; Secure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificates; The ability to perform post issuance updates and management of hardware tokens (smart cards form factor).

14. esMD Specific RA Suggested Requirements Policy and Practices (CPS/RPS) 1.RA is able to provide identity proofing (IDP) for both Organizations and Individuals 2.RA identity proofing is accepted by all qualified FBCA cross- certified CAs 3.RAs may be certified by qualified industry accreditation / certification agencies 4.Can exiting IDP by new local RAs be reused? (time frame – e.g. must have occurred within prior 6 months) 5.How do we make this real –RFP –Create process under ONC or CMS or FBCA to establish the policies and practices for standardized RA functionality

15. Electronic Submission of Medical Documentation (esMD) Digital Signature and Delegation of Rights Sub-Workgroup October 17, 2012

16. 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 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 16

17. 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 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 17

18. Schedule for Identity Proofing SWG DateTopicDeliverable(s) September 26, 2012StandardsList and review of standards October 3, 2012Standards and industry examples List and review of additional standards industry examples October 10, 2012Transaction and AoR digital signature and delegation process Document digital signature and delegation of rights process October 17, 2012Transaction and AoR signature and delegation artifacts Document digital signature and delegation of rights artifacts October 24, 2012Validation process for non-repudiation review Document validation process with assurance of non-repudiation of signer and delegation(s) October 31, 2012Gaps in policy and standards Identify gaps in standards, process and policy and make recommendations November 7, 2012Review SWG recommendation Review final report

19. 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

20. Discussion 1.Reviewed LCC use case assumptions about use of CDA as the basis for communicating the plan of care and the digital signatures and delegation artifacts – Larry advocates it be part of the CDA and not external metadata 2.Architectural Issues –National network –Design for “cloud”? –Authentication to system with credential Based on attributes and credentials allow specific cascaded workflows (e.g. prescribe controlled substances) Shibboleth (higher education) –Federated method Local – e.g. EHR National services for authentication or complete AoR Level 1

21. Delegation of Rights Methods for delegation: 1)Proxy certificates a.Advantages 1)Understood form and use 2)Does not require additional delegation artifacts (self contained) 3)Holds information for active date, purpose, … b.Disadvantages 1)No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user certificate 2)Requires the delegation activity to be done with the specific proxy certificate 3)Revocation process – who and how is it handled 2)Delegation of Rights Artifacts (e.g SAML) a.Advantages 1)Understood form and use 2)Requires use of artifact (eg. SAML to convey delegation) 3)Easy to use (sign with own certificate and provide assertion as proof of right 4)Uses certificate verification to ensure identity of grantor and grantee b.Disadvantages 1)Revocation process – who and how is it handled 2)May not hold all required information without modification of standard

22. 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