esMD+AoR+L1+SWG+1+(Digital+Credentials)+White+Paper

include component="page" wikiName="siframework" page="esMD Header"

=
All of the Use Case materials listed below have been consensus-approved and published to the [|S&I Framework Repository Browser]. For un-published, draft versions of any materials refer to the appropriate S&I Phase and/or workgroup.======

Consensus voting for the esMD AoR L1 Digital Credentials White Paper is now closed. Click here to see the votes.

Click below to download the Use Case in a MS Word document:

=0. Terms= The following are definitions of specific terms used in this document. For a full list of definitions see Appendix A: Glossary.


 * esMD** – electronic submission of Medical Documentation


 * esMD Program** – the program established by CMS for the electronic submission of Medical Documentation


 * esMD Phase 1** – the first phase of the esMD Program focused on the electronic submission of PDF(s) containing medical documentation in a C62 wrapper using the NwHIN Exchange. The primary source of the submission is through certified Health Information Handlers (HIHs). esMD Phase 1 started pilot production submission of documents in September of 2011.


 * esMD Phase 1 Transaction** – the transaction specified in the Implementation Guide for Electronic Submission of Medical Documentation Project (esMD) Version 2.9 (4/17/2012)


 * esMD Gateway** – the CMS NwHIN Connect instance that receives esMD Phase I transactions for CMS


 * esMD Initiative** – the current esMD Program effort in conjunction with the ONC S&I Framework is focused on three specific use cases: 1) Provider registration, 2) secure transmission of the electronic Medical Documentation Request, and 3) Author of Record, digital identities and digital signatures. With this initiative, the esMD Program is soliciting participation by commercial payers and including specific support for both CMS and commercial payers.

Individual - Healthcare providers with patient care responsibilities including physicians, advanced practice nurses, physician assistants, nurses, psychologists, emergency care providers, home health providers, definitive care providers, pharmacists and other personnel or their delegated agents involved in patient care (for the purposes of esMD Author of Record, “individual” does not apply to the patient).
 * esMD Initiative Transactions** – the specific transactions defined by the esMD Initiative use cases and the subsequent implementation guides


 * Organization or Entity** – in this document, any reference to an organization or entity is to a legal entity other than an Individual. In some cases, an Individual may also be the sole individual that is the owner/subject of a professional corporation (PC) or limited liability corporation (LLC); in which case, the Individual is the live person and PC or LLC is an organization or entity. Note: The term Organization will be used in this document.

=1.0 Summary= On September 15, 2011, the esMD Program launched a pilot to accept electronic submissions from providers via Health Information Handlers (HIHs). The current esMD initiative will enable Medicare Review Contractors to send electronic medical request letters, eliminating the need to send the paper letters via mail. The next release will also implement the replacement of wet signatures with Digital Signatures on the bundle of documents requested by CMS or the appropriate commercial requestor.
 * PKI Sponsor** – fills the role of a subscriber for non-human system components that are named as public key certificate subjects, and is responsible for meeting the obligations of subscribers as defined throughout NIST SP 800-32.

There is a need on CMS’s part to: 1) verify the identification of the individual or organization receiving Protected Health Information (PHI) contained in the eMDR and 2) to ensure authenticity of the documents submitted in response to the eMDR. These are requirements for participation in the esMD Program.

Three separate work groups were assembled to address Identity Proofing, Digital Credentials, Digital Signatures, and Delegation of Rights issues associated with Digital Signatures. The Digital Credential workgroup focused specifically on Digital Credential Management required to support Non-Repudiation Actions (Signing and Delegation), Data Integrity, and Encryption.

The workgroup recommendations are constrained by two primary factors; (1) the solution must be implemented within the first two quarters of calendar 2013, and (2) the systems that support esMD Initiative (including esMD Phase 1) would have to meet standards established by the Federal Information Security Management Act of 2002 (FISMA).

The workgroup identified a number of relevant standards. However, considering the FISMA requirements, special emphasis was placed on NIST SP 800-63-1 and X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA) version 2.25 in determining the core requirements for their recommendations. Section 6 of this document highlights a number of alternative solutions discussed during the evaluation including those belonging to Safe BioPharma’s FDA project, DEA’s e-Prescribe, and Direct.

The overall recommendation is that all Individuals and Organizations and their agents must use a digital certificate to sign esMD Initiative Transactions and document bundles (as defined in the esMD Initiative Author of Record Level 1 Use Case). The certificate’s root Certificate Authority (CA) must be cross certified with the FBCA at Medium Assurance or above. Additionally, the provider should authenticate to the signing module or application with at least one additional authentication factor prior to the actual signing event. Adding the additional factor meets NIST Level of Assurance (LOA) 3 and supports the non-repudiation assurances necessary for valid digital signatures. As technology options for both authentication and digital signing continue to evolve, the esMD Initiative should continue to monitor and update policies as appropriate to reflect improved technological capabilities. =2.0 Statement of Problem= Define the required process for issuing and managing digital credentials for the electronic submission of Medical Documentation to the Centers for Medicare and Medicaid Services (CMS) and commercial payers that adopt the esMD Initiative Implementation Guides. =3.0 Requirements= =4.0 Assumptions= The following assumptions were made by the Digital Credential Management SWG as part of their consideration of the esMD AoR Use Case: =5.0 Review of Standards= This section enumerates the relevant standards and provides a short review of their relevance to the problem.
 * 1) The following specific requirements were provided by the esMD Initiative Author of Record Level 1 workgroup:In general the solutions must:
 * be implementable for pilot in Q1/Q2 of calendar-year 2013
 * scale to all providers (any Individual or Organization that may submit a claim to a healthcare payer), healthcare payers and agents for either party
 * minimize the operational impact required to establish, maintain or use a digital identity and digital signature
 * allow the relying party to verify authenticity of the signature without resorting to audit logs or validation of system configuration
 * 1) Appropriate portions of the following standards must be supported:
 * NIST SP 800-63-1 Level 3 and above (December 2011)
 * NIST SP 800-57 Part 1 (Revision 3 July 2012)
 * NIST SP 800-89
 * Federal Bridge Certification Authority Medium Assurance Level
 * X.509v3+ Digital Certificates
 * 1) In-Scope:
 * Digital credential life cycle
 * Relevant standards
 * Policy issues regarding Digital Credentials
 * 1) Out-of-Scope (addressed by other esMD Initiative Author of Record Level 1 Sub-Workgroups):
 * Identity Proofing
 * Digital Signatures
 * Delegation of Rights
 * Must comply with US government standards and regulations.
 * All certificates must be issued to Individuals or Organizations, and include their unique identification number. Examples include: Provider NPI, Health Plan HPID, Other Entity OEID, or EIN.
 * CMS does not plan to issue credentials for digital signatures.
 * The esMD Initiative Implementation Guides require digital signatures for provider registration and the receipt of electronic Medical Documentation Requests (eMDRs)

OMB M-04-04 defines four levels of assurance--Levels 1 to 4--in terms of the consequences of authentication errors and misuse of credentials. Level 1 is the lowest assurance level, and Level 4 is the highest. The OMB guidance defines the required level of authentication assurance in terms of the likely consequences of an authentication error. As the consequences of an authentication error become more serious, the required level of assurance increases. The OMB guidance provides agencies with the criteria for determining the level of e-authentication assurance required for specific applications and transactions, based on the risks and their likelihood of occurrence with each application or transaction.

NIST SP 800-63-1 supplements OMB M-04-04 and provides technical implementation guidance to the agencies. CMS performed a risk assessment on all their major assets and as a general rule deemed that all of their external facing systems must, at a minimum, meet the NIST Level 3 Assurance level.

NIST LOA 3 provides multi-factor remote network authentication, where at least two authentication factors are required. Level 3 authentication is based on proof of possession of the allowed types of tokens listed in section 7.2 of SP 800-63-1. Multi-factor Software Cryptographic Tokens are allowed as well as any “hard” cryptographic token methods of Level 4. Level 3 authentication requires cryptographic strength mechanisms that protect the primary authentication token against compromise by online guessing, replay, session hijacking, eavesdropping attacks, and impersonation attacks. “Man-in-the-middle” attacks are strongly resisted when using FIPS 140-2 Level 2 or higher validated modules. Additional information about a validated FIPS 140-2 module can be found at: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2012.htm.

Authentication requires that the Claimant prove control of the token. The Claimant unlocks the token with a password or biometric, or uses a secure multi-token authentication protocol to establish two-factor authentication.

Agencies are, in general, issuing certificates under the policies specified in the Federal PKI Common Policy Framework [FBCA3] to satisfy FIPS 201 for PIV cards. Organizations outside the US Government have begun issuing credentials under a parallel set of policies and requirements known collectively as PIV Interoperability specifications (PIV-I). Agencies that were early adopters of PKI technology, and organizations outside the Federal government, issue PKI certificates under organization-specific policies instead of the Common Policy Framework. The primary mechanism for evaluating the assurance provided by public key certificates issued under organizationspecific policies is the policy mapping of the Federal Policy Authority to the Federal Bridge CA policies. These policies include the Rudimentary, Basic, Medium, Medium-HW, and High Assurance policies specified in [FBCA1]. These policies incorporate all aspects of the credential lifecycle, and include security controls (e.g., multi-party control and system auditing for CSPs). However, the FPKI policies are based on work that largely predates the NIST SP 800-63 specification, and the security requirements are not always strictly aligned.

The table below summarizes how certificates issued under the Common Policy Framework correspond to the e-authentication assurance levels for those policies relevant to the esMD Initiative. Table 1: FPKI Levels of Assurance
 * = **FPKI LOA** ||= **Assurance description** ||= **800-63-1**
 * Token and LOA** ||= **800-63-1**
 * ID Proofing** ||
 * **Basic** || Basic level of risk and compromise. Likelihood of malicious access not high ||= LOA3 ||= LOA3 ||
 * **Medium** || Moderate risk and compromise – includes monetary value or risk of fraud ||= LOA3 ||= LOA4 ||
 * **Medium**
 * Hardware**


 * Common-HW**
 * PIVI-HW** || High risk ||= LOA4 ||= LOA4 ||

=6.0 Evaluation of Alternative Solutions= This section lists alternative solutions that were considered and provides an evaluation of the merits of each.

6.1 DEA
The Drug Enforcement Administration (DEA) published an interim final rule in March of 2010 that proposed regulation for e-prescribing allowing doctors to electronically prescribe controlled substances. Users of e-prescribing systems for controlled substances sign the order by implementing a two factor authentication to the system. Two of the following three factors are required:
 * something you know (password or response to a challenge question),
 * something you have (hard token),or
 * something you are (biometric).

The interim final rule allows the use of a biometric as a substitute for a hard token or a password. The DEA consulted extensively with NIST for recommendations. Additionally, they purposefully did not specify a specific biometric as to allow for the greatest flexibility and adaptation.

The hard token must meet FIPS 140-2, and they have the option of obtaining a new token or adding an additional certificate to an existing token. Since the solution is hardware-based and the certificate must be bound with an existing DEA certificate, the DEA allows an FBCA Basic Assurance certificate.

The DEA is still considering alternatives that would not diminish the safety and security of the system. Additionally, they were hesitant to discuss while still in an interim status.

6.2 Direct
The Direct Project develops specifications for a secure, scalable, standards-based way to establish universal health addressing and transport for participants (including providers, laboratories, hospitals, pharmacies and patients) using SMTP, S/MIME, and X.509 certificates to securely transport health information over the Internet.

Direct requires the use of digital certificates for transport. The certificates are issued at domain, organization and address levels with additional attributes related to organizational affiliation. There is a requirement to use the same certificate for both signing and encryption, thus the certificate can never be used for non-repudiation purposes.

Direct should be considered as one of the transport options for commercial payers but Direct certificates would not be used for digital signature purposes.

6.3 Safe BioPharma, NCI, and FDA
In 2010, The National Cancer Institute (NCI) Cancer Therapy Evaluation Program (CTEP) performed a study to determine the effectiveness of automating the workflow of their various paper submissions. Researchers were given cell phones, tablets, and digital credentials issued by Safe-BioPharma that were cross-certified at Medium Assurance to use for digital signatures.

Safe BioPharma hosted a cloud-based digital signing service (DSS) that managed the workflow associated with the document. The workflow was as follows:
 * 1) Researchers self-provision themselves to the DSS using the email identified on their certificate and password.
 * 2) Documents are uploaded to the DSS and assigned to a specific workflow.
 * 3) Signatories are alerted via email that a document is ready for signature.
 * 4) Once all signatures are complete the originator is notified that the document is ready for download.

In order to submit those documents via the FDA electronic submissions gateway (ESG), a PKI certificate is needed to encrypt and sign the package for delivery. The ESG requirements are: =7.0 Recommended Solution= This section describes the recommended solution and describes the details of the solution in the following sub sections.
 * A separate letter of non-repudiation
 * A limited 3-year certificate that can be either self-signed or purchased through a commercial vendor. A list of recognized vendors is available on their website.
 * Additional commercial vendors not on that list or the trust anchors for self signed certificates would need to be coordinated out-of-band with the FDA.

7.1 Dependence on Identity Proofing
The issuance of digital credentials following this SWG’s recommendations requires that the Individual or Organization has successfully completed identity proofing with a certified RA following, at a minimum, identity verification guidelines for FBCA Medium Assurance as described in the recommendations from the Author of Record Identity Proofing SWG.

7.2 CA Qualifications and List
CAs submit Certification Practices Statements (CPSs) to the FPKI Management Authority for a compliance audit. CAs apply for cross-certification with the FBCA. Their applications and Certificate Policy are submitted to the FPKI Policy Authority (FPKIPA). The Certificate Policy WG (CPWG) maps their CP to the FBCA CP and provides the report of the mapping to the FPKIPA, which is responsible for the cross-certification and reviewing the audit submitted by the CA.

All CAs that have approved cross-certification for the following policies may be used for esMD Initiative signing:
 * FBCA Medium, FBCA Medium CBP
 * FBCA Medium Hardware
 * FBCA Medium Hardware CBP
 * FBCA Medium Device
 * FBCA Medium Device Hardware
 * PIV-I Hardware

A list of currently approved CAs is located at: http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Management-Authority-entities-crosscertified-with-the-FBCA.

7.3 Credential Types, Forms and Contents
This section describes the types of credentials/tokens and their forms.

7.3.1 FBCA Certificates
The below table lists the types of certificates that may be acceptable for esMD Initiative digital signatures. All certificates issued to individuals must include their unique identification number (Provider NPI, Health Plan HPID, Other Entity OEID, or EIN) in the subjectAlt name of the certificate. The FBCA indicates that group policies are not desired for non-repudiation efforts but it is possible that some CAs may have established additional policies that have been found appropriate for use by the Federal PKI Authority. In all cases, group policies must require that responsible individuals are held accountable for the group signature. CAs will need to be examined on a case by case basis.

Table 2: Types of Certificates


 * **Type** || **Contents** ||
 * **Individual** || * Identifies the subscriber
 * May have an organization affiliation ||
 * **Role** || * Where non-repudiation is desired
 * Identifies the role, not the subscriber
 * The role may be issued to many subscribers, but key pairs are unique
 * Cannot be shared
 * The sponsor must have an Individual certificate ||
 * **Device** || * System to system authentication and signing
 * Where non-repudiation is desired
 * Must have a human sponsor ||

The actual certificate is a series of three required fields arranged in a specific sequence:
 * 1) tbsCetificate: subject and issuer, a public key associated with the subject, a validity period, and other associated information.
 * 2) SignatureAlgorithm: identifier for the cryptographic algorithm used by the CA to sign this certificate.
 * 3) signatureValue: signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertifcate.

The following table lists values generally used within the Certificate field and aligns with the values used for the signature certificate defined within the FBCA PIV-I profile. Table 3: Certificate Field Values Begin and end dates for which the certificate is valid || required || DigitalSignature 1 NonRepudiation 1 || Required extension ||
 * **name** || **Additional Info** ||  ||
 * **version** || Value:2 for v3 certificate || required ||
 * **serialNumber** || Must be a positive integer || required ||
 * **signature** || Algorithm details || required ||
 * **Issuer** || RelativeDistinquishedName and OID of entity who has issued the certificate || required ||
 * **validity** || General time
 * **subject** || X.500 Distinguish name of certificate owner || required ||
 * **SubjectPublicKeyInfo** || Indicate algorithm used || required ||
 * **AuthorityKeyIdentifier** || Hash of public key used if there are multiple signing keys || Required extension ||
 * **subjectKeyIdentifier** || Hash of public key – assists in path construction || Required extension ||
 * **keyUsage** || Defines purpose
 * **certificatePolicies** || URI – policy OIDs || Required extension ||
 * **crlDistributionPoints** || URI || Required extension ||
 * **authorityInfoAccess** || Access method and location pair || Required extension ||
 * **IssuerAltName** || Associated other identities with the certificate issuer || Optional extensions ||
 * **subjectAltname** || Allows for alternative names or extension bound to the subject Suggested container for NPI or alternate payer ID shall include OID of ID issurer || Optional extensions ||

7.3.2 Authentication Tokens
The following Authentication tokens are considered appropriate for second factor use in the esMD Initiative. Credit card password generator || Generally a signed message (Something you have and something you know) || PKI certificate + PIN || (Something you have and something you know or something you are) || Verizon or Symantec OTP offering DAON IdX || Possession of device and control of key (Something you have and something you know or something you are) || PIV PIV-I ATM cards || Table 4: Valid Second Factor Authentication Tokens
 * **Type** || **Description** || **Examples** ||
 * **Single Factor One-Time**
 * Password (OTP) Device** || Hardware device (Something you have) || RSA key fob token
 * **Multi-Factor Cryptographic Token** || Key is stored on a disk or soft media and requires activation. Does not require a second factor
 * **Multi-Factor OTP** || OTP hardware device that requires activation via PIN or biometric
 * **Multi-Factor Cryptographic Device** || Hardware device that contains protected key that requires activation through a second factor

7.4 Credential Maintenance Requirements
This section draws directly from both the FPKI Certification Requirements and the Certificate Maintenance Lifecycle section of the FBCA CP. For convenience, we have paraphrased and highlighted the major requirements below. Please refer to the actual documents for detailed information.

7.4.1 Key Pair and Certificate Usage

 * Subscribers shall protect their private keys from access by other parties.
 * Restrictions in the intended scope of usage for a private key are specified through certificate extensions.

7.4.2. Certificate Renewal

 * Certificate renewal consists of issuing a new certificate with a new validity period and serial number while retaining all other information in the original certificate, including the public key.
 * Frequent renewal of certificates may assist in reducing the size of CRLs.
 * After certificate renewal, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.
 * A certificate may be renewed if the public key has not reached the end of its validity period, the associated private key has not been compromised, and the Subscriber name and attributes are unchanged.
 * Certificates may also be renewed when a CA re-keys.
 * Renewal shall only be accepted from certificate subjects, PKI sponsors, or RAs.
 * CAs may perform renewal of its subscriber certificates without a corresponding request, such as when the CA re-keys.

7.4.3. Certificate Re-Key
Re-key requests shall only be accepted from the subject of the certificate or PKI sponsors. Additionally, CAs and RAs may initiate re-key of a subscriber’s certificates without a corresponding request.
 * Re-keying a certificate consists of creating new certificates with a different public key (and serial number) while retaining the remaining contents of the old certificate that describe the subject.
 * The new certificate may be assigned a different validity period, key identifiers, specify a different CRL distribution point, and/or be signed with a different key.
 * Re-key of a certificate does not require a change to the subjectName and does not violate the requirement for name uniqueness.
 * Subscribers shall identify themselves for the purpose of re-keying.
 * After certificate re-key, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.

7.4.4. Modifications

 * Certificate modification consists of creating new certificates with subject information (e.g., a name or email address) that differs from the old certificate. For example, a CA may perform certificate modification for a Subscriber whose characteristics have changed (e.g., has just received a medical degree). The new certificate may have the same or different subject public key.
 * After certificate modification, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.
 * The Principal CA may request certificate modification for currently cross-certified CAs.
 * The validity period associated with the new certificate must not extend beyond the date of the old certificate MOA.
 * Proof of all subject information changes must be provided to the RA or other designated agent and verified before the modified certificate is issued.

7.4.5. Certificate Revocation and Suspension

 * Revocation requests must be authenticated. Requests to revoke a certificate may be authenticated using that certificate's associated private key, regardless of whether or not the private key has been compromised.
 * All CAs shall publish CRLs.
 * CAs that implement certificate revocation shall accept revocation requests from subscribers. CAs that issue certificates in association with Affiliated Organizations shall accept revocation requests from the Affiliated Organization named in the certificate. Requests for certificate revocation from other parties may be supported by CAs.
 * CAs that implement certificate revocation shall revoke certificates upon receipt of sufficient evidence of compromise or loss of the subscriber’s corresponding private key. A request to revoke a certificate shall identify the certificate to be revoked, explain the reason for revocation, and allow the request to be authenticated (e.g., digitally or manually signed).
 * CAs will revoke certificates as quickly as practical upon receipt of a proper revocation request. Revocation requests shall be processed before the next CRL is published, excepting those requests validated within 2 hours of CRL issuance. Revocation requests validated within 2 hours of CRL issuance shall be processed before the following CRL is published.
 * CRL issuance encompasses both CRL generation and publication.
 * The interval between CRLs shall not exceed 24 hours.
 * CRLs may be issued more frequently.
 * For principal CAs that are operated in an off-line manner, routine CRLs may be issued less frequently than specified above if the CA only issues: CA certificates, CSS certificates, and end user certificates solely for the administration of the principal CA.
 * However, the interval between routine CRL issuance shall not exceed 31 days.
 * CRLs shall be published within 4 hours of generation.
 * CRL shall be published no later than the time specified in the nextUpdate field of the previously issued CRL for the same scope.
 * If on-line revocation/status checking is supported by a CA, the latency of certificate status information distributed on-line by CAs or their delegated status responders must meet or exceed the requirements for CRL issuance.
 * A CA may also use other methods to publicize the certificates it has revoked. Any alternative method must meet the following requirements:
 * The alternative method must be described in the CA’s approved CPS.
 * The alternative method must provide authentication and integrity services commensurate with the assurance level of the certificate being verified.
 * The alternative method must meet the issuance and latency requirements for CRLs.
 * In the event of a Principal CA private key compromise or loss, the cross-certificate shall be revoked and a CRL shall be published at the earliest feasible time by the FPKI Management Authority.
 * For CAs, when a CA certificate is revoked or subscriber certificate is revoked because of compromise, or suspected compromise of a private key, a CRL must be issued within 18 hours for Medium and 6 hours for High Assurance.

7.4.6. Key Escrow and Recovery

 * CA signature private keys are never escrowed. There is no reason to revisit once the private key has been assigned to the document. If the private key is lost or compromised it is acceptable to generate new signing key pairs.
 * Subscriber key management keys may be escrowed to provide key recovery. CAs that support private key escrow for key management keys shall document their key recovery practices.
 * Under no circumstances will a subscriber signature key be held in trust by a third party.
 * CAs that support session key encapsulation and recovery shall identify the document describing the practices in the applicable CP.

7.4.7.Record Archive

 * 1) The CA archive must comply with applicable CMS legal and policy requirements. The minimum FBCA retention period for Medium Assurance is 10 years and 6 months, but records associated with minors may need to be retained for as long as 21 years.
 * 2) Archive records should include verification information to ensure the CA was properly operated and valid at the time of issuance and use. The following is a list of archive content required for Medium Assurance:
 * 3) Certificate Policy
 * 4) Certification Practice Statement
 * 5) Contractual obligations and other agreements concerning operation of the CA
 * 6) System configuration, modifications and update
 * 7) Certificate requests
 * 8) Revocation requests
 * 9) Subscriber agreements and the associated identity data collected
 * 10) Key generation, updates and changes
 * 11) CRLs
 * 12) Compromises and violations
 * 13) Archive information may only be released, upon request, to any subscribers or their legal agents involved in the transaction.

7.5. Trust Anchor
When verifying a digital certificate, the receiver needs to decide whether to trust the certificate. In order to do that, the verification process needs to determine whether the certificate presented can be associated with an existing top-level trusted certificate or trust anchor. Often this process involves chaining the certificate back through several issuers. The process is termed "path discovery" and the resulting chain is called a "certification path."

Many systems are able to build these paths using certificates stored in their local trust store. However, if the entire path is not included in the trust store, the verifier will be unable to completely verify that the certificate used can be entirely trusted. Some products are able to dynamically discover the certificate using information within the certificates, but some agencies such as DOD and DOJ prefer to offload that process to a separate system.

It is this SWG’s recommendation that compliant systems will implement the ability to create a complete chain to the trust anchor from their internal store or by chaining directly through the certificate issuers. The Server-based Certificate Validation Protocol (SCVP) is a standards-based client-server protocol that implements validation policies to determine the path to a trusted root and the validation of that path. SCVP facilitates Federated PKIs, and is utilized by some applications that have been federated with the Federal Bridge Certificate Authority but has yet to be widely adopted by the vendor community. Webcullis, an open source solution built on top of PKIF, has been tested and approved by both the DOJ and GSA testing labs for use in the federal government environment. Additionally, on the FIPS 201approved list at [], products from Ascertia Limited, CodeBench and Corestreet have incorporated SCVP into their product lines.

The esMD sub workgroup recommends that certificates be x.509.v3 FBCA certified and issued by cross certified CAs or their approved sub CAs. Sub CAs may issue end user certificates only.

7.6 Non-Repudiation Assurance
Non-repudiation assurance ensures that the person who signs an esMD document, document bundle or transaction cannot later deny the signature. The assurance process will need to verify the signature as well as the identity of the sender, ensure possession of the private key, verify the certificate was not revoked at the time of the signing, and record the relevant transaction information necessary for archival purposes.

A digital signature is a digest of the message being signed and encrypted by the digital signing algorithm using the private key. Private keys stored on a local computer should, at a minimum, be protected by a password or Personal Identification Number (PIN). The PIN would not prevent other covert hacking methods such as keystroke logging. Thus, it is strongly suggested that signers consider using authentication protocols that meet NIST LOA 3.

The private key used to create digital signatures needs to be closely guarded. If users forget their passwords or lose, break, or corrupt their signing keys, a new signing key pair will need to be generated. The keys used for digital signature cannot be backed up and must be under the control of the signer at all times. =8.0Gaps= This section describes any gaps that exist in recommended standards or policy. =9.0Risks, Issues and Obstacles= The Risks, Issues and Obstacles section lists the concerns that might interfere with meeting the recommendations of the Sub Workgroup. =Appendix A: GlossaryAppendices=
 * 1) Not all providers are eligible for an NPI
 * 2) Non-repudiation using group certificates
 * 3) A significant number of software products that validate X.509v3 certificates do not do full-path validation nor check CRLs to ensure the certificate is currently valid.
 * 1) The burden to individual providers to obtain and manage certificates. Some reasons include that providers will need to learn how to obtain the certificates, undergo identity proofing, implement enrollment policies, manage renewals, etc.
 * 2) Provider Entities or Payer Entities that have Digital Certificates that are not issued by CAs cross-certified with the Federal Bridge will need to obtain or have new Certificates issued to itself and its trading partners to be compliant with the identify proofing and certificate requirements.
 * 3) Compliance with the Certificate Lifecycle (including revocation).
 * 4) Issues inherent in the creation and use of X.509v3+ Digital Certificates.
 * 5) Limiting the solution in a way that it does not allow for emerging technologies
 * 6) If X.509v3 certificates are not validated, compromise of the trust environment may occur.
 * 1) ** Authentication (NIST) ** - Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. [NS4009]
 * 2) ** Author (of Record) ** - The individual that creates a record.
 * 3) ** Certificate Authority (NIST) ** - An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or CRLs.
 * 4) ** Credential ** (NIST) - An object or data structure that authoritatively binds an identity (and optionally, additional attributes) to a token possessed and controlled by a Subscriber.
 * 5) ** Credentialing ** – the process by which personal or professional information about an Individual or Organization is verified by a third party.
 * 6) ** Data Integrity (NIST) ** - A property whereby data has not been altered in an unauthorized manner since it was created, transmitted or stored. Alteration includes the insertion, deletion and substitution of data.
 * 7) ** Decryption ** - The reverse process of encryption, i.e., to make the encrypted information readable again.
 * 8) ** Delegation of Rights ** - The ability to delegate rights or authority to another to act in a specific capacity on behalf of the grantor of the right.
 * 9) ** Digital Certificate (NIST) ** - A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it.
 * 10) ** Digital Id Management ** - A trusted authority is responsible for creating the key pair, distributing the private key, publishing the public key and revoking the keys as necessary. The “Passport Office” of the Digital World. The keys and their associated information (e.g. Digital Certificate) are typically stored as software tokens, browser certificate stores, and hardware tokens (Smart Cards, USB Tokens).
 * 11) ** Digital Signatures ** - An artifact appended to a record as a result of a user’s intended action wherein that memorializes a signing event by a process that digitally signs a document or transaction using the private key component of his certificate.(From NIST - The result of a transformation of a message by means of a cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made.) (From 800-63-1 an asymmetric key operation where the private key is used to digitally sign data and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and non-repudiation).
 * 12) ** Encryption ** - In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called a cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.
 * 13) ** Identity ** - A unique name of an Individual or Organization. Since the legal names of an Individual or Organization are not necessarily unique, the ID must include sufficient additional information (for example an address and NPI number) to make the complete name unique.
 * 14) ** Identity Proofing ** - The process by which the credential issuer validates sufficient information to uniquely identify an Individual or Organization or applying for the credential. It proves that the ID exists, proves the applicant is entitled to that ID, and addresses the potential for fraudulent issuance of credentials based on collusion.
 * 15) ** Non-repudiation (NIST) ** - A service that is used to provide assurance of the integrity and origin of data in such a way that the integrity and origin can be verified by a third party. This service prevents an Individual or Organization from successfully denying involvement in a previous action.
 * 16) ** Public Key Infrastructure ** - A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.
 * 17) ** Registration Authority (NIST) ** - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates.
 * 18) ** X.509v3+ ** - Includes X.509 version 3 and all subsequent versions [RFC 5280 and its predecessors]

Appendix B: References

 * [|CMS Internet Only Manuals (IOM)]
 * [|ELECTRONIC SIGNATURES IN GLOBAL AND NATIONAL COMMERCE ACT]
 * [|Recommendation for Obtaining Assurances for Digital Signature Applications]
 * OMB 04-04
 * NIST SP 800-63-1
 * DEA Interim Rule, Electronic Prescriptions for Controlled Substances 21 CFR 1311
 * [|Records Management Guidance For PKI Digital Signature Authenticated and Secured Transaction Records]
 * [|X.509 Certificate and Certificate Revocation List (CRL) Extensions Profile for Personal Identity Verification Interoperable (PIV-I) Cards]
 * [|X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA)]
 * [| Direct Project]
 * [|FDA electronic submissions gateway (ESG)]

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"