draft-ietf-pkix-ipki-new-rfc2527-01.txt

PKIX的RFC英文文档

The IATA Commercial-Grade CP could be used to protect financial 
transactions or binding contractual exchanges between airlines.  
Under this policy, IATA could require that certified key pairs be 
generated and stored in approved cryptographic hardware tokens.  
Certificates and tokens could be provided to airline employees with 
disbursement authority.  These authorized individuals might then be 
required to present themselves to the corporate security office, 
show a valid identification badge, and sign a subscriber agreement 
requiring them to protect the token and use it only for authorized 
purposes, as a condition of being issued a token and a certificate. 

3.3 X.509 CERTIFICATE FIELDS

The following extension fields in an X.509 certificate are used to 
support CPs:
 
* Certificate Policies extension;
* Policy Mappings extension; and
* Policy Constraints extension.

3.3.1 Certificate Policies Extension

A Certificate Policies field lists CPs that the certification 
authority declares are applicable.  Using the example of the IATA 
General-Purpose and Commercial-Grade policies defined in Section 
3.2, the certificates issued to regular airline employees would 
contain the object identifier for General-Purpose policy.  The 
certificates issued to the employees with disbursement authority 
would contain the object identifiers for both the General-Purpose 
policy and the Commercial-Grade policy.  The inclusion of both 

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 10]

object identifiers in the certificates means that they would be 
appropriate for either the General-Purpose or Commercial-Grade 
policies.  The Certificate Policies field may also optionally convey 
qualifier values for each identified policy; the use of qualifiers 
is discussed in Section 3.4.

When processing a certification path, a CP that is acceptable to the 
relying party application must be present in every certificate in 
the path, i.e., in CA-certificates as well as end entity 
certificates.
 
If the Certificate Policies field is flagged critical, it serves the 
same purpose as described above but also has an additional role.  
Specifically, it indicates that the use of the certificate is 
restricted to one of the identified policies, i.e., the 
certification authority is declaring that the certificate must only 
be used in accordance with the provisions of at least one of the 
listed CPs.  This field is intended to protect the certification 
authority against claims for damages asserted by a relying party who 
has used the certificate for an inappropriate purpose or in an 
inappropriate manner, as stipulated in the applicable CP.
 
For example, the Internal Revenue Service might issue certificates 
to taxpayers for the purpose of protecting tax filings.  The 
Internal Revenue Service understands and can accommodate the risks 
of erroneously issuing a bad certificate, e.g., to an imposter.  
Suppose, however, that someone used an Internal Revenue Service tax-
filing certificate as the basis for encrypting multi-million-dollar-
value proprietary trade secrets, which subsequently fell into the 
wrong hands because of a cryptanalytic attack by an attacker who is 
able to decrypt the message.  The Internal Revenue Service may want 
to defend itself against claims for damages in such circumstances by 
pointing to the criticality of the Certificate Policies extension to 
show that the subscriber and relying party misused the certificate.  
The critical-flagged Certificate Policies extension is intended to 
mitigate the risk to the CA in such situations.  

3.3.2  Policy Mappings Extension

The Policy Mappings extension may only be used in CA-certificates.  
This field allows a certification authority to indicate that certain 
policies in its own domain can be considered equivalent to certain 
other policies in the subject certification authority's domain.
 
For example, suppose that for purposes of facilitating 
interoperability, the ACE Corporation establishes an agreement with 
the ABC Corporation to cross-certify the public keys of each others' 
certification authorities for the purposes of mutually securing 
their respective business-to-business exchanges.  Further, suppose 
that both companies have pre-existing financial transaction 
protection policies called ace-e-commerce and abc-e-commerce, 
respectively.  One can see that simply generating cross-certificates 
between the two domains will not provide the necessary 
interoperability, as the two companies' applications are configured 

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 11]
with, and employee certificates are populated with, their 
respective certificate policies.  One possible solution is to 
reconfigure all of the financial applications to require either 
policy and to reissue all the certificates with both policies 
appearing in their Certificate Policies extensions.  Another 
solution, which may be easier to administer, uses the Policy Mapping 
field.  If this field is included in a cross-certificate for the ABC 
Corporation certification authority issued by the ACE Corporation 
certification authority, it can provide a statement that the ABC's 
financial transaction protection policy (i.e., abc-e-commerce) can 
be considered equivalent to that of the ACE Corporation (i.e., ace-
e-commerce).  With such a statement included in the cross-
certificate issued to ABC, relying party applications in the ACE 
domain requiring the presence of the object identifier for the ace-
e-commerce CP can also accept, process, and rely upon certificates 
issued within the ABC domain containing the object identifier for 
the abc-e-commerce CP.

3.3.3  Policy Constraints Extension

The Policy Constraints extension supports two optional features.  
The first is the ability for a certification authority to require 
that explicit CP indications be present in all subsequent 
certificates in a certification path.  Certificates at the start of 
a certification path may be considered by a relying party to be part 
of a trusted domain, i.e., certification authorities are trusted for 
all purposes so no particular CP is needed in the Certificate 
Policies extension.  Such certificates need not contain explicit 
indications of CP.  When a certification authority in the trusted 
domain, however, certifies outside the domain, it can activate the 
requirement that a specific CP's object identifier appear in 
subsequent certificates in the certification path.

The other optional feature in the Policy Constraints field is the 
ability for a certification authority to disable policy mapping by 
subsequent certification authorities in a certification path.  It 
may be prudent to disable policy mapping when certifying outside the 
domain.  This can assist in controlling risks due to transitive 
trust, e.g., a domain A trusts domain B, domain B trusts domain C, 
but domain A does not want to be forced to trust domain C.

3.3.4  Policy Qualifiers

The Certificate Policies extension field has a provision for 
conveying, along with each CP identifier, additional policy-
dependent information in a qualifier field.  The X.509 standard does 
not mandate the purpose for which this field is to be used, nor does 
it prescribe the syntax for this field.  Policy qualifier types can 
be registered by any organization.
 
The following policy qualifier types are defined in PKIX RFC 2459 
[PKI1]:
 
(a) The CPS Pointer qualifier contains a pointer to a CPS, CPS 
Summary, RPA, or PDS published by the CA.  The pointer is in the 

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 12]
form of a uniform resource identifier (URI).

(b) The User Notice qualifier contains a text string that is to be 
displayed to subscribers and relying parties prior to the use of the 
certificate.  The text string may be an IA5String or a BMPString - a 
subset of the ISO 100646-1 multiple octet coded character set.  A CA 
may invoke a procedure that requires that the relying party 
acknowledge that the applicable terms and conditions have been 
disclosed and/or accepted.

Policy qualifiers can be used to support the definition of generic, 
or parameterized, CPs.  Provided the base CP so provides, policy 
qualifier types can be defined to convey, on a per-certificate 
basis, additional specific policy details that fill in the generic 
definition.

3.4  CERTIFICATION PRACTICE STATEMENT

The term certification practice statement (CPS) is defined by the 
DSG and PAG as:  "A statement of the practices which a certification 
authority employs in issuing certificates." [ABA1, ABA2]  As stated 
above, a CPS establishes practices concerning lifecycle services in 
addition to issuance, such as certificate management (including 
publication and archiving), revocation, and renewal or re-keying.  In
the DSG, the ABA expands this definition with the following comments:

"A certification practice statement may take the form of a 
declaration by the certification authority of the details of its 
trustworthy system and the practices it employs in its operations 
and in support of issuance of a certificate . . . ."  This form of 
CPS is the most common type, and can vary in length and level of 
detail.

Some PKIs may not have the need to create a thorough and detailed 
statement of practices.  For example, the CA may itself be the 
relying party and would already be aware of the nature and 
trustworthiness of its services.  In other cases, a PKI may provide 
certificates providing only a very low level of assurances where the 
applications being secured may pose only marginal risks if 
compromised.  In these cases, an organization establishing a PKI 
may only want to write or have CAs use a subscriber agreement, 
relying party agreement, or agreement combining subscriber and 
relying party terms, depending on the role of the different PKI 
participants.  In such a PKI, that agreement may serve as the only 
"statement of practices" used by one or more CAs within that PKI.
Consequently, that agreement may also be considered a CPS and can 
be entitled or subtitled as such.

Likewise, since a detailed CPS may contain sensitive details of its 
system, a CA may elect not to publish its entire CPS.  It may 
instead opt to publish a CPS Summary (or CPS Abstract).  The CPS 
Summary would contain only those provisions from the CPS that the CA 
considers to be relevant to the participants in the PKI (such as the 
responsibilities of the parties or the stages of the certificate 
lifecycle).  A CPS Summary, however, would not contain those 

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 13]


sensitive provisions of the full CPS that might provide an 
attacker with useful information about the CA's operations.  
Throughout this document, the use of "CPS" includes both a detailed 
CPS and a CPS Summary (unless otherwise specified).

CPSs do not automatically constitute contracts and do not 
automatically bind PKI participants as a contract would.  Where a 
document serves the dual purpose of being a subscriber or relying 
party agreement and CPS, the document is intended to be a contract 
and constitutes a binding contract to the extent that a subscriber 
or relying party agreement would ordinarily be considered as such.  
Most CPSs, however, do not serve such a dual purpose.  Therefore, in 
most cases, a CPS's terms have a binding effect as contract terms 
only if a separate document creates a contractual relationship 
between the parties and that document incorporates part or all of 
the CPS by reference.  Further, if a particular PKI employs a CPS 
Summary (as opposed to the entire CPS), the CPS Summary could be 
incorporated into any applicable subscriber or relying party 
agreement.

In the future, a court or applicable statutory or regulatory law may 
declare that a certificate itself is a document that is capable of 
creating a contractual relationship, to the extent its mechanisms 
designed for incorporation by reference (such as the Certificate 
Policies extension and its qualifiers) indicate that terms of its 
use appear in certain documents.  In the meantime, however, some 
subscriber agreements and relying party agreements may incorporate a 
CPS by reference and therefore make its terms binding on the parties 
to such agreements.

3.5  RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION 
PRACTICE STATEMENT

The CP and CPS address the same set of topics that are of interest 
to the relying party in terms of the degree to and purpose for which 
a public key certificate should be trusted.  Their primary 
difference is in the focus of their provisions.  A CP sets forth the 
requirements and standards imposed by the PKI with respect to the 
various topics.  In other words, the purpose of the CP is to 
establish what participants must do.  A CPS, by contrast, states how 
a CA and other participants in a given domain implement procedures 
and controls to meet the requirements stated in the CP.  In other 
words, the purpose of the CPS is to disclose how the participants 
perform their functions and implement controls.

An additional difference between a CP and CPS relates the scope of 
coverage of the two kinds of documents.  Since a CP is a statement 
of requirements, it best serves as the vehicle for communicating 
minimum operating guidelines that must be met by interoperating PKIs.  
Thus, a CP generally applies to multiple CAs, multiple organizations,
or multiple domains.  By contrast, a CPS applies only to a single CA 
or single organization and is not generally a vehicle to facilitate 
interoperation.

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 14]
A CA with a single CPS may support multiple CPs (used for 
different application purposes and/or by different relying party 
communities).  Also, multiple CAs, with non-identical CPSs, may 
support the same CP.

For example, the Federal Government might define a government-wide 
CP for handling confidential human resources information.  The CP 
will be a broad statement of the general requirements for 
participants within the Government's PKI, and an indication of the