ASTM E2212-02a(2010)
(Practice)Standard Practice for Healthcare Certificate Policy (Withdrawn 2017)
Standard Practice for Healthcare Certificate Policy (Withdrawn 2017)
SIGNIFICANCE AND USE
The policy defined by this practice is written from the perspective of healthcare relying parties. It defines a set of requirements to ensure that certificates, used for authentication, authorization, confidentiality, integrity, and nonrepudiation of health information by healthcare organizations and persons, have a minimally sufficient assurance level.
This policy defines a healthcare public key infrastructure that can be used to implement other ASTM standards including Specification E2084 and Guide E2086.
CA that implement procedures satisfying each requirement of the policy should reference the policy's OID in the appropriate fields within its certificates. Relying parties can recognize the inclusion of the policy's OID as an indication that the issuing CA has conformed to the requirements of the policy and that the certificates referencing the policy's OID may be used for healthcare purposes.
CA that do not comply with all provisions of the policy must not assert the policy's OID in its certificates. A CA that complies with all but a limited number of provisions may reference the policy in its own policy, provided that it clearly states the specific deviations. For example, a healthcare organization might operate an internal CA that complies with all of the provisions of the basic individual certificate class except that it uses a noncomplying cryptographic module for the CA signer keys. The organization might want to use the policy as the basis for establishing trust with external relying parties. While it may not directly assert this policy using the OID, it may reference the policy in a document that includes statements explaining measures it has taken to protect the integrity of the CA signing key. Relying parties or CA wishing to facilitate cross-trust relationships must then make their own risk analysis to determine if the modified policy is adequate for the proposed usage. This assessment, while not as easy as that based upon full compliance, should...
SCOPE
1.1 This practice covers a policy (“the policy”) for digital certificates that support the authentication, authorization, confidentiality, integrity, and nonrepudiation requirements of persons and organizations that electronically create, disclose, receive, or otherwise transact health information.
1.2 This practice defines a policy for three classes of certificates: (1) entity certificates issued to computing components such as servers, devices, applications, processes, or accounts reflecting role assignment; (2) basic individual certificates issued to natural persons involved in the exchange of health information used for healthcare provisioning; and (3) clinical individual certificates issued to natural persons and used for authentication of prescriptive orders relating to the clinical treatment of patients.
1.3 The policy defined by this practice covers: (1) definition of healthcare certificates, healthcare certification authorities, healthcare subscribers, and healthcare relying parties; (2) appropriate use of healthcare certificates; (3) general conditions for the issuance of healthcare certificates; (4) healthcare certificate formats and profile; and (5) requirements for the protection of key material.
1.4 The policy establishes minimum responsibilities for healthcare certification authorities, relying parties, and certificate subscribers.
WITHDRAWN RATIONALE
Formerly under the jurisdiction of Committee E31 on Healthcare Informatics, this practice was withdrawn in March 2017. This standard is being withdrawn without replacement due to its limited use by industry.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation:E2212 −02a (Reapproved 2010) An American National Standard
Standard Practice for
Healthcare Certificate Policy
This standard is issued under the fixed designation E2212; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope 2.2 Other Documents:
Public Law 104-191, Aug. 21, 1996, Health Insurance Por-
1.1 This practice covers a policy (“the policy”) for digital
tability and Accountability Act of 1996
certificates that support the authentication, authorization,
RFC 2527—Internet X.509 Public Key Infrastructure Cer-
confidentiality, integrity, and nonrepudiation requirements of
tificate Policy and Certification Practices Frame-
persons and organizations that electronically create, disclose,
work, PKIX Working Group Internet Draft, January 3,
receive, or otherwise transact health information.
1.2 This practice defines a policy for three classes of
RFC2560—InternetX.509PublicKeyInfrastructureOnline
certificates: (1) entity certificates issued to computing compo- 6
Certificate Status Protocol, OCSP, June 1999
nents such as servers, devices, applications, processes, or
accounts reflecting role assignment; (2) basic individual cer-
3. Terminology
tificates issued to natural persons involved in the exchange of
3.1 Certificate and Related Terms—A certificate, also re-
health information used for healthcare provisioning; and (3)
ferred to as a digital certificate or public key certificate, binds
clinical individual certificates issued to natural persons and
a public key value to information identifying the entity
used for authentication of prescriptive orders relating to the
associated with the use of a corresponding private key. An
clinical treatment of patients.
entity may be an individual, organization, account, role,
1.3 The policy defined by this practice covers: (1) definition computer process, or device. The entity identified within the
of healthcare certificates, healthcare certification authorities, certificateisreferredtoasthecertificatesubject.Thecertificate
healthcare subscribers, and healthcare relying parties; (2) is typically used to verify the digital signature of the certificate
appropriate use of healthcare certificates; (3) general condi- subject or to encrypt information for that subject. The reliabil-
tions for the issuance of healthcare certificates; (4) healthcare ity of the binding of a public key to a certificate subject is
certificate formats and profile; and (5) requirements for the asserted by the certification authority (CA) that creates, issues,
protection of key material. and distributes certificates. Certification authority is synony-
mous with certificate authority. Parties that depend on the
1.4 The policy establishes minimum responsibilities for
accuracy of information in the certificate are referred to as
healthcare certification authorities, relying parties, and certifi-
relying parties. Certificate users are the collective relying
cate subscribers.
parties and subscribers.
2. Referenced Documents
3.2 Certificate Policy:
2.1 ASTM Standards: 3.2.1 TheX.509standarddefinesacertificatepolicy(CP)as
E2084 Specification for Authentication of Healthcare Infor- “a named set of rules that indicates the applicability of a
mation Using Digital Signatures (Withdrawn 2009) certificatetoaparticularcommunityand/orclassofapplication
E2086 Guide for Internet and Intranet Healthcare Security withcommonsecurityrequirements.”Forexample,aparticular
(Withdrawn 2009) certificate 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. In
This practice is under the jurisdiction ofASTM Committee E31 on Healthcare
contrast, Practice E2212 addresses rules for certificates that
Informatics, and is the direct responsibility of Subcommittee E31.25 on Healthcare
Data Management, Security, Confidentiality, and Privacy.
support the authentication, authorization, confidentiality,
Current edition approved March 1, 2010. Published August 2010. Originally
integrity, and nonrepudiation requirements of persons and
approved in 2002. Last previous edition approved in 2002 as E2212–02a. DOI:
organizations that electronically create, disclose, receive, or
10.1520/E2212-02AR10.
otherwise transact health information.
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
Standards volume information, refer to the standard’s Document Summary page on
the ASTM website. Available at http://aspe.hhs.gov/admnsimp/pl104191.htm.
3 5
The last approved version of this historical standard is referenced on Available at www.ietf.org/html.charters/pkix-charter.html.
www.astm.org. Available at http://www.ietf.org/rfc/rfc2560.txt.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E2212−02a (2010)
3.2.2 Certificates contain a registered certificate policy ob- 4. Significance and Use
ject identifier (OID) that the relying party may use to decide
4.1 The policy defined by this practice is written from the
whether a certificate may be trusted for a particular purpose.
perspective of healthcare relying parties. It defines a set of
The OID registration process follows the procedures specified
requirementstoensurethatcertificates,usedforauthentication,
inISO/IECandITUstandards.ThepartythatregisterstheOID
authorization, confidentiality, integrity, and nonrepudiation of
also publishes the CP for examination by certificate users and
health information by healthcare organizations and persons,
otherparties.EachcertificateshouldrefertoaCP,butmayalso
have a minimally sufficient assurance level.
refer to additional nonconflicting CP.
3.2.3 Certificate policies constitute a basis for accrediting
4.2 This policy defines a healthcare public key infrastruc-
CA. Certificate policies are also used to establish a trust
ture that can be used to implement other ASTM standards
relationship between two or more CA (cross-certification).
including Specification E2084 and Guide E2086.
When CA issue cross-certificates, one CA assesses and recog-
4.3 CA that implement procedures satisfying each require-
nizes the relevant certificate policies of the other CA.
ment of the policy should reference the policy’s OID in the
3.3 Certification Practice Statement—The term certification
appropriate fields within its certificates. Relying parties can
practicestatement(CPS)isdefinedintheInternetX.509Public
recognize the inclusion of the policy’s OID as an indication
Key Infrastructure Certificate Policy and Certificate Practices
that the issuing CA has conformed to the requirements of the
Framework as “a statement of the practices, which a certifica-
policy and that the certificates referencing the policy’s OID
tion authority employs in issuing certificates.” The CPS is
may be used for healthcare purposes.
differentiated from the CP in the same way that any policy is
4.4 CAthat do not comply with all provisions of the policy
different from a practice statement. The CPS is a comprehen-
must not assert the policy’s OID in its certificates. A CA that
sive description by the CA of the methods, components, and
complies with all but a limited number of provisions may
procedures it has elected to implement and which define how
reference the policy in its own policy, provided that it clearly
it conducts itself throughout the certificate life cycle. A CA
states the specific deviations. For example, a healthcare orga-
with a single CPS may support multiple certificate policies if
nization might operate an internal CAthat complies with all of
the certificates it issues will be used for different application
the provisions of the basic individual certificate class except
purposes or by different certificate user communities, or both.
that it uses a noncomplying cryptographic module for the CA
Any number of CA, with unique CPS, may support the same
signer keys. The organization might want to use the policy as
certificate policy.
the basis for establishing trust with external relying parties.
3.4 Relationship Between a Certificate Policy and a Certi-
While it may not directly assert this policy using the OID, it
fication Practice Statement:
may reference the policy in a document that includes state-
3.4.1 A certificate policy assigns responsibilities to various
ments explaining measures it has taken to protect the integrity
participants in a public key infrastructure (PKI). These respon-
of the CA signing key. Relying parties or CA wishing to
sibilities may be stated in differential levels of specificity. For
facilitate cross-trust relationships must then make their own
example, a policy may require the CA to confirm subscriber
risk analysis to determine if the modified policy is adequate for
identity but leave the details to the CAto specify in its CPS. In
the proposed usage. This assessment, while not as easy as that
this case, the CPS might include a list of acceptable identifi-
based upon full compliance, should be significantly facilitated
cationdocumentsandthemethodsbywhichtheCA,itsagents,
by treating the policy as a reference standard from which to
or both, verify their authenticity. Alternatively, the CA might
judge the modifications.
implement other identity authentication methods that rely upon
statements by an employer’s human resources manager.With a
4.5 Certificates and the certificate issuance process can vary
less specific requirement, the CA has more flexibility in
in at least three distinct ways. The most frequently cited
determining its practices and would need to describe what
variation is about assurance. Assurance levels vary depending
options it has chosen to implement in the CPS.
upon the degree of diligence applied in the registration, key
3.4.2 On the other hand, a policy may have a very specific generation, certificate issuance, certificate revocation, and
requirements, such as that the CAmust use only cryptographic private key protection. The required assurance level depends
modules that have been formally certified as complying with on the risks associated with a potential compromise. The
the U.S. Federal Information Processing Standard 140-2 Level federalPKI,amongothers,dividesassuranceintothreeclasses.
3. In this case, the CPS would mirror the policy statement or Rudimentary assurance involves very little control of either the
perhaps extend the policy statement by indicating the name of
registration process or key security. The federal PKI does not
the cryptographic module in use. consider rudimentary assurance appropriate for healthcare use.
3.4.3 A certificate policy may apply to a group of organi- Medium assurance involves a higher degree of diligence in the
zations and is often written for a defined community of relying registration process and requires a number controls over CA
parties. A CPS is written by a CA and applies only to it. Thus keys. Medium assurance is designed for moderate risk appli-
certificate policies are the basis of establishing requirements cations. High assurance adds additional controls on the CAand
for interoperability and equivalent assurance criteria on an subscriber keys as well as careful division of roles in the
industry basis. A CPS is specific to a given CA and does not issuance process. These additions make high assurance certifi-
provide a suitable basis for interoperability between CA cates more appropriate for higher risk applications. Certificates
operated by different organizations. mayalsovarydependinguponthetypeofentitywhoseidentity
E2212−02a (2010)
is bound to the certificate. Finally, certificates are often Practices Framework, describes the expected contents and
described in terms of appropriate and inappropriate uses. format of certificate policy statements. It also specifies stan-
dard section headings, contents, and numbering. The policy
4.6 The policy does not define certificates in terms of
follows the IETF conventions.
assurance levels. Instead, it defines three classes of certificates
(entity, basic individual, and clinical individual) that differ in
5.2 The term “no stipulation” is used whenever the IETF
terms of their primary intended use or purpose and in terms of
draft includes a section heading for which this practice has no
their intended subscriber type. The three certificate classes are
requirement.
ordered so that the clinical individual certificate must meet all
the requirements of the basic individual certificate and the
5.3 IETF Guidelines (RFC 2119) require the use of “must”
basic individual certificate must meet all the requirements of
and “must not” while ASTM International requires the use of
the entity certificate.
“shall” and “shall not.” The two sets of terms are defined
equivalently. IETF andASTM International agree in the use of
4.7 It is anticipated that the policy will be used to facilitate
cross-licensing between healthcare CA. The policy is intended terms “should,” “should not,” and “may.” Annex A1, which
to provide a common reference point for establishing compat- contains the healthcare certificate policy (referred to as the
ibility of purposes, representations, and practices among a
policy), follows the IETF conventions.
number of autonomous healthcare CA.
5. Healthcare Certificate Policy
5.1 The IETF Draft Standard (RFC 2527), Internet X.509
Public Key Infrastructure Certificate Policy and Certification
ANNEX
(Mandatory Information)
A1. HEALTHCARE CERTIFICATE POLICY
Contents
E31-20 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
10065}
1. Introduction
Healthcare-certificate-policy ::= {E31-20 2}
2. General Provisions
OBJECT IDENTIFIER
id-e3120-certpcy OBJECT ::= {Healthcare-certificate-policy 1}
3. Identification and Authentication
IDENTIFIER
4. Operational Requirements
id-e3120-certpcy-entity ::= {Id-e3120-certpcy 1}
id-e3120-certpcy-basicIndividual ::= {Id-e3120-certpcy 2}
5. Physical, Procedural, and Personnel Security Controls
id-e3120-certpcy- ::= {Id-e3120-certpcy 3}
6. Technical Security Controls
clinicalIndividual
7. Certificate and CRL Profiles
1.3 Community and Applicability
8. Policy Administration
The only persons or organizations expected to benefit from
9. Bibliography
this policy and participate in the PKI it defines (that is, issue,
10. Acronyms obtain, use, or rely upon healthcare certificates) are CA
identified in 1.3.1; certificate applicants and subscribers iden-
11. Glossary
tified in 1.3.2.1; and qualified relying parties identified in
12. Attachment—Healthcare Ce
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.