esMD Initiative Author of Record Sub Workgroup Report
DRAFT Digital Credential Management
11/6/2012
10/10/12 1

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
No table of figures entries found. ................................................................................................................. 3
0.5 Terms ...................................................................................................................................................... 4
1.0 Summary ................................................................................................................................................. 4
2.0 Statement of Problem ............................................................................................................................. 5
3.0 Requirements .......................................................................................................................................... 5
4.0 Assumptions ............................................................................................................................................ 6
5.0 Review of Standards ............................................................................................................................... 6
6.0 Evaluation of Alternative Solutions......................................................................................................... 7
7.0 Recommended Solution .......................................................................................................................... 8
7.1 Dependence on Identity Proofing ....................................................................................................... 8
7.2 CA Qualifications and List.................................................................................................................... 8
7.3 Credential Types, Forms and Contents ............................................................................................... 9
7.3.1 FBCA Certificates .......................................................................................................................... 9
7.3.2 Authentication Tokens ................................................................................................................. 9
7.4 Credential Maintenance Requirements ............................................................................................ 10
7.4.1 Key Pair and Certificate Usage ................................................................................................... 11
7.4.2 Certificate Renewal .................................................................................................................... 11
7.4.3 Certificate Re-Key ....................................................................................................................... 11
7.4.4 Modifications ............................................................................................................................. 12
7.45.5 Certificate Revocation and Suspension ................................................................................... 12
7.4.6 Key Escrow and Recovery .......................................................................................................... 13
7.5 “Trust Anchor” .................................................................................................................................. 14
7.6 Non-Repudiation Assurance ............................................................................................................. 14
8.0 Gaps ...................................................................................................................................................... 14
9.0 Risks, Issues and Obstacles ................................................................................................................... 14
Appendices .................................................................................................................................................. 15
Appendix A: Glossary ............................................................................................................................. 15
Appendix B: References .......................................................................................................................... 16
10/10/12 2

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
10/10/12 3

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
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 Framwork program 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.
esMD Initiativie Transactions – the specific transactions defined by the esMD Initiative use cases and the subsequent implications guides
Summary of the workgroup effort and recommendation
On September 15, 2011, the esMD Program launched a pilot to accept electronic submissions from a group of Health Information Handlers (HIHs) and Medicare Review Contractors and commercial payers.
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 to send to
CMS or the appropriate commercial requestor.
Three separate work groups were assembled to address Identity Proofing, Digital Credentials, Signing, 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.
10/10/12 4

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
The workgroup recommendations are constrained by two primary factors; (1) the solution must be implemented within the first two quarters of 2013, and (2) the systems that support esMD Initiative
(including esMD Phase 1) would have to abide standards established by the Federal Information Security
Management Act of 2002 (FISMA).
The workgroup identified a number of standards, but 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 entities, professional individuals (a natural person) or their agents and organizations, 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 Certificate Authority (CA) must be cross certified with the FBCA at medium assurance.
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 Intiative should continue to monitor and update policies as appropriate to reflect improved technological capabilities.
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.
General Requirements for AoR L1 SWGs:

In general the solutions must: o be implementable for pilot in Q1/Q2 2013 o scale to all providers and payers o minimize the operational impact required to establish, maintain or use a digital identities o provide for non-repudiation without resorting to audit logs or validation of system configuration

Include standards identified in: o NIST SP 800-63-1 Level 3 and above (December 2011) o NIST SP 800-57 Part 1 (Revision 3 July 2012)
10/10/12 5

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case o NIST SP 800-89 o Federal Bridge Certification Authority Medium Level o X.509v3+ Digital Certificates

In-Scope o Digital credential life cycle o Relevant standards o Policy issues regarding Digital Credentials

Out-of-Scope (addressed by other esMD Intiative Author of Record Level 1 Sub-Workgroups) o Identity Proofing o Digital Signatures o Delegation of Rights
This section lists the assumptions used by the sub workgroup

Must comply with US government standards and regulations.

All certificates must be issued to individuals or entities, and include their unique identification

 number examples: Provider NPI, Health Plan HPID, Other Entity OEID, or EIN.
CMS does not plan issue credentials for digital signatures.
The I esMD Initiative Implementation Guides require digital signatures for provider registration the receipt of electronic Medical Documentation Requests (eMDR)
This section enumerates the relevant standards and provides a short review of their relevance to the problem. Note inconsistencies between standards in this section
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 of 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 assess and as general rule deemed that all of their external facing systems must, at a minimum meet, NIST Level 3 assurance level.
NIST Level 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. “Manin-the-middle” attacks are strongly resisted when using FIPS 140-2 Level 2 or higher validated modules
10/10/12 6

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
Additional information about regarding validated FIPS 140-2 validated module can be found at : http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2012.htm
Authentication requires that the Claimant prove controls of the token. The Claimant unlocks the token with a password or biometric, or uses a secure multi-token authentication protocol to establish twofactor 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 organization specific 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] and the Citizen and
Commerce class policy specified in [FBCA2].
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 esMD Initiative.
FPKI LOA
Basic
Medium
Medium
Hardware
Common-HW
PIVI-HW
Assurance description
Basic level of risk and compromise.
Likelihood of malicious access not high
Moderate risk and compromise – includes monetary value or risk of fraud
High risk
800-63-1
Token and LOA
LOA3
LOA3
LOA4
800-63-1
ID Proofing
LOA3
LOA4
LOA4
This section list alterative solutions that were considered and provide an evaluation of the merits of each.
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.
10/10/12 7

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
Users of e-prescribing systems for controlled substances have to prove their identities with two of the following three factors:
 something you know (password);
 something you have (token) or
 something you are (biometric).
The interim final rule DEA is allows the use of a biometric as a substitute for a hard token or a password the IFR states.
** Expand on pilot by SureScript and Dr. First
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.
** Expand on dual use key – non repudiation bit turned off. Cannot be used for signing but good candidate for 3 rd party providers to encrypt and send payload to esMD Gateway
This section describes the recommended solution and describes the details of the solutions in the following sub sections...
This section describes dependence on Id Proofing
The issuance of digital credentials following this SWG’s recommendations require that the individual or entity has successfully completed identity proofing with a certified RA following, as a minimum, identity verification guidelines for FBCA Medium Assurance or NIST 800-63-1 LOA 4 as described in the recommendations from the Author of Record Identity Proofing SWG
This section describes CA qualifications and provides or cites a current list of qualified CAs
CAs submit Certification Practices Statements to the FPKI Management Authority for a compliance audit.
The FPKI Management Authority in turn submits the results for the audit to the FPKI Policy authority for approval. 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
10/10/12 8

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case

PIV-I Hardware

PIV-I Content Signing
A list of currently approved CAs may be located at: http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Management-Authority-entitiescrosscertified-with-the-FBCA
This section describes the types of credentials/tokens and their forms
7.3.1 FBCA Certificates
The below table lists the type of certificates that may be acceptable for esMD Initiative digital signatures. The FBCA indicates that group policies are not desired for non-repudiation efforts but its is possible that some CAs may have established additional policies that have been found appropriate for use by the Federal PKI Authority. CAs will need to be examined on a case by case basis.
Type
Individual
Contents

Identifies subscriber

May have organization affiliation
Role
Group



Where non-repudiation is desired
Identifies role not subscriber
Role may be issued to many subscribers but key pairs are unique

Cannot be shared

Sponsor must have individual certificate

Shared certificate among many

Were non-repudiation not desired

ISSO controls private key and tracks who had control at what time
7.3.2 Authentication Tokens
The following Authentication tokens are considered appropriate for second factor use in the esMD
Intitiative
Type Description
Memorized Secret Token Shared secret between user and credential provider
(Something you know)
Examples
PIN or Password
10/10/12 9

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
Pre Registered
Knowledge Tokens
Challenge/Response
Pre-registered responses or images
I forgot my password setup
Transaction information - “what was the amount of your last payment to your phone company
Set of shared secrets
(Something you know)
Out of Band Tokens
Single Factor One-Time
Password (OTP) Device
Physical token that can receive a secret for one time use
(Something you have)
Hardware device
(Something you have)
SMS message on a registered cell phone
RSA key fob token
Credit card password generator
Single Factor
Cryptographic Device
Multi-Factor
Cryptographic Token
Multi-Factor OTP
Multi-Factor
Cryptographic Device
Hardware device that performs crypto operation on input provided to the device
Requires a second factor
Generally a signed message
(Something you have)
Key is stored on a disk or soft media and requires activation
Does not require a second factor
Generally a signed message
(Something you have and something you know)
OTP hardware device that requires activation via PIN or biometric
(Something you have and something you know /or something you are)
Hardware device that contains protected key that requires activation through a second factor
Possession of device and control of key(Something you have and something you know or something you are)
PKI certificate
PKI certificate + PIN
Verizon or Symantec OTP offering
DAON IdX
PIV
PIV-I
ATM cards
This section describes required or recommended credential maintenance
10/10/12 10

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
The certificate maintenance lifecycle is detailed in Chapter 4 of the FBCA. For convenience we have paraphrased and highlighted most of the options below. Please consult the FBCA and the FPKI
Management Authority for further guidance.
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-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 rekey, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.
10/10/12 11

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
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.
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.45.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
10/10/12 12

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case requests validated within two hours of CRL issuance. Revocation requests validated within two 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 same scope.
• If on-line revocation/status checking is supported by an 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.
7.4.6 Key Escrow and Recovery
• CA private keys are never escrowed.
10/10/12 13

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
• 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.
This section describes how to evaluate and use the “trust anchor”
*** detail the process of trust anchors and the extended work necessary for full path validation for
reciever
This sections describes the use of these credentials to ensure non-repudiation of signed transactions and events
Non-repudiation is assurance necessary for valid digital signatures, includingassurance of domain parameter validity, assurance of public key validity, assurance that the key pair owner actually possesses the private key, and assurance of the identity of the key pair owner.
*** place holder for greater detail – drives the second factor need
This section describes any gaps that exist in recommended standards or policy
Not all providers are eligible for an NPI
The Risks, Issues and Obstacles section lists the concerns that might interfere with meeting the recommendations of the Sub Workgroup.
A.
B.
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 ID-proofing, implement enrollment policies, manage renewals, etc.
Provider Entities or Payer Entities that have Digital Certificates that are not issued by CAs cross-certified with the Federal Bridge that will need to obtain or have new Certificates issued to itself and its trading partners to be compliant with the identify proofing and
10/10/12 14

C.
D.
E.
Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case certificate requirements
Compliance with Certificate Lifecycle (including revocation)
Issues inherent in the creation and use of X.509v3+ Digital Certificates
Limiting solution in a way that it does not allow for emerging technologies
A.
Authentication (NIST) - Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. [NS4009]
B.
Author (of Record) - The individual that creates a record.
C.
Certificate Authority (NIST) - An authority trusted by one or more users to issue and manage
X.509 Public Key Certificates and CARLs or CRLs.
D.
Credential -
E.
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.
F.
Decryption - The reverse process of encryption, i.e., to make the encrypted information readable again.
G.
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. 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.
H.
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).
I.
Digital Signatures - “An artifact appended to a record as a result of a user’s intended action wherein that memorializes a signing event by a process that digitally signs a document or transaction using the private key component of his certificate.
(From NIST - The result of a transformation of a message by means of a cryptographic system using keys such that a Relying
Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made.) (From 800-63-1 an asymmetric key operation where the private key is used to digitally sign data and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and nonrepudiation.
J.
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.
10/10/12 15

Use Case Development and Functional Requirements for Interoperability
DRAFT Digital Identities and Submission Level Signatures Use Case
K.
Id - A unique name of an individual person or legal. Since the legal names of persons and entities are not necessarily unique, the id of a person or must include sufficient additional information (for example an address and NPI number) to make the complete name unique.
L.
Id Proofing - The process by which the credential issuer validates sufficient information to uniquely identify a person or applying for the credential. It proves that the id exists, proves the applicant is entitled to that id, and address the potential for fraudulent issuance of credentials based on collusion.
M.
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 from successfully denying involvement in a previous action.
N.
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.
O.
Registration Authority (NIST) -An that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., a Registration Authority is delegated certain tasks on behalf of an authorized CA).
P.
X.509v3+ - Includes X.509 version 3 and all subsequent versions [RFC 5280 and its predecessors]




OMB 04-04
10/10/12 16