ASTM E2212 - 02a(2010) Standard Practice for Healthcare Certificate Policy (Withdrawn 2017).pdf

《ASTM E2212 - 02a(2010) Standard Practice for Healthcare Certificate Policy (Withdrawn 2017).pdf》由会员分享，可在线阅读，更多相关《ASTM E2212 - 02a(2010) Standard Practice for Healthcare Certificate Policy (Withdrawn 2017).pdf（21页珍藏版）》请在麦多课文档分享上搜索。

1、Designation: E2212 02a (Reapproved 2010) An American National StandardStandard Practice forHealthcare Certificate Policy1This standard is issued under the fixed designation E2212; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, the

2、 year of last revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon () 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, authori

3、zation,confidentiality, integrity, and nonrepudiation requirements ofpersons 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

4、-nents such 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 pers

5、ons andused 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 us

6、e of healthcare 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, relyin

7、g parties, and certifi-cate subscribers.2. Referenced Documents2.1 ASTM Standards:2E2084 Specification for Authentication of Healthcare Infor-mation Using Digital Signatures (Withdrawn 2009)3E2086 Guide for Internet and Intranet Healthcare Security(Withdrawn 2009)32.2 Other Documents:Public Law 104-

8、191, Aug. 21, 1996, Health Insurance Por-tability and Accountability Act of 19964RFC 2527Internet X.509 Public Key Infrastructure Cer-tificate Policy and Certification Practices Frame-work, PKIX Working Group Internet Draft, January 3,20025RFC 2560Internet X.509 Public Key Infrastructure OnlineCerti

9、ficate Status Protocol, OCSP, June 199963. Terminology3.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 ma

10、y be an individual, organization, account, role,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. T

11、he reliabil-ity of the binding of a public key 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 certif

12、icate are referred to asrelying parties. Certificate 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 cla

13、ss of applicationwith common security requirements.” 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 E2212 address

14、es rules for certificates thatsupport the authentication, authorization, confidentiality,integrity, and nonrepudiation requirements of persons andorganizations that electronically create, disclose, receive, orotherwise transact health information.1This practice is under the jurisdiction of ASTM Comm

15、ittee E31 on HealthcareInformatics, and is the direct responsibility of Subcommittee E31.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved March 1, 2010. Published August 2010. Originallyapproved in 2002. Last previous edition approved in 2002 as E22120

16、2a. DOI:10.1520/E2212-02AR10.2For referenced ASTM standards, visit the ASTM website, www.astm.org, orcontact ASTM Customer Service at serviceastm.org. For Annual Book of ASTMStandards volume information, refer to the standards Document Summary page onthe ASTM website.3The last approved version of th

17、is historical standard is referenced onwww.astm.org.4Available at http:/aspe.hhs.gov/admnsimp/pl104191.htm.5Available at www.ietf.org/html.charters/pkix-charter.html.6Available at http:/www.ietf.org/rfc/rfc2560.txt.Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken,

18、PA 19428-2959. United StatesNOTICE: This standard has either been superseded and replaced by a new version or withdrawn.Contact ASTM International (www.astm.org) for the latest information13.2.2 Certificates contain a registered certificate policy ob-ject identifier (OID) that the relying party may

19、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 OIDalso publishes the CP for examination by certificate users andother parties. Each certificate should r

20、efer 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 between two or more CA (cross-certification).When CA issue cross-certificates, one CA assesses and reco

21、g-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 Certificate Policy and Certificate PracticesFramework as “a statement of the practices, which a certi

22、fica-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 by the CA of the methods, components, andprocedures it has elected to implement and which define h

23、owit 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 by different certificate user communities, or both.Any number of CA, with unique CPS, may support

24、 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 key infrastructure (PKI). These respon-sibilities may be stated in differential levels of specifici

25、ty. 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 documents and the methods by which the CA, its agents,or both, verify their authenticity. Alternati

26、vely, 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 indetermining its practices and would need to describe whatoptions it has chosen to implement in the CPS.3.

27、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 Information Processing Standard 140-2 Level3. In this case, the CPS would mirror the policy statement orper

28、haps 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 of relyingparties. A CPS is written by a CA and applies only to it. Thuscertificate policies are th

29、e 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 between CAoperated by different organizations.4. Significance and Use4.1 The policy defined by thi

30、s practice is written from theperspective of healthcare relying parties. It defines a set ofrequirements to ensure that certificates, used for authentication,authorization, confidentiality, integrity, and nonrepudiation ofhealth information by healthcare organizations and persons,have a minimally su

31、fficient assurance level.4.2 This policy defines a healthcare public key infrastruc-ture that can be used to implement other ASTM standardsincluding Specification E2084 and Guide E2086.4.3 CA that implement procedures satisfying each require-ment of the policy should reference the policys OID in the

32、appropriate 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 the certificates referencing the policys OIDmay be used for healthcare purposes.4.4 CA that do not com

33、ply 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, provided that it clearlystates the specific deviations. For example, a healthcare orga-nization might ope

34、rate 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 might want to use the policy asthe basis for establishing trust with external relying parties.While it

35、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. Relying parties or CA wishing tofacilitate cross-trust relationships must then make their ownrisk anal

36、ysis 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 policy as a reference standard from which tojudge the modifications.4.5 Certificates and the certificat

37、e 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 registration, keygeneration, certificate issuance, certificate revocation, andprivate key protection. The requ

38、ired 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 of either theregistration process or key security. The federal PKI does notconsider rudimentary assur

39、ance 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 moderate risk appli-cations. High assurance adds additional controls on the CAandsubscriber keys as well

40、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 of entity whose identityE2212 02a (2010)2is bound to the certificate. Finally, certificates are ofte

41、ndescribed 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 clinical individual) that differ interms of their primary intended use or purpose and in

42、terms oftheir intended subscriber type. The three certificate classes areordered so that the clinical individual certificate must meet allthe requirements of the basic individual certificate and thebasic individual certificate must meet all the requirements ofthe entity certificate.4.7 It is anticip

43、ated 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, and practices among anumber of autonomous healthcare CA.5. Healthcare Certificate Policy5.1 Th

44、e IETF Draft Standard (RFC 2527), Internet X.509Public Key Infrastructure Certificate Policy and CertificationPractices Framework, describes the expected contents andformat of certificate policy statements. It also specifies stan-dard section headings, contents, and numbering. The policyfollows the

45、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 “must not” while ASTM International requires the use of“shall” and “shall not.” The two sets

46、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), follows the IETF conventions.ANNEX(Mandatory Information)A1. HEALTHCARE CERTIFICATE POLICYCo

47、ntents1. Introduction2. General Provisions3. Identification and Authentication4. Operational Requirements5. Physical, Procedural, and Personnel Security Controls6. Technical Security Controls7. Certificate and CRL Profiles8. Policy Administration9. Bibliography10. Acronyms11. Glossary12. AttachmentH

48、ealthcare Certificate Profile1. INTRODUCTION1.1 OverviewThis certificate policy sets requirements for certificates thatsupport the authentication, authorization, confidentiality, integ-rity, and nonrepudiation requirements of persons and organi-zations that electronically create, disclose, receive,

49、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) which 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 OBJECTIDENTIFIER:= Healthcare-certificate-policy 1id-e31