RFC2527 日本語訳
2527 Internet X.509 Public Key Infrastructure Certificate Policy andCertification Practices Framework. S. Chokhani, W. Ford. March 1999. (Format: TXT=91860 bytes) (Obsoleted by RFC3647) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Chokhani
Request for Comments: 2527 CygnaCom Solutions, Inc.
Category: Informational W. Ford
VeriSign, Inc.
March 1999
Network Working Group S. Chokhani Request for Comments: 2527 CygnaCom Solutions, Inc. Category: Informational W. Ford VeriSign, Inc. March 1999
Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework
Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
Status of this Memo
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
Abstract
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement.
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement.
1. INTRODUCTION
1. INTRODUCTION
1.1 BACKGROUND
1.1 BACKGROUND
A public-key certificate (hereinafter "certificate") binds a public- key value to a set of information that identifies the entity (such as person, organization, account, or site) associated with use of the corresponding private key (this entity is known as the "subject" of the certificate). A certificate is used by a "certificate user" or "relying party" that needs to use, and rely upon the accuracy of, the public key distributed via that certificate (a certificate user is typically an entity that is verifying a digital signature from the certificate's subject or an entity sending encrypted data to the subject). The degree to which a certificate user can trust the binding embodied in a certificate depends on several factors. These factors include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and security controls; the subject's obligations (for example, in protecting the private key); and the stated undertakings
A public-key certificate (hereinafter "certificate") binds a public- key value to a set of information that identifies the entity (such as person, organization, account, or site) associated with use of the corresponding private key (this entity is known as the "subject" of the certificate). A certificate is used by a "certificate user" or "relying party" that needs to use, and rely upon the accuracy of, the public key distributed via that certificate (a certificate user is typically an entity that is verifying a digital signature from the certificate's subject or an entity sending encrypted data to the subject). The degree to which a certificate user can trust the binding embodied in a certificate depends on several factors. These factors include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and security controls; the subject's obligations (for example, in protecting the private key); and the stated undertakings
Chokhani & Ford Informational [Page 1] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 1] RFC 2527 PKIX March 1999
and legal obligations of the CA (for example, warranties and limitations on liability).
and legal obligations of the CA (for example, warranties and limitations on liability).
A Version 3 X.509 certificate may contain a field declaring that one or more specific certificate policies applies to that certificate [ISO1]. According to X.509, a certificate policy is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." A certificate policy may be used by a certificate user to help in deciding whether a certificate, and the binding therein, is sufficiently trustworthy for a particular application. The certificate policy concept is an outgrowth of the policy statement concept developed for Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1].
A Version 3 X.509 certificate may contain a field declaring that one or more specific certificate policies applies to that certificate [ISO1]. According to X.509, a certificate policy is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." A certificate policy may be used by a certificate user to help in deciding whether a certificate, and the binding therein, is sufficiently trustworthy for a particular application. The certificate policy concept is an outgrowth of the policy statement concept developed for Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1].
A more detailed description of the practices followed by a CA in issuing and otherwise managing certificates may be contained in a certification practice statement (CPS) published by or referenced by the CA. According to the American Bar Association Digital Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1]
A more detailed description of the practices followed by a CA in issuing and otherwise managing certificates may be contained in a certification practice statement (CPS) published by or referenced by the CA. According to the American Bar Association Digital Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1]
1.2 PURPOSE
1.2 PURPOSE
The purpose of this document is to establish a clear relationship between certificate policies and CPSs, and to present a framework to assist the writers of certificate policies or CPSs with their tasks. In particular, the framework identifies the elements that may need to be considered in formulating a certificate policy or a CPS. The purpose is not to define particular certificate policies or CPSs, per se.
The purpose of this document is to establish a clear relationship between certificate policies and CPSs, and to present a framework to assist the writers of certificate policies or CPSs with their tasks. In particular, the framework identifies the elements that may need to be considered in formulating a certificate policy or a CPS. The purpose is not to define particular certificate policies or CPSs, per se.
1.3 SCOPE
1.3 SCOPE
The scope of this document is limited to discussion of the contents of a certificate policy (as defined in X.509) or CPS (as defined in the ABA Guidelines). In particular, this document describes the types of information that should be considered for inclusion in a certificate policy definition or a CPS. While the framework as presented generally assumes use of the X.509 version 3 certificate format, it is not intended that the material be restricted to use of that certificate format. Rather, it is intended that this framework be adaptable to other certificate formats that may come into use.
The scope of this document is limited to discussion of the contents of a certificate policy (as defined in X.509) or CPS (as defined in the ABA Guidelines). In particular, this document describes the types of information that should be considered for inclusion in a certificate policy definition or a CPS. While the framework as presented generally assumes use of the X.509 version 3 certificate format, it is not intended that the material be restricted to use of that certificate format. Rather, it is intended that this framework be adaptable to other certificate formats that may come into use.
The scope does not extend to defining security policies generally (such as organization security policy, system security policy, or data labeling policy) beyond the policy elements that are considered
The scope does not extend to defining security policies generally (such as organization security policy, system security policy, or data labeling policy) beyond the policy elements that are considered
Chokhani & Ford Informational [Page 2] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 2] RFC 2527 PKIX March 1999
of particular relevance to certificate policies or CPSs.
of particular relevance to certificate policies or CPSs.
This document does not define a specific certificate policy or CPS.
This document does not define a specific certificate policy or CPS.
It is assumed that the reader is familiar with the general concepts of digital signatures, certificates, and public-key infrastructure, as used in X.509 and the ABA Guidelines.
It is assumed that the reader is familiar with the general concepts of digital signatures, certificates, and public-key infrastructure, as used in X.509 and the ABA Guidelines.
2. DEFINITIONS
2. DEFINITIONS
This document makes use of the following defined terms:
This document makes use of the following defined terms:
Activation data - Data values, other than keys, that are required
to operate cryptographic modules and that need to be protected
(e.g., a PIN, a passphrase, or a manually-held key share).
Activation data - Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share).
CA-certificate - A certificate for one CA's public key issued by
another CA.
CA-certificate - A certificate for one CA's public key issued by another CA.
Certificate policy - A named set of rules that indicates the
applicability of a certificate to a particular community and/or
class of application with common security requirements. For
example, a particular certificate policy might indicate
applicability of a type of certificate to the authentication of
electronic data interchange transactions for the trading of goods
within a given price range.
Certificate policy - A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.
Certification path - An ordered sequence of certificates which,
together with the public key of the initial object in the path,
can be processed to obtain that of the final object in the path.
Certification path - An ordered sequence of certificates which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path.
Certification Practice Statement (CPS) - A statement of the
practices which a certification authority employs in issuing
certificates.
Certification Practice Statement (CPS) - A statement of the practices which a certification authority employs in issuing certificates.
Issuing certification authority (issuing CA) - In the context of a
particular certificate, the issuing CA is the CA that issued the
certificate (see also Subject certification authority).
Issuing certification authority (issuing CA) - In the context of a particular certificate, the issuing CA is the CA that issued the certificate (see also Subject certification authority).
Policy qualifier - Policy-dependent information that accompanies a
certificate policy identifier in an X.509 certificate.
Policy qualifier - Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate.
Registration authority (RA) - An entity that is responsible for
identification and authentication of certificate subjects, but
that does not sign or issue certificates (i.e., an RA is delegated
certain tasks on behalf of a CA). [Note: The term Local
Registration Authority (LRA) is used elsewhere for the same
concept.]
Registration authority (RA) - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: The term Local Registration Authority (LRA) is used elsewhere for the same concept.]
Chokhani & Ford Informational [Page 3] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 3] RFC 2527 PKIX March 1999
Relying party - A recipient of a certificate who acts in reliance
on that certificate and/or digital signatures verified using that
certificate. In this document, the terms "certificate user" and
"relying party" are used interchangeably.
Relying party - A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably.
Set of provisions - A collection of practice and/or policy
statements, spanning a range of standard topics, for use in
expressing a certificate policy definition or CPS employing the
approach described in this framework.
Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework.
Subject certification authority (subject CA) - In the context of a
particular CA-certificate, the subject CA is the CA whose public
key is certified in the certificate (see also Issuing
certification authority).
Subject certification authority (subject CA) - In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate (see also Issuing certification authority).
3. CONCEPTS
3. CONCEPTS
This section explains the concepts of certificate policy and CPS, and describes their relationship. Other related concepts are also described. Some of the material covered in this section and in some other sections is specific to certificate policies extensions as defined X.509 version 3. Except for those sections, this framework is intended to be adaptable to other certificate formats that may come into use.
This section explains the concepts of certificate policy and CPS, and describes their relationship. Other related concepts are also described. Some of the material covered in this section and in some other sections is specific to certificate policies extensions as defined X.509 version 3. Except for those sections, this framework is intended to be adaptable to other certificate formats that may come into use.
3.1 CERTIFICATE POLICY
3.1 CERTIFICATE POLICY
When a certification authority issues a certificate, it is providing a statement to a certificate user (i.e., a relying party) that a particular public key is bound to a particular entity (the certificate subject). However, the extent to which the certificate user should rely on that statement by the CA needs to be assessed by the certificate user. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.
When a certification authority issues a certificate, it is providing a statement to a certificate user (i.e., a relying party) that a particular public key is bound to a particular entity (the certificate subject). However, the extent to which the certificate user should rely on that statement by the CA needs to be assessed by the certificate user. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.
The X.509 standard defines a certificate policy as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements"[ISO1]. An X.509 Version 3 certificate may contain an indication of certificate policy, which may be used by a certificate user to decide whether or not to trust a certificate for a particular purpose.
The X.509 standard defines a certificate policy as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements"[ISO1]. An X.509 Version 3 certificate may contain an indication of certificate policy, which may be used by a certificate user to decide whether or not to trust a certificate for a particular purpose.
A certificate policy, which needs to be recognized by both the issuer and user of a certificate, is represented in a certificate by a unique, registered Object Identifier. The registration process follows the procedures specified in ISO/IEC and ITU standards. The
A certificate policy, which needs to be recognized by both the issuer and user of a certificate, is represented in a certificate by a unique, registered Object Identifier. The registration process follows the procedures specified in ISO/IEC and ITU standards. The
Chokhani & Ford Informational [Page 4] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 4] RFC 2527 PKIX March 1999
party that registers the Object Identifier also publishes a textual specification of the certificate policy, for examination by certificate users. Any one certificate will typically declare a single certificate policy or, possibly, be issued consistent with a small number of different policies.
party that registers the Object Identifier also publishes a textual specification of the certificate policy, for examination by certificate users. Any one certificate will typically declare a single certificate policy or, possibly, be issued consistent with a small number of different policies.
Certificate policies also constitute a basis for accreditation of CAs. Each CA is accredited against one or more certificate policies which it is recognized as implementing. When one CA issues a CA- certificate for another CA, the issuing CA must assess the set of certificate policies for which it trusts the subject CA (such assessment may be based upon accreditation with respect to the certificate policies involved). The assessed set of certificate policies is then indicated by the issuing CA in the CA-certificate. The X.509 certification path processing logic employs these certificate policy indications in its well-defined trust model.
Certificate policies also constitute a basis for accreditation of CAs. Each CA is accredited against one or more certificate policies which it is recognized as implementing. When one CA issues a CA- certificate for another CA, the issuing CA must assess the set of certificate policies for which it trusts the subject CA (such assessment may be based upon accreditation with respect to the certificate policies involved). The assessed set of certificate policies is then indicated by the issuing CA in the CA-certificate. The X.509 certification path processing logic employs these certificate policy indications in its well-defined trust model.
3.2 CERTIFICATE POLICY EXAMPLES
3.2 CERTIFICATE POLICY EXAMPLES
For example purposes, suppose that IATA undertakes to define some certificate policies for use throughout the airline industry, in a public-key infrastructure operated by IATA in combination with public-key infrastructures operated by individual airlines. Two certificate policies are defined - the IATA General-Purpose policy, and the IATA Commercial-Grade policy.
For example purposes, suppose that IATA undertakes to define some certificate policies for use throughout the airline industry, in a public-key infrastructure operated by IATA in combination with public-key infrastructures operated by individual airlines. Two certificate policies are defined - the IATA General-Purpose policy, and the IATA Commercial-Grade policy.
The IATA General-Purpose policy is intended for use by industry personnel for protecting routine information (e.g., casual electronic mail) and for authenticating connections from World Wide Web browsers to servers for general information retrieval purposes. The key pairs may be generated, stored, and managed using low-cost, software-based systems, such as commercial browsers. Under this policy, a certificate may be automatically issued to anybody listed as an employee in the corporate directory of IATA or any member airline who submits a signed certificate request form to a network administrator in his or her organization.
The IATA General-Purpose policy is intended for use by industry personnel for protecting routine information (e.g., casual electronic mail) and for authenticating connections from World Wide Web browsers to servers for general information retrieval purposes. The key pairs may be generated, stored, and managed using low-cost, software-based systems, such as commercial browsers. Under this policy, a certificate may be automatically issued to anybody listed as an employee in the corporate directory of IATA or any member airline who submits a signed certificate request form to a network administrator in his or her organization.
The IATA Commercial-Grade policy is used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA requires that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens are provided to airline employees with disbursement authority. These authorized individuals are required to present themselves to the corporate security office, show a valid identification badge, and sign an undertaking to protect the token and use it only for authorized purposes, before a token and a certificate are issued.
The IATA Commercial-Grade policy is used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA requires that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens are provided to airline employees with disbursement authority. These authorized individuals are required to present themselves to the corporate security office, show a valid identification badge, and sign an undertaking to protect the token and use it only for authorized purposes, before a token and a certificate are issued.
Chokhani & Ford Informational [Page 5] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 5] RFC 2527 PKIX March 1999
3.3 X.509 CERTIFICATE FIELDS
3.3 X.509 CERTIFICATE FIELDS
The following extension fields in an X.509 certificate are used to support certificate policies:
The following extension fields in an X.509 certificate are used to support certificate policies:
* Certificate Policies extension;
* Policy Mappings extension; and
* Policy Constraints extension.
* Certificate Policies extension; * Policy Mappings extension; and * Policy Constraints extension.
3.3.1 Certificate Policies Extension
3.3.1 Certificate Policies Extension
The Certificate Policies extension has two variants - one with the field flagged non-critical and one with the field flagged critical. The purpose of the field is different in the two cases.
The Certificate Policies extension has two variants - one with the field flagged non-critical and one with the field flagged critical. The purpose of the field is different in the two cases.
A non-critical Certificate Policies field lists certificate policies that the certification authority declares are applicable. However, use of the certificate is not restricted to the purposes indicated by the applicable policies. Using the example of the IATA General- Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees will contain the object identifier for certificate policy for the General-Purpose policy. The certificates issued to the employees with disbursement authority will contain the object identifiers for both the General- Purpose policy and the Commercial-Grade policy. The Certificate Policies field may also optionally convey qualifier values for each identified policy; use of qualifiers is discussed in Section 3.4.
A non-critical Certificate Policies field lists certificate policies that the certification authority declares are applicable. However, use of the certificate is not restricted to the purposes indicated by the applicable policies. Using the example of the IATA General- Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees will contain the object identifier for certificate policy for the General-Purpose policy. The certificates issued to the employees with disbursement authority will contain the object identifiers for both the General- Purpose policy and the Commercial-Grade policy. The Certificate Policies field may also optionally convey qualifier values for each identified policy; use of qualifiers is discussed in Section 3.4.
The non-critical Certificate Policies field is designed to be used by applications as follows. Each application is pre-configured to know what policy it requires. Using the example in Section 3.2, electronic mail applications and Web servers will be configured to require the General-Purpose policy. However, an airline's financial applications will be configured to require the Commercial-Grade policy for validating financial transactions over a certain dollar value.
The non-critical Certificate Policies field is designed to be used by applications as follows. Each application is pre-configured to know what policy it requires. Using the example in Section 3.2, electronic mail applications and Web servers will be configured to require the General-Purpose policy. However, an airline's financial applications will be configured to require the Commercial-Grade policy for validating financial transactions over a certain dollar value.
When processing a certification path, a certificate policy that is acceptable to the certificate-using application must be present in every certificate in the path, i.e., in CA-certificates as well as end entity certificates.
When processing a certification path, a certificate policy that is acceptable to the certificate-using 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. 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 one of the listed certificate policies. This field is
If the Certificate Policies field is flagged critical, it serves the same purpose as described above but also has an additional role. 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 one of the listed certificate policies. This field is
Chokhani & Ford Informational [Page 6] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 6] RFC 2527 PKIX March 1999
intended to protect the certification authority against damage claims by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable certificate policy definition.
intended to protect the certification authority against damage claims by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable certificate policy definition.
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 accidentally issuing a bad certificate, e.g., to a wrongly- authenticated person. However, suppose someone used an Internal Revenue Service tax-filing certificate as the basis for encrypting multi-million-dollar-value proprietary secrets which subsequently fell into the wrong hands because of an error in issuing the Internal Revenue Service certificate. The Internal Revenue Service may want to protect itself against claims for damages in such circumstances. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the certificate issuer in such situations.
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 accidentally issuing a bad certificate, e.g., to a wrongly- authenticated person. However, suppose someone used an Internal Revenue Service tax-filing certificate as the basis for encrypting multi-million-dollar-value proprietary secrets which subsequently fell into the wrong hands because of an error in issuing the Internal Revenue Service certificate. The Internal Revenue Service may want to protect itself against claims for damages in such circumstances. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the certificate issuer in such situations.
3.3.2 Policy Mappings Extension
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.
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 the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify each others' public-key infrastructures for the purposes of mutually protecting electronic data interchange (EDI). 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 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. 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).
For example, suppose the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify each others' public-key infrastructures for the purposes of mutually protecting electronic data interchange (EDI). 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 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. 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).
Chokhani & Ford Informational [Page 7] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 7] RFC 2527 PKIX March 1999
3.3.3 Policy Constraints Extension
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 certificate policy indications be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a certificate user to be part of a trusted domain, i.e., certification authorities are trusted for all purposes so no particular certificate policy is needed in the Certificate Policies extension. Such certificates need not contain explicit indications of certificate policy. However, when a certification authority in the trusted domain certifies outside the domain, it can activate the requirement for explicit certificate policy in subsequent certificates in the certification path.
The Policy Constraints extension supports two optional features. The first is the ability for a certification authority to require that explicit certificate policy indications be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a certificate user to be part of a trusted domain, i.e., certification authorities are trusted for all purposes so no particular certificate policy is needed in the Certificate Policies extension. Such certificates need not contain explicit indications of certificate policy. However, when a certification authority in the trusted domain certifies outside the domain, it can activate the requirement for explicit certificate policy 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.
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.4 POLICY QUALIFIERS
3.4 POLICY QUALIFIERS
The Certificate Policies extension field has a provision for conveying, along with each certificate policy 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 Certificate Policies extension field has a provision for conveying, along with each certificate policy 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 Part I [PKI1]:
The following policy qualifier types are defined in PKIX Part I [PKI1]:
(a) The CPS Pointer qualifier contains a pointer to a
Certification Practice Statement (CPS) published by the CA.
The pointer is in the form of a uniform resource identifier
(URI).
(a) The CPS Pointer qualifier contains a pointer to a Certification Practice Statement (CPS) published by the CA. The pointer is in the form of a uniform resource identifier (URI).
(b) The User Notice qualifier contains a text string that is to be
displayed to a certificate user (including 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 certficate user
acknowledge that the applicable terms and conditions have been
disclosed or accepted.
(b) The User Notice qualifier contains a text string that is to be displayed to a certificate user (including 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 certficate user acknowledge that the applicable terms and conditions have been disclosed or accepted.
Chokhani & Ford Informational [Page 8] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 8] RFC 2527 PKIX March 1999
Policy qualifiers can be used to support the definition of generic, or parameterized, certificate policy definitions. Provided the base certificate policy definition 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.
Policy qualifiers can be used to support the definition of generic, or parameterized, certificate policy definitions. Provided the base certificate policy definition 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.5 CERTIFICATION PRACTICE STATEMENT
3.5 CERTIFICATION PRACTICE STATEMENT
The term certification practice statement (CPS) is defined by the ABA Guidelines as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1] In the 1995 draft of the ABA guidelines, the ABA expands this definition with the following comments:
The term certification practice statement (CPS) is defined by the ABA Guidelines as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1] In the 1995 draft of the ABA guidelines, 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, or it may be a
statute or regulation applicable to the certification authority
and covering similar subject matter. It may also be part of the
contract between the certification authority and the subscriber. A
certification practice statement may also be comprised of multiple
documents, a combination of public law, private contract, and/or
declaration.
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, or it may be a statute or regulation applicable to the certification authority and covering similar subject matter. It may also be part of the contract between the certification authority and the subscriber. A certification practice statement may also be comprised of multiple documents, a combination of public law, private contract, and/or declaration.
Certain forms for legally implementing certification practice
statements lend themselves to particular relationships. For
example, when the legal relationship between a certification
authority and subscriber is consensual, a contract would
ordinarily be the means of giving effect to a certification
practice statement. The certification authority's duties to a
relying person are generally based on the certification
authority's representations, which may include a certification
practice statement.
Certain forms for legally implementing certification practice statements lend themselves to particular relationships. For example, when the legal relationship between a certification authority and subscriber is consensual, a contract would ordinarily be the means of giving effect to a certification practice statement. The certification authority's duties to a relying person are generally based on the certification authority's representations, which may include a certification practice statement.
Whether a certification practice statement is binding on a relying
person depends on whether the relying person has knowledge or
notice of the certification practice statement. A relying person
has knowledge or at least notice of the contents of the
certificate used by the relying person to verify a digital
signature, including documents incorporated into the certificate
by reference. It is therefore advisable to incorporate a
certification practice statement into a certificate by reference.
Whether a certification practice statement is binding on a relying person depends on whether the relying person has knowledge or notice of the certification practice statement. A relying person has knowledge or at least notice of the contents of the certificate used by the relying person to verify a digital signature, including documents incorporated into the certificate by reference. It is therefore advisable to incorporate a certification practice statement into a certificate by reference.
As much as possible, a certification practice statement should
indicate any of the widely recognized standards to which the
certification authority's practices conform. Reference to widely
recognized standards may indicate concisely the suitability of the
As much as possible, a certification practice statement should indicate any of the widely recognized standards to which the certification authority's practices conform. Reference to widely recognized standards may indicate concisely the suitability of the
Chokhani & Ford Informational [Page 9] RFC 2527 PKIX March 1999
Chokhani & Ford Informational [Page 9] RFC 2527 PKIX March 1999
certification authority's practices for another person's purposes,
as well as the potential technological compatibility of the
certificates issued by the certification authority with
repositories and other systems.
certification authority's practices for another person's purposes, as well as the potential technological compatibility of the certificates issued by the certification authority with repositories and other systems.
3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION PRACTICE
STATEMENT
3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION PRACTICE STATEMENT
The concepts of certificate policy and CPS come from different sources and were developed for different reasons. However, their interrelationship is important.
The concepts of certificate policy and CPS come from different sources and were developed for different reasons. However, their interrelationship is important.
A certification practice statement is a detailed statement by a certification authority as to its practices, that potentially needs to be understood and consulted by subscribers and certificate users (relying parties). Although the level of detail may vary among CPSs, they will generally be more detailed than certificate policy definitions. Indeed, CPSs may be quite comprehensive, robust documents providing a description of the precise service offerings, detailed procedures of the life-cycle management of certificates, and more - a level of detail which weds the CPS to a particular (proprietary) implementation of a service offering.
認証実施規定は習慣、そんなに潜在的に加入者によって理解されている、相談されるべき必要性、および証明書ユーザに関する証明権威による詳細な声明(信用はパーティーへ行く)です。 詳細のレベルがCPSsの中で異なるかもしれませんが、一般に、彼らは証明書方針定義よりさらに詳細になるでしょう。 本当に、CPSsは正確なサービス提供の記述、証明書のライフサイクル管理の詳細手順書、およびその他を提供するかなり包括的で、強健なドキュメントであるかもしれません--サービス提供の特定(独占)の実装とCPSと結婚する詳細のレベル。
Although such detail may be indispensable to adequately disclose, and to make a full assessment of trustworthiness in the absence of accreditation or other recognized quality metrics, a detailed CPS does not form a suitable basis for interoperability between CAs operated by different organizations. Rather, certificate policies best serve as the vehicle on which to base common interoperability standards and common assurance criteria on an industry-wide (or possibly more global) basis. A CA with a single CPS may support multiple certificate policies (used for different application purposes and/or by different certificate user communities). Also, multiple different CAs, with non-identical certification practice statements, may support the same certificate policy.
そのような詳細ですが、適切に明らかにするのにおいて不可欠であるかもしれません、そして、認可か他の認識された上質の測定基準がないとき信頼できることの完全な査定をするように、詳細なCPSは異なった組織によって運用されたCAsの間で相互運用性の適当な基礎を形成しません。 むしろ、証明書方針は一般的な相互運用性規格と譲渡証書評価基準を産業全体の、そして、(ことによるとよりグローバル)のベースに基礎づける乗り物として最もよく機能します。 独身のCPSがあるカリフォルニアは、複数の証明書が方針(異なったアプリケーション目的異なった証明書ユーザーコミュニティによって使用される)であるとサポートするかもしれません。 また、非同じ認証実施規定で、複数の異なったCAsが同じ証明書方針をサポートするかもしれません。
For example, the Federal Government might define a government-wide certificate policy for handling confidential human resources information. The certificate policy definition will be a broad statement of the general characteristics of that certificate policy, and an indication of the types of applications for which it is suitable for use. Different departments or agencies that operate certification authorities with different certification practice statements might support this certificate policy. At the same time, such certification authorities may support other certificate policies.
例えば、連邦政府は秘密の人的資源情報を扱うための政府全体の証明書方針を定義するかもしれません。 証明書方針定義は、その証明書方針の一般的特色の広い声明と、それが使用に適しているアプリケーションのタイプのしるしになるでしょう。 異なった認証実施規定で証明当局を経営する異なった部か政府機関がこの証明書方針をサポートするかもしれません。 同時に、そのような証明当局は、他の証明書が方針であるとサポートするかもしれません。
Chokhani & Ford Informational [Page 10] RFC 2527 PKIX March 1999
1999年の[10ページ]RFC2527PKIX行進の情報のChokhaniとフォード
The main difference between certificate policy and CPS can therefore be summarized as follows:
したがって、以下の通り証明書方針とCPSの主な違いをまとめることができます:
(a) Most organizations that operate public or inter-
organizational certification authorities will document their
own practices in CPSs or similar statements. The CPS is one
of the organization's means of protecting itself and
positioning its business relationships with subscribers and
other entities.
(a) 公共の、または、相互組織的な証明当局を経営するほとんどの組織がCPSsか同様の声明にそれら自身の習慣を記録するでしょう。 CPSは組織の加入者と他の実体で我が身をかばって、取引関係を置く手段の1つです。
(b) There is strong incentive, on the other hand, for a
certificate policy to apply more broadly than to just a single
organization. If a particular certificate policy is widely
recognized and imitated, it has great potential as the basis
of automated certificate acceptance in many systems, including
unmanned systems and systems that are manned by people not
independently empowered to determine the acceptability of
different presented certificates.
(b) 他方では、証明書方針がまさしく単純組織より広く適用されるために、強い動機があります。 特定の証明書方針が広く認識されて、模倣されるなら、それには、多くのシステムの自動化された証明書承認の基礎として素晴らしい潜在能力があります、異なった提示された証明書の受容性を決定するのは独自に権限を与えられなかった人々によって配置される無人システムとシステムを含んでいて。
In addition to populating the certificate policies field with the certificate policy identifier, a certification authority may include, in certificates it issues, a reference to its certification practice statement. A standard way to do this, using a certificate policy qualifier, is described in Section 3.4.
証明書方針識別子で証明書方針分野に居住することに加えて、証明権威はそれが発行する証明書に認証実施規定の指示するものを含むかもしれません。 証明書方針資格を与える人を使用して、これをする標準の方法はセクション3.4に述べられます。
3.7 SET OF PROVISIONS
3.7 条項のセット
A set of provisions is a collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework.
証明書方針定義かこのフレームワークで説明されたアプローチを使うCPSを急送することにおける使用のためにさまざまな標準の話題にかかっていて、1セットの条項は習慣、そして/または、施政方針の収集です。
A certificate policy can be expressed as a single set of provisions.
1セットの条項として証明書方針を言い表すことができます。
A CPS can be expressed as a single set of provisions with each component addressing the requirements of one or more certificate policies, or, alternatively, as an organized collection of sets of provisions. For example, a CPS could be expressed as a combination of the following:
各コンポーネントが1つ以上の証明書方針の要件を扱っている1セットの条項として、または、代わりに条項のセットの組織化された収集としてCPSを急送できます。 例えば、以下の組み合わせとしてCPSを急送できました:
(a) a list of certificate policies supported by the CPS;
(a) CPSによってサポートされた証明書方針のリスト。
(b) for each certificate policy in (a), a set of provisions which
contains statements that refine that certificate policy by
filling in details not stipulated in that policy or expressly
left to the discretion of the CPS by that certificate policy;
such statements serve to state how this particular CPS
implements the requirements of the particular certificate
(b) (a)のそれぞれの証明書方針のために、その方針か明白に規定されなかった詳細に記入することによってその証明書方針を洗練する声明を含む1セットの条項はその証明書方針によるCPSにいなくなりました。 そのような声明は、この特定のCPSがどう特定の証明書の要件を実装するかを述べるのに役立ちます。
Chokhani & Ford Informational [Page 11] RFC 2527 PKIX March 1999
1999年の[11ページ]RFC2527PKIX行進の情報のChokhaniとフォード
policy;
方針。
(c) a set of provisions that contains statements regarding the
certification practices on the CA, regardless of certificate
policy.
(c) 証明に関する声明を含む1セットの条項が証明書方針にかかわらずカリフォルニアを練習します。
The statements provided in (b) and (c) may augment or refine the stipulations of the applicable certificate policy definition, but must not conflict with any of the stipulations of such certificate policy definition.
(b)と(c)に提供された声明は、適切な証明書方針定義の約款を増大するか、または洗練するかもしれませんが、そのような証明書方針定義の約款のいずれも衝突してはいけません。
This framework outlines the contents of a set of provisions, in terms of eight primary components, as follows:
このフレームワークは以下の通り8つのプライマリ構成要素に関して1セットの条項のコンテンツについて概説します:
* Introduction;
* 序論。
* General Provisions;
* 予算総則。
* Identification and Authentication;
* 識別と認証。
* Operational Requirements;
* 操作上の要件。
* Physical, Procedural, and Personnel Security Controls;
* 物理的な手続き上、および人的安全保護コントロール。
* Technical Security Controls;
* 技術的なセキュリティは制御されます。
* Certificate and CRL Profile; and
* 証明書とCRLプロフィール。 そして
* Specification Administration.
* 仕様政権。
Components can be further divided into subcomponents, and a subcomponent may comprise multiple elements. Section 4 provides a more detailed description of the contents of the above components, and their subcomponents.
さらにコンポーネントをサブコンポーネントに分割できます、そして、サブコンポーネントは複数の要素を包括するかもしれません。 セクション4は上のコンポーネントのコンテンツの、より詳細な記述、およびそれらのサブコンポーネントを提供します。
4. CONTENTS OF A SET OF PROVISIONS
4. 1セットの条項のコンテンツ
This section expands upon the contents of a set of provisions, as introduced in Section 3.7. The topics identified in this section are, consequently, candidate topics for inclusion in a certificate policy definition or CPS.
このセクションはセクション3.7で導入するように1セットの条項のコンテンツで膨張します。 その結果、このセクションで特定された話題は証明書方針定義かCPSでの包含のための候補話題です。
While many topics are identified, it is not necessary for a certificate policy or a CPS to include a concrete statement for every such topic. Rather, a particular certificate policy or CPS may state "no stipulation" for a component, subcomponent, or element on which the particular certificate policy or CPS imposes no requirements. In this sense, the list of topics can be considered a checklist of
多くの話題が特定されますが、証明書方針かCPSがそのようなあらゆる話題のための具体的な声明を含むのは必要ではありません。 むしろ、特定の証明書方針かCPSがコンポーネント、サブコンポーネント、または要素のための特定の証明書方針かCPSが要件を全く課さない「約款がありません」を述べるかもしれません。 この意味で、チェックリストであると話題のリストを考えることができます。
Chokhani & Ford Informational [Page 12] RFC 2527 PKIX March 1999
1999年の[12ページ]RFC2527PKIX行進の情報のChokhaniとフォード
topics for consideration by the certificate policy or CPS writer. It is recommended that each and every component and subcomponent be included in a certificate policy or CPS, even if there is "no stipulation"; this will indicate to the reader that a conscious decision was made to include or exclude that topic. This protects against inadvertent omission of a topic, while facilitating comparison of different certificate policies or CPSs, e.g., when making policy mapping decisions.
証明書方針かCPS作家による考慮のために話題。 それぞれとあらゆるコンポーネントとサブコンポーネントが証明書方針かCPSに含まれているのは、お勧めです、「約款がありません」があっても。 これは、その話題を含んでいるか、または除くのを意識的な決断をしたのを読者に示すでしょう。 これは例えば、決定を写像しながら方針を打ち出すとき、異なった証明書方針かCPSsの比較を容易にしている間、話題の不注意な省略から守ります。
In a certificate policy definition, it is possible to leave certain components, subcomponents, and/or elements unspecified, and to stipulate that the required information will be indicated in a policy qualifier. Such certificate policy definitions can be considered parameterized definitions. The set of provisions should reference or define the required policy qualifier types and should specify any applicable default values.
証明書方針定義では、あるコンポーネント、サブコンポーネント、そして/または、要素を不特定のままにし、必須情報が方針資格を与える人で示されるのを規定するのは可能です。 parameterized定義であるとそのような証明書方針定義を考えることができます。 条項のセットは、必要な方針資格を与える人タイプを参照をつけるべきであるか、または定義するべきです、そして、どんな適切なデフォルト値も指定するべきです。
4.1 INTRODUCTION
4.1 序論
This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the specification is targeted.
このコンポーネントは、条項のセットを特定して、導入して、仕様が狙う実体とアプリケーションのタイプを示します。
This component has the following subcomponents:
このコンポーネントには、以下のサブコンポーネントがあります:
* Overview;
* 概要。
* Identification;
* 識別。
* Community and Applicability; and
* 共同体と適用性。 そして
* Contact Details.
* 詳細に連絡してください。
4.1.1 Overview
4.1.1 概要
This subcomponent provides a general introduction to the specification.
このサブコンポーネントは一般的な序論を仕様に提供します。
4.1.2 Identification
4.1.2 識別
This subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, for the set of provisions.
このサブコンポーネントは条項のセットのためのASN.1オブジェクト識別子を含むどんな適切な名前や他の識別子も提供します。
4.1.3 Community and Applicability
4.1.3 共同体と適用性
This subcomponent describes the types of entities that issue certificates or that are certified as subject CAs (2, 3), the types of entities that perform RA functions (4), and the types of entities
このサブコンポーネントは証明書を発行するか、または対象のCAs(2、3)が公認される実体のタイプ、RA機能(4)を実行する実体のタイプ、および実体のタイプについて説明します。
Chokhani & Ford Informational [Page 13] RFC 2527 PKIX March 1999
1999年の[13ページ]RFC2527PKIX行進の情報のChokhaniとフォード
that are certified as subject end entities or subscribers. (5, 6)
終わりの実体か加入者をかけるとき、それは公認されています。 (5, 6)
This subcomponent also contains:
また、このサブコンポーネントは以下を含んでいます。
* A list of applications for which the issued certificates are
suitable. (Examples of application in this case are: electronic
mail, retail transactions, contracts, travel order, etc.)
* 発行された証明書が適しているアプリケーションのリスト。 (この場合、アプリケーションに関する例は: 電子メール、小売のトランザクション、契約、旅行注文ですなど)
* A list of applications for which use of the issued certificates
is restricted. (This list implicitly prohibits all other uses
for the certificates.)
* 発行された証明書の使用が制限されるアプリケーションのリスト。 (このリストはそれとなく証明書への他のすべての用途を禁止します。)
* A list of applications for which use of the issued certificates
is prohibited.
* 発行された証明書の使用が禁止されているアプリケーションのリスト。
4.1.4 Contact Details
4.1.4 詳細な連絡先
This subcomponent includes the name and mailing address of the authority that is responsible for the registration, maintenance, and interpretation of this certificate policy or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person.
このサブコンポーネントは名前、登録に原因となる権威の郵送先住所、メインテナンス、およびこの証明書方針かCPSの解釈を含んでいます。また、それは連絡窓口の名前、電子メールアドレス、電話番号、およびファックス番号を含んでいます。
4.2 GENERAL PROVISIONS
4.2 一般的な条項
This component specifies any applicable presumptions on a range of legal and general practices topics.
このコンポーネントはさまざまな法的、そして、一般診療話題におけるどんな適切な推定も指定します。
This component contains the following subcomponents:
このコンポーネントは以下のサブコンポーネントを含んでいます:
* Obligations;
* 義務。
* Liability;
* 責任。
* Financial Responsibility;
* 金融責任。
* Interpretation and Enforcement;
* 解釈と実施。
* Fees;
* 料金。
* Publication and Repositories;
* 公表と倉庫。
* Compliance Audit;
* 承諾監査。
* Confidentiality; and
* 秘密性。 そして
* Intellectual Property Rights.
* 知的所有権はまっすぐになります。
Chokhani & Ford Informational [Page 14] RFC 2527 PKIX March 1999
1999年の[14ページ]RFC2527PKIX行進の情報のChokhaniとフォード
Each subcomponent may need to separately state provisions applying to the entity types: CA, repository, RA, subscriber, and relying party. (Specific provisions regarding subscribers and relying parties are only applicable in the Liability and Obligations subcomponents.)
各サブコンポーネントは、別々に実体タイプに適用される条項を述べる必要があるかもしれません: カリフォルニア、倉庫、RA、加入者、および信用はパーティーへ行きます。 (加入者と信用パーティーに関する特定の条項はLiabilityとObligationsサブコンポーネントだけで適切です。)
4.2.1 Obligations
4.2.1 義務
This subcomponent contains, for each entity type, any applicable provisions regarding the entity's obligations to other entities. Such provisions may include:
このサブコンポーネントはそれぞれの実体タイプのために実体の義務に関するどんな適切な条項も他の実体に含んでいます。 そのような条項は以下を含むかもしれません。
* CA and/or RA obligations:
* Notification of issuance of a certificate to the
subscriber who is the subject of the certificate being
issued;
* Notification of issuance of a certificate to others
than the subject of the certificate;
* Notification of revocation or suspension of a
certificate to the subscriber whose certificate is being
revoked or suspended; and
* Notification of revocation or suspension of a
certificate to others than the subject whose certificate
is being revoked or suspended.
* カリフォルニア、そして/または、RA義務: * 発行される証明書の対象である加入者への証明書の発行の通知。 * 証明書の対象より他のものへの証明書の発行の通知。 * 証明書が取り消されるか、または吊されている加入者への取消しの通知か証明書のサスペンション。 そして、証明書が取り消されるか、または吊されている対象より取消しの*通知か他のものへの証明書のサスペンション。
* Subscriber obligations:
* 加入者義務:
* Accuracy of representations in certificate application;
* Protection of the entity's private key;
* Restrictions on private key and certificate use; and
* Notification upon private key compromise.
* 証明書アプリケーションにおける、表現の精度。 * 実体の秘密鍵の保護。 * 秘密鍵における制限と証明書使用。 そして、秘密鍵感染に関する*通知。
* Relying party obligations:
* 当てにしているパーティー義務:
* Purposes for which certificate is used;
* Digital signature verification responsibilities;
* Revocation and suspension checking responsibilities;
and
* Acknowledgment of applicable liability caps and
warranties.
* 証明書が使用されている目的。 * デジタル署名検証責任。 * 取消しとサスペンション照合責任。 そして、適切な責任上限と保証の*承認。
* Repository obligations
* 倉庫義務
* Timely publication of certificates and revocation
information
* 証明書と取消し情報のタイムリーな公表
Chokhani & Ford Informational [Page 15] RFC 2527 PKIX March 1999
1999年の[15ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.2.2 Liability
4.2.2 責任
This subcomponent contains, for each entity type, any applicable provisions regarding apportionment of liability, such as:
このサブコンポーネントはそれぞれの実体タイプのために以下などの責任の配分に関するどんな適切な条項も含んでいます。
* Warranties and limitations on warranties;
* 保証における保証と制限。
* Kinds of damages covered (e.g., indirect, special,
consequential, incidental, punitive, liquidated damages,
negligence and fraud) and disclaimers;
* カバーされた損害賠償(例えば、間接的で、特別で、ゆゆしくて、付帯的で、懲罰的な損害の弁償、怠慢、および詐欺)と注意書きの種類。
* Loss limitations (caps) per certificate or per transaction; and
* 証明書かトランザクションあたりの損失制限(上限)。 そして
* Other exclusions (e.g., Acts of God, other party
responsibilities).
* 他の除外、(例えば、神、相手の条例、責任)
4.2.3 Financial Responsibility
4.2.3 金融責任
This subcomponent contains, for CAs, repository, and RAs, any applicable provisions regarding financial responsibilities, such as:
このサブコンポーネントは以下としてCAs、倉庫とRAs、金融責任に関するどんな適切な条項のためのそのようなものも含んでいます。
* Indemnification of CA and/or RA by relying parties;
* 当てにするのによるカリフォルニア、そして/または、RAの保障はパーティーへ行きます。
* Fiduciary relationships (or lack thereof) between the various
entities; and
* 様々な実体の間の信用上の関係(または、それの不足)。 そして
* Administrative processes (e.g., accounting, audit).
* 管理プロセス(例えば、会計、監査)。
4.2.4 Interpretation and Enforcement
4.2.4 解釈と実施
This subcomponent contains any applicable provisions regarding interpretation and enforcement of the certificate policy or CPS, addressing such topics as:
以下としてそのようなものが話題であると扱って、このサブコンポーネントは証明書方針かCPSの解釈と実施に関するどんな適切な条項も含んでいます。
* Governing law;
* 準拠法。
* Severability of provisions, survival, merger, and notice; and
* 条項、生存、合併、および通知のSeverability。 そして
* Dispute resolution procedures.
* 解決手順について議論してください。
4.2.5 Fees
4.2.5 料金
This subcomponent contains any applicable provisions regarding fees charged by CAs, repositories, or RAs, such as:
このサブコンポーネントは以下などのCAs、倉庫、またはRAsによって請求された料金に関するどんな適切な条項も含んでいます。
* Certificate issuance or renewal fees;
* 発行か更新料を証明してください。
* Certificate access fee;
* アクセスチャージを証明してください。
Chokhani & Ford Informational [Page 16] RFC 2527 PKIX March 1999
1999年の[16ページ]RFC2527PKIX行進の情報のChokhaniとフォード
* Revocation or status information access fee;
* 取消しか状態情報アクセスチャージ。
* Fees for other services such as policy information; and
* 方針情報などの他のサービスのための料金。 そして
* Refund policy.
* 方針を還付してください。
4.2.6 Publication and Repositories
4.2.6 公表と倉庫
This subcomponent contains any applicable provisions regarding:
このサブコンポーネントは以下に関してどんな適切な条項も含んでいます。
* A CA's obligations to publish information regarding its
practices, its certificates, and the current status of such
certificates;
* 習慣、証明書、およびそのような証明書の現在の状態の情報を発表するCAの義務。
* Frequency of publication;
* 公表の頻度。
* Access control on published information objects including
certificate policy definitions, CPS, certificates, certificate
status, and CRLs; and
* 証明書方針定義、CPS、証明書、証明書状態、およびCRLsを含んでいて、発行された情報オブジェクトの上にコントロールにアクセスしてください。 そして
* Requirements pertaining to the use of repositories operated by
CAs or by other independent parties.
* 倉庫の使用に関係する要件がCAsか他の独立しているパーティーで作動しました。
4.2.7 Compliance Audit
4.2.7 承諾監査
This subcomponent addresses the following:
このサブコンポーネントは以下を扱います:
* Frequency of compliance audit for each entity;
* 各実体のための承諾監査の頻度。
* Identity/qualifictions of the auditor;
* 監査役のアイデンティティ/qualifictions。
* Auditor's relationship to the entity being audited; (30)
* 監査される実体との監査役の関係。 (30)
* List of topics covered under the compliance audit; (31)
* 承諾監査の下でカバーされた話題のリスト。 (31)
* Actions taken as a result of a deficiency found during
compliance audit; (32)
* 承諾監査の間に見つけられた欠乏の結果、取られた行動。 (32)
* Compliance audit results: who they are shared with (e.g.,
subject CA, RA, and/or end entities), who provides them (e.g.,
entity being audited or auditor), how they are communicated.
* 承諾監査結果: 彼らが(例えば、対象のカリフォルニア、RA、そして/または、終わりの実体)と共有される人である、だれがそれらがどう伝えられるかというそれら(例えば監査される実体か監査役)を提供しますか?
Chokhani & Ford Informational [Page 17] RFC 2527 PKIX March 1999
1999年の[17ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.2.8 Confidentiality Policy
4.2.8 秘密性方針
This subcomponent addresses the following:
このサブコンポーネントは以下を扱います:
* Types of information that must be kept confidential by CA or RA;
* カリフォルニアかRAが秘密にしなければならない情報のタイプ。
* Types of information that are not considered confidential;
* 秘密であることは考えられない情報のタイプ。
* Who is entitled to be informed of reasons for revocation and
suspension of certificates;
* だれが取消しの理由において知識がある権利を与えられますか、そして、証明書のサスペンション。
* Policy on release of information to law enforcement officials;
* 取締官への情報公開に関する方針。
* Information that can be revealed as part of civil discovery;
* 離れているとき明らかにすることができる民間発見に関する情報。
* Conditions upon which CA or RA may disclose upon owner's
request; and
* カリフォルニアかRAが所有者のところで要求を明らかにするかもしれない状態。 そして
* Any other circumstances under which confidential information may
be disclosed.
* いかなる他の事情もどの秘密情報の下に明らかにされるかもしれないか。
4.2.9 Intellectual Property Rights
4.2.9 知的所有権
This subcomponent addresses ownership rights of certificates, practice/policy specifications, names, and keys.
このサブコンポーネントは、所有権が証明書の権利と、習慣/方針仕様と、名前と、キーであると扱います。
4.3 IDENTIFICATION AND AUTHENTICATION
4.3 識別と認証
This component describes the procedures used to authenticate a certificate applicant to a CA or RA prior to certificate issuance. It also describes how parties requesting rekey or revocation are authenticated. This component also addresses naming practices, including name ownership recognition and name dispute resolution.
このコンポーネントは証明書発行の前にカリフォルニアかRAに証明書応募者を認証するのに用いられた手順について説明します。 また、それはrekeyか取消しを要求するパーティーがどう認証されるかを説明します。 また、このコンポーネントは、命名が名前所有権認識と名前論争の解決を含む習慣であると扱います。
This component has the following subcomponents:
このコンポーネントには、以下のサブコンポーネントがあります:
* Initial Registration;
* 登録に頭文字をつけてください。
* Routine Rekey;
* 通常のRekey。
* Rekey After Revocation; and
* 取消しの後のRekey。 そして
* Revocation Request.
* 取消し要求。
Chokhani & Ford Informational [Page 18] RFC 2527 PKIX March 1999
1999年の[18ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.3.1 Initial Registration
4.3.1 新規登録
This subcomponent includes the following elements regarding identification and authentication procedures during entity registration or certificate issuance:
このサブコンポーネントは実体登録か証明書発行の間、識別と認証手順に関する以下の要素を含んでいます:
* Types of names assigned to the subject (7);
* 対象(7)に割り当てられた名前のタイプ。
* Whether names have to be meaningful or not (8);
* 名前は重要でなければならないか、そして、(8)でない。
* Rules for interpreting various name forms;
* 様々な名前フォームを解釈するための規則。
* Whether names have to be unique;
* 名前が特有でなければならないか否かに関係なく。
* How name claim disputes are resolved;
* 名前クレーム論争はどう解決されているか。
* Recognition, authentication, and role of trademarks;
* 商標の認識、認証、および役割。
* If and how the subject must prove possession of the companion
private key for the public key being registered (9);
* 登録されていて、対象が公開鍵のために仲間秘密鍵の所有物を立証しなければならない、(9)。
* Authentication requirements for organizational identity of
subject (CA, RA, or end entity) (10);
* 対象(カリフォルニア、RA、または終わりの実体)(10)の組織的なアイデンティティのための認証要件。
* Authentication requirements for a person acting on behalf of a
subject (CA, RA, or end entity) (11), including:
* 対象(カリフォルニア、RA、または終わりの実体)を代表して(11)で、含んでいるのに行動している人のための認証要件:
* Number of pieces of identification required;
* How a CA or RA validates the pieces of identification
provided;
* If the individual must present personally to the
authenticating CA or RA;
* How an individual as an organizational person is
authenticated (12).
* 識別の個数が必要です。 * カリフォルニアかRAがどう識別の断片を有効にするかは提供されました。 * 個人が個人的に認証カリフォルニアを贈らなければならないかどうか、さもなければ、RA。 * 組織的な人としての個人は認証されます。どのように、(12)。
4.3.2 Routine Rekey
4.3.2 通常のRekey
This subcomponent describes the identification and authentication procedures for routine rekey for each subject type (CA, RA, and end entity). (13)
このサブコンポーネントは識別について説明します、そして、各対象のための通常のrekeyのための認証手順は(カリフォルニア、RA、および終わりの実体)をタイプします。 (13)
4.3.3 Rekey After Revocation -- No Key Compromise
4.3.3 取消し--いいえ主要な感染の後のRekey
This subcomponent describes the identification and authentication procedures for rekey for each subject type (CA, RA, and end entity) after the subject certificate has been revoked. (14)
このサブコンポーネントは識別について説明します、そして、対象の証明書が取り消された後に各対象のためのrekeyのための認証手順は(カリフォルニア、RA、および終わりの実体)をタイプします。 (14)
Chokhani & Ford Informational [Page 19] RFC 2527 PKIX March 1999
1999年の[19ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.3.4 Revocation Request
4.3.4 取消し要求
This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, and end entity). (16)
このサブコンポーネントは識別について説明します、そして、各対象による取消し要求のための認証手順は(カリフォルニア、RA、および終わりの実体)をタイプします。 (16)
4.4 OPERATIONAL REQUIREMENTS
4.4 操作上の要件
This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, or end entities with respect to various operational activities.
このコンポーネントは、様々な操作上の活動に関してカリフォルニア、対象のCAs、RAs、または終わりの実体を発行するのに課された要件を指定するのに使用されます。
This component consists of the following subcomponents:
このコンポーネントは以下のサブコンポーネントから成ります:
* Certificate Application;
* アプリケーションを証明してください。
* Certificate Issuance;
* 発行を証明してください。
* Certificate Acceptance;
* 承認を証明してください。
* Certificate Suspension and Revocation;
* サスペンションと取消しを証明してください。
* Security Audit Procedures;
* セキュリティ監査手順。
* Records Archival;
* 記録保管所で、記録します。
* Key Changeover;
* キー転換。
* Compromise and Disaster Recovery; and
* 感染と災害復旧。 そして
* CA Termination.
* カリフォルニアの終了。
Within each subcomponent, separate consideration may need to be given to issuing CA, repository, subject CAs, RAs, and end entities.
各サブコンポーネントの中では、別々の考慮は、カリフォルニア、倉庫、対象のCAs、RAs、および終わりの実体を発行するのに与えられている必要があるかもしれません。
4.4.1 Certificate Application
4.4.1 証明書アプリケーション
This subcomponent is used to state requirements regarding subject enrollment and request for certificate issuance.
このサブコンポーネントは、対象の登録に関する要件と証明書発行を求める要求を述べるのに使用されます。
4.4.2 Certificate Issuance
4.4.2 証明書発行
This subcomponent is used to state requirements regarding issuance of a certificate and notification to the applicant of such issuance.
このサブコンポーネントは、証明書と通知の発行に関する要件をそのような発行の応募者に述べるのに使用されます。
Chokhani & Ford Informational [Page 20] RFC 2527 PKIX March 1999
1999年の[20ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.4.3 Certificate Acceptance
4.4.3 証明書承認
This subcomponent is used to state requirements regarding acceptance of an issued certificate and for consequent publication of certificates.
このサブコンポーネントは、発行された証明書の承認と証明書の結果の公表のための要件を述べるのに使用されます。
4.4.4 Certificate Suspension and Revocation
4.4.4 証明書サスペンションと取消し
This subcomponent addresses the following:
このサブコンポーネントは以下を扱います:
* Circumstances under which a certificate may be revoked;
* 証明書が取り消されるかもしれない事情。
* Who can request the revocation of the entity certificate;
* だれが実体証明書の取消しを要求できるか。
* Procedures used for certificate revocation request;
* 証明書取消し要求に用いられた手順。
* Revocation request grace period available to the subject;
* 対象に利用可能な取消し要求据置期間。
* Circumstances under which a certificate may be suspended;
* 証明書が吊されるかもしれない事情。
* Who can request the suspension of a certificate;
* だれが証明書のサスペンションを要求できるか。
* Procedures to request certificate suspension;
* 要求する手順はサスペンションを証明します。
* How long the suspension may last;
* どれくらい長い間、サスペンションがそうするかもしれないかは持続します。
* If a CRL mechanism is used, the issuance frequency;
* CRLメカニズムが使用されているなら、発行頻度です。
* Requirements on relying parties to check CRLs;
* CRLsをチェックするという信用パーティーに関する要件。
* On-line revocation/status checking availability;
* 有用性をチェックするオンライン取消し/状態。
* Requirements on relying parties to perform on-line
revocation/status checks;
* オンライン取消し/状態チェックを実行するという信用パーティーに関する要件。
* Other forms of revocation advertisements available; and
* 他の形式の利用可能な取消し広告。 そして
* Requirements on relying parties to check other forms of
revocation advertisements.
* 他の形式の取消し広告をチェックするという信用パーティーに関する要件。
* Any variations on the above stipulations when the suspension or
revocation is the result of private key compromise (as opposed
to other reasons for suspension or revocation).
* サスペンションか取消しが秘密鍵の結果であるときに、上の約款のどんな変化も妥協します(サスペンションか取消しの他の理由と対照的に)。
Chokhani & Ford Informational [Page 21] RFC 2527 PKIX March 1999
1999年の[21ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.4.5 Security Audit Procedures
4.4.5 セキュリティ監査手順
This subcomponent is used to describe event logging and audit systems, implemented for the purpose of maintaining a secure environment. Elements include the following:
このサブコンポーネントは、安全な環境を維持する目的のために実装されたイベント伐採と監査制度について説明するのに使用されます。 要素は以下を含んでいます:
* Types of events recorded; (28)
* イベントのタイプは記録しました。 (28)
* Frequency with which audit logs are processed or audited;
* 監査ログが処理されるか、または監査される頻度。
* Period for which audit logs are kept;
* どの監査ログが保たれるかために以上。
* Protection of audit logs:
* 監査ログの保護:
- Who can view audit logs;
- Protection against modification of audit log; and
- Protection against deletion of audit log.
- だれが視点監査ログをそうすることができるか。 - 監査ログの変更に対する保護。 そして、--監査ログの削除に対する保護。
* Audit log back up procedures;
* ログ後部を手順に監査してください。
* Whether the audit log accumulation system is internal or
external to the entity;
* 監査ログアキュミュレーション方式が実体に内部である、または外部であることにかかわらず。
* Whether the subject who caused an audit event to occur is
notified of the audit action; and
* 監査イベントが起こることを引き起こした対象が監査動作について通知されるか否かに関係なく。 そして
* Vulnerability assessments.
* 弱点査定。
4.4.6 Records Archival
4.4.6、記録保管所で、記録します。
This subcomponent is used to describe general records archival (or records retention) policies, including the following:
このサブコンポーネントは使用されて、一般について説明するのが記録保管所(または、記録保有)の方針を記録して、包含が以下であるということです:
* Types of events recorded; (29)
* イベントのタイプは記録しました。 (29)
* Retention period for archive;
* アーカイブのための保有の期間。
* Protection of archive:
* アーカイブの保護:
- Who can view the archive;
- Protection against modification of archive; and
- Protection against deletion of archive.
- だれがアーカイブを見ることができるか。 - アーカイブの変更に対する保護。 そして、--アーカイブの削除に対する保護。
* Archive backup procedures;
* バックアップ手順を格納してください。
* Requirements for time-stamping of records;
* 記録の時間の刻印のための要件。
* Whether the archive collection system is internal or external;
* アーカイブ収集システムが内部である、または外部であることにかかわらず。
Chokhani & Ford Informational [Page 22] RFC 2527 PKIX March 1999
1999年の[22ページ]RFC2527PKIX行進の情報のChokhaniとフォード
and
そして
* Procedures to obtain and verify archive information.
* 得て、確かめる手順は情報を格納します。
4.4.7 Key Changeover
4.4.7 主要な転換
This subcomponent describes the procedures to provide a new public key to a CA's users.
このサブコンポーネントは、新しい公開鍵をCAのユーザに提供するために手順について説明します。
4.4.8 Compromise and Disaster Recovery
4.4.8 感染と災害復旧
This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following circumstances may need to be addressed separately:
このサブコンポーネントは感染か災害の場合、通知とリカバリ手順に関連する要件について説明します。 それぞれの以下の事情は、別々に扱われる必要があるかもしれません:
* The recovery procedures used if computing resources, software,
and/or data are corrupted or suspected to be corrupted. These
procedures describe how a secure environment is reestablished,
* リソース、ソフトウェア、そして/または、データを計算するなら使用されるリカバリ手順は、崩壊するように崩壊するか、または疑われます。 これらの手順は安全な環境がどう回復するかを説明します。
which certificates are revoked, whether the entity key is
revoked, how the new entity public key is provided to the users,
and how the subjects are recertified.
実体キーが取り消されるか否かに関係なく、どの証明書が取り消されるか、そして、どう新しい実体公開鍵をユーザに提供するか、そして、対象はどう再公認されるか。
* The recovery procedures used if the entity public key is
revoked. These procedures describe how a secure environment is
reestablished, how the new entity public key is provided to the
users, and how the subjects are recertified.
* 実体公開鍵が取り消されるなら使用されるリカバリ手順。 これらの手順は、安全な環境をどのように回復させるか、そして、どのように新しい実体公開鍵をユーザに提供するか、そして、どのように対象を再公認するかを説明します。
* The recovery procedures used if the entity key is compromised.
These procedures describe how a secure environment is
reestablished, how the new entity public key is provided to the
users, and how the subjects are recertified.
* 実体キーが感染されるなら使用されるリカバリ手順。 これらの手順は、安全な環境をどのように回復させるか、そして、どのように新しい実体公開鍵をユーザに提供するか、そして、どのように対象を再公認するかを説明します。
* The CA's procedures for securing its facility during the period
of time following a natural or other disaster and before a
secure environment is reestablished either at the original site
or a remote hot-site. For example, procedures to protect
against theft of sensitive materials from an earthquake-damaged
site.
* 自然であるか他の災害に続く期間、安全な環境が元のサイトか遠く離れた熱いサイトで回復する前に施設を保証するためのCAの手順。 例えば、地震で破損しているサイトから感光材料の窃盗から守る手順。
4.4.9 CA Termination
4.4.9 カリフォルニアの終了
This subcomponent describes requirements relating to procedures for termination and for termination notification of a CA or RA, including the identity of the custodian of CA and RA archival records.
このサブコンポーネントは終了とカリフォルニアかRAの終了通知のための手順に関連する要件について説明します、カリフォルニアとRA履歴の管理人のアイデンティティを含んでいて。
Chokhani & Ford Informational [Page 23] RFC 2527 PKIX March 1999
1999年の[23ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.5 PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS
4.5 物理的であって、手続き上であり、そして、人的安全保護は制御されます。
This component describes non-technical security controls (that is, physical, procedural, and personnel controls) used by the issuing CA to perform securely the functions of key generation, subject authentication, certificate issuance, certificate revocation, audit, and archival.
このコンポーネントはしっかりとキー生成、対象の認証、証明書発行、証明書取消しの機能を実行する発行カリフォルニアのそばで中古であって、監査で、記録保管所で非技術系のセキュリティコントロール(それはそうです、物理的です、手続き上であり、人員はコントロールである)について説明します。
This component can also be used to define non-technical security controls on repository, subject CAs, RAs, and end entities. The non technical security controls for the subject CAs, RAs, and end entities could be the same, similar, or very different.
また、倉庫、対象のCAs、RAs、および終わりの実体で非技術系のセキュリティコントロールを定義するのにこのコンポーネントを使用できます。 対象のCAs、RAs、および終わりの実体のための非技術的なセキュリティコントロールは、同じであるか、同様であるか、または非常に異なっているかもしれません。
These non-technical security controls are critical to trusting the certificates since lack of security may compromise CA operations resulting, for example, in the creation of certificates or CRLs with erroneous information or the compromise of the CA private key.
これらの非技術系のセキュリティコントロールはセキュリティの不足が、カリフォルニアが例えば間違った情報がある証明書かCRLsの作成かカリフォルニア秘密鍵の感染に結果として生じる操作であると感染するかもしれなくて、証明書を信じるのに重要です。
This component consists of three subcomponents:
このコンポーネントは3つのサブコンポーネントから成ります:
* Physical Security Controls;
* 物理的なセキュリティは制御されます。
* Procedural Controls; and
* 手続き上のコントロール。 そして
* Personnel Security Controls.
* 人的安全保護は制御されます。
Within each subcomponent, separate consideration will, in general, need to be given to each entity type, that is, issuing CA, repository, subject CAs, RAs, and end entities.
一般に、各サブコンポーネントの中では、別々の考慮は、すなわち、それぞれの実体タイプ、カリフォルニアを発行する、倉庫、対象のCAs、RAs、および終わりの実体に与えられている必要があるでしょう。
4.5.1 Physical Security Controls
4.5.1 物理的なセキュリティコントロール
In this subcomponent, the physical controls on the facility housing the entity systems are described.(21) Topics addressed may include:
このサブコンポーネントでは、実体システムを収容する施設における物的管理は話題が扱った説明された.(21)が以下を含むかもしれないということです。
* Site location and construction;
* 立地と工事。
* Physical access;
* 物理的なアクセス。
* Power and air conditioning;
* パワーと空調。
* Water exposures;
* 暴露に水をまいてください。
* Fire prevention and protection;
* 防火と保護。
* Media storage;
* メディアストレージ。
* Waste disposal; and
* 処分を浪費してください。 そして
Chokhani & Ford Informational [Page 24] RFC 2527 PKIX March 1999
1999年の[24ページ]RFC2527PKIX行進の情報のChokhaniとフォード
* Off-site backup.
* オフサイトバックアップ。
4.5.2 Procedural Controls
4.5.2 手続き上のコントロール
In this subcomponent, requirements for recognizing trusted roles are described, together with the responsibilities for each role.(22)
このサブコンポーネントでは、信じられた役割を認識するための要件は各役割への責任と共に説明されます。(22)
For each task identified for each role, it should also be stated how many individuals are required to perform the task (n out m rule). Identification and authentication requirements for each role may also be defined.
また、各役割のために特定された各タスクに関しては、何人の個人がタスク(n出ているm規則)を実行するのに必要であるかと述べられているべきです。 また、各役割のための識別と認証要件は定義されるかもしれません。
4.5.3 Personnel Security Controls
4.5.3 人的安全保護コントロール
This subcomponent addresses the following:
このサブコンポーネントは以下を扱います:
* Background checks and clearance procedures required for the
personnel filling the trusted roles; (23)
* 素性調査とクリアランス手順が信じられた役割をいっぱいにしている人員に必要です。 (23)
* Background checks and clearance procedures requirements for
other personnel, including janitorial staff; (24)
* 用務のスタッフを含む他の人員のための素性調査とクリアランス手順要件。 (24)
* Training requirements and training procedures for each role;
* 各役割のためのトレーニング要件と訓練方法。
* Any retraining period and retraining procedures for each role;
* 各役割のためのどんな再教育の期間と再教育手順も。
* Frequency and sequence for job rotation among various roles;
* 様々な役割の中のジョブローテーションのための頻度と系列。
* Sanctions against personnel for unauthorized actions,
unauthorized use of authority, and unauthorized use of entity
systems; (25)
* 権限のない動作のための人員に対する制裁、権威の無断使用、および実体システムの権限のない使用。 (25)
* Controls on contracting personnel, including:
* 契約人員におけるコントロール、含み:
- Bonding requirements on contract personnel;
- Contractual requirements including indemnification for
damages due to the actions of the contractor personnel;
- Audit and monitoring of contractor personnel; and
- Other controls on contracting personnel.
- 契約人員に要件を接着します。 - 契約者人員の動作による損害賠償のための保障を含む契約要求事項。 - 契約者人員の監査とモニター。 そして、--契約人員における他のコントロール。
* Documentation to be supplied to personnel.
* 人員に提供されるドキュメンテーション。
4.6 TECHNICAL SECURITY CONTROLS
4.6 技術的なセキュリティコントロール
This component is used to define the security measures taken by the issuing CA to protect its cryptographic keys and activation data (e.g., PINs, passwords, or manually-held key shares). This component may also be used to impose constraints on repositories, subject CAs
このコンポーネントは、その暗号化キーと起動データ(例えば、暗証番号、パスワード、または手動で保持された主要なシェア)を保護するために発行カリフォルニアによって取られた安全策を定義するのに使用されます。 また、このコンポーネントは、倉庫、対象のCAsに規制を課すのに使用されるかもしれません。
Chokhani & Ford Informational [Page 25] RFC 2527 PKIX March 1999
1999年の[25ページ]RFC2527PKIX行進の情報のChokhaniとフォード
and end entities to protect their cryptographic keys and critical security parameters. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel.
そして、実体を終わらせて、それらの暗号化キーときわどいセキュリティパラメタを保護してください。 安全なかぎ管理は、すべての秘密、秘密鍵、および起動データが単に任命された者によって保護されて、使用されるのを保証するために重要です。
This component also describes other technical security controls used by the issuing CA to perform securely the functions of key generation, user authentication, certificate registration, certificate revocation, audit, and archival. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls.
また、このコンポーネントはしっかりとキー生成、ユーザー認証、証明書登録、証明書取消しの機能を実行する発行カリフォルニアのそばで中古であって、監査で、記録保管所で他の技術的なセキュリティコントロールについて説明します。 技術制御はライフサイクルセキュリティコントロール(ソフトウェア開発環境セキュリティ、信じられたソフトウェア開発方法論を含んでいる)と操作上のセキュリティコントロールを含んでいます。
This component can also be used to define other technical security controls on repositories, subject CAs, RAs, and end entities.
また、倉庫、対象のCAs、RAs、および終わりの実体で他の技術的なセキュリティコントロールを定義するのにこのコンポーネントを使用できます。
This component has the following subcomponents:
このコンポーネントには、以下のサブコンポーネントがあります:
* Key Pair Generation and Installation;
* 主要な組世代とインストール。
* Private Key Protection;
* 秘密鍵保護。
* Other Aspects of Key Pair Management;
* 主要な組管理の他の局面。
* Activation Data;
* 起動データ。
* Computer Security Controls;
* コンピュータセキュリティコントロール。
* Life-Cycle Security Controls;
* ライフサイクルセキュリティは制御されます。
* Network Security Controls; and
* ネットワークセキュリティは制御されます。 そして
* Cryptographic Module Engineering Controls.
* 暗号のモジュール工学は制御されます。
4.6.1 Key Pair Generation and Installation
4.6.1 主要な組世代とインストール
Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these types of entities, the following questions potentially need to be answered:
主要な組世代とインストールは、発行カリフォルニア、倉庫、対象のCAs、RAs、および対象の終わりの実体のために考えられる必要があります。 それぞれのこれらのタイプの実体のために、以下の質問は、潜在的に答えられる必要があります:
1. Who generates the entity public, private key pair?
1. だれが公立の実体秘密鍵組を生成しますか?
2. How is the private key provided securely to the entity?
2. どのようにしっかりと秘密鍵を実体に提供しますか?
3. How is the entity's public key provided securely to the
certificate issuer?
3. どのようにしっかりと実体の公開鍵を証明書発行人に提供しますか?
Chokhani & Ford Informational [Page 26] RFC 2527 PKIX March 1999
1999年の[26ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4. If the entity is a CA (issuing or subject) how is the entity's
public key provided securely to the users?
4. 実体がカリフォルニア(発行しているか受けることがある)であるなら、どのようにしっかりと実体の公開鍵をユーザに提供しますか?
5. What are the key sizes?
5. 主要なサイズはどのくらいですか?
6. Who generates the public key parameters?
6. だれが、公開鍵がパラメタであると生成しますか?
7. Is the quality of the parameters checked during key generation?
7. パラメタの品質はキー生成の間、チェックされますか?
8. Is the key generation performed in hardware or software?
8. キー生成はハードウェアかソフトウェアで実行されますか?
9. For what purposes may the key be used, or for what purposes
should usage of the key be restricted (for X.509 certificates,
these purposes should map to the key usage flags in the Version
3, X.509 certificates)?
9. どんな目的のために、キーが使用されるかもしれないか、そして、またはキーの使用法はどんな目的のために制限されるべきですか?(X.509証明書に関して、これらの目的がバージョン3で主要な用法に旗を配置するべきです、X.509証明書)
4.6.2 Private Key Protection
4.6.2 秘密鍵保護
Requirements for private key protection need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these types of entity, the following questions potentially need to be answered:
秘密鍵保護のための要件は、発行カリフォルニア、倉庫、対象のCAs、RAs、および対象の終わりの実体のために考えられる必要があります。 それぞれのこれらのタイプの実体のために、以下の質問は、潜在的に答えられる必要があります:
1. What standards, if any, are required for the module used to
generate the keys? For example, are the keys certified by the
infrastructure required to be generated using modules complaint
with the US FIPS 140-1? If so, what is the required FIPS 140-1
level of the module?
1. もしあればどんな規格がキーを生成するのにおいて中古のモジュールに必要ですか? 例えば、キーはUS FIPS140-1と共にモジュール苦情を使用することで生成されるのに必要であるインフラストラクチャによって公認されますか? そうだとすれば、モジュールの必要なFIPS140-1レベルは何ですか?
2. Is the private key under n out of m multi-person control?(18)
If yes, provide n and m (two person control is a special case
of n out of m, where n = m = 2)?
2. mからのnの下の秘密鍵はマルチ人のコントロールですか?(18) はいなら、nとmを提供してください(2人のコントロールはmからのnがmと等しいnの特別なケース=2です)--
3. Is the private key escrowed? (19) If so, who is the escrow
agent, what form is the key escrowed in (examples include
plaintext, encrypted, split key), and what are the security
controls on the escrow system?
3. 秘密鍵はescrowedされますか? (19) そうだとすれば、条件付き証書受託者はだれです、そして、キーはどんなフォームでescrowedされるか、そして、(例が平文を含んでいます、暗号化された分裂キー)第三者預託システムの上のセキュリティコントロールは何ですか?
4. Is the private key backed up? If so, who is the backup agent,
what form is the key backed up in (examples include plaintext,
encrypted, split key), and what are the security controls on
the backup system?
4. 秘密鍵は支援されますか? そうだとすれば、バックアップエージェントはだれです、そして、(平文を含んで、暗号化された例、分裂キー)で支援されたキーはどんなフォームであるか、そして、バックアップ・システムの上のセキュリティコントロールは何ですか?
5. Is the private key archived? If so, who is the archival agent,
what form is the key archived in (examples include plaintext,
encrypted, split key), and what are the security controls on
the archival system?
5. 秘密鍵は格納されますか? そうだとすれば、記録保管所のエージェントはだれです、そして、キーはどんなフォームで格納されるか、そして、(例が平文を含んでいます、暗号化された分裂キー)記録保管所のシステムの上のセキュリティコントロールは何ですか?
Chokhani & Ford Informational [Page 27] RFC 2527 PKIX March 1999
1999年の[27ページ]RFC2527PKIX行進の情報のChokhaniとフォード
6. Who enters the private key in the cryptographic module? In
what form (i.e., plaintext, encrypted, or split key)? How is
the private key stored in the module (i.e., plaintext,
encrypted, or split key)?
6. だれが暗号のモジュールに秘密鍵を入れますか? どんなフォーム(すなわち、暗号化された平文か分裂キー)で? モジュール(すなわち、暗号化された平文か分裂キー)で秘密鍵はどのように保存されますか?
7. Who can activate (use) the private key? What actions must be
performed to activate the private key (e.g., login, power on,
supply PIN, insert token/key, automatic, etc.)? Once the key
is activated, is the key active for an indefinite period,
active for one time, or active for a defined time period?
7. だれが秘密鍵を活性化できますか?(使用します) 秘密鍵を活性化するためにどんな動作を実行しなければなりませんか?(例えば、ログインしてください、そして、電源を入れてください、そして、差し込みトークン/主要で、自動である暗証番号などを供給してください) キーがいったん活性になると、キーは、アクティブですか無期限の間、アクティブですかあるとき、または定義された期間、アクティブですか?
8. Who can deactivate the private key and how? Example of how
might include, logout, power off, remove token/key, automatic,
or time expiration.
8. だれが秘密鍵を非活性化できるか、そして、どのようにですか? どのようにが、包含するかもしれなくて、パワーは下にある状態で、ログアウトするか。例、自動トークン/キーか時間満了を取り外してください。
9. Who can destroy the private key and how? Examples of how might
include token surrender, token destruction, or key overwrite.
9. だれが秘密鍵を破壊できるか、そして、どのようにですか? 力のインクルードトークン降伏、トークン破壊、またはキーがどう上書きされるかに関する例。
4.6.3 Other Aspects of Key Pair Management
4.6.3 主要な組管理の他の局面
Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these types of entity, the following questions potentially need to be answered:
かぎ管理の他の局面は、発行カリフォルニア、倉庫、対象のCAs、RAs、および対象の終わりの実体のために考えられる必要があります。 それぞれのこれらのタイプの実体のために、以下の質問は、潜在的に答えられる必要があります:
1. Is the public key archived? If so, who is the archival agent
and what are the security controls on the archival system? The
archival system should provide integrity controls other than
digital signatures since: the archival period may be greater
than the cryptanalysis period for the key and the archive
requires tamper protection, which is not provided by digital
signatures.
1. 公開鍵は格納されますか? そうだとすれば、記録保管所のエージェントはだれです、そして、記録保管所のシステムの上のセキュリティコントロールは何ですか? 記録保管所のシステムはデジタル署名以外の以下以来の一貫性制御を提供するはずです。 記録保管所の期間は暗号文解読術の期間よりキーが長いかもしれません、そして、アーカイブはタンパー保護を必要とします。(それは、デジタル署名で提供されません)。
2. What are the usage periods, or active lifetimes, for the public
and the private key respectively?
2. 何が、それぞれ公衆と秘密鍵のための用法の期間、またはアクティブな生涯ですか?
4.6.4 Activation Data
4.6.4 起動データ
Activation data refers to data values other than keys that are required to operate cryptographic modules and that need to be protected. (20) Protection of activation data potentially needs to be considered for the issuing CA, subject CAs, RAs, and end entities. Such consideration potentially needs to address the entire life-cycle of the activation data from generation through archival and destruction. For each of the entity types (issuing CA, repository, subject CA, RA, and end entity) all of the questions listed in 4.6.1 through 4.6.3 potentially need to be answered with respect to activation data rather than with respect to keys.
起動データは暗号のモジュールを操作するのが必要であり、保護される必要があるキー以外のデータ値について言及します。 (20) 起動データの保護は、潜在的に発行カリフォルニア、対象のCAs、RAs、および終わりの実体のために考えられる必要があります。 そのような考慮は、潜在的に記録保管所を通る世代と破壊から起動データの全体のライフサイクルを扱う必要があります。 質問のすべてが記載した実体タイプ各人(カリフォルニアを発行する、倉庫、対象のカリフォルニア、RA、および終わりの実体)、4.6、.1、通じて、4.6、.3、潜在的に、キーに関してというよりむしろ起動データに関して答えられるのが必要です。
Chokhani & Ford Informational [Page 28] RFC 2527 PKIX March 1999
1999年の[28ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.6.5 Computer Security Controls
4.6.5 コンピュータセキュリティコントロール
This subcomponent is used to describe computer security controls such as: use of the trusted computing base concept, discretionary access control, labels, mandatory access controls, object reuse, audit, identification and authentication, trusted path, security testing, and penetration testing. Product assurance may also be addressed.
このサブコンポーネントは、以下などのコンピュータセキュリティコントロールについて説明するのに使用されます。 信頼できるコンピューティングベース概念の使用、任意のアクセスコントロール(ラベル、コントロール(オブジェクト再利用)が監査する義務的なアクセス、識別、および認証)は経路、セキュリティテスト、および侵入テストを信じました。 また、製品保証は扱われるかもしれません。
A computer security rating for computer systems may be required. The rating could be based, for example, on the Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), or the Common Criteria. This subcomponent can also address requirements for product evaluation analysis, testing, profiling, product certification, and/or product accreditation related activity undertaken.
コンピュータ・システムのためのコンピュータセキュリティ格付けが必要であるかもしれません。 例えば、格付けはTrusted System Evaluation Criteria(TCSEC)、カナダのTrusted Products Evaluation Criteria、ヨーロッパの情報Technology Security Evaluation Criteria(ITSEC)、またはCommon Criteriaに基づくことができました。 また、このサブコンポーネントは引き受けられた製品評価分析、テスト、プロフィール、製品証明、そして/または、製品認可関連活動のための要件を扱うことができます。
4.6.6 Life Cycle Security Controls
4.6.6 ライフサイクルセキュリティコントロール
This subcomponent addresses system development controls and security management controls.
このサブコンポーネントは、システム開発規則とセキュリティがマネジメント・コントロールであると扱います。
System development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of failsafe design and implementation techniques (e.g., defensive programming) and development facility security.
システム開発規則は製品メインテナンス、ソフトウェア工学習慣、ソフトウェア開発方法論、モジュール方式、レイヤリング、フェールセイフの設計と実装のテクニック(例えば、防衛的なプログラミング)と開発施設セキュリティの使用の間、開発環境セキュリティ、開発人的安全保護、構成管理セキュリティを含んでいます。
Security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation.
セキュリティマネジメント・コントロールは、基幹系システムとネットワークが構成されたセキュリティを固く守るのを保証するためにツールと手順の実行を含んでいます。 これらのツールと手順は、彼らの正しい操作を確実にするために機密保護ソフトウェア、ファームウェア、およびハードウェアの保全をチェックするのを含んでいます。
This subcomponent can also address life-cycle security ratings based, for example, on the Trusted Software Development Methodology (TSDM) level IV and V, independent life-cycle security controls audit, and the Software Engineering Institute's Capability Maturity Model (SEI- CMM).
また、このサブコンポーネントは、ライフサイクルセキュリティが例えばTrusted Software Development MethodologyレベルIVとV(TSDM)、コントロールが監査する独立しているライフサイクルセキュリティ、およびSoftware Engineering InstituteのCapability Maturity Model(SEI- CMM)に基づく格付けであると扱うことができます。
4.6.7 Network Security Controls
4.6.7 ネットワークセキュリティコントロール
This subcomponent addresses network security related controls, including firewalls.
このサブコンポーネントは、ネットワークセキュリティがファイアウォールを含む関連するコントロールであると扱います。
Chokhani & Ford Informational [Page 29] RFC 2527 PKIX March 1999
1999年の[29ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.6.8 Cryptographic Module Engineering Controls (26)
4.6.8 暗号のモジュール工学コントロール(26)
This subcomponent addresses the following aspects of a cryptographic module: identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests. Requirements may be expressed through reference to a standard such as U.S. FIPS 140-1. (27)
このサブコンポーネントは暗号のモジュールの以下の局面を扱います: 暗号のモジュール限界、入力/出力、役割、サービス、有限状態機械、物理的なセキュリティ、ソフトウェアセキュリティ、オペレーティングシステムセキュリティ、アルゴリズムコンプライアンス、電磁環境適合性、および自己診断の識別。 要件はU.S. FIPS140-1などの規格の参照で言い表されるかもしれません。 (27)
4.7 CERTIFICATE AND CRL PROFILES
4.7 証明書AND CRLプロフィール
This component is used to specify the certificate format and, if CRLs are used, the CRL format. Assuming use of the X.509 certificate and CRL formats, this includes information on profiles, versions, and extensions used.
このコンポーネントは、証明書形式とCRLsが使用されているときのCRL形式を指定するのに使用されます。 X.509証明書とCRL形式の使用を仮定して、これはプロフィール、バージョン、および使用される拡張子の情報を含んでいます。
This component has two subcomponents:
このコンポーネントには、2つのサブコンポーネントがあります:
* Certificate Profile; and
* プロフィールを証明してください。 そして
* CRL Profile.
* CRLプロフィール。
4.7.1 Certificate Profile
4.7.1 証明書プロフィール
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the PKIX Part I profile):
このサブコンポーネントは以下のような話題を扱います(aの参照で潜在的にプロフィール定義を切り離してください、私が輪郭を描くPKIX Partなどのように):
* Version number(s) supported;
* (s)がサポートしたバージョン番号。
* Certificate extensions populated and their criticality;
* 居住された拡大とそれらの臨界を証明してください。
* Cryptographic algorithm object identifiers;
* 暗号アルゴリズムオブジェクト識別子。
* Name forms used for the CA, RA, and end entity names;
* 名前フォームはカリフォルニア、RA、および終わりの実体に名前を使用しました。
* Name constraints used and the name forms used in the name
constraints;
* 規制が使用した名前と形成という名前は名前に規制を使用しました。
* Applicable certificate policy Object Identifier(s);
* 適切な証明書方針Object Identifier(s)。
* Usage of the policy constraints extension;
* 方針規制拡大の用法。
* Policy qualifiers syntax and semantics; and
* 方針資格を与える人構文と意味論。 そして
* Processing semantics for the critical certificate policy
extension.
* 重要な証明書方針拡張子のために意味論を処理します。
Chokhani & Ford Informational [Page 30] RFC 2527 PKIX March 1999
1999年の[30ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.7.2 CRL Profile
4.7.2 CRLプロフィール
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the PKIX Part I profile):
このサブコンポーネントは以下のような話題を扱います(aの参照で潜在的にプロフィール定義を切り離してください、私が輪郭を描くPKIX Partなどのように):
* Version numbers supported for CRLs; and
* CRLsのためにサポートされたバージョン番号。 そして
* CRL and CRL entry extensions populated and their criticality.
* CRL、居住されたCRLエントリー拡張子、およびそれらの臨界。
4.8 SPECIFICATION ADMINISTRATION
4.8 仕様管理
This component is used to specify how this particular certificate policy definition or CPS will be maintained.
このコンポーネントは、この特定の証明書方針定義かCPSがどう維持されるかを指定するのに使用されます。
It contains the following subcomponents:
それは以下のサブコンポーネントを含んでいます:
* Specification Change Procedures;
* 仕様書変更手順。
* Publication and Notification Procedures; and
* 公表と通知手順。 そして
* CPS Approval Procedures.
* CPS承認の手順。
4.8.1 Specification Change Procedures
4.8.1 仕様書変更手順
It will occasionally be necessary to change certificate policies and Certification Practice Statements. Some of these changes will not materially reduce the assurance that a certificate policy or its implementation provides, and will be judged by the policy administrator as not changing the acceptability of certificates asserting the policy for the purposes for which they have been used. Such changes to certificate policies and Certification Practice Statements need not require a change in the certificate policy Object Identifier or the CPS pointer (URL). Other changes to a specification will change the acceptability of certificates for specific purposes, and these changes will require changes to the certificate policy Object Identifier or CPS pointer (URL).
証明書方針とCertification Practice Statementsを変えるのが時折必要でしょう。 これらのいくつかの変化が、物質的に、証明書方針かその実装が提供されるという保証を抑えないで、それらが使用された目的のために方針を断言する証明書の受容性を変えないとき、方針管理者で判断されるでしょう。 そのようなものは方針を証明するために変化します、そして、Certification Practice Statementsは証明書方針Object IdentifierかCPS指針(URL)における変化を必要とする必要はありません。 仕様への他の変化は特定の目的で証明書の受容性を変えるでしょう、そして、これらの変化は証明書方針Object IdentifierかCPS指針(URL)に釣り銭がいるでしょう。
This subcomponent contains the following information:
このサブコンポーネントは以下の情報を含んでいます:
* A list of specification components, subcomponents, and/or
elements thereof that can be changed without notification and
without changes to the certificate policy Object Identifier or
CPS pointer (URL).
* 仕様コンポーネント、サブコンポーネント、そして/または、それの通知なしで証明書方針Object Identifierへの変化なしで変えることができる要素またはCPS指針(URL)のリスト。
* A list of specification components, subcomponents, and/or
elements thereof that may change following a notification period
without changing the certificate policy Object Identifier or CPS
* それの証明書方針のObject IdentifierかCPSを変えることのない通知の期間に続いて、変化するかもしれない仕様コンポーネントのリスト、サブコンポーネント、そして/または、要素
Chokhani & Ford Informational [Page 31] RFC 2527 PKIX March 1999
1999年の[31ページ]RFC2527PKIX行進の情報のChokhaniとフォード
pointer (URL). The procedures to be used to notify interested
parties (relying parties, certification authorities, etc.) of
the certificate policy or CPS changes are described. The
description of notification procedures includes the notification
mechanism, notification period for comments, mechanism to
receive, review and incorporate the comments, mechanism for
final changes to the policy, and the period before final changes
become effective.
指針(URL)。 証明書方針かCPS変化について利害関係者(信用パーティー、証明当局など)に通知するのに使用されるべき手順は説明されます。 手順が通知メカニズムを含んでいるという通知の記述、コメントのための通知の期間、受け取るメカニズムは、最終的な変化が有効になる前のコメント、方針への最終的な変化のためのメカニズム、および期間に論評して、盛込まれます。
* A list of specification components, subcomponents, and/or
elements, changes to which require a change in certificate
policy Object Identifier or CPS pointer (URL)..
* 仕様コンポーネントのリスト(サブコンポーネント、そして/または、要素)は、どれが証明書方針Object IdentifierかCPS指針(URL)における変化を必要とするかに変化します。
4.8.2 Publication and Notification Procedures
4.8.2 公表と通知手順
This subcomponent contains the following elements:
このサブコンポーネントは以下の要素を含んでいます:
* A list of components, subcomponents, and elements thereof that
exist but that are not made publicly available; (33)
* それの存在しますが、公的に利用可能にされないコンポーネントのリスト、サブコンポーネント、および要素。 (33)
* Descriptions of mechanisms used to distribute the certificate
policy definition or CPS, including access controls on such
distribution.
* そのような分配でのアクセス制御を含んでいて、メカニズムの記述は以前はよく証明書方針の定義かCPSを広げていました。
4.8.3 CPS Approval Procedures
4.8.3 CPS承認の手順
In a certificate policy definition, this subcomponent describes how the compliance of a specific CPS with the certificate policy can be determined.
証明書方針定義では、このサブコンポーネントは証明書方針への特定のCPSのコンプライアンスがどう決定できるかを説明します。
5. OUTLINE OF A SET OF PROVISIONS
5. 1セットの条項のアウトライン
This section contains a possible outline for a set of provisions, intended to serve as a checklist or (with some further development) a standard template for use by certificate policy or CPS writers. Such a common outline will facilitate:
このセクションはチェックリストとして機能することを意図する1セットの条項のための可能なアウトラインか証明書方針かCPS作家による使用のために(さらなる何らかの開発がある)標準のテンプレートを含みます。 そのような一般的なアウトラインは以下を容易にするでしょう。
(a) Comparison of two certificate policies during cross-
certification (for the purpose of equivalency mapping).
(a) 十字証明(同等マッピングの目的のための)の間の2つの証明書方針の比較。
(b) Comparison of a CPS with a certificate policy definition to
ensure that the CPS faithfully implements the policy.
(b) CPSが政策を忠実に実施するのを保証する証明書方針定義とのCPSの比較。
(c) Comparison of two CPSs.
(c) 2CPSsの比較。
Chokhani & Ford Informational [Page 32] RFC 2527 PKIX March 1999
1999年の[32ページ]RFC2527PKIX行進の情報のChokhaniとフォード
1. INTRODUCTION
1. 序論
1.1 Overview
1.1 概要
1.2 Identification
1.2 識別
1.3 Community and Applicability
1.3.1 Certification authorities
1.3.2 Registration authorities
1.3.3 End entities
1.3.4 Applicability
1.3 共同体とApplicability1.3.1のCertification当局1.3.2のRegistration当局1.3.3のEnd実体1.3.4Applicability
1.4 Contact Details
1.4.1 Specification administration organization
1.4.2 Contact person
1.4.3 Person determining CPS suitability for the policy
1.4 方針へのCPS適合を決定する接触Details1.4.1Specification管理組織の1.4.2Contact人1.4の.3Person
2. GENERAL PROVISIONS
2. 予算総則
2.1 Obligations
2.1 義務
2.1.1 CA obligations
2.1.2 RA obligations
2.1.3 Subscriber obligations
2.1.4 Relying party obligations
2.1.5 Repository obligations
2.1.1 カリフォルニア義務2.1.2のRA義務2.1.3のSubscriber義務2.1.4のRelyingパーティー義務2.1.5のRepository義務
2.2 Liability
2.2 責任
2.2.1 CA liability
2.2.2 RA liability
2.2.1 カリフォルニア責任2.2.2RA責任
2.3 Financial responsibility
2.3 金融責任
2.3.1 Indemnification by relying parties
2.3.2 Fiduciary relationships
2.3.3 Administrative processes
2.3.1 2.3.2Fiduciary関係2.3.3Administrativeが処理する当てにしているパーティーによる保障
2.4 Interpretation and Enforcement
2.4 解釈と実施
2.4.1 Governing law
2.4.2 Severability, survival, merger, notice
2.4.3 Dispute resolution procedures
2.4.1 準拠法2.4.2Severability、生存、合併、通知2.4.3のDispute解決手順
2.5 Fees
2.5 料金
2.5.1 Certificate issuance or renewal fees
2.5.2 Certificate access fees
2.5.1 証明書発行か更新料2.5.2のCertificateアクセスチャージ
Chokhani & Ford Informational [Page 33] RFC 2527 PKIX March 1999
1999年の[33ページ]RFC2527PKIX行進の情報のChokhaniとフォード
2.5.3 Revocation or status information access fees
2.5.4 Fees for other services such as policy information
2.5.5 Refund policy
2.5.3 方針情報2.5.5Refund方針などの他のサービスのための2.5取消しか状態情報アクセスチャージ.4Fees
2.6 Publication and Repository
2.6 公表と倉庫
2.6.1 Publication of CA information
2.6.2 Frequency of publication
2.6.3 Access controls
2.6.4 Repositories
2.6.1 公表2.6.3のAccessコントロール2.6.4Repositoriesのカリフォルニア情報2.6.2Frequencyの公表
2.7 Compliance audit
2.7 承諾監査
2.7.1 Frequency of entity compliance audit
2.7.2 Identity/qualifications of auditor
2.7.3 Auditor's relationship to audited party
2.7.4 Topics covered by audit
2.7.5 Actions taken as a result of deficiency
2.7.6 Communication of results
2.7.1 監査役の実体承諾監査2.7.2のIdentity/資格の頻度、2.7、.3監査役の関係、欠乏の結果、取られた監査2.7.5Actionsでカバーされた監査のパーティー2.7.4Topics、2.7、.6Communication、結果
2.8 Confidentiality
2.8 秘密性
2.8.1 Types of information to be kept confidential
2.8.2 Types of information not considered confidential
2.8.3 Disclosure of certificate revocation/suspension information
2.8.4 Release to law enforcement officials
2.8.5 Release as part of civil discovery
2.8.6 Disclosure upon owner's request
2.8.7 Other information release circumstances
2.8.1 情報の.2Typesが証明書取消し/サスペンション情報の.3Disclosureであると秘密の2.8に考えなかった秘密の2.8であることが保たれるべき情報のタイプ、2.8、.4Release、取締官、2.8、.5Release、民間発見の一部、2.8、.6Disclosure、所有者の要求2.8.7のOther情報リリース事情
2.9 Intellectual Property Rights
2.9 知的所有権
3. IDENTIFICATION AND AUTHENTICATION (34)
3. 識別と認証(34)
3.1 Initial Registration
3.1.1 Types of names
3.1.2 Need for names to be meaningful
3.1.3 Rules for interpreting various name forms
3.1.4 Uniqueness of names
3.1.5 Name claim dispute resolution procedure
3.1.6 Recognition, authentication and role of trademarks
3.1.7 Method to prove possession of private key
3.1.8 Authentication of organization identity
3.1.9 Authentication of individual identity
3.1がRegistrationに頭文字をつける、名前の3.1.1Types、3.1、.2、名前が解釈するのに、様々な3.1重要な.3Rulesが.5Nameが解決手順について議論すると主張する名前3.1の3.1.4Uniquenessとフォームを命名するということであることが必要である、3.1、.6Recognition、商標の認証と役割、3.1、.7Method、秘密鍵の所有物を立証する、3.1、.8Authentication、組織のアイデンティティ、3.1、.9Authentication、個々のアイデンティティ
3.2 Routine Rekey
3.2 通常のRekey
3.3 Rekey after Revocation
3.3 取消しの後のRekey
Chokhani & Ford Informational [Page 34] RFC 2527 PKIX March 1999
1999年の[34ページ]RFC2527PKIX行進の情報のChokhaniとフォード
3.4 Revocation Request
3.4 取消し要求
4. OPERATIONAL REQUIREMENTS (34)
4. 操作上の要件(34)
4.1 Certificate Application
4.1 証明書アプリケーション
4.2 Certificate Issuance
4.2 証明書発行
4.3 Certificate Acceptance
4.3 証明書承認
4.4 Certificate Suspension and Revocation
4.4.1 Circumstances for revocation
4.4.2 Who can request revocation
4.4.3 Procedure for revocation request
4.4.4 Revocation request grace period
4.4.5 Circumstances for suspension
4.4.6 Who can request suspension
4.4.7 Procedure for suspension request
4.4.8 Limits on suspension period
4.4.9 CRL issuance frequency (if applicable)
4.4.10 CRL checking requirements
4.4.11 On-line revocation/status checking availability
4.4.12 On-line revocation checking requirements
4.4.13 Other forms of revocation advertisements available
4.4.14 Checking requirements for other forms of revocation
advertisements
4.4.15 Special requirements re key compromise
取消し4.4.2Whoのための4.4 4.4証明書SuspensionとRevocation.1Circumstancesが取消しを要求できる、4.4、.3Procedure、取消し要求4.4.4Revocationが、サスペンション4.4.6Whoのための据置期間4.4の.5Circumstancesがサスペンションを要求できるよう要求する、4.4、.7Procedure、サスペンションに関して、休職期間4.4に4.4.8Limitsを要求してください; 9 他のフォームのreの取消し広告4.4.15の特別な要件キー感染のための要件をチェックする他の要件4.4.13のフォームの取消し広告利用可能な4.4.14をチェックする有用性4.4.12のオンライン取消しをチェックするCRLの(適切であるなら)4.4の.10の発行頻度CRL照合要件4.4.11のオンライン取消し/状態
4.5 Security Audit Procedures
4.5.1 Types of event recorded
4.5.2 Frequency of processing log
4.5.3 Retention period for audit log
4.5.4 Protection of audit log
4.5.5 Audit log backup procedures
4.5.6 Audit collection system (internal vs external)
4.5.7 Notification to event-causing subject
4.5.8 Vulnerability assessments
4.5セキュリティAudit Procedures、イベントの4.5.1Typesが4.5に監査のための4.5.3Retentionの期間が登録する処理ログの.2Frequencyを記録した、4.5、.4Protection、監査ログ4.5.5Auditでは、バックアップ手順4.5.6Audit収集システム(外部に対して内部の)4.5に.7Notificationを4.5のイベントを引き起こす対象の.8Vulnerability査定まで登録してください。
4.6 Records Archival
4.6は記録保管所で記録します。
4.6.1 Types of event recorded
4.6.2 Retention period for archive
4.6.3 Protection of archive
4.6.4 Archive backup procedures
4.6.5 Requirements for time-stamping of records
4.6.6 Archive collection system (internal or external)
4.6.7 Procedures to obtain and verify archive information
4.6.1 イベントのタイプがアーカイブのために4.6.2Retentionの期間を記録した、4.6、.3Protection、アーカイブ4.6.4のアーカイブバックアップ手順では、得て、確かめる記録4.6.6アーカイブ収集システム(内部か外部)の4.6.7Proceduresの時間の刻印のための4.6.5Requirementsが情報を格納します。
Chokhani & Ford Informational [Page 35] RFC 2527 PKIX March 1999
1999年の[35ページ]RFC2527PKIX行進の情報のChokhaniとフォード
4.7 Key changeover
4.7 主要な転換
4.8 Compromise and Disaster Recovery
4.8.1 Computing resources, software, and/or data are corrupted
4.8.2 Entity public key is revoked
4.8.3 Entity key is compromised
4.8.4 Secure facility after a natural or other type of disaster
4.8の感染とDisaster Recovery、4.8の.1Computingリソース、ソフトウェア、そして/または、データは崩壊した4.8.2Entity公開鍵が取り消された4.8.3Entityキーが自然であるか他のタイプの災害の後に4.8.4Secure施設であると感染されるということであるということです。
4.9 CA Termination
4.9 カリフォルニアの終了
5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34)
5. 物理的であって、手続き上であり、そして、人的安全保護は制御されます。(34)
5.1 Physical Controls
5.1.1 Site location and construction
5.1.2 Physical access
5.1.3 Power and air conditioning
5.1.4 Water exposures
5.1.5 Fire prevention and protection
5.1.6 Media storage
5.1.7 Waste disposal
5.1.8 Off-site backup
5.1 物理的なControls5.1.1Site位置と工事5.1.2Physicalアクセス5.1.3Powerと5.1の.4Water枚撮り5.1.5のFire防止と保護5.1.6の空調メディアストレージ5.1.7Waste処分5.1.8Off-サイトバックアップ
5.2 Procedural Controls
5.2.1 Trusted roles
5.2.2 Number of persons required per task
5.2.3 Identification and authentication for each role
5.2手続き上のControls5.2.1のTrustedの役割、5.2、.2Number、各役割のためのタスク5.2.3Identification単位で必要である人々と認証
5.3 Personnel Controls
5.3.1 Background, qualifications, experience, and clearance
requirements
5.3.2 Background check procedures
5.3.3 Training requirements
5.3.4 Retraining frequency and requirements
5.3.5 Job rotation frequency and sequence
5.3.6 Sanctions for unauthorized actions
5.3.7 Contracting personnel requirements
5.3.8 Documentation supplied to personnel
5.3人員Controls、5.3、.1Background、資格、経験、およびクリアランス要件5.3.2Backgroundは権限のない動作5.3.7のContracting人材の条件5.3.8Documentationのための5.3.6Sanctionsが人員に提供した手順5.3.3のTraining要件5.3.4のRetraining頻度と要件5.3.5のJob回転頻度と系列をチェックします。
6. TECHNICAL SECURITY CONTROLS (34)
6. 技術的なセキュリティコントロール(34)
6.1 Key Pair Generation and Installation
6.1.1 Key pair generation
6.1.2 Private key delivery to entity
6.1.3 Public key delivery to certificate issuer
6.1.4 CA public key delivery to users
6.1.5 Key sizes
6.1.6 Public key parameters generation
6.1.7 Parameter quality checking
6.1 主要なPair GenerationとInstallation6.1.1Keyは、チェックしながら.6のPublicの主要なパラメタ世代6.1.7Parameter上質でユーザ6.1.5Keyへの6.1.4カリフォルニアの公開鍵配送が6.1に大きさで分ける発行人を証明するために世代6.1.2の兵士の主要な配送を実体6.1.3のPublicの主要な配送と対にします。
Chokhani & Ford Informational [Page 36] RFC 2527 PKIX March 1999
1999年の[36ページ]RFC2527PKIX行進の情報のChokhaniとフォード
6.1.8 Hardware/software key generation
6.1.9 Key usage purposes (as per X.509 v3 key usage field)
6.1.8 ハードウェア/ソフトウェアキー生成6.1.9のKey用法目的(X.509 v3の主要な用法分野に従って)
6.2 Private Key Protection
6.2.1 Standards for cryptographic module
6.2.2 Private key (n out of m) multi-person control
6.2.3 Private key escrow
6.2.4 Private key backup
6.2.5 Private key archival
6.2.6 Private key entry into cryptographic module
6.2.7 Method of activating private key
6.2.8 Method of deactivating private key
6.2.9 Method of destroying private key
6.2の個人的なKey Protection、暗号のモジュール6.2.2の兵士の主要な(mからのn)マルチ人のための6.2.1Standardsが6.2の6.2の.4の兵士の主要な.3兵士のキーエスクローバックアップ6.2.5兵士のキー記録保管所の6.2に.6の兵士の主要なエントリーを暗号のモジュールに制御する、6.2、.7Method、秘密鍵を活性化する、6.2、.8Method、秘密鍵を非活性化する、6.2、.9Method、秘密鍵を破壊すること。
6.3 Other Aspects of Key Pair Management
6.3.1 Public key archival
6.3.2 Usage periods for the public and private keys
6.3 公衆と秘密鍵のためのKey Pair Management6.3.1Public主要な記録保管所の6.3.2回のUsageの期間の他のAspects
6.4 Activation Data
6.4.1 Activation data generation and installation
6.4.2 Activation data protection
6.4.3 Other aspects of activation data
6.4起動Data6.4.1回のActivationデータ生成とインストール6.4.2Activationデータ保護、起動データの6.4の.3Other局面
6.5 Computer Security Controls
6.5.1 Specific computer security technical requirements
6.5.2 Computer security rating
6.5 コンピュータSecurity Controls6.5.1のSpecificコンピュータセキュリティ技術的要求事項6.5.2コンピュータセキュリティ格付け
6.6 Life Cycle Technical Controls
6.6.1 System development controls
6.6.2 Security management controls
6.6.3 Life cycle security ratings
6.6 寿命Cycle Technical Controls6.6.1のSystem開発規則6.6.2のSecurityマネジメント・コントロール6.6.3のLifeサイクル債券評価
6.7 Network Security Controls
6.7 ネットワークセキュリティコントロール
6.8 Cryptographic Module Engineering Controls
6.8 暗号のモジュール工学コントロール
7. CERTIFICATE AND CRL PROFILES
7. 証明書AND CRLプロフィール
7.1 Certificate Profile
7.1 証明書プロフィール
7.1.1 Version number(s)
7.1.2 Certificate extensions
7.1.3 Algorithm object identifiers
7.1.4 Name forms
7.1.5 Name constraints
7.1.6 Certificate policy Object Identifier
7.1.7 Usage of Policy Constraints extension
7.1.8 Policy qualifiers syntax and semantics
7.1.1 バージョンNo.7.1.2のCertificate拡張子7.1.3のAlgorithmオブジェクト識別子7.1.4Nameが7.1に.5のName規制7.1.6Certificate方針Object Identifierを形成する、7.1、.7Usage、Policy Constraints拡張子7.1.8Policy資格を与える人構文と意味論
Chokhani & Ford Informational [Page 37] RFC 2527 PKIX March 1999
1999年の[37ページ]RFC2527PKIX行進の情報のChokhaniとフォード
7.1.9 Processing semantics for the critical certificate policy
extension
7.1.9 重要な証明書方針拡張子のための処理意味論
7.2 CRL Profile
7.2 CRLプロフィール
7.2.1 Version number(s)
7.2.2 CRL and CRL entry extensions
7.2.1 バージョンNo.7.2.2CRLとCRLエントリー拡張子
8. SPECIFICATION ADMINISTRATION
8. 仕様管理
8.1 Specification change procedures
8.1 仕様書変更手順
8.2 Publication and notification policies
8.2 公表と通知方針
8.3 CPS approval procedures
8.3のCPS承認の手順
Chokhani & Ford Informational [Page 38] RFC 2527 PKIX March 1999
1999年の[38ページ]RFC2527PKIX行進の情報のChokhaniとフォード
6. ACKNOWLEDGMENTS
6. 承認
The development of this document was supported by the Government of Canada's Policy Management Authority (PMA) Committee, the National Security Agency, the National Institute of Standards and Technology (NIST), and the American Bar Association Information Security Committee Accreditation Technical Working Group. Special thanks are due to Dave Fillingham, Jim Brandt, and Edmond Van Hees for their inspiration, support, and valuable inputs.
このドキュメントの開発はカナダのPolicy Management Authority(PMA)委員会の政府、国家安全保障局、米国商務省標準技術局(NIST)、およびアメリカ法曹協会情報Security Committee Accreditation Technical作業部会によってサポートされました。 特別な感謝は彼らのインスピレーション、サポート、および貴重な入力のためのデーヴFillingham、ジム・ブラント、およびエドモンドヴァンHeesのためです。
The following individuals also deserve credit for their review and input:
また、以下の個人は彼らのレビューと入力のためのクレジットに値します:
Teresa Acevedo, A&N Associates;
Michael Baum; VeriSign;
Sharon Boeyen, Entrust;
Bob Burger, McCarter & English;
Bill Burr, NIST;
Patrick Cain, BBN;
Michael Harrop, Government of Canada Treasury Board;
Rick Hornbeck, Digital Commerce Services;
Francois Marinier, Domus Software;
John Morris, CygnaCom Solutions;
Tim Moses, Entrust;
Noel Nazario, NIST;
John Nicolletos, A&N Associates;
Jean Petty, CygnaCom Solutions;
Denis Pinkas, Bull;
J.-F. Sauriol, Domus Software;
Robert Shirey, BBN;
Mark Silvern, VeriSign;
David Simonetti, Booz, Allen and Hamilton; and
Darryl Stal, Entrust.
テレサアセベド、A、およびNは交際します。 マイケルバウム。 ベリサイン。 シャロンBoeyen、ゆだねます。 ボブバーガー、McCarter、および英語。 ビルBurr、NIST。 パトリック・カイン、BBN。 マイケル・ハロップ、カナダ政府国庫ボード。 リックHornbeck、デジタル商業サービス。 フランソアMarinier、Domusソフトウェア。 ジョンモリス、CygnaComソリューション。 ティムMoses、ゆだねます。 クリスマスNazario、NIST。 ジョンNicolletos、A、およびNは交際します。 ジーンPettyのCygnaComソリューション。 デニス・ピンカス、雄牛。 J.-F。 Sauriol、Domusソフトウェア。 ロバートShirey、BBN。 マークSilvernである、ベリサイン。 デヴィッド・シモネッティ、Booz、アレン、およびハミルトン。 そして、ダリルStal、ゆだねます。
Johnny Hsiung, and Chris Miller assisted in the preparation of the manuscript.
ジョニー・シュン、および原稿の準備が助けられたクリス・ミラー。
Chokhani & Ford Informational [Page 39] RFC 2527 PKIX March 1999
1999年の[39ページ]RFC2527PKIX行進の情報のChokhaniとフォード
7. REFERENCES
7. 参照
[ABA1] American Bar Association, Digital Signature Guidelines: Legal
Infrastructure for Certification Authorities and Electronic
Commerce, 1995.
[ABA1]アメリカ法曹協会、デジタル署名ガイドライン: 証明当局と電子通商のための法的基盤、1995。
[BAU1] Michael. S. Baum, Federal Certification Authority Liability
and Policy, NIST-GCR- 94-654, June 1994.
[BAU1]マイケル。 S。 バウムと連邦政府の認証局責任と方針、NIST-GCR94-654、1994年6月。
[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
Technology - Open Systems Interconnection: The Directory:
Authentication Framework," 1997 edition. (Pending publication
of 1997 edition, use 1993 edition with the following amendment
applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8
on Certificate Extensions, June 1996.)
[ISO1]ISO/IEC ITU9594-8/T推薦X.509、「情報技術--オープン・システム・インターコネクション:、」 ディレクトリ: 「認証Framework」、1997年の版。 (1997年の版の公表まで、適用される以下の修正と共に1993年の版を使用してください: Certificate Extensions(1996年6月)の上のDraft Amendment DAM1からISO/IEC9594-8の最終的なText)
[PEM1] Kent, S., "Privacy Enhancement for Internet Electronic Mail,
Part II: Certificate-Based Key Management", RFC 1422, February
1993.
[PEM1]ケント、S.、「インターネット電子メール、パートIIのためのプライバシー増進:、」 「証明書ベースのKey Management」、RFC1422、1993年2月。
[PKI1] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure, Certificate and CRL Profile", RFC
2459, January 1999.
[PKI1] HousleyとR.とフォードとW.とポークとW.と一人で生活して、「インターネットX.509公開鍵基盤、証明書、およびCRLは輪郭を描く」D.、RFC2459、1999年1月。
8. AUTHORS' ADDRESSES
8. 作者のアドレス
Santosh Chokhani CygnaCom Solutions, Inc. Suite 100 West 7927 Jones Branch Drive McLean, VA 22102
Santosh Chokhani CygnaComソリューションInc.スイート100の西7927ジョーンズ・支店のDriveマクリーン、ヴァージニア 22102
Phone: (703) 848-0883 Fax: (703) 848-0960 EMail: chokhani@cygnacom.com
以下に電話をしてください。 (703) 848-0883 Fax: (703) 848-0960 メールしてください: chokhani@cygnacom.com
Warwick Ford VeriSign, Inc. 301 Edgewater Place, Suite 210 Wakefield, MA 01880
ウォリックフォードベリサインInc.301Edgewater場所、ウェークフィールド、Suite210MA 01880
Phone: (781) 245-6996 x225 Fax: (781) 245-6006 EMail: wford@verisign.com
以下に電話をしてください。 (781) 245-6996 x225Fax: (781) 245-6006 メールしてください: wford@verisign.com
Chokhani & Ford Informational [Page 40] RFC 2527 PKIX March 1999
1999年の[40ページ]RFC2527PKIX行進の情報のChokhaniとフォード
NOTES
注意
1 The ABA Digital Signature Guidelines can be purchased from the ABA.
See http://www.abanet.com for ordering details.
1 ABAからABA Digital Signature Guidelinesを購入できます。 詳細を注文するために http://www.abanet.com を見てください。
2 Examples of types of entity for subject CAs are a subordinate
organization (e.g., branch or division), a federal government
agency, or a state or provincial government department.
対象のCAsのための実体のタイプに関する2つの例が、下位の組織(例えば、ブランチか分割)、連邦政府代理店、州または地方の政府の各省です。
3 This statement can have significant implications. For example,
suppose a bank claims that it issues CA certificates to its
branches only. Now, the user of a CA certificate issued by the
bank can assume that the subject CA in the certificate is a branch
of the bank
3 この声明は重要な意味を持つことができます。 例えば、銀行が、カリフォルニア証明書をブランチだけに発行すると主張すると仮定してください。 今、銀行によって発行されたカリフォルニア証明書のユーザは、証明書の対象のカリフォルニアが銀行の支店であると仮定できます。
4 Examples of the types of subject RA entities are branch and
division of an organization.
対象のRA実体のタイプに関する4つの例が、組織のブランチと師団です。
5 Examples of types of subject end entities are bank customers,
telephone company subscribers, and employees of a government
department
対象の終わりの実体のタイプに関する5つの例が、政府の各省の銀行の顧客と、電話会社の加入者と、従業員です。
6 This statement can have significant implications. For example,
suppose Government CA claims that it issues certificates to
Government employees only. Now, the user of a certificate issued
by the Government CA can assume that the subject of the certificate
is a Government employee.
6 この声明は重要な意味を持つことができます。 例えば、政府の従業員だけに証明書を発行するという政府カリフォルニアのクレームを仮定してください。 今、政府カリフォルニアによって発行された証明書のユーザは、証明書の対象が政府の従業員であると仮定できます。
7 Examples include X.500 distinguished name, Internet e-mail address,
and URL.
7つの例がX.500分類名、インターネット電子メールアドレス、およびURLを含んでいます。
8 The term "meaningful" means that the name form has commonly
understood semantics to determine identity of the person and/or
organization. Directory names and RFC 822 names may be more or
less meaningful.
8 「重要である」という用語は、名前フォームが、意味論が人、そして/または、組織のアイデンティティを決定するのを一般的に理解していたことを意味します。 ディレクトリ名とRFC822名は多少重要であるかもしれません。
9 Examples of proof include the issuing CA generating the key, or
requiring the subject to send an electronically signed request or
to sign a challenge.
証拠に関する9つの例が電子的に署名している要求を送るか、または挑戦に署名するためにキーを生成するか、または対象を必要とする発行カリフォルニアを含んでいます。
10 Examples of organization identity authentication are: articles of
incorporation, duly signed corporate resolutions, company seal,
and notarized documents.
組織アイデンティティ認証に関する10の例は以下の通りです。 定款、正しく署名している取締役会決議、社印、および公証されたドキュメント。
11 Examples of individual identity authentication are: biometrics
(thumb print, ten finger print, face, palm, and retina scan),
driver's license, passport, credit card, company badge, and
government badge.
個々のアイデンティティ認証に関する11の例は以下の通りです。 生体認証(10の親指印刷、指の印刷、顔、掌、および網膜はスキャンする)、運転免許証、パスポート、クレジットカード、社員バッジ、および政府バッジ。
Chokhani & Ford Informational [Page 41] RFC 2527 PKIX March 1999
1999年の[41ページ]RFC2527PKIX行進の情報のChokhaniとフォード
12 Examples include duly signed authorization papers or corporate ID
badge.
12の例が正しく署名している承認書類か法人のIDバッジを含んでいます。
13 The identification policy for routine rekey should be the same as
the one for initial registration since the same subject needs
rekeying. The rekey authentication may be accomplished using the
techniques for initial I&A or using digitally signed requests.
13 同じ対象が、「再-合わせ」る必要があるので、通常のrekeyのための識別方針は新規登録のためのものと同じであるべきです。 rekey認証は初期の私とAかデジタルに使用するためのテクニックが要求に署名した優れた使用であるかもしれません。
14 This identification and authentication policy could be the same as
that for initial registration.
14 この識別と認証方針は新規登録のためのそれと同じであるかもしれません。
15 This policy could be the same as the one for initial registration.
15 この方針は新規登録のためのものと同じであるかもしれません。
16 The identification policy for Revocation request could be the same
as that for initial registration since the same subject
certificate needs to be revoked. The authentication policy could
accept a Revocation request digitally signed by subject. The
authentication information used during initial registration could
be acceptable for Revocation request. Other less stringent
authentication policy could be defined.
16 同じ対象の証明書が、取り消される必要があるので、Revocation要求のための識別方針は新規登録のためのそれと同じであるかもしれません。 認証方針は、Revocation要求に対象によってデジタルに署名されると受け入れるかもしれません。 Revocation要求において、新規登録の間に使用される認証情報は許容できるかもしれません。 他のそれほど厳しくない認証方針を定義できました。
17 The identification policy for key compromise notification could be
the same as the one for initial registration since the same
subject certificate needs to be revoked. The authentication
policy could accept a Revocation request digitally signed by
subject. The authentication information used during initial
registration could be acceptable for key compromise notification.
Other less stringent authentication policy could be defined.
17 同じ対象の証明書が、取り消される必要があるので、主要な感染通知のための識別方針は新規登録のためのものと同じであるかもしれません。 認証方針は、Revocation要求に対象によってデジタルに署名されると受け入れるかもしれません。 主要な感染通知において、新規登録の間に使用される認証情報は許容できるかもしれません。 他のそれほど厳しくない認証方針を定義できました。
18 The n out of m rule allows a key to be split in m parts. The m
parts may be given to m different individuals. Any n parts out of
the m parts may be used to fully reconstitute the key, but having
any n- 1 parts provides one with no information about the key.
18 規則がmで部品を分けることであることをキーを許容するmからのn。 mの異なった個人にmの部品を与えるかもしれません。 mの部品からのどんなn部品もキーを完全に再編成するのに使用されるかもしれませんが、どんなn1の部品も持っている場合、キーの情報は全く1つに提供されません。
19 A key may be escrowed, backed up or archived. Each of these
functions have different purpose. Thus, a key may go through any
subset of these functions depending on the requirements. The
purpose of escrow is to allow a third party (such as an
organization or government) to legally obtain the key without the
cooperation of the subject. The purpose of back up is to allow
the subject to reconstitute the key in case of the destruction of
the key. The purpose of archive is to provide for reuse of the
key in future, e.g., use the private key to decrypt a document.
19 キーは、escrowedされるか、支援されるか、または格納されるかもしれません。 それぞれのこれらの機能には、異なる役割があります。 したがって、要件によって、キーはこれらの機能のどんな部分集合を通っても動くかもしれません。 エスクローの目的は第三者(組織か政府などの)が対象の協力なしでキーを法的に入手するのを許容することです。 逆上の目的は対象がキーの破壊の場合にキーを再編成するのを許容することです。 アーカイブの目的は未来、例えば、使用における、キーの再利用にドキュメントを解読する秘密鍵を提供することです。
20 An example of activation data is a PIN or passphrase.
20 起動データに関する例は、暗証番号かパスフレーズです。
21 Examples of physical access controls are: monitored facility ,
guarded facility, locked facility, access controlled using tokens,
物理的なアクセス制御に関する21の例は以下の通りです。 モニターされた施設(用心深い施設)は施設をロックして、アクセスは、トークンを使用することで制御されました。
Chokhani & Ford Informational [Page 42] RFC 2527 PKIX March 1999
1999年の[42ページ]RFC2527PKIX行進の情報のChokhaniとフォード
access controlled using biometrics, and access controlled through
an access list.
アクセスは生体認証を使用することで制御されました、そして、アクセスはアクセスリストを通して制御されました。
22 Examples of the roles include system administrator, system
security officer, and system auditor. The duties of the system
administrator are to configure, generate, boot, and operate the
system. The duties of the system security officer are to assign
accounts and privileges. The duties of the system auditor are to
set up system audit profile, perform audit file management, and
audit review.
役割に関する22の例がシステム管理者、システムセキュリティ担当責任者、およびシステム監査役を含んでいます。 システム管理者の義務は、システムを構成して、生成して、ブートして、操作することです。 システムセキュリティ担当責任者の義務はアカウントと特権を割り当てることです。 システム監査役の義務は、システム監査プロフィールをセットアップして、監査ファイル管理を実行して、レビューを監査することです。
23 The background checks may include clearance level (e.g., none,
sensitive, confidential, secret, top secret, etc.) and the
clearance granting authority name. In lieu of or in addition to a
defined clearance, the background checks may include types of
background information (e.g., name, place of birth, date of birth,
home address, previous residences, previous employment, and any
other information that may help determine trustworthiness). The
description should also include which information was verified and
how.
23 素性調査はクリアランスレベル(例えば、なにも、敏感で、秘密の、そして、秘密の最高機密など)と権威名を与えるクリアランスを含むかもしれません。 クリアランスか定義されたクリアランスに加えて、素性調査は基礎的な情報のタイプを含むかもしれません(例えば、名前、出生の場所、生年月日、ホームアドレス、前の住居、前の雇用、および助けるかもしれないいかなる他の情報も信頼できることを決定します)。 また、記述はどの情報が確かめられたか、そして、どのようにを含むべきであるか。
24 For example, the certificate policy may impose personnel security
requirements on the network system administrator responsible for a
CA's network access.
24 例えば、証明書方針はCAのネットワークアクセサリーに責任があるネットワークシステム管理者に人的安全保護要件を課すかもしれません。
25 Regardless of whether authorized persons are employees, practices
should be implemented to ensure that each authorized person is
held accountable for his/her actions.
25 権限保持者が従業員であるかどうかにかかわらず、習慣は、各権限保持者がその人の動作について責任があるように保たれるのを保証するために実装されるべきです。
26 A cryptographic module is hardware, software, or firmware or any
combination of them.
26 暗号のモジュールは、それらのハードウェア、ソフトウェア、ファームウェアまたはあらゆる組み合わせです。
27 The compliance description should be specific and detailed. For
example, for each FIPS 140-1 requirement, describe the level and
whether the level has been certified by an accredited laboratory.
27 承諾記述は、明確であって、詳細であるべきです。 例えば、それぞれのFIPS140-1要件には、レベルとレベルが公認の実験室によって公認されたかどうか説明してください。
28 Example of audit events are: request to create a certificate,
request to revoke a certificate, key compromise notification,
creation of a certificate, revocation of a certificate, issuance
of a certificate, issuance of a CRL, issuance of key compromise
CRL, establishment of trusted roles on the CA, actions of truste
personnel, changes to CA keys, etc.
監査イベントに関する28の例は以下の通りです。 証明書を作成するという要求、証明書を取り消すという要求、主要な感染通知、証明書の作成、証明書の取消し、証明書の発行、CRLの発行、主要な感染CRLの発行、カリフォルニアにおける信じられた役割の設立、truste人員の動作、カリフォルニアキーへの変化など
29 Example of archive events are: request to create a certificate,
request to revoke a certificate, key compromise notification,
creation of a certificate, revocation of a certificate, issuance
of a certificate, issuance of a CRL, issuance of key compromise
CRL, and changes to CA keys.
アーカイブイベントに関する29の例は以下の通りです。 証明書を作成するよう要求して、証明書、主要な感染通知、証明書の作成、証明書の取消し、証明書の発行、CRLの発行、主要な感染CRLの発行、およびカリフォルニアキーへの変化を取り消すよう要求します。
Chokhani & Ford Informational [Page 43] RFC 2527 PKIX March 1999
1999年の[43ページ]RFC2527PKIX行進の情報のChokhaniとフォード
30 A parent CA is an example of audit relationship.
30 親カリフォルニアは監査関係に関する例です。
31 Example of compliance audit topics: sample check on the various
I&A policies, comprehensive checks on key management policies,
comprehensive checks on system security controls, comprehensive
checks on operations policy, and comprehensive checks on
certificate profiles.
承諾監査話題に関する31の例: 様々なI&A方針のチェックを抽出してください、かぎ管理方針の包括的なチェック、システムセキュリティコントロールの包括的なチェック、証明書プロフィールの操作方針的、そして、包括的なチェックの包括的なチェック。
32 The examples include, temporary suspension of operations until
deficiencies are corrected, revocation of entity certificate,
change in personnel, invocation of liability policy, more frequent
compliance audit, etc.
例が含む32、欠乏が直るまでの操作の一時的なサスペンション、実体証明書の取消し、人事異動、責任方針の実施、以上は承諾監査などによく行きます。
33 An organization may choose not to make public some of its security
controls, clearance procedures, or some others elements due to
their sensitivity.
33 組織は、それらの感度のためセキュリティコントロール、クリアランス手順、またはいくつかの他のもの要素をいくつか公表しないのを選ぶかもしれません。
34 All or some of the following items may be different for the
various types of entities, i.e., CA, RA, and end entities.
34 すなわち、様々なタイプの実体、カリフォルニア、RA、および終わりの実体において、すべてか以下の数個の項目が、異なっているかもしれません。
LIST OF ACRONYMS
頭文字語のリスト
ABA - American Bar Association CA - Certification Authority CPS - Certification Practice Statement CRL - Certificate Revocation List DAM - Draft Amendment FIPS - Federal Information Processing Standard I&A - Identification and Authentication IEC - International Electrotechnical Commission IETF - Internet Engineering Task Force IP - Internet Protocol ISO - International Organization for Standardization ITU - International Telecommunications Union NIST - National Institute of Standards and Technology OID - Object Identifier PIN - Personal Identification Number PKI - Public Key Infrastructure PKIX - Public Key Infrastructure (X.509) (IETF Working Group) RA - Registration Authority RFC - Request For Comment URL - Uniform Resource Locator US - United States
アバ--アメリカ法曹協会カリフォルニア--認証局CPS--認証実施規定CRL--証明書失効リストダム--修正案FIPS--連邦情報処理基準私と--識別と認証IEC--国際電気標準化会議IETF--インターネット・エンジニアリング・タスク・フォースIP--インターネットプロトコルISO--国際機関; ITU--国際電気通信組合NIST--米国商務省標準技術局OID--オブジェクト識別子暗証番号--個人識別番号PKI--公開鍵暗号基盤PKIX--公開鍵暗号基盤(X.509)(IETF作業部会)RA(登録局RFC)がコメントURL--Uniform Resource Locator米国--合衆国に要求する標準化のために
Chokhani & Ford Informational [Page 44] RFC 2527 PKIX March 1999
1999年の[44ページ]RFC2527PKIX行進の情報のChokhaniとフォード
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Chokhani & Ford Informational [Page 45]
ChokhaniとフォードInformationalです。[45ページ]
一覧
スポンサーリンク
