Embed Size (px)
DESCRIPTION
Electronic Submission of Medical Documentation (esMD) Identity Proofing Sub-Workgroup. October 17, 2012. Sub Workgroup: Identity Proofing. Deliverable: “Summary White Paper” Assumptions Statement of Problem Recommended Solution(s) Review of Standards (e.g. NIST, FICAM, FBCA) - PowerPoint PPT Presentation
Citation preview
Electronic Submission of Medical Documentation (esMD)
Identity Proofing Sub-Workgroup
October 17 2012
Sub Workgroup Identity ProofingGoal
ndash Define required process for identity proofing of healthcare individuals and organizations for esMD
Requirementsndash NIST SP 800-63-1 Level 3 authentication
(December 2011)ndash Federal Bridge Certification Authority Medium Level
In-Scope ndash RA qualifications and certificationndash Combining RA process with other healthcare identity
proofing (eg credentialing)ndash Policy issues regarding identity proofing
Out-of-Scopendash Digital Credential Managementndash Digital Signaturesndash Delegation of Rights
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg NIST FICAM FBCA)
bull Certification requirements for RAsbull Proof of identity requirements for
ndash Entitiesndash Individuals
bull Allowed proofing processes (eg as part of credentialing)
bull Frequency of Identity reviewbull Appeals process for denialbull Variation based on specific
credentialsusebull Revocation (triggers and process)
ndash Identify gaps in current policy impacting Identity Proofing
ndash References
2
Schedule for Identity Proofing SWG
Date Topic Deliverable(s)
September 26 2012 Standards (NISTFBCA)
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 ldquoCertificationrdquo 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
Identity Proofing ndash Individual Provider1) Individual provider fills our application for Identity Proofing2) Individual provider assembles required documents and picture IDs3) Verification of identity process as part of
a) CARA current level 4 defined processb) Provider organization in-person verification process
a) Credentialing (eg for delivery of services in a hospital)b) HR processc) 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 information6) Verification of NPI or other Payer Identification (eg verify address associated with NPI or
other Payer Identification) (Note demographics address must be maintainedupdated prior to identity proofing as part of this process)
7) Issues confirmation to address of record8) Issues Proof of Identity to CA
Identity Proofing ndash Organization Provider1) Authorized representative fills out application for Identity Proofing2) Authorized representative assembles required documents
a Papers of incorporationb State licensec Federal tax IDd 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 licensingb) Payer reviewc) Accreditation by recognized organization (eg 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 information6) Verification of NPI or other Payer Identification7) Issues verification to address of record8) Issues Proof of Identity to CA
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Overviewbull 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 (ie an RA is delegated certain tasks on behalf of an authorized CA)
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority PurposeThe Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA)11 to collect and verify each Subscriberrsquos 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
ndash In person proofingndash Verification and validation of identity documentsndash Enrollment and registrationndash Oversee Identity Issues related to (addition by SWG)
bull Credential issuancebull Credential usagebull Credential revocationbull Post issuance updates and additionsbull 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 Policyhellip
Federal PKI Policy Authority ndash Registration Authority Overview
Functional AreaCertification
AuthorityRegistration 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 keys YES NO Establishing an environment and procedure for certificate applicants to submit their certificate applications (eg creating a web-based enrollment page) YES YES The identification and authentication of individuals or entities applying for a certificate YES YES The approval or rejection of certificate applications YES YES The signing and issuance of certificates in a repository where certificates are made available for potential relying parties YES NO The publication of certificates in a repository where certificates are made available for potential relying parties YES NO The initiation of certificate revocations either at the subscriberrsquos request or upon the entityrsquos own initiative YES YES 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 methods YES NO 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 requests YES YES
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Sub Workgroup Identity ProofingGoal
ndash Define required process for identity proofing of healthcare individuals and organizations for esMD
Requirementsndash NIST SP 800-63-1 Level 3 authentication
(December 2011)ndash Federal Bridge Certification Authority Medium Level
In-Scope ndash RA qualifications and certificationndash Combining RA process with other healthcare identity
proofing (eg credentialing)ndash Policy issues regarding identity proofing
Out-of-Scopendash Digital Credential Managementndash Digital Signaturesndash Delegation of Rights
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg NIST FICAM FBCA)
bull Certification requirements for RAsbull Proof of identity requirements for
ndash Entitiesndash Individuals
bull Allowed proofing processes (eg as part of credentialing)
bull Frequency of Identity reviewbull Appeals process for denialbull Variation based on specific
credentialsusebull Revocation (triggers and process)
ndash Identify gaps in current policy impacting Identity Proofing
ndash References
2
Schedule for Identity Proofing SWG
Date Topic Deliverable(s)
September 26 2012 Standards (NISTFBCA)
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 ldquoCertificationrdquo 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
Identity Proofing ndash Individual Provider1) Individual provider fills our application for Identity Proofing2) Individual provider assembles required documents and picture IDs3) Verification of identity process as part of
a) CARA current level 4 defined processb) Provider organization in-person verification process
a) Credentialing (eg for delivery of services in a hospital)b) HR processc) 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 information6) Verification of NPI or other Payer Identification (eg verify address associated with NPI or
other Payer Identification) (Note demographics address must be maintainedupdated prior to identity proofing as part of this process)
7) Issues confirmation to address of record8) Issues Proof of Identity to CA
Identity Proofing ndash Organization Provider1) Authorized representative fills out application for Identity Proofing2) Authorized representative assembles required documents
a Papers of incorporationb State licensec Federal tax IDd 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 licensingb) Payer reviewc) Accreditation by recognized organization (eg 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 information6) Verification of NPI or other Payer Identification7) Issues verification to address of record8) Issues Proof of Identity to CA
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Overviewbull 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 (ie an RA is delegated certain tasks on behalf of an authorized CA)
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority PurposeThe Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA)11 to collect and verify each Subscriberrsquos 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
ndash In person proofingndash Verification and validation of identity documentsndash Enrollment and registrationndash Oversee Identity Issues related to (addition by SWG)
bull Credential issuancebull Credential usagebull Credential revocationbull Post issuance updates and additionsbull 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 Policyhellip
Federal PKI Policy Authority ndash Registration Authority Overview
Functional AreaCertification
AuthorityRegistration 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 keys YES NO Establishing an environment and procedure for certificate applicants to submit their certificate applications (eg creating a web-based enrollment page) YES YES The identification and authentication of individuals or entities applying for a certificate YES YES The approval or rejection of certificate applications YES YES The signing and issuance of certificates in a repository where certificates are made available for potential relying parties YES NO The publication of certificates in a repository where certificates are made available for potential relying parties YES NO The initiation of certificate revocations either at the subscriberrsquos request or upon the entityrsquos own initiative YES YES 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 methods YES NO 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 requests YES YES
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Schedule for Identity Proofing SWG
Date Topic Deliverable(s)
September 26 2012 Standards (NISTFBCA)
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 ldquoCertificationrdquo 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
Identity Proofing ndash Individual Provider1) Individual provider fills our application for Identity Proofing2) Individual provider assembles required documents and picture IDs3) Verification of identity process as part of
a) CARA current level 4 defined processb) Provider organization in-person verification process
a) Credentialing (eg for delivery of services in a hospital)b) HR processc) 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 information6) Verification of NPI or other Payer Identification (eg verify address associated with NPI or
other Payer Identification) (Note demographics address must be maintainedupdated prior to identity proofing as part of this process)
7) Issues confirmation to address of record8) Issues Proof of Identity to CA
Identity Proofing ndash Organization Provider1) Authorized representative fills out application for Identity Proofing2) Authorized representative assembles required documents
a Papers of incorporationb State licensec Federal tax IDd 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 licensingb) Payer reviewc) Accreditation by recognized organization (eg 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 information6) Verification of NPI or other Payer Identification7) Issues verification to address of record8) Issues Proof of Identity to CA
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Overviewbull 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 (ie an RA is delegated certain tasks on behalf of an authorized CA)
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority PurposeThe Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA)11 to collect and verify each Subscriberrsquos 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
ndash In person proofingndash Verification and validation of identity documentsndash Enrollment and registrationndash Oversee Identity Issues related to (addition by SWG)
bull Credential issuancebull Credential usagebull Credential revocationbull Post issuance updates and additionsbull 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 Policyhellip
Federal PKI Policy Authority ndash Registration Authority Overview
Functional AreaCertification
AuthorityRegistration 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 keys YES NO Establishing an environment and procedure for certificate applicants to submit their certificate applications (eg creating a web-based enrollment page) YES YES The identification and authentication of individuals or entities applying for a certificate YES YES The approval or rejection of certificate applications YES YES The signing and issuance of certificates in a repository where certificates are made available for potential relying parties YES NO The publication of certificates in a repository where certificates are made available for potential relying parties YES NO The initiation of certificate revocations either at the subscriberrsquos request or upon the entityrsquos own initiative YES YES 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 methods YES NO 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 requests YES YES
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Identity Proofing ndash Individual Provider1) Individual provider fills our application for Identity Proofing2) Individual provider assembles required documents and picture IDs3) Verification of identity process as part of
a) CARA current level 4 defined processb) Provider organization in-person verification process
a) Credentialing (eg for delivery of services in a hospital)b) HR processc) 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 information6) Verification of NPI or other Payer Identification (eg verify address associated with NPI or
other Payer Identification) (Note demographics address must be maintainedupdated prior to identity proofing as part of this process)
7) Issues confirmation to address of record8) Issues Proof of Identity to CA
Identity Proofing ndash Organization Provider1) Authorized representative fills out application for Identity Proofing2) Authorized representative assembles required documents
a Papers of incorporationb State licensec Federal tax IDd 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 licensingb) Payer reviewc) Accreditation by recognized organization (eg 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 information6) Verification of NPI or other Payer Identification7) Issues verification to address of record8) Issues Proof of Identity to CA
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Overviewbull 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 (ie an RA is delegated certain tasks on behalf of an authorized CA)
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority PurposeThe Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA)11 to collect and verify each Subscriberrsquos 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
ndash In person proofingndash Verification and validation of identity documentsndash Enrollment and registrationndash Oversee Identity Issues related to (addition by SWG)
bull Credential issuancebull Credential usagebull Credential revocationbull Post issuance updates and additionsbull 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 Policyhellip
Federal PKI Policy Authority ndash Registration Authority Overview
Functional AreaCertification
AuthorityRegistration 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 keys YES NO Establishing an environment and procedure for certificate applicants to submit their certificate applications (eg creating a web-based enrollment page) YES YES The identification and authentication of individuals or entities applying for a certificate YES YES The approval or rejection of certificate applications YES YES The signing and issuance of certificates in a repository where certificates are made available for potential relying parties YES NO The publication of certificates in a repository where certificates are made available for potential relying parties YES NO The initiation of certificate revocations either at the subscriberrsquos request or upon the entityrsquos own initiative YES YES 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 methods YES NO 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 requests YES YES
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Identity Proofing ndash Organization Provider1) Authorized representative fills out application for Identity Proofing2) Authorized representative assembles required documents
a Papers of incorporationb State licensec Federal tax IDd 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 licensingb) Payer reviewc) Accreditation by recognized organization (eg 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 information6) Verification of NPI or other Payer Identification7) Issues verification to address of record8) Issues Proof of Identity to CA
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Overviewbull 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 (ie an RA is delegated certain tasks on behalf of an authorized CA)
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority PurposeThe Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA)11 to collect and verify each Subscriberrsquos 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
ndash In person proofingndash Verification and validation of identity documentsndash Enrollment and registrationndash Oversee Identity Issues related to (addition by SWG)
bull Credential issuancebull Credential usagebull Credential revocationbull Post issuance updates and additionsbull 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 Policyhellip
Federal PKI Policy Authority ndash Registration Authority Overview
Functional AreaCertification
AuthorityRegistration 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 keys YES NO Establishing an environment and procedure for certificate applicants to submit their certificate applications (eg creating a web-based enrollment page) YES YES The identification and authentication of individuals or entities applying for a certificate YES YES The approval or rejection of certificate applications YES YES The signing and issuance of certificates in a repository where certificates are made available for potential relying parties YES NO The publication of certificates in a repository where certificates are made available for potential relying parties YES NO The initiation of certificate revocations either at the subscriberrsquos request or upon the entityrsquos own initiative YES YES 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 methods YES NO 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 requests YES YES
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Overviewbull 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 (ie an RA is delegated certain tasks on behalf of an authorized CA)
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority PurposeThe Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA)11 to collect and verify each Subscriberrsquos 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
ndash In person proofingndash Verification and validation of identity documentsndash Enrollment and registrationndash Oversee Identity Issues related to (addition by SWG)
bull Credential issuancebull Credential usagebull Credential revocationbull Post issuance updates and additionsbull 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 Policyhellip
Federal PKI Policy Authority ndash Registration Authority Overview
Functional AreaCertification
AuthorityRegistration 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 keys YES NO Establishing an environment and procedure for certificate applicants to submit their certificate applications (eg creating a web-based enrollment page) YES YES The identification and authentication of individuals or entities applying for a certificate YES YES The approval or rejection of certificate applications YES YES The signing and issuance of certificates in a repository where certificates are made available for potential relying parties YES NO The publication of certificates in a repository where certificates are made available for potential relying parties YES NO The initiation of certificate revocations either at the subscriberrsquos request or upon the entityrsquos own initiative YES YES 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 methods YES NO 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 requests YES YES
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority PurposeThe Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA)11 to collect and verify each Subscriberrsquos 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
ndash In person proofingndash Verification and validation of identity documentsndash Enrollment and registrationndash Oversee Identity Issues related to (addition by SWG)
bull Credential issuancebull Credential usagebull Credential revocationbull Post issuance updates and additionsbull 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 Policyhellip
Federal PKI Policy Authority ndash Registration Authority Overview
Functional AreaCertification
AuthorityRegistration 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 keys YES NO Establishing an environment and procedure for certificate applicants to submit their certificate applications (eg creating a web-based enrollment page) YES YES The identification and authentication of individuals or entities applying for a certificate YES YES The approval or rejection of certificate applications YES YES The signing and issuance of certificates in a repository where certificates are made available for potential relying parties YES NO The publication of certificates in a repository where certificates are made available for potential relying parties YES NO The initiation of certificate revocations either at the subscriberrsquos request or upon the entityrsquos own initiative YES YES 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 methods YES NO 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 requests YES YES
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Federal PKI Policy Authority ndash Registration Authority Overview
Functional AreaCertification
AuthorityRegistration 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 keys YES NO Establishing an environment and procedure for certificate applicants to submit their certificate applications (eg creating a web-based enrollment page) YES YES The identification and authentication of individuals or entities applying for a certificate YES YES The approval or rejection of certificate applications YES YES The signing and issuance of certificates in a repository where certificates are made available for potential relying parties YES NO The publication of certificates in a repository where certificates are made available for potential relying parties YES NO The initiation of certificate revocations either at the subscriberrsquos request or upon the entityrsquos own initiative YES YES 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 methods YES NO 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 requests YES YES
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
X509 Certificate Policy For The US Federal PKI Common Policy Framework Version 3647 - 117 December 9 2011
1316 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 132 Registration Authorities The registration authorities (RAs) collect and verify each subscriberrsquos identity and information that is to be entered into
the subscriberrsquos 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
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Federal PKI Policy Authority ndash 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
31 Shared Service Provider Working Group (SSPWG) The SSPWG is responsible for the following areas including policy development and management and providing guidance where appropriate
ndash Acts in accordance with the FPKIPA Charter as approved ndash 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
ndash Establishes and oversees the subcommittees required to develop policy procedures and guidance for Federal agencies
32 Federal PKI Policy AuthorityThe FPKIPA acts to establish monitor and evaluate the Federal common trust anchor as provided for in the Federal Common
Policyndash 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 Policyndash Responsible for the review and acceptance of the CPS and RPS documents directly related to the Federal Common
Policyndash 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 CampA of the Federal Common Policy root CA
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Federal PKI Policy Authority ndash Registration Authority Overview
33 PKI Shared Service ProviderEach PKI SSP is responsible for the following areas as it pertains to the RA function
ndash 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
ndash 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
34 Contracting Federal AgencyEach Contracting Federal Agency is responsible for the following areas as it pertains to the RA function
ndash Responsible for any Federal information security requirements such as compliance audits or contracting for CampA 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
ndash Identification and management of the authoritative data source used to create digital credentialsndash 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
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Federal PKI Policy Authority ndash Registration Authority OverviewRegistration Authority Practice Statementbull X509 Certificate Policy for the Common Policy Framework (Federal
Common Policy)bull Federal Smart Card Policybull Federal Identity Assurance Policybull Consideration of NIST policy
bull FIPSbull PKI standards
bull Other bull American Bar Association PKI Assessment Guidebull Industry Specific Referencebull ANS X979-1 PKI Practices and Policy Framework
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Federal PKI Policy Authority ndash Registration Authority Overview
Registration Authority Component RequirementsThe 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 CIMCThe 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
1048708 Automated certificate issuance and management software supportingbullCertificate issuance where key pair generation is performed on a GSC-IS compliant smart cardbullOut-of-band management requests for issuance of digital credentials and post issuance life cycle managementbullSecure communications with an authoritative data source and Certification Authority (CA) used for the purposes of issuing certificatesbullThe ability to perform post issuance updates and management of hardware tokens (smart cards form factor)
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
esMD Specific RA Suggested RequirementsPolicy and Practices (CPSRPS)1 RA is able to provide identity proofing (IDP) for both Organizations
and Individuals2 RA identity proofing is accepted by all qualified FBCA cross-
certified CAs3 RAs may be certified by qualified industry accreditation
certification agencies4 Can exiting IDP by new local RAs be reused (time frame ndash eg
must have occurred within prior 6 months)5 How do we make this real
ndash RFPndash Create process under ONC or CMS or FBCA to establish the
policies and practices for standardized RA functionality
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Electronic Submission of Medical Documentation (esMD)
Digital Signature and Delegation of Rights
Sub-Workgroup
October 17 2012
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Sub Workgroup Digital SignaturesGoal
ndash Define process artifacts and standards for transaction and document bundle digital signatures for esMD
Requirementsndash Must provide for non-repudiation as part of the
credentials and artifactsndash Must ensure data integrity
In-Scopendash Use Case 1 and 2 transactionsndash AoR L1 (Signature binding to aggregated
document bundle)ndash Signature workflowndash Signature artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull Transaction signature processbull Transaction artifacts to meet Use Case
1 and 2 requirementsbull Document Bundle signature processbull Artifacts to meet AoR L1 requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Digital Signatures
ndash References
16
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Sub Workgroup Delegation and Proxy Goal
ndash Define credentials artifacts and process for Delegation of Rights for esMD
Requirementsndash Must provide for non-repudiation (NIST definition)
as part of the credentials and artifactsndash Revocable
In-Scopendash Use Case 1 and AoR L1 Delegation of Rights
requirementsndash DelegationProxy workflowndash DelegationProxy artifactsndash Identification of relevant standards
Out-of-Scopendash AoR L2ndash AoR L3
Deliverable ldquoSummary White Paperrdquondash Assumptionsndash Statement of Problemndash Recommended Solution(s)
bull Review of Standards (eg OASIS IHE HL7 hellip)
bull ProxyDelegation CredentialArtifact(s) bull Operational consideration for
ProxyDelegation Creationbull ScopeContent of ProxyDelegationbull Revocation of Proxybull Credential Transaction proxy
requirementsbull Transaction artifacts to meet Use Case
1 requirementsbull Document Bundle proxy signature
processbull Artifacts to meet AoR L1 signature
proxy requirementsbull Data Integrity requirementsbull Non-repudiation assurance
ndash Identify gaps in current policy impacting Delegation amp Proxy
ndash References
17
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Schedule for Identity Proofing SWGDate 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 non-repudiation 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 2012 Review SWG recommendation
Review final report
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Assumptions
AoR Level 1bull Source record for episode of care exists and has been finalizedbull Need to address externally provided records (eg from another
provider) that are the basis for a decisionbull Need to address transition to digital signature (probably applies to
AoR Level 2 and 3
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
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 ndash Larry advocates it be part of the CDA and not external metadata
2 Architectural Issuesndash National network ndash Design for ldquocloudrdquondash Authentication to system with credential
bull Based on attributes and credentials allow specific cascaded workflows (eg prescribe controlled substances)
bull Shibboleth (higher education)ndash Federated method
bull Local ndash eg EHR bull National services for authentication or complete AoR Level 1
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
Delegation of RightsMethods for delegation1) Proxy certificates
a Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date purpose hellip
b Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user
certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process ndash who and how is it handled
2) Delegation of Rights Artifacts (eg SAML)a Advantages
1) Understood form and use2) Requires use of artifact (eg SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee
b Disadvantages1) Revocation process ndash who and how is it handled2) May not hold all required information without modification of standard
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
FIPS ndash 186 (Digital Signature Standards)
INTRODUCTION 1 2 GLOSSARY OF TERMS ACRONYMS AND MATHEMATICAL SYMBOLS 2 21 TERMS AND DEFINITIONS 2 22 ACRONYMS 5 23 MATHEMATICAL SYMBOLS6 3 GENERAL DISCUSSION 9 31 INITIAL SETUP 11 32 DIGITAL SIGNATURE GENERATION 12 33 DIGITAL SIGNATURE VERIFICATION AND VALIDATION 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) 15 41 DSA PARAMETERS 15 42 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA 15 43 DSA DOMAIN PARAMETERS 16 431 Domain Parameter Generation17 432 Domain Parameter Management17 44 KEY PAIRS 17 441 DSA Key Pair Generation17 442 Key Pair Management 18 45 DSA PER-MESSAGE SECRET NUMBER 18 46 DSA SIGNATURE GENERATION 19 47 DSA SIGNATURE VERIFICATION AND VALIDATION 19 5 THE RSA DIGITAL SIGNATURE ALGORITHM 22 51 RSA KEY PAIR GENERATION 22 52 KEY PAIR MANAGEMENT 23 53 ASSURANCES23 54 ANS X931 23 55 PKCS 1 24 6 THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)26 61 ECDSA DOMAIN PARAMETERS 26 611 Domain Parameter Generation26 612 Domain Parameter Management28 62 PRIVATEPUBLIC KEYS 28 621 Key Pair Generation28 622 Key Pair Management 29 63 SECRET NUMBER GENERATION 29 64 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION 29 65 ASSURANCES30 APPENDIX A GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS 31
