1、Designation: E 2212 02aAn American National StandardStandard Practice forHealthcare Certificate Policy1This standard is issued under the fixed designation E 2212; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, the year of last rev
2、ision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon (e) indicates an editorial change since the last revision or reapproval.1. Scope1.1 This practice covers a policy (“the policy”) for digitalcertificates that support the authentication, authorization, con-fide
3、ntiality, integrity, and nonrepudiation requirements of per-sons and organizations that electronically create, disclose,receive, or otherwise transact health information.1.2 This practice defines a policy for three classes ofcertificates: (1) entity certificates issued to computing compo-nents such
4、as servers, devices, applications, processes, oraccounts reflecting role assignment; (2) basic individual cer-tificates issued to natural persons involved in the exchange ofhealth information used for healthcare provisioning; and (3)clinical individual certificates issued to natural persons andused
5、for authentication of prescriptive orders relating to theclinical treatment of patients.1.3 The policy defined by this practice covers: (1) definitionof healthcare certificates, healthcare certification authorities,healthcare subscribers, and healthcare relying parties; (2)appropriate use of healthc
6、are certificates; (3) general condi-tions for the issuance of healthcare certificates; (4) healthcarecertificate formats and profile; and (5) requirements for theprotection of key material.1.4 The policy establishes minimum responsibilities forhealthcare certification authorities, relying parties, a
7、nd certifi-cate subscribers.2. Referenced Documents2.1 ASTM Standards:E 2084 Specification for Authentication of Healthcare In-formation Using Digital Signatures2E 2086 Guide for Internet and Intranet Healthcare Security22.2 Other Documents:Public Law 104-191, Aug. 21, 1996, Health InsurancePortabil
8、ity and Accountability Act of 19963RFC 2527Internet X.509 Public Key Infrastructure Cer-tificate Policy and Certification Practices Framework, P-KIX Working Group Internet Draft, January 3, 20024RFC 2560Internet X.509 Public Key Infrastructure OnlineCertificate Status Protocol, OCSP, June 199953. Te
9、rminology3.1 Certificate and Related TermsA certificate, also re-ferred to as a digital certificate or public key certificate, bindsa public key value to information identifying the entityassociated with the use of a corresponding private key. Anentity may be an individual, organization, account, ro
10、le,computer process, or device. The entity identified within thecertificate is referred to as the certificate subject. The certificateis typically used to verify the digital signature of the certificatesubject or to encrypt information for that subject. The reliabil-ity of the binding of a public ke
11、y to a certificate subject isasserted by the certification authority (CA) that creates, issues,and distributes certificates. Certification authority is synony-mous with certificate authority. Parties that depend on theaccuracy of information in the certificate are referred to asrelying parties. Cert
12、ificate users are the collective relyingparties and subscribers.3.2 Certificate Policy:3.2.1 The X.509 standard defines a certificate policy (CP) as“a named set of rules that indicates the applicability of acertificate to a particular community and/or class of applicationwith common security require
13、ments.” For example, a particularcertificate policy might indicate the type of certificate appli-cable for authenticating electronic data interchange transac-tions for the trading of goods within a specified price range. Incontrast, Practice E 2212 addresses rules for certificates thatsupport the au
14、thentication, authorization, confidentiality, integ-rity, and nonrepudiation requirements of persons and organi-zations that electronically create, disclose, receive, or other-wise transact health information.3.2.2 Certificates contain a registered certificate policy ob-ject identifier (OID) that th
15、e relying party may use to decidewhether a certificate may be trusted for a particular purpose.The OID registration process follows the procedures specifiedin ISO/IEC and ITU standards. The party that registers the OID1This practice is under the jurisdiction of ASTM Committee E31 on HealthcareInform
16、atics , and is the direct responsibility of Subcommittee E31.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved Nov. 10, 2002. Published January 2003. Originallyapproved in 2002. Last previous edition approved in 2002 as E 221202.2Annual Book of ASTM Sta
17、ndards, Vol 14.01.3Available at http:/aspe.hhs.gov/admnsimp/pl104191.htm.4Available at www.ietf.org/html.charters/pkix-charter.html.5Available at http:/www.ietf.org/rfc/rfc2560.txt.1Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.also
18、 publishes the CP for examination by certificate users andother parties. Each certificate should refer to a CP, but may alsorefer to additional nonconflicting CP.3.2.3 Certificate policies constitute a basis for accreditingCA. Certificate policies are also used to establish a trustrelationship betwe
19、en two or more CA (cross-certification).When CA issue cross-certificates, one CA assesses and recog-nizes the relevant certificate policies of the other CA.3.3 Certification Practice StatementThe term certificationpractice statement (CPS) is defined in the Internet X.509 PublicKey Infrastructure Cer
20、tificate Policy and Certificate PracticesFramework as “a statement of the practices, which a certifica-tion authority employs in issuing certificates.” The CPS isdifferentiated from the CP in the same way that any policy isdifferent from a practice statement. The CPS is a comprehen-sive description
21、by the CA of the methods, components, andprocedures it has elected to implement and which define howit conducts itself throughout the certificate life cycle. A CAwith a single CPS may support multiple certificate policies ifthe certificates it issues will be used for different applicationpurposes or
22、 by different certificate user communities, or both.Any number of CA, with unique CPS, may support the samecertificate policy.3.4 Relationship Between a Certificate Policy and a Certi-fication Practice Statement:3.4.1 A certificate policy assigns responsibilities to variousparticipants in a public k
23、ey infrastructure (PKI). These respon-sibilities may be stated in differential levels of specificity. Forexample, a policy may require the CA to confirm subscriberidentity but leave the details to the CA to specify in its CPS. Inthis case, the CPS might include a list of acceptable identifi-cation d
24、ocuments and the methods by which the CA, its agents,or both, verify their authenticity. Alternatively, the CA mightimplement other identity authentication methods that rely uponstatements by an employers human resources manager. With aless specific requirement, the CA has more flexibility indetermi
25、ning its practices and would need to describe whatoptions it has chosen to implement in the CPS.3.4.2 On the other hand, a policy may have a very specificrequirements, such as that the CA must use only cryptographicmodules that have been formally certified as complying withthe U.S. Federal Informati
26、on Processing Standard 140-2 Level3. In this case, the CPS would mirror the policy statement orperhaps extend the policy statement by indicating the name ofthe cryptographic module in use.3.4.3 A certificate policy may apply to a group of organi-zations and is often written for a defined community o
27、f relyingparties. A CPS is written by a CA and applies only to it. Thuscertificate policies are the basis of establishing requirementsfor interoperability and equivalent assurance criteria on anindustry basis. A CPS is specific to a given CA and does notprovide a suitable basis for interoperability
28、between CAoperated by different organizations.4. Significance and Use4.1 The policy defined by this practice is written from theperspective of healthcare relying parties. It defines a set ofrequirements to ensure that certificates, used for authentication,authorization, confidentiality, integrity, a
29、nd nonrepudiation ofhealth information by healthcare organizations and persons,have a minimally sufficient assurance level.4.2 This policy defines a healthcare public key infrastruc-ture that can be used to implement other ASTM standardsincluding Specification E 2084 and Guide E 2086.4.3 CA that imp
30、lement procedures satisfying each require-ment of the policy should reference the policys OID in theappropriate fields within its certificates. Relying parties canrecognize the inclusion of the policys OID as an indicationthat the issuing CA has conformed to the requirements of thepolicy and that th
31、e certificates referencing the policys OIDmay be used for healthcare purposes.4.4 CA that do not comply with all provisions of the policymust not assert the policys OID in its certificates. A CA thatcomplies with all but a limited number of provisions mayreference the policy in its own policy, provi
32、ded that it clearlystates the specific deviations. For example, a healthcare orga-nization might operate an internal CA that complies with all ofthe provisions of the basic individual certificate class exceptthat it uses a noncomplying cryptographic module for the CAsigner keys. The organization mig
33、ht want to use the policy asthe basis for establishing trust with external relying parties.While it may not directly assert this policy using the OID, itmay reference the policy in a document that includes state-ments explaining measures it has taken to protect the integrityof the CA signing key. Re
34、lying parties or CA wishing tofacilitate cross-trust relationships must then make their ownrisk analysis to determine if the modified policy is adequate forthe proposed usage. This assessment, while not as easy as thatbased upon full compliance, should be significantly facilitatedby treating the pol
35、icy as a reference standard from which tojudge the modifications.4.5 Certificates and the certificate issuance process can varyin at least three distinct ways. The most frequently citedvariation is about assurance. Assurance levels vary dependingupon the degree of diligence applied in the registrati
36、on, keygeneration, certificate issuance, certificate revocation, andprivate key protection. The required assurance level dependson the risks associated with a potential compromise. Thefederal PKI, among others, divides assurance into three classes.Rudimentary assurance involves very little control o
37、f either theregistration process or key security. The federal PKI does notconsider rudimentary assurance appropriate for healthcare use.Medium assurance involves a higher degree of diligence in theregistration process and requires a number controls over CAkeys. Medium assurance is designed for moder
38、ate risk appli-cations. High assurance adds additional controls on the CAandsubscriber keys as well as careful division of roles in theissuance process. These additions make high assurance certifi-cates more appropriate for higher risk applications. Certificatesmay also vary depending upon the type
39、of entity whose identityis bound to the certificate. Finally, certificates are oftendescribed in terms of appropriate and inappropriate uses.4.6 The policy does not define certificates in terms ofassurance levels. Instead, it defines three classes of certificates(entity, basic individual, and clinic
40、al individual) that differ interms of their primary intended use or purpose and in terms oftheir intended subscriber type. The three certificate classes areE 2212 02a2ordered so that the clinical individual certificate must meet allthe requirements of the basic individual certificate and thebasic in
41、dividual certificate must meet all the requirements ofthe entity certificate.4.7 It is anticipated that the policy will be used to facilitatecross-licensing between healthcare CA. The policy is intendedto provide a common reference point for establishing compat-ibility of purposes, representations,
42、and practices among anumber of autonomous healthcare CA.5. Healthcare Certificate Policy5.1 The IETF Draft Standard (RFC 2527), Internet X.509Public Key Infrastructure Certificate Policy and CertificationPractices Framework, describes the expected contents andformat of certificate policy statements.
43、 It also specifies stan-dard section headings, contents, and numbering. The policyfollows the IETF conventions.5.2 The term “no stipulation” is used whenever the IETFdraft includes a section heading for which this practice has norequirement.5.3 IETF Guidelines (RFC 2119) require the use of “must”and
44、 “must not” while ASTM International requires the use of“shall” and “shall not.” The two sets of terms are definedequivalently. IETF and ASTM International agree in the use ofterms “should,” “should not,” and “may.” Annex A1, whichcontains the healthcare certificate policy (referred to as thepolicy)
45、, follows the IETF conventions.ANNEX(Mandatory Information)A1. HEALTHCARE CERTIFICATE POLICYContents1. Introduction2. General Provisions3. Identification and Authentication4. Operational Requirements5. Physical, Procedural, and Personnel Security Controls6. Technical Security Controls7. Certificate
46、and CRL Profiles8. Policy Administration9. Bibliography10. Acronyms11. Glossary12. AttachmentHealthcare Certificate Profile1. INTRODUCTION1.1 OverviewThis certificate policy sets requirements for certificates thatsupport the authentication, authorization, confidentiality, integ-rity, and nonrepudiat
47、ion requirements of persons and organi-zations that electronically create, disclose, receive, or other-wise transact health information.1.2 Policy IdentificationThere are three classes of certificates in this policy, whichare defined in 1.3.3. Each of these classes has an objectidentifier (OID) whic
48、h should be asserted in the certificate-Policy extension of certificates that comply with this policy.The OID are registered under the ASTM E31.20 ARC asfollows:E31-20 OBJECT IDENTIFIER := iso(1) member-body(2) us(840) 10065Healthcare-certificate-policyOBJECT IDENTIFIER:= E31-20 2id-e3120-certpcy OB
49、JECTIDENTIFIER:= Healthcare-certificate-policy 1id-e3120-certpcy-entity := Id-e3120-certpcy 1id-e3120-certpcy-basicIndividual := Id-e3120-certpcy 2id-e3120-certpcy-clinicalIndividual := Id-e3120-certpcy 31.3 Community and ApplicabilityThe only persons or organizations expected to benefit fromthis policy and participate in the PKI it defines (that is, issue,obtain, use, or rely upon healthcare certificates) are CAidentified in 1.3.1; certificate applicants and subscribers iden-tified in 1.3.2.1; and qualified relying parties identified insection 1.3.2.2. Cer
