ASTM E2212-02
(Practice)Standard Practice for Healthcare Certificate Policy
Standard Practice for Healthcare Certificate Policy
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.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or discontinued.
Contact ASTM International (www.astm.org) for the latest information.
Designation: E 2212 – 02
Standard Practice for
Healthcare Certificate Policy
This standard is issued under the fixed designation E 2212; 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 (e) indicates an editorial change since the last revision or reapproval.
1. Scope RFC 2560—Internet X.509 Public Key Infrastructure Online
Certificate Status Protocol, OCSP, June 1999
1.1 This practice covers a policy (“the policy”) for digital
certificates that support the authentication, authorization, con-
3. Terminology Certificate and Related Terms—
fidentiality, integrity, and nonrepudiation requirements of per-
3.1 Certificate and Related Terms—A certificate, also re-
sons and organizations that electronically create, disclose,
ferred to as a digital certificate or public key certificate, binds
receive, or otherwise transact health information.
a public key value to information identifying the entity
1.2 This practice defines a policy for three classes of
associated with the use of a corresponding private key. An
certificates: (1) entity certificates issued to computing compo-
entity may be an individual, organization, account, role,
nents such as servers, devices, applications, processes, or
computer process, or device. The entity identified within the
accounts reflecting role assignment; (2) basic individual cer-
certificate is referred to as the certificate subject. The certificate
tificates issued to natural persons involved in the exchange of
is typically used to verify the digital signature of the certificate
health information used for healthcare provisioning; and (3)
subject or to encrypt information for that subject. The reliabil-
clinical individual certificates issued to natural persons and
ity of the binding of a public key to a certificate subject is
used for authentication of prescriptive orders relating to the
asserted by the certification authority (CA) that creates, issues,
clinical treatment of patients.
and distributes certificates. Certification authority is synony-
1.3 The policy defined by this practice covers: (1) definition
mous with certificate authority. Parties that depend on the
of healthcare certificates, healthcare certification authorities,
accuracy of information in the certificate are referred to as
healthcare subscribers, and healthcare relying parties; (2)
relying parties. Certificate users are the collective relying
appropriate use of healthcare certificates; (3) general condi-
parties and subscribers.
tions for the issuance of healthcare certificates; (4) healthcare
3.2 Certificate Policy:
certificate formats and profile; and (5) requirements for the
3.2.1 The X.509 standard defines a certificate policy (CP) as
protection of key material.
“a named set of rules that indicates the applicability of a
1.4 The policy establishes minimum responsibilities for
certificate to a particular community and/or class of application
healthcare certification authorities, relying parties, and certifi-
with common security requirements.” For example, a particular
cate subscribers.
certificate policy might indicate the type of certificate appli-
2. Referenced Documents cable for authenticating electronic data interchange transac-
tions for the trading of goods within a specified price range. In
2.1 ASTM Standards:
contrast, Practice E 2212 addresses rules for certificates that
E 2084 Specification for Authentication of Healthcare In-
support the authentication, authorization, confidentiality, integ-
formation Using Digital Signatures
2 rity, and nonrepudiation requirements of persons and organi-
E 2086 Guide for Internet and Intranet Healthcare Security
zations that electronically create, disclose, receive, or other-
2.2 Other Documents:
wise transact health information.
Public Law 104-191, Aug. 21, 1996, Health Insurance
3.2.2 Certificates contain a registered certificate policy ob-
Portability and Accountability Act of 1996
ject identifier (OID) that the relying party may use to decide
RFC 2527—Internet X.509 Public Key Infrastructure Cer-
whether a certificate may be trusted for a particular purpose.
tificate Policy and Certification Practices Framework, P-
4 The OID registration process follows the procedures specified
KIX Working Group Internet Draft, January 3, 2002
in ISO/IEC and ITU standards. The party that registers the OID
also publishes the CP for examination by certificate users and
1 other parties. Each certificate should refer to a CP, but may also
This practice is under the jurisdiction of ASTM Committee E31 on Healthcare
refer to additional nonconflicting CP.
Informatics, and is the direct responsibility of Subcommittee E31.20 on Data and
System Security for Health Information.
3.2.3 Certificate policies constitute a basis accrediting CA.
Current edition approved May 10, 2002. Published October 2002.
Annual Book of ASTM Standards, Vol 14.01.
Available at http://aspe.hhs.gov/admnsimp/pl104191.htm.
4 5
Available at www.ietf.org/html.charters/pkix-charter.html. 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.
NOTICE: This standard has either been superseded and replaced by a new version or discontinued.
Contact ASTM International (www.astm.org) for the latest information.
E2212–02
Certificate policies are also used to establish a trust relationship including Specification E 2084 and Guide E 2086.
between two or more CA (cross-certification). When CA issue
4.3 CA that implement procedures satisfying each require-
cross-certificates, one CA assesses and recognizes the relevant
ment of the policy should reference the policy’s OID in the
certificate policies of the other CA.
appropriate fields within its certificates. Relying parties can
3.3 Certification Practice Statement—The term certification
recognize the inclusion of the policy’s OID as an indication
practice statement (CPS) is defined in the Internet X.509 Public
that the issuing CA has conformed to the requirements of the
Key Infrastructure Certificate Policy and Certificate Practices
policy and that the certificates referencing the policy’s OID
Framework as “a statement of the practices, which a certifica-
may be used for healthcare purposes.
tion authority employs in issuing certificates.” The CPS is
4.4 CA that do not comply with all provisions of the policy
differentiated from the CP in the same way that any policy is
must not assert the policy’s OID in its certificates. A CA that
different from a practice statement. The CPS is a comprehen-
complies with all but a limited number of provisions may
sive description by the CA of the methods, components, and
reference the policy in its own policy, provided that it clearly
procedures it has elected to implement and which define how
states the specific deviations. For example, a healthcare orga-
it conducts itself throughout the certificate life cycle. A CA
nization might operate an internal CA that complies with all of
with a single CPS may support multiple certificate policies if
the provisions of the basic individual certificate class except
the certificates it issues will be used for different application
that it uses a noncomplying cryptographic module for the CA
purposes or by different certificate user communities, or both.
signer keys. The organization might want to use the policy as
Any number of CA, with unique CPS, may support the same
the basis for establishing trust with external relying parties.
certificate policy.
While it may not directly assert this policy using the OID, it
3.4 Relationship Between a Certificate Policy and a Certi-
may reference the policy in a document that includes state-
fication Practice Statement:
ments explaining measures it has taken to protect the integrity
3.4.1 A certificate policy assigns responsibilities to various
of the CA signing key. Relying parties or CA wishing to
participants in a public key infrastructure (PKI). These respon-
facilitate cross-trust relationships must then make their own
sibilities may be stated in differential levels of specificity. For
risk analysis to determine if the modified policy is adequate for
example, a policy may require the CA to confirm subscriber
the proposed usage. This assessment, while not as easy as that
identity but leave the details to the CA to specify in its CPS. In
based upon full compliance, should be significantly facilitated
this case, the CPS might include a list of acceptable identifi-
by treating the policy as a reference standard from which to
cation documents and the methods by which the CA, its agents,
judge the modifications.
or both, verify their authenticity. Alternatively, the CA might
4.5 Certificates and the certificate issuance process can vary
implement other identity authentication methods that rely upon
in at least three distinct ways. The most frequently cited
statements by an employer’s human resources manager. With a
variation is about assurance. Assurance levels vary depending
less specific requirement, the CA has more flexibility in
upon the degree of diligence applied in the registration, key
determining its practices and would need to describe what
generation, certificate issuance, certificate revocation, and
options it has chosen to implement in the CPS.
private key protection. The required assurance level depends
3.4.2 On the other hand, a policy may have a very specific
on the risks associated with a potential compromise. The
requirements, such as that the CA must use only cryptographic
federal PKI, among others, divides assurance into three classes.
modules that have been formally certified as complying with
Rudimentary assurance involves very little control of either the
the U.S. Federal Information Processing Standard 140-2 Level
registration process or key security. The federal PKI does not
3. In this case, the CPS would mirror the policy statement or
consider rudimentary assurance appropriate for healthcare use.
perhaps extend the policy statement by indicating the name of
Medium assurance involves a higher degree of diligence in the
the cryptographic module in use.
registration process and requires a number controls over CA
3.4.3 A certificate policy may apply to a group of organi-
keys. Medium assurance is designed for moderate risk appli-
zations and is often written for a defined community of relying
cations. High assurance adds additional controls on the CA and
parties. A CPS is written by a CA and applies only to it. Thus
subscriber keys as well as careful division of roles in the
certificate policies are the basis of establishing requirements
issuance process. These additions make high assurance certifi-
for interoperability and equivalent assurance criteria on an
cates more appropriate for higher risk applications. Certificates
industry basis. A CPS is specific to a given CA and does not
may also vary depending upon the type of entity whose identity
provide a suitable basis for interoperability between CA
is bound to the certificate. Finally, certificates are often
operated by different organizations.
described in terms of appropriate and inappropriate uses.
4. Significance and Use
4.6 The policy does not define certificates in terms of
4.1 The policy defined by this practice is written from the assurance levels. Instead, it defines three classes of certificates
perspective of healthcare relying parties. It defines a set of (entity, basic individual, and clinical individual) that differ in
requirements to ensure that certificates, used for authentication, terms of their primary intended use or purpose and in terms of
authorization, confidentiality, integrity, and nonrepudiation of their intended subscriber type. The three certificate classes are
health information by healthcare organizations and persons, ordered so that the clinical individual certificate must meet all
have a minimally sufficient assurance level. the requirements of the basic individual certificate and the
4.2 This policy defines a healthcare public key infrastruc- basic individual certificate must meet all the requirements of
ture that can be used to implement other ASTM standards the entity certificate.
NOTICE: This standard has either been superseded and replaced by a new version or discontinued.
Contact ASTM International (www.astm.org) for the latest information.
E2212–02
4.7 It is anticipated that the policy will be used to facilitate follows the IETF conventions.
cross-licensing between healthcare CA. The policy is intended
5.2 The term “no stipulation” is used whenever the IETF
to provide a common reference point for establishing compat-
draft includes a section heading for which this specification has
ibility of purposes, representations, and practices among a
no requirement.
number of autonomous healthcare CA.
5.3 IETF Guidelines (RFC 2119) require the use of “must”
5. Healthcare Certificate Policy
and “must not” while ASTM International requires the use of
“shall” and “shall not.” The two sets of terms are defined
5.1 The IETF Draft Standard (RFC 2527), Internet X.509
equivalently. IETF and ASTM International agree in the use of
Public Key Infrastructure Certificate Policy and Certification
terms “should,” “should not,” and “may.” Annex A1, which
Practices Framework, describes the expected contents and
format of certificate policy statements. It also specifies stan- contains the healthcare certificate policy (referred to as the
dard section headings, contents, and numbering. The policy policy), follows the IETF conventions.
ANNEX
(Mandatory Information)
A1. HEALTHCARE CERTIFICATE POLICY
Contents under this policy may be used for nonhealthcare purposes;
however, assurances for such purposes are outside the scope of
Introduction
this policy.
Terminology
A1.3.1 This policy is intended to define minimum require-
General Provisions
Identification and Authentication ments that must be satisfied by CA issuing certificates to
Operational Requirements healthcare persons in order for those certificates to be generally
Physical, Procedural, and Personnel Security Controls acceptable to autonomous healthcare relying parties. This
Technical Security Controls policy assumes that parties participating in the PKI will have
Certificate and CRL Profiles healthcare industry roles and responsibilities defined by federal
Policy Administration regulation such as that mandated by the Health Insurance
Portability and Accountability Act of 1996 also known as
Introduction
HIPAA [Public Law 104-191, Subtitle F–Administrative Sim-
plification, dated Aug 21, 1996], by various state licensing
A1.1 Overview—This certificate policy sets requirements
requiremen
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.