RFC3125 日本語訳
3125 Electronic Signature Policies. J. Ross, D. Pinkas, N. Pope. September 2001. (Format: TXT=95505 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Ross
Request for Comments: 3125 Security & Standards
Category: Experimental D. Pinkas
Integris
N. Pope
Security & Standards
September 2001
Network Working Group J. Ross Request for Comments: 3125 Security & Standards Category: Experimental D. Pinkas Integris N. Pope Security & Standards September 2001
Electronic Signature Policies
Electronic Signature Policies
Status of this Memo
Status of this Memo
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Abstract
This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements.
This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements.
A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation.
A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation.
The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied.
The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied.
To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1.
To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1.
The contents of this document is based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org.
The contents of this document is based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org.
Ross, et al. Experimental [Page 1] RFC 3125 Electronic Signature Policies September 2001
Ross, et al. Experimental [Page 1] RFC 3125 Electronic Signature Policies September 2001
Table of Contents
Table of Contents
1. Introduction 3 2. Major Parties 3 3. Signature Policy Specification 5 3.1 Overall ASN.1 Structure 5 3.2 Signature Validation Policy 6 3.3 Common Rules 7 3.4 Commitment Rules 8 3.5 Signer and Verifier Rules 9 3.5.1 Signer Rules 9 3.5.2 Verifier Rules 11 3.6 Certificate and Revocation Requirements 11 3.6.1 Certificate Requirements 11 3.6.2 Revocation Requirements 13 3.7 Signing Certificate Trust Conditions 14 3.8 Time-Stamp Trust Conditions 15 3.9 Attribute Trust Conditions 16 3.10 Algorithm Constraints 17 3.11 Signature Policy Extensions 18 4. Security Considerations 18 4.1 Protection of Private Key 18 4.2 Choice of Algorithms 18 5. Conformance Requirements 19 6. References 19 7. Authors' Addresses 20 Annex A (normative): 21 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 21 A.2 Definitions Using X.680 (1997) ASN.1 Syntax 27 Annex B (informative): 34 B.1 Signature Policy and Signature Validation Policy 34 B.2 Identification of Signature Policy 36 B.3 General Signature Policy Information 36 B.4 Recognized Commitment Types 37 B.5 Rules for Use of Certification Authorities 37 B.5.1 Trust Points 38 B.5.2 Certification Path 38 B.6 Revocation Rules 39 B.7 Rules for the Use of Roles 39 B.7.1 Attribute Values 39 B.7.2 Trust Points for Certified Attributes 40 B.7.3 Certification Path for Certified Attributes 40 B.8 Rules for the Use of Time-Stamping and Timing 40 B.8.1 Trust Points and Certificate Paths 41 B.8.2 Time-Stamping Authority Names 41 B.8.3 Timing Constraints - Caution Period 41 B.8.4 Timing Constraints - Time-Stamp Delay 41 B.9 Rules for Verification Data to be followed 41
1. Introduction 3 2. Major Parties 3 3. Signature Policy Specification 5 3.1 Overall ASN.1 Structure 5 3.2 Signature Validation Policy 6 3.3 Common Rules 7 3.4 Commitment Rules 8 3.5 Signer and Verifier Rules 9 3.5.1 Signer Rules 9 3.5.2 Verifier Rules 11 3.6 Certificate and Revocation Requirements 11 3.6.1 Certificate Requirements 11 3.6.2 Revocation Requirements 13 3.7 Signing Certificate Trust Conditions 14 3.8 Time-Stamp Trust Conditions 15 3.9 Attribute Trust Conditions 16 3.10 Algorithm Constraints 17 3.11 Signature Policy Extensions 18 4. Security Considerations 18 4.1 Protection of Private Key 18 4.2 Choice of Algorithms 18 5. Conformance Requirements 19 6. References 19 7. Authors' Addresses 20 Annex A (normative): 21 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 21 A.2 Definitions Using X.680 (1997) ASN.1 Syntax 27 Annex B (informative): 34 B.1 Signature Policy and Signature Validation Policy 34 B.2 Identification of Signature Policy 36 B.3 General Signature Policy Information 36 B.4 Recognized Commitment Types 37 B.5 Rules for Use of Certification Authorities 37 B.5.1 Trust Points 38 B.5.2 Certification Path 38 B.6 Revocation Rules 39 B.7 Rules for the Use of Roles 39 B.7.1 Attribute Values 39 B.7.2 Trust Points for Certified Attributes 40 B.7.3 Certification Path for Certified Attributes 40 B.8 Rules for the Use of Time-Stamping and Timing 40 B.8.1 Trust Points and Certificate Paths 41 B.8.2 Time-Stamping Authority Names 41 B.8.3 Timing Constraints - Caution Period 41 B.8.4 Timing Constraints - Time-Stamp Delay 41 B.9 Rules for Verification Data to be followed 41
Ross, et al. Experimental [Page 2] RFC 3125 Electronic Signature Policies September 2001
Ross, et al. Experimental [Page 2] RFC 3125 Electronic Signature Policies September 2001
B.10 Rules for Algorithm Constraints and Key Lengths 42 B.11 Other Signature Policy Rules 42 B.12 Signature Policy Protection 42 Full Copyright Statement 44
B.10 Rules for Algorithm Constraints and Key Lengths 42 B.11 Other Signature Policy Rules 42 B.12 Signature Policy Protection 42 Full Copyright Statement 44
1. Introduction
1. Introduction
This document is intended to cover signature policies which can be used with electronic signatures for various types of transactions, including business transactions (e.g., purchase requisition, contract, and invoice applications). Electronic signatures can be used for any transaction between an individual and a company, between two companies, between an individual and a governmental body, etc. This document is independent of any environment. It can be applied to any environment e.g., smart cards, GSM SIM cards, special programs for electronic signatures etc.
This document is intended to cover signature policies which can be used with electronic signatures for various types of transactions, including business transactions (e.g., purchase requisition, contract, and invoice applications). Electronic signatures can be used for any transaction between an individual and a company, between two companies, between an individual and a governmental body, etc. This document is independent of any environment. It can be applied to any environment e.g., smart cards, GSM SIM cards, special programs for electronic signatures etc.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
2. Major Parties
2. Major Parties
The document uses the following terms:
The document uses the following terms:
* the Signature Policy Issuer;
* the Signer;
* the Verifier;
* the Arbitrator;
* Trusted Service Providers (TSP);
* the Signature Policy Issuer; * the Signer; * the Verifier; * the Arbitrator; * Trusted Service Providers (TSP);
The Signature Policy Issuer (which is a Trusted Service Provider (TSP)) issues signatures policies that define the technical and procedural requirements for electronic signature creation, and validation/ verification, in order to meet a particular business need.
The Signature Policy Issuer (which is a Trusted Service Provider (TSP)) issues signatures policies that define the technical and procedural requirements for electronic signature creation, and validation/ verification, in order to meet a particular business need.
The Signer is the entity that creates the electronic signature. When the signer digitally signs over an signature policy identifier, it represents a commitment on behalf of the signing entity that the data being signed is signed under the rules defined by the signature policy.
The Signer is the entity that creates the electronic signature. When the signer digitally signs over an signature policy identifier, it represents a commitment on behalf of the signing entity that the data being signed is signed under the rules defined by the signature policy.
The Verifier is the entity that validates the electronic signature, it may be a single entity or multiple entities. The verifier MUST validate the electronic signature under the rules defined by the electronic signature policy for the signature to be valid.
The Verifier is the entity that validates the electronic signature, it may be a single entity or multiple entities. The verifier MUST validate the electronic signature under the rules defined by the electronic signature policy for the signature to be valid.
Ross, et al. Experimental [Page 3] RFC 3125 Electronic Signature Policies September 2001
Ross, et al. Experimental [Page 3] RFC 3125 Electronic Signature Policies September 2001
An arbitrator, is an entity which arbitrates disputes between a signer and a verifier. It acts as verifier when it verifies the electronic signature after it has been previously validated.
An arbitrator, is an entity which arbitrates disputes between a signer and a verifier. It acts as verifier when it verifies the electronic signature after it has been previously validated.
The Trusted Service Providers (TSPs) are one or more entities that help to build trust relationships between the signer and verifier. Use of TSP specific services MAY be mandated by signature policy. TSP supporting services include: user certificates, cross- certificates, time-stamping tokens,CRLs, ARLs, OCSP responses.
The Trusted Service Providers (TSPs) are one or more entities that help to build trust relationships between the signer and verifier. Use of TSP specific services MAY be mandated by signature policy. TSP supporting services include: user certificates, cross- certificates, time-stamping tokens,CRLs, ARLs, OCSP responses.
A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer, as Such, the TSP MUST define the technical and procedural requirements for electronic signature creation and validation, in order to meet a particular business need.
A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer, as Such, the TSP MUST define the technical and procedural requirements for electronic signature creation and validation, in order to meet a particular business need.
The following other TSPs are used to support the functions defined in this document:
The following other TSPs are used to support the functions defined in this document:
* Certification Authorities;
* Registration Authorities;
* Repository Authorities (e.g., a Directory);
* Time-Stamping Authorities;
* One-line Certificate Status Protocol responders;
* Attribute Authorities.
* Certification Authorities; * Registration Authorities; * Repository Authorities (e.g., a Directory); * Time-Stamping Authorities; * One-line Certificate Status Protocol responders; * Attribute Authorities.
Certification Authorities provide users with public key certificates.
Certification Authorities provide users with public key certificates.
Registration Authorities allows the registration of entities before a CA generates certificates.
Registration Authorities allows the registration of entities before a CA generates certificates.
Repository Authorities publish CRLs issued by CAs, , cross- certificates (i.e., CA certificates) issued by CAs, signature policies issued by Signature Policy Issuers and optionally public key certificates (i.e., leaf certificates) issued by CAs.
Repository Authorities publish CRLs issued by CAs, , cross- certificates (i.e., CA certificates) issued by CAs, signature policies issued by Signature Policy Issuers and optionally public key certificates (i.e., leaf certificates) issued by CAs.
Time-Stamping Authorities attest that some data was formed before a given trusted time.
Time-Stamping Authorities attest that some data was formed before a given trusted time.
One-line Certificate Status Protocol responders (OSCP responders) provide information about the status (i.e., revoked, not revoked, unknown) of a particular certificate.
One-line Certificate Status Protocol responders (OSCP responders) provide information about the status (i.e., revoked, not revoked, unknown) of a particular certificate.
Attributes Authorities provide users with attributes linked to public key certificates
Attributes Authorities provide users with attributes linked to public key certificates
An Arbitrator is an entity that arbitrates disputes between a signer and a verifier.
An Arbitrator is an entity that arbitrates disputes between a signer and a verifier.
Ross, et al. Experimental [Page 4] RFC 3125 Electronic Signature Policies September 2001
Ross, et al. Experimental [Page 4] RFC 3125 Electronic Signature Policies September 2001
3. Signature Policy Specification
3. Signature Policy Specification
A signature policy specification includes general information about the policy, the validation policy rules and other signature policy information.
A signature policy specification includes general information about the policy, the validation policy rules and other signature policy information.
This document mandates that:
This document mandates that:
* an electronic signature must be processed by the signer and
verifier in accordance with the signature policy referenced by
the signer;
* the signature policy referenced by the signer must be
identifiable by an Object Identifier;
* there must exist a specification of the signature policy;
* for a given signature policy there must be one definitive form
of the specification which has a unique binary encoding;
* a hash of the definitive specification, using an agreed
algorithm, must be provided by the signer and checked by the
verifier.
* an electronic signature must be processed by the signer and verifier in accordance with the signature policy referenced by the signer; * the signature policy referenced by the signer must be identifiable by an Object Identifier; * there must exist a specification of the signature policy; * for a given signature policy there must be one definitive form of the specification which has a unique binary encoding; * a hash of the definitive specification, using an agreed algorithm, must be provided by the signer and checked by the verifier.
This document defines but does not mandate the form of the signature policy specification. The signature policy may be specified either:
This document defines but does not mandate the form of the signature policy specification. The signature policy may be specified either:
* in a free form document for human interpretation; or
* in a structured form using an agreed syntax and encoding.
* in a free form document for human interpretation; or * in a structured form using an agreed syntax and encoding.
This document defines an ASN.1 based syntax that may be used to define a structured signature policy. Future versions of this document may include structured a signature policy specification using XML.
This document defines an ASN.1 based syntax that may be used to define a structured signature policy. Future versions of this document may include structured a signature policy specification using XML.
3.1 Overall ASN.1 Structure
3.1 Overall ASN.1 Structure
The overall structure of a signature policy defined using ASN.1 is given in this section. Use of this ASN.1 structure is optional.
The overall structure of a signature policy defined using ASN.1 is given in this section. Use of this ASN.1 structure is optional.
This ASN.1 syntax is encoded using the Distinguished Encoding Rules (DER).
This ASN.1 syntax is encoded using the Distinguished Encoding Rules (DER).
In this structure the policy information is preceded by an identifier for the hashing algorithm used to protect the signature policy and followed by the hash value which must be re-calculated and checked whenever the signature policy is passed between the issuer and signer/verifier.
In this structure the policy information is preceded by an identifier for the hashing algorithm used to protect the signature policy and followed by the hash value which must be re-calculated and checked whenever the signature policy is passed between the issuer and signer/verifier.
The hash is calculated without the outer type and length fields.
The hash is calculated without the outer type and length fields.
Ross, et al. Experimental [Page 5] RFC 3125 Electronic Signature Policies September 2001
Ross, et al. Experimental [Page 5] RFC 3125 Electronic Signature Policies September 2001
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignaturePolicy ::= SEQUENCE { signPolicyHashAlg AlgorithmIdentifier, signPolicyInfo SignPolicyInfo, signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyInfo ::= SEQUENCE { signPolicyIdentifier SignPolicyId, dateOfIssue GeneralizedTime, policyIssuerName PolicyIssuerName, fieldOfApplication FieldOfApplication, signatureValidationPolicy SignatureValidationPolicy, signPolExtensions SignPolExtensions OPTIONAL }
SignPolicyId ::= OBJECT IDENTIFIER
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
FieldOfApplication ::= DirectoryString
The policyIssuerName field identifies the policy issuer in one or more of the general name forms.
The policyIssuerName field identifies the policy issuer in one or more of the general name forms.
The fieldofApplication is a description of the expected application of this policy.
The fieldofApplication is a description of the expected application of this policy.
The signature validation policy rules are fully processable to allow the validation of electronic signatures issued under that form of signature policy. They are described in the rest of this section.
The signature validation policy rules are fully processable to allow the validation of electronic signatures issued under that form of signature policy. They are described in the rest of this section.
The signPolExtensions is a generic way to extend the definition of any sub-component of a signature policy.
The signPolExtensions is a generic way to extend the definition of any sub-component of a signature policy.
3.2 Signature Validation Policy
3.2 Signature Validation Policy
The signature validation policy defines for the signer which data elements must be present in the electronic signature he provides and for the verifier which data elements must be present under that signature policy for an electronic signature to be potentially valid.
The signature validation policy defines for the signer which data elements must be present in the electronic signature he provides and for the verifier which data elements must be present under that signature policy for an electronic signature to be potentially valid.
The signature validation policy is described as follows:
The signature validation policy is described as follows:
Ross, et al. Experimental [Page 6] RFC 3125 Electronic Signature Policies September 2001
Ross, et al. Experimental [Page 6] RFC 3125 Electronic Signature Policies September 2001
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
SignatureValidationPolicy ::= SEQUENCE { signingPeriod SigningPeriod, commonRules CommonRules, commitmentRules CommitmentRules, signPolExtensions SignPolExtensions OPTIONAL }
The signingPeriod identifies the date and time before which the signature policy SHOULD NOT be used for creating signatures, and an optional date after which it should not be used for creating signatures.
The signingPeriod identifies the date and time before which the signature policy SHOULD NOT be used for creating signatures, and an optional date after which it should not be used for creating signatures.
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
SigningPeriod:、:= 系列notBefore GeneralizedTimeで、notAfter GeneralizedTime任意です。
3.3 Common Rules
3.3 一般的な規則
The CommonRules define rules that are common to all commitment types. These rules are defined in terms of trust conditions for certificates, time-stamps and attributes, along with any constraints on attributes that may be included in the electronic signature.
CommonRulesはすべての委任タイプに、一般的な規則を定義します。 これらの規則は証明書のための信頼状態、タイムスタンプ、および属性で定義されます、電子署名に含まれるかもしれない属性におけるどんな規制と共にも。
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommonRules:、:= 系列signerAndVeriferRules[0]SignerAndVerifierRulesの任意の、そして、signingCertTrustCondition[1]SigningCertTrustCondition任意のtimeStampTrustCondition[2]TimestampTrustCondition任意であって、attributeTrustCondition[3]AttributeTrustConditionの任意の、そして、algorithmConstraintSet[4]AlgorithmConstraintSet任意のsignPolExtensions[5]SignPolExtensions任意です。
If a field is present in CommonRules then the equivalent field must not be present in any of the CommitmentRules (see below). If any of the following fields are not present in CommonRules then it must be present in each CommitmentRule:
分野がCommonRulesに存在しているなら、同等な分野はCommitmentRulesのいずれにも存在しているはずがありません(以下を見てください)。 以下の分野のいずれもCommonRulesに存在していないなら、各CommitmentRuleに存在していなければなりません:
* signerAndVeriferRules;
* signingCertTrustCondition;
* timeStampTrustCondition.
* signerAndVeriferRules。 * signingCertTrustCondition。 * timeStampTrustCondition。
Ross, et al. Experimental [Page 7] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[7ページ]RFC3125
3.4 Commitment Rules
3.4 委任規則
The CommitmentRules consists of the validation rules which apply to given commitment types:
CommitmentRulesは委任タイプを考えて、当てはまる合法化規則から成ります:
CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRules:、:= CommitmentRuleの系列
The CommitmentRule for given commitment types are defined in terms of trust conditions for certificates, time-stamps and attributes, along with any constraints on attributes that may be included in the electronic signature.
与えられた委任タイプのためのCommitmentRuleは証明書のための信頼状態、タイムスタンプ、および属性で定義されます、電子署名に含まれるかもしれない属性におけるどんな規制と共にも。
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommitmentRule:、:= 系列signerAndVeriferRules[0]SignerAndVerifierRulesの任意の、そして、signingCertTrustCondition[1]SigningCertTrustCondition任意のtimeStampTrustCondition[2]TimestampTrustCondition任意の、そして、attributeTrustCondition[3]AttributeTrustConditionの任意の、そして、algorithmConstraintSet[4]AlgorithmConstraintSet任意のsignPolExtensions[5]SignPolExtensions任意のselCommitmentTypes SelectedCommitmentTypes
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
SelectedCommitmentTypes:、:= 選択の系列空のNULL、recognizedCommitmentType CommitmentType
If the SelectedCommitmentTypes indicates "empty" then this rule applied when a commitment type is not present (i.e., the type of commitment is indicated in the semantics of the message). Otherwise, the electronic signature must contain a commitment type indication that must fit one of the commitments types that are mentioned in CommitmentType.
委任タイプが出席していないとき(すなわち、委任のタイプはメッセージの意味論で示されます)、「空になってください」と、SelectedCommitmentTypesが示すなら、この規則は適用されました。 さもなければ、電子署名はCommitmentTypeで言及される委任タイプのひとりに合わなければならない委任タイプ指示を含まなければなりません。
A specific commitment type identifier must not appear in more than one commitment rule.
具体的な言明タイプ識別子は1つ以上の委任規則で現れてはいけません。
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
CommitmentType:、:= 系列識別子CommitmentTypeIdentifier、fieldOfApplication[0]FieldOfApplication OPTIONAL、意味論[1]DirectoryString OPTIONAL
Ross, et al. Experimental [Page 8] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[8ページ]RFC3125
The fieldOfApplication and semantics fields define the specific use and meaning of the commitment within the overall field of application defined for the policy.
fieldOfApplicationと意味論分野は方針のために定義されたアプリケーションの総合的な分野の中で委任の特定的用法と意味を定義します。
3.5 Signer and Verifier Rules
3.5署名者と検証規則
The following rules apply to the format of electronic signatures defined using [ES-FORMATS].
以下の規則は[ES-FORMATS]を使用することで定義された電子署名の形式に適用されます。
The SignerAndVerifierRules consists of signer rule and verification rules as defined below:
SignerAndVerifierRulesは以下で定義されるように署名者規則と検証規則から成ります:
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
SignerAndVerifierRules:、:= 系列signerRules SignerRules、verifierRules VerifierRules
3.5.1 Signer Rules
3.5.1 署名者規則
The signer rules identify:
署名者規則は以下を特定します。
* if the eContent is empty and the signature is calculated using
a hash of signed data external to CMS structure.
* eContentが空であり、署名がCMS構造への外部の署名しているデータのハッシュを使用することで計算されるなら。
* the CMS signed attributes that must be provided by the signer
under this policy;
* CMSはこの方針の下で署名者で提供しなければならない属性に署名しました。
* the CMS unsigned attribute that must be provided by the signer
under this policy;
* この方針の下で署名者で提供しなければならないCMSの未署名の属性。
* whether the certificate identifiers from the full certification
path up to the trust point must be provided by the signer in
the SigningCertificate attribute;
* SigningCertificate属性における署名者で信頼ポイントまでの完全な証明経路からの証明書識別子を提供しなければならないか否かに関係なく。
* whether a signer's certificate, or all certificates in the
certification path to the trust point must be by the signer in
the * certificates field of SignedData.
* 署名者の証明書、または信頼ポイントへの証明経路のすべての証明書がなければならないか否かに関係なく、SignedDataの*証明書分野の署名者でいてください。
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- Not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
SignerRules:、:= SEQUENCE、署名されるなら、本当に、データはCMS構造に外部です--データであると署名されるなら虚偽で、CMS構造(現在ではありませんが、許容されたmandatedSignedAttr CMSAttrs)の一部が属性mandatedUnsignedAttr CMSAttrsであると署名されるCMSを強制したというexternalSignedData BOOLEAN OPTIONALはCMS未署名の結果と考えられたmandatedCertificateRef[0]CertRefReq DEFAULT signerOnlyを強制しました--Certificate Referenceを強制します。
Ross, et al. Experimental [Page 9] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[9ページ]RFC3125
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
mandatedCertificateInfo[1]CertInfoReq DEFAULT、なにも--Certificate Info signPolExtensions[2]SignPolExtensions OPTIONALを強制します。
CMSattrs ::= SEQUENCE OF OBJECT IDENTIFIER
CMSattrs:、:= オブジェクト識別子の系列
The mandated SignedAttr field must include the object identifier for all those signed attributes required by this document as well as additional attributes required by this policy.
強制されたSignedAttr分野はと同様にこのドキュメントによって必要とされた属性であると署名されるすべてのもののためのオブジェクト識別子を含まなければなりません。
The mandatedUnsignedAttr field must include the object identifier for all those unsigned attributes required by this document as well as additional attributes required by this policy. For example, if a signature time-stamp <see section 1.1) is required by the signer the object identifier for this attribute must be included.
mandatedUnsignedAttr分野はと同様にこのドキュメントによって必要とされたそれらのすべての未署名の属性のためのオブジェクト識別子を含まなければなりません。 例えば、署名タイムスタンプ<であるなら見てください。セクション1.1) 含まれて、この属性のためのオブジェクト識別子がそうしなければならない署名者が必要です。
The mandatedCertificateRef identifies whether just the signer's certificate, or all the full certificate path must be provided by the signer.
mandatedCertificateRefは、まさしく署名者の証明書、またはすべての完全な証明書経路がそうであるに違いないかどうか署名者で提供していた状態で特定します。
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullpath (2)
CertRefReq:、:= ENUMERATED、signerOnly(1)--単に署名者本命に強制されたfullpathに参照をつけてください。(2)
-- References for full cert path up to a trust point required
}
-- 信頼ポイントまでの完全な本命道の参照が必要です。
The mandatedCertificateInfo field identifies whether a signer's certificate, or all certificates in the certification path to the trust point must be provided by the signer in the certificates field of SignedData.
SignedDataの証明書分野の署名者は分野が署名者の証明書、または信頼ポイントへの証明経路のすべての証明書であることにかかわらず特定するmandatedCertificateInfoを提供しなければなりません。
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory requirements
signerOnly (1) ,
-- Only reference to signer cert mandated
fullpath (2)
-- References for full cert path up to a
-- trust point mandated
}
CertInfoReq:、:= 列挙されます。強制されて、(0)--義務的な要件signerOnlyがありません(1)--署名者の本命の強制されたfullpath(2)の参照だけ--aまでの完全な本命道の参照--信頼が指さないなにも
Ross, et al. Experimental [Page 10] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[10ページ]RFC3125
3.5.2 Verifier Rules
3.5.2 検証規則
The verifier rules identify:
検証規則は以下を特定します。
* The CMS unsigned attributes that must be present under this
policy and must be added by the verifier if not added by the
signer.
* この方針の下で存在していなければならなくて、検証によって加えられなければならないか、または署名者で加えなければならないCMSの未署名の属性。
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
VerifierRules:、:= 系列mandatedUnsignedAttr MandatedUnsignedAttrで、signPolExtensions SignPolExtensions任意です。
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
MandatedUnsignedAttr:、:= CMSAttrs--CMSを強制する、未署名、結果と考え
3.6 Certificate and Revocation Requirement
3.6 証明書と取消し要件
The SigningCertTrustCondition, TimestampTrustCondition and AttributeTrustCondition (defined in subsequent sub-sections) make use of two ASN1 structures which are defined below: CertificateTrustTrees and CertRevReq.
SigningCertTrustCondition、TimestampTrustCondition、およびAttributeTrustCondition(その後の小区分では、定義される)は以下で定義される2つのASN1構造を利用します: CertificateTrustTreesとCertRevReq。
3.6.1 Certificate Requirements
3.6.1 証明書要件
The certificateTrustTrees identifies a set of self signed certificates for the trust points used to start (or end) certificate path processing and the initial conditions for certificate path validation as defined RFC 2459 [7] section 4. This ASN1 structure is used to define policy for validating the signing certificate, the TSA's certificate and attribute certificates.
certificateTrustTreesは定義されたRFC2459[7]部4として証明書経路処理を始めること(終わる)に使用される信頼ポイントと証明書経路合法化のための初期条件のための証明書であると署名される1セットの自己を特定します。 このASN1構造は、署名証明書、TSAの証明書、および属性証明書を有効にするための方針を定義するのに使用されます。
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustTrees:、:= CertificateTrustPointの系列
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
CertificateTrustPoint:、:= 系列trustpoint Certificate--自己署名入りの証書pathLenConstraint[0]PathLenConstraint OPTIONAL、acceptablePolicySet[1]AcceptablePolicySet OPTIONAL--Ifは「どんな方針も」nameConstraints[2]NameConstraints OPTIONALを寄贈しません、policyConstraints[3]PolicyConstraints OPTIONAL
The trustPoint field gives the self signed certificate for the CA that is used as the trust point for the start of certificate path processing.
trustPoint分野は信頼が証明書経路処理の始まりに指すとき使用されたカリフォルニアのための自己署名入りの証書を与えます。
Ross, et al. Experimental [Page 11] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[11ページ]RFC3125
The pathLenConstraint field gives the maximum number of CA certificates that may be in a certification path following the trustpoint. A value of zero indicates that only the given trustpoint certificate and an end-entity certificate may be used. If present, the pathLenConstraint field must be greater than or equal to zero. Where pathLenConstraint is not present, there is no limit to the allowed length of the certification path.
pathLenConstraint分野はtrustpointに続いて、証明経路にあるかもしれないカリフォルニア証明書の最大数を与えます。 ゼロの値は、与えられたtrustpoint証明書と終わり実体証明書だけを使用してもよいのを示します。 存在しているなら、pathLenConstraint分野はゼロ以上であるに違いありません。 pathLenConstraintが存在していないところには、証明経路の許容長さへの限界が全くありません。
PathLenConstraint ::= INTEGER (0..MAX)
PathLenConstraint:、:= 整数(0..MAX)
The acceptablePolicySet field identifies the initial set of certificate policies, any of which are acceptable under the signature policy. AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
acceptablePolicySet分野は証明書方針の始発を特定します。そのいずれも署名方針の下で許容できます。 AcceptablePolicySet:、:= CertPolicyIdの系列
CertPolicyId ::= OBJECT IDENTIFIER
CertPolicyId:、:= オブジェクト識別子
The nameConstraints field indicates a name space within which all subject names in subsequent certificates in a certification path must be located. Restrictions may apply to the subject distinguished name or subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.
nameConstraints分野は証明経路のその後の証明書のすべての対象の名前が位置しなければならない名前スペースを示します。 制限は対象の分類名か対象の代替名に適用されるかもしれません。 形成という指定された名前が存在しているときだけ、制限は適用されます。 タイプの名前が全く証明書にないなら、証明書は許容できます。
Restrictions are defined in terms of permitted or excluded name subtrees. Any name matching a restriction in the excludedSubtrees field is invalid regardless of information appearing in the permittedSubtrees.
制限は受入れられたか除かれた名前下位木で定義されます。 excludedSubtrees分野で制限に合っているどんな名前もpermittedSubtreesに現れる情報にかかわらず無効です。
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
NameConstraints:、:= 系列permittedSubtrees[0]GeneralSubtrees任意であって、excludedSubtrees[1]GeneralSubtrees任意です。
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtrees:、:= GeneralSubtreeの系列サイズ(1..MAX)
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
GeneralSubtree:、:= 系列ベースGeneralName、最小限[0]BaseDistance DEFAULT0、最大[1]BaseDistance OPTIONAL
BaseDistance ::= INTEGER (0..MAX)
BaseDistance:、:= 整数(0..MAX)
The policyConstraints extension constrains path processing in two ways. It can be used to prohibit policy mapping or require that each certificate in a path contain an acceptable policy identifier.
policyConstraints拡張子は2つの方法で経路処理を抑制します。 方針マッピングを禁止するか、または経路の各証明書が許容できる方針識別子を含むのが必要であるのにそれを使用できます。
The policyConstraints field, if present specifies requirement for explicit indication of the certificate policy and/or the constraints on policy mapping.
policyConstraints分野、プレゼントが証明書方針の明白なしるしのための要件を指定するか、そして、そして/または、方針マッピングにおける規制。
Ross, et al. Experimental [Page 12] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[12ページ]RFC3125
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
PolicyConstraints:、:= 系列requireExplicitPolicy[0]SkipCerts任意であって、inhibitPolicyMapping[1]SkipCerts任意です。
SkipCerts ::= INTEGER (0..MAX)
SkipCerts:、:= 整数(0..MAX)
If the inhibitPolicyMapping field is present, the value indicates the number of additional certificates that may appear in the path (including the trustpoint's self certificate) before policy mapping is no longer permitted. For example, a value of one indicates that policy mapping may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path.
inhibitPolicyMapping分野が存在しているなら、値は方針マッピングがもう受入れられない前に経路(trustpointの自己証明書を含んでいる)に現れるかもしれない追加証明書の数を示します。 例えば、1の値は、方針マッピングが経路でこの証明書の対象によって発行された証明書で処理されますが、追加証明書で処理されるかもしれないというわけではないのを示します。
If the requireExplicitPolicy field is present, subsequent certificates must include an acceptable policy identifier. The value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path (including the trustpoint's self certificate) before an explicit policy is required. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy which has been declared equivalent through policy mapping.
requireExplicitPolicy分野が存在しているなら、その後の証明書は許容できる方針識別子を含まなければなりません。 requireExplicitPolicyの値は明白な方針が必要である前に経路(trustpointの自己証明書を含んでいる)に現れるかもしれない追加証明書の数を示します。 許容できる方針識別子は、証明経路のユーザによって必要とされた方針に関する識別子か方針マッピングを通して同等であると宣言された方針に関する識別子です。
3.6.2 Revocation Requirements
3.6.2 取消し要件
The RevocRequirements field specifies minimum requirements for revocation information, obtained through CRLs and/or OCSP responses, to be used in checking the revocation status of certificates. This ASN1 structure is used to define policy for validating the signing certificate, the TSA's certificate and attribute certificates.
RevocRequirements分野は、証明書の取消し状態をチェックする際に使用されるためにCRLs、そして/または、OCSP応答で得られた取消し情報に必要最小限を指定します。 このASN1構造は、署名証明書、TSAの証明書、および属性証明書を有効にするための方針を定義するのに使用されます。
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
CertRevReq:、:= 系列endCertRevReq RevReq、caCerts[0]RevReq
Certificate revocation requirements are specified in terms of checks required on:
証明書取消し要件は以下で必要であったチェックで指定されます。
* endCertRevReq: end certificates (i.e., the signers certificate,
the attribute certificate or the time-stamping authority
certificate).
* endCertRevReq: 証明書(すなわち、署名者証明書、属性証明書または時間の刻印権威証明書)を終わらせてください。
* caCerts: CA certificates.
* caCerts: カリフォルニア証明書。
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
RevReq:、:= 系列enuRevReq EnuRevReqで、exRevReq SignPolExtensions任意です。
Ross, et al. Experimental [Page 13] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[13ページ]RFC3125
An authority certificate is certificate issued to an authority (e.g., either to a certification authority or to an attribute authority (AA)).
権威証明書は権威(例えば、証明権威、または、属性権威(AA)への)に発行された証明書です。
A Time-Stamping Authority (TSA) is a trusted third party that creates time-stamp tokens in order to indicate that a datum existed at a particular point in time. See [TSP].
Time-押し込むAuthority(TSA)はデータが時間内に特定のポイントで存在したのを示すためにタイムスタンプトークンを作成する信頼できる第三者機関です。 [ティースプーンフル]を見てください。
EnuRevReq ::= ENUMERATED {
clrCheck (0),
--Checks must be made against current CRLs
-- (or authority revocation lists (ARL))
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol
-- (OCSP),RFC 2450.
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be
-- carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy
-- extension
}
EnuRevReq:、:= 列挙されます。チェックが現在のCRLs((または、権威取消しリスト(ARL))ocspCheck(1))に対して作られていて、取消し状態をチェックしなければならないということであるに違いないというOnline Certificate Statusプロトコル--(OCSP)、RFC2450bothCheck(2)--CRLとOCSPチェックの両方を使用するclrCheck(0)による行われて、少なくともCRLかOCSPチェックの1つがそうであるに違いないというeitherCheck(3)はnoCheck(4)を行いました--どんなチェックも強制された他の(5)(署名方針で定義される他のメカニズム)拡大でないということでなければなりません。
Revocation requirements are specified in terms of:
取消し要件は以下に関して指定されます。
* clrCheck: Checks must be made against current CRLs (or
authority revocation lists);
* ocspCheck: The revocation status must be checked using the
Online Certificate Status Protocol (RFC 2450);
* bothCheck: Both OCSP and CRL checks must be carried out;
* eitherCheck: Either OCSP or CRL checks must be carried out;
* noCheck: No check is mandated.
* clrCheck: 現在のCRLs(または、権威取消しリスト)に対してチェックをしなければなりません。 * ocspCheck: Online Certificate Statusプロトコル(RFC2450)を使用することで取消し状態をチェックしなければなりません。 * bothCheck: OCSPとCRLチェックの両方を行わなければなりません。 * eitherCheck: OCSPかCRLチェックのどちらかを行わなければなりません。 * noCheck: チェックは全く強制されません。
3.7 Signing Certificate Trust Conditions
3.7 証明書信頼が状態であると署名すること。
The SigningCertTrustCondition field identifies trust conditions for certificate path processing used to validate the signing certificate.
SigningCertTrustCondition分野は署名証明書を有効にするのに使用される証明書経路処理のための信頼状態を特定します。
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
SigningCertTrustCondition:、:= 系列signerTrustTrees CertificateTrustTrees、signerRevReq CertRevReq
Ross, et al. Experimental [Page 14] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[14ページ]RFC3125
3.8 Time-Stamp Trust Conditions
3.8 タイムスタンプ信頼状態
The TimeStampTrustCondition field identifies trust conditions for certificate path processing used to authenticate the timstamping authority and constraints on the name of the time-stamping authority. This applies to the time-stamp that must be present in every ES-T.
TimeStampTrustCondition分野は時間の刻印権威の名前でtimstamping権威と規制を認証するのに使用される証明書経路処理のための信頼状態を特定します。 これはあらゆるES-Tに存在しなければならないタイムスタンプに適用されます。
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
TimestampTrustCondition:、:= 系列ttsCertificateTrustTrees[0]CertificateTrustTreesの任意の、そして、ttsRevReq[1]CertRevReqの任意の、そして、ttsNameConstraints[2]NameConstraints任意のcautionPeriod[3]DeltaTime任意のsignatureTimestampDelay[4]DeltaTime任意
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
DeltaTime:、:= 系列deltaSeconds整数、deltaMinutes整数、deltaHours整数、deltaDays整数
If ttsCertificateTrustTrees is not present then the same rule as defined in certificateTrustCondition applies to certification of the time-stamping authorities public key.
ttsCertificateTrustTreesが存在していないなら、certificateTrustConditionで定義されるのと同じ規則は時間の刻印当局公開鍵の証明に適用されます。
The tstrRevReq specifies minimum requirements for revocation information, obtained through CRLs and/or OCSP responses, to be used in checking the revocation status of the time-stamp that must be present in the ES-T.
tstrRevReqは、ES-Tで存在しなければならないタイムスタンプの取消し状態をチェックする際に使用されるためにCRLs、そして/または、OCSP応答で得られた取消し情報に必要最小限を指定します。
If ttsNameConstraints is not present then there are no additional naming constraints on the trusted time-stamping authority other than those implied by the ttsCertificateTrustTrees.
ttsNameConstraintsが存在していないなら、どんな追加命名規制もttsCertificateTrustTreesによって含意されたもの以外の信じられた時間の刻印権威にありません。
The cautionPeriod field specifies a caution period after the signing time that it is mandated the verifier must wait to get high assurance of the validity of the signer's key and that any relevant revocation has been notified. The revocation status information forming the ES with Complete validation data must not be collected and used to validate the electronic signature until after this caution period.
cautionPeriod分野は署名の後に検証が、署名者のキーの正当性の高い保証を得るのを待たなければならないのが強制されて、どんな関連取消しも通知された時間、警告の期間を指定します。 この警告の期間の後まで電子署名を有効にするのにComplete合法化データでESを形成する取消し状態情報を、集めて、使用してはいけません。
The signatureTimestampDelay field specifies a maximum acceptable time between the signing time and the time at which the signature time- stamp, as used to form the ES Time-Stamped, is created for the
時間が押し込むES Timeによって押し込まれるのを形成するのに使用される署名がどれにおいて作成されるかでsignatureTimestampDelay分野は署名時間と時間の間で最大の許容できる時間のaを指定します。
Ross, et al. Experimental [Page 15] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[15ページ]RFC3125
verifier. If the signature time-stamp is later that the time in the signing-time attribute by more than the value given in signatureTimestampDelay, the signature must be considered invalid.
検証。 署名タイムスタンプが、より遅れているなら、無効であると署名時間の時間がsignatureTimestampDelayで与えられた値、署名以上を結果と考えるのを考えなければなりません。
3.9 Attribute Trust Conditions
3.9 属性信頼状態
If the attributeTrustCondition field is not present then any certified attributes may not considered to be valid under this validation policy. The AttributeTrustCondition field is defined as follows:
attributeTrustCondition分野が存在していないなら、この合法化方針の下で有効であることは考えられないで、どんな公認された属性もそうするかもしれません。 AttributeTrustCondition分野は以下の通り定義されます:
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
AttributeTrustCondition:、:= 系列ブールであることで、attributeMandatedされました--属性は現在のhowCertAttribute HowCertAttributeであるに違いありません、attrCertificateTrustTrees[0]CertificateTrustTrees OPTIONAL、attrRevReq[1]CertRevReq OPTIONAL、attributeConstraints[2]AttributeConstraints OPTIONAL
If attributeMandated is true then an attribute, certified within the following constraints, must be present. If false, then the signature is still valid if no attribute is specified.
attributeMandatedが本当であるなら、以下の規制の中で公認された属性は存在していなければなりません。 誤って、属性が全く指定されないなら、署名はまだ有効です。
The howCertAttribute field specifies whether attributes uncertified attributes "claimed" by the signer, or certified attributes (i.e., Attribute Certificates) or either using the signer attributes attribute defined in [ES-FORMATS] section 3.12.3.
howCertAttribute分野は、属性が署名者によって「要求される」か、属性(すなわち、Attribute Certificates)であることが公認されるか、または[ES-FORMATS]セクション3.12.3で定義された署名者属性属性を使用することで属性を非公認したかどうか指定します。
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
HowCertAttribute:、:= 列挙されます。claimedAttribute(0)、certifiedAttribtes(1)、(2)
The attrCertificateTrustTrees specifies certificate path conditions for any attribute certificate. If not present the same rules apply as in certificateTrustCondition.
attrCertificateTrustTreesはどんな属性証明書のための証明書経路状態も指定します。 そうでなければ、同じ現在の規則はcertificateTrustConditionのように適用されます。
The attrRevReq specifies minimum requirements for revocation information, obtained through CRLs and/or OCSP responses, to be used in checking the revocation status of Attribute Certificates, if any are present.
attrRevReqはAttribute Certificatesの取消し状態をチェックする際に使用されるためにCRLs、そして/または、OCSP応答で得られた取消し情報に必要最小限を指定します、いずれか存在しているなら。
If the attributeConstraints field is not present then there are no constraints on the attributes that may be validated under this policy. The attributeConstraints field is defined as follows:
attributeConstraints分野が存在していないなら、規制が全くこの方針の下で有効にされるかもしれない属性にありません。 attributeConstraints分野は以下の通り定義されます:
Ross, et al. Experimental [Page 16] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[16ページ]RFC3125
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeConstraints:、:= 系列attributeTypeConstarints[0]AttributeTypeConstraints任意であって、attributeValueConstarints[1]AttributeValueConstraints任意です。
If present, the attributeTypeConstarints field specifies the attribute types which are considered valid under the signature policy. Any value for that attribute is considered valid.
存在しているなら、attributeTypeConstarints分野は署名方針の下で有効であると考えられる属性タイプを指定します。 その属性のためのどんな値も有効であると考えられます。
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeTypeConstraints:、:= AttributeTypeの系列
If present, the attributeTypeConstraints field specifies the specific attribute values which are considered valid under the signature policy.
存在しているなら、attributeTypeConstraints分野は署名方針の下で有効であると考えられる特定の属性値を指定します。
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AttributeValueConstraints:、:= AttributeTypeAndValueの系列
3.10 Algorithm Constraints
3.10 アルゴリズム規制
The algorithmConstrains fields, if present, identifies the signing algorithms (hash, public key cryptography, combined hash and public key cryptography) that may be used for specific purposes and any minimum length. If this field is not present then the policy applies no constraints.
存在しているなら、algorithmConstrains分野は特定の目的で使用されるかもしれない署名アルゴリズム(ハッシュ(公開鍵暗号)はハッシュと公開鍵暗号を結合した)とどんな最小の長さも特定します。 この分野が存在していないなら、方針は規制を全く当てはまりません。
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- Time-Stamping Authority
}
AlgorithmConstraintSet:、:= 系列--アルゴリズムは以下でsignerAlgorithmConstraints[0]AlgorithmConstraints OPTIONALを抑制します--署名者eeCertAlgorithmConstraints[1]AlgorithmConstraints OPTIONAL--終わりの実体本命caCertAlgorithmConstraints[2]AlgorithmConstraints OPTIONALの発行人--カリフォルニアの発行人がaaCertAlgorithmConstraints[3]AlgorithmConstraints OPTIONAL--属性Authority tsaCertAlgorithmConstraints[4]AlgorithmConstraints OPTIONAL--時間を押し込むAuthorityを証明する
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgorithmConstraints:、:= AlgAndLengthの系列
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}
AlgAndLength:、:= 系列algID OBJECT IDENTIFIER、minKeyLength INTEGER OPTIONAL--、ビットもう一方SignPolExtensions OPTIONALの最小のキー長
Ross, et al. Experimental [Page 17] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[17ページ]RFC3125
An Attribute Authority (AA)is authority which assigns privileges by issuing attribute certificates
Attribute Authority(AA)は属性証明書を発行することによって特権を割り当てる権威です。
3.11 Signature Policy Extensions
3.11 署名方針拡大
Additional signature policy rules may be added to:
追加署名政策ルールは以下のことのために加えられるかもしれません。
* the overall signature policy structure, as defined in section
3.1;
* the signature validation policy structure, as defined in
section 3.2;
* the common rules, as defined in section 3.3;
* the commitment rules, as defined in section 3.4;
* the signer rules, as defined in section 3.5.1;
* the verifier rules, as defined in section 3.5.2;
* the revocation requirements in section 3.6.2;
* the algorithm constraints in section 3.10.
* セクション3.1で定義されるような総合的な署名方針構造 * セクション3.2で定義されるような署名合法化方針構造 * セクション3.3で定義されるような共通規則 * 委任はセクション3.4で定義されるように統治されます。 * 署名者はセクション3.5.1で定義されるように統治されます。 * 検証はセクション3.5.2で定義されるように統治されます。 * セクション3.6.2における取消し要件。 * セクション3.10でのアルゴリズム規制。
These extensions to the signature policy rules must be defined using an ASN.1 syntax with an associated object identifier carried in the SignPolExtn as defined below:
SignPolExtnで運ばれる関連オブジェクト識別子と共に以下で定義されるようにASN.1構文を使用することで署名政策ルールへのこれらの拡大を定義しなければなりません:
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtensions:、:= SignPolExtnの系列
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
SignPolExtn:、:= 系列extnIDオブジェクト識別子、extnValue八重奏ストリング
The extnID field must contain the object identifier for the extension. The extnValue field must contain the DER (see ITU-T Recommendation X.690 [4]) encoded value of the extension. The definition of an extension, as identified by extnID must include a definition of the syntax and semantics of the extension.
extnID分野は拡大のためのオブジェクト識別子を含まなければなりません。 extnValue分野はDERを含まなければなりません。(ITU-T Recommendation X.690[4])が拡大の値をコード化したのを確実にしてください。 拡大の定義、特定されるように、extnIDは構文の定義と拡大の意味論を含まなければなりません。
4. Security Considerations
4. セキュリティ問題
4.1 Protection of Private Key
4.1 秘密鍵の保護
The security of the electronic signature mechanism defined in this document depends on the privacy of the signer's private key. Implementations must take steps to ensure that private keys cannot be compromised.
本書では定義された電子署名メカニズムのセキュリティは署名者の秘密鍵のプライバシーによります。 実装は、秘密鍵に感染することができないのを保証するために手を打たなければなりません。
4.2 Choice of Algorithms
4.2 アルゴリズムの選択
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and computing performance improves, the work factor to break a particular
Implementersは時間に従って暗号アルゴリズムが、より弱くなるのを意識しているべきです。 発生していて、性能を計算していると改良される、新しい暗号解読のテクニック、事項を破るワーク・ファクタとして
Ross, et al. Experimental [Page 18] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[18ページ]RFC3125
cryptographic algorithm will reduce. Therefore, cryptographic algorithm implementations should be modular allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of mandatory to implement algorithms to change over time.
暗号アルゴリズムは減少するでしょう。 したがって、新しいアルゴリズムが容易に挿入されるのを許容することにおいて暗号アルゴリズム実装はモジュールであるべきです。 義務的のセットが時間がたつにつれて変化するようにアルゴリズムを実装するように、すなわち、implementersは準備されているべきです。
5. Conformance Requirements
5. 順応要件
Signer and verifier systems shall be able to process an electronic signature in accordance with the specification of the signature policy signature policy referenced identifiable by an Object Identifier, see section 3.
署名者と検証システムはObject Identifierが身元保証可能な状態で参照をつけられる署名方針署名方針の仕様通りに電子署名を処理できるでしょう、とセクション3は見ます。
6. References
6. 参照
[TS101733] ETSI Standard TS 101 733 V.1.2.2 (2000-12) Electronic
Signature Formats. Note: copies of ETSI TS 101 733 can
be freely download from the ETSI web site www.etsi.org.
[TS101733]ETSI標準のt101 733V.1.2.2の(2000-12)の電子署名形式。 以下に注意してください。 ETSI TS101 733のコピーはETSIウェブサイトwww.etsi.orgから自由にダウンロードすることであるかもしれません。
[ES-FORMATS] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
Formats for Long Term Electronic Signatures", RFC 3126,
June 2001.
[ES-形式] ピンカスとD.とロスとJ.とN.ポープ、「長期の電子署名のための電子署名形式」、RFC3126、2001年6月。
[TSP] Adams, C, Pinkas, D., Zuccherato, R. and P. Cain,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[ティースプーンフル] アダムスとCとピンカスとD.とZuccheratoとR.とP.カイン、「インターネットX.509公開鍵暗号基盤タイムスタンププロトコル(ティースプーンフル)」、RFC3161、2001年8月。
[OCSP] Myers, M., Ankney, R., Malpani, R., Galperin, S. and C.
Adams, "On-line Status Certificate Protocol", RFC 2560,
June 1999.
[OCSP] マイアーズとM.とAnkneyとR.とMalpaniとR.とガリペリンとS.とC.アダムス、「オンライン状態証明書プロトコル」、RFC2560、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESS]ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure, Certificate and CRL
Profile," RFC 2459, January 1999.
[RFC2459] HousleyとR.とフォードとW.とポークとW.と一人で生活して、「インターネットX.509公開鍵基盤、証明書、およびCRLは輪郭を描く」D.、RFC2459、1999年1月。
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City,
California, November 1993 Release.
RSA Data Security株式会社、レッドウッドシティー(カリフォルニア)、1993年11月は、[PKCS9]RSA研究所、「公開鍵暗号化標準(PKCS)」とリリースします。
Ross, et al. Experimental [Page 19] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[19ページ]RFC3125
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework. April 1997.
[ISONR]ISO/IEC10181-5: オープンシステム非拒否フレームワークにおけるセキュリティフレームワーク。 1997年4月。
7. Authors' Addresses
7. 作者のアドレス
This Experimental RFC has been produced in ETSI TC-SEC.
このExperimental RFCはETSI TC-SECで生産されました。
ETSI
F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles - Sophia Antipolis
Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
secretariat@etsi.fr
http://www.etsi.org
ETSI F-06921ソフィアAntipolis、Cedex--650台のRoute desルシオール--ソフィアAntipolis Valbonne--フランスFranceTel: +33 4 92 94 42 00、Fax: +33 4 93 65 47 16 secretariat@etsi.fr http://www.etsi.org
Contact Point
接点
Harri Rasilainen
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex
FRANCE
ハリーRasilainen ETSI650Route desルシオールF-06921ソフィア・Antipolis Cedexフランス
EMail: harri.rasilainen@etsi.fr
メール: harri.rasilainen@etsi.fr
John Ross
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
Moulsham通りチェルムズフォード、ジョンロスSecurityと規格192エセックスCM2 0LGイギリス
EMail: ross@secstan.com
メール: ross@secstan.com
Denis Pinkas
Integris, Bull.
68, Route de Versailles
78434 Louveciennes CEDEX
FRANCE
デニスピンカスIntegris、雄牛。 68 Route deベルサイユ78434Louveciennes CEDEXフランス
EMail: Denis.Pinkas@bull.net
メール: Denis.Pinkas@bull.net
Nick Pope
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
EMail: pope@secstan.com
Moulsham通りチェルムズフォード、ニック法王Securityと規格192エセックスCM2 0LGイギリスはメールされます: pope@secstan.com
Ross, et al. Experimental [Page 20] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[20ページ]RFC3125
Annex A (normative):
別館A(標準の):
ASN.1 Definitions This annex provides the reference definition of the ASN.1 syntax signature policies definitions for new syntax defined in this document.
ASN.1Definitions This別館は新しい構文のための.1の構文署名方針定義が本書では定義したASNの参照定義を提供します。
A.1 Definitions Using X.208 (1988) ASN.1 Syntax
X.208(1988)ASN.1構文を使用するA.1定義
NOTE: The ASN.1 Module defined in section A.1 has precedence over that defined in Annex A-2 in the case of any conflict.
以下に注意してください。 セクションA.1で定義されたASN.1Moduleはどんな闘争の場合でもAnnex A-2で定義されたそれの上の先行を持っています。
ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0)
7}
ETS-ElectronicSignaturePolicies-88syntaxiso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イドモッズ(0)7をメンバーと同じくらい具体化させます。
DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS All
定義、明白なタグ:、:= 始まってください--、すべてを輸出します。
IMPORTS
輸入
-- Internet X.509 Public Key Infrastructure
- Certificate and CRL Profile: RFC 2560
Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString,Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation, BMPString, UTF8String
-- インターネットX.509公開鍵暗号基盤--証明書とCRLは以下の輪郭を描きます。 AlgorithmIdentifier(CertificateList)が、GeneralNames(GeneralName、DirectoryString)が結果と考えると命名する2560年のRFC証明書、AttributeTypeAndValue、AttributeType、AttributeValue、PolicyInformation、BMPString、UTF8String
FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
;
FROM PKIX1Explicit88のiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ風の(0)イドpkix1明白な88(1)。
-- Signature Policy Specification -- ==============================
-- 署名方針仕様--==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignaturePolicy:、:= 系列signPolicyInfo SignPolicyInfoの、そして、signPolicyHash SignPolicyHash任意のsignPolicyHashAlg AlgorithmIdentifier
SignPolicyHash ::= OCTET STRING
SignPolicyHash:、:= 八重奏ストリング
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
SignPolicyInfo:、:= 系列、signPolicyIdentifier SignPolicyId、dateOfIssue GeneralizedTime、policyIssuerName PolicyIssuerName
Ross, et al. Experimental [Page 21] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[21ページ]RFC3125
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
signatureValidationPolicy SignatureValidationPolicyの、そして、signPolExtensions SignPolExtensions任意のfieldOfApplication FieldOfApplication
PolicyIssuerName ::= GeneralNames
PolicyIssuerName:、:= GeneralNames
FieldOfApplication ::= DirectoryString
FieldOfApplication:、:= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignatureValidationPolicy:、:= 系列signingPeriod SigningPeriod、commitmentRules CommitmentRulesの、そして、signPolExtensions SignPolExtensions任意のcommonRules CommonRules
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
SigningPeriod:、:= 系列notBefore GeneralizedTimeで、notAfter GeneralizedTime任意です。
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommonRules:、:= 系列signerAndVeriferRules[0]SignerAndVerifierRulesの任意の、そして、signingCertTrustCondition[1]SigningCertTrustCondition任意のtimeStampTrustCondition[2]TimestampTrustCondition任意であって、attributeTrustCondition[3]AttributeTrustConditionの任意の、そして、algorithmConstraintSet[4]AlgorithmConstraintSet任意のsignPolExtensions[5]SignPolExtensions任意です。
CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRules:、:= CommitmentRuleの系列
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
CommitmentRule:、:= 系列、signerAndVeriferRules[0]SignerAndVerifierRulesの任意の、そして、signingCertTrustCondition[1]SigningCertTrustCondition任意のtimeStampTrustCondition[2]TimestampTrustCondition任意のselCommitmentTypes SelectedCommitmentTypes
Ross, et al. Experimental [Page 22] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[22ページ]RFC3125
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
attributeTrustCondition[3]AttributeTrustConditionの任意の、そして、algorithmConstraintSet[4]AlgorithmConstraintSet任意のsignPolExtensions[5]SignPolExtensions任意 SelectedCommitmentTypes:、:= 選択の系列空のNULL、recognizedCommitmentType CommitmentType
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
CommitmentType:、:= 系列識別子CommitmentTypeIdentifier、fieldOfApplication[0]FieldOfApplication OPTIONAL、意味論[1]DirectoryString OPTIONAL
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
SignerAndVerifierRules:、:= 系列signerRules SignerRules、verifierRules VerifierRules
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions
OPTIONAL}
SignerRules:、:= 系列{ externalSignedData BOOLEAN OPTIONAL--本当に、サインされるなら、データはCMS構造に外部です--サインされるなら、虚偽で、CMS構造(現在ではありませんが、許容されたmandatedSignedAttr CMSAttrs)のデータ部分は、CMSが属性mandatedUnsignedAttr CMSAttrsにサインしたのを強制しました; 強制されたCMS無記名の結果と考えられたmandatedCertificateRef0CertRefReq DEFAULT signerOnly--なにもにCertificate Reference mandatedCertificateInfo1CertInfoReq DEFAULTを強制します--Certificate Info signPolExtensions2SignPolExtensions OPTIONALを強制します; }
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CMSAttrs:、:= 物の識別子の系列
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust point required
CertRefReq:、:= ENUMERATED、signerOnly(1)--署名者の本命の強制されたfullPath(2)の唯一の参照--信用ポイントまでの完全な本命道の参照が必要です。
}
}
CertInfoReq ::= ENUMERATED {
CertInfoReq:、:= 列挙
Ross, et al. Experimental [Page 23] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[23ページ]RFC3125
none (0),
-- No mandatory requirements
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust point mandated
}
なにもに、(0)--義務的な要件signerOnlyがありません(1)--署名者本命についての言及だけがfullPath(2)を強制しました--完全な本命道の参照は強制された信用ポイントへ上昇します。
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
VerifierRules:、:= 系列mandatedUnsignedAttr MandatedUnsignedAttrで、signPolExtensions SignPolExtensions任意です。
MandatedUnsignedAttr ::= CMSAttrs -- Mandated CMS unsigned attributed
MandatedUnsignedAttr:、:= CMSAttrs--結果と考えられて、無記名でCMSを強制します。
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustTrees:、:= CertificateTrustPointの系列
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
CertificateTrustPoint:、:= 系列trustpoint Certificate--自己署名入りの証書pathLenConstraint[0]PathLenConstraint OPTIONAL、acceptablePolicySet[1]AcceptablePolicySet OPTIONAL--Ifは「どんな方針も」nameConstraints[2]NameConstraints OPTIONALを寄贈しません、policyConstraints[3]PolicyConstraints OPTIONAL
PathLenConstraint ::= INTEGER (0..MAX)
PathLenConstraint:、:= 整数(0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
AcceptablePolicySet:、:= CertPolicyIdの系列
CertPolicyId ::= OBJECT IDENTIFIER
CertPolicyId:、:= 物の識別子
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
NameConstraints:、:= 系列permittedSubtrees[0]GeneralSubtrees任意であって、excludedSubtrees[1]GeneralSubtrees任意です。
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtrees:、:= GeneralSubtreeの系列サイズ(1..MAX)
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
GeneralSubtree:、:= 系列ベースGeneralName、最小限[0]BaseDistance DEFAULT0、最大[1]BaseDistance OPTIONAL
BaseDistance ::= INTEGER (0..MAX)
BaseDistance:、:= 整数(0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
PolicyConstraints:、:= 系列、requireExplicitPolicy[0]SkipCerts任意です。
Ross, et al. Experimental [Page 24] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[24ページ]RFC3125
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
inhibitPolicyMapping[1]SkipCerts任意
SkipCerts ::= INTEGER (0..MAX)
SkipCerts:、:= 整数(0..MAX)
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
CertRevReq:、:= 系列endCertRevReq RevReq、caCerts[0]RevReq
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
RevReq:、:= 系列enuRevReq EnuRevReqで、exRevReq SignPolExtensions任意です。
EnuRevReq ::= ENUMERATED {
clrCheck (0), --Checks must be made against current CRLs
-- (or authority revocation lists)
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol (RFC 2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy extension
}
EnuRevReq:、:= 列挙されます。取消し状態をチェックしなければならないという(または、権威取消しリスト)ocspCheck(1)がeitherCheck(3)からCRLとOCSPチェックの両方を運ばなければならないという少なくともCRLの1つのOnline Certificate Statusプロトコル(RFC2450)bothCheck(2)を使用して、現在のCRLsに対して(0)--チェックをしなければならない、さもなければOCSPがどんなチェックも強制されたもう一方(5)でないという運ばれた出ているnoCheck(4)が他のメカニズムであったに違いないなら署名方針拡大で定義されるようにチェックするclrCheck
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
SigningCertTrustCondition:、:= 系列signerTrustTrees CertificateTrustTrees、signerRevReq CertRevReq
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
TimestampTrustCondition:、:= 系列ttsCertificateTrustTrees[0]CertificateTrustTreesの任意の、そして、ttsRevReq[1]CertRevReqの任意の、そして、ttsNameConstraints[2]NameConstraints任意のcautionPeriod[3]DeltaTime任意のsignatureTimestampDelay[4]DeltaTime任意
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
DeltaTime:、:= 系列、deltaSeconds整数、deltaMinutes整数
Ross, et al. Experimental [Page 25] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[25ページ]RFC3125
deltaHours INTEGER,
deltaDays INTEGER }
deltaHours整数、deltaDays整数
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
AttributeTrustCondition:、:= 系列ブールであることで、attributeMandatedされました--属性は現在のhowCertAttribute HowCertAttributeであるに違いありません、attrCertificateTrustTrees[0]CertificateTrustTrees OPTIONAL、attrRevReq[1]CertRevReq OPTIONAL、attributeConstraints[2]AttributeConstraints OPTIONAL
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
HowCertAttribute:、:= 列挙されます。claimedAttribute(0)、certifiedAttribtes(1)、(2)
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeConstraints:、:= 系列attributeTypeConstarints[0]AttributeTypeConstraints任意であって、attributeValueConstarints[1]AttributeValueConstraints任意です。
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeTypeConstraints:、:= AttributeTypeの系列
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AttributeValueConstraints:、:= AttributeTypeAndValueの系列
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- Time-Stamping Authority
}
AlgorithmConstraintSet:、:= 系列--アルゴリズムは以下でsignerAlgorithmConstraints[0]AlgorithmConstraints OPTIONALを抑制します--署名者eeCertAlgorithmConstraints[1]AlgorithmConstraints OPTIONAL--終わりの実体本命caCertAlgorithmConstraints[2]AlgorithmConstraints OPTIONALの発行人--カリフォルニアの発行人がaaCertAlgorithmConstraints[3]AlgorithmConstraints OPTIONAL--属性Authority tsaCertAlgorithmConstraints[4]AlgorithmConstraints OPTIONAL--時間を押し込むAuthorityを証明する
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgorithmConstraints:、:= AlgAndLengthの系列
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits other
SignPolExtensions OPTIONAL
AlgAndLength:、:= SEQUENCE、algID OBJECT IDENTIFIER、minKeyLength INTEGER OPTIONAL--、ビットもう一方SignPolExtensions OPTIONALの最小のキー長
Ross, et al. Experimental [Page 26] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[26ページ]RFC3125
}
}
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtensions:、:= SignPolExtnの系列
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
SignPolExtn:、:= 系列extnID物の識別子、extnValue八重奏ストリング
END -- ETS-ElectronicSignaturePolicies-88syntax --
終わってください(ETS-ElectronicSignaturePolicies-88syntax)。
A.2 Definitions Using X.680 1997 ASN.1 Syntax
X.680 1997ASN.1構文を使用するA.2定義
NOTE: The ASN.1 module defined in section A.1 has precedence over that defined in section A.2 in the case of any conflict.
以下に注意してください。 セクションA.1で定義されたASN.1モジュールはどんな闘争の場合でもセクションA.2で定義されたそれの上の先行を持っています。
ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8}
ETS-ElectronicSignaturePolicies-97Syntaxiso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イドモッズ(0)8をメンバーと同じくらい具体化させます。
DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS All -
定義、明白なタグ:、:= 始まってください--、すべてを輸出する、-
IMPORTS
輸入
-- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC 2560
Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString, Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation
-- インターネットX.509公開鍵暗号基盤--証明書とCRLは以下の輪郭を描きます。 AlgorithmIdentifier(CertificateList)が、GeneralNames(GeneralName、DirectoryString)が結果と考えると命名する2560年のRFC証明書、AttributeTypeAndValue、AttributeType、AttributeValue、PolicyInformation
FROM PKIX1Explicit93
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
nid-pkix1-explicit-88(1)}
;
FROM PKIX1Explicit93のiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ風の(0)nid-pkix1明白な88(1)。
-- S/MIME Object Identifier arcs used in the present document -- ==================================================================
-- 現在のドキュメントで使用されるS/MIME Object Identifierアーク--==================================================================
-- S/MIME OID arc used in the present document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- 現在のドキュメントで使用されるS/MIME OIDアーク--、イド-smime OBJECT IDENTIFIER:、:= {iso(1)は(2)をメンバーと同じくらい具体化させます--私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9)16}
-- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules
-- S/MIME Arcs--イドモッズOBJECT IDENTIFIER:、:= イド-smime0--モジュール
Ross, et al. Experimental [Page 27] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[27ページ]RFC3125
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier
-- Signature Policy Specification
-- ==============================
-- イドct OBJECT IDENTIFIER:、:= イド-smime1--満足しているタイプ--イド-aa OBJECT IDENTIFIER:、:= イド-smime2--属性--イド-spq OBJECT IDENTIFIER:、:= イド-smime5--署名方針資格を与える人--イド-cti OBJECT IDENTIFIER:、:= イド-smime6--委任タイプ識別子--署名Policy Specification--==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignaturePolicy:、:= 系列signPolicyInfo SignPolicyInfoの、そして、signPolicyHash SignPolicyHash任意のsignPolicyHashAlg AlgorithmIdentifier
SignPolicyHash ::= OCTET STRING
SignPolicyHash:、:= 八重奏ストリング
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyInfo:、:= 系列signPolicyIdentifier SignPolicyId、dateOfIssue GeneralizedTime、policyIssuerName PolicyIssuerName、signatureValidationPolicy SignatureValidationPolicyの、そして、signPolExtensions SignPolExtensions任意のfieldOfApplication FieldOfApplication
SignPolicyId ::= OBJECT IDENTIFIER
SignPolicyId:、:= 物の識別子
PolicyIssuerName ::= GeneralNames
PolicyIssuerName:、:= GeneralNames
FieldOfApplication ::= DirectoryString
FieldOfApplication:、:= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
SignatureValidationPolicy:、:= 系列signingPeriod SigningPeriod、commitmentRules CommitmentRulesの、そして、signPolExtensions SignPolExtensions任意のcommonRules CommonRules
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
SigningPeriod:、:= 系列notBefore GeneralizedTimeで、notAfter GeneralizedTime任意です。
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
CommonRules:、:= 系列、signerAndVeriferRules[0]SignerAndVerifierRules任意です。
Ross, et al. Experimental [Page 28] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[28ページ]RFC3125
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
signingCertTrustCondition[1]SigningCertTrustConditionの任意の、そして、timeStampTrustCondition[2]TimestampTrustConditionの任意の、そして、attributeTrustCondition[3]AttributeTrustCondition任意のalgorithmConstraintSet[4]AlgorithmConstraintSet任意のsignPolExtensions[5]SignPolExtensions任意
CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRules:、:= CommitmentRuleの系列
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommitmentRule:、:= 系列signerAndVeriferRules[0]SignerAndVerifierRulesの任意の、そして、signingCertTrustCondition[1]SigningCertTrustCondition任意のtimeStampTrustCondition[2]TimestampTrustCondition任意の、そして、attributeTrustCondition[3]AttributeTrustConditionの任意の、そして、algorithmConstraintSet[4]AlgorithmConstraintSet任意のsignPolExtensions[5]SignPolExtensions任意のselCommitmentTypes SelectedCommitmentTypes
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
SelectedCommitmentTypes:、:= 選択の系列空のNULL、recognizedCommitmentType CommitmentType
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
CommitmentType:、:= 系列識別子CommitmentTypeIdentifier、fieldOfApplication[0]FieldOfApplication OPTIONAL、意味論[1]DirectoryString OPTIONAL
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
SignerAndVerifierRules:、:= 系列signerRules SignerRules、verifierRules VerifierRules
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- not present if either allowed
SignerRules:、:= SEQUENCE、許容されているなら、サインされるなら本当に、データがCMS構造のサインされたデータ部分であるならCMS構造に虚偽で外部であるというexternalSignedData BOOLEAN OPTIONALは提示しません。
Ross, et al. Experimental [Page 29] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[29ページ]RFC3125
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
なにも--mandatedSignedAttr CMSAttrs--CMSを強制するのは属性mandatedUnsignedAttr CMSAttrsにサインして、--強制されたCMS無記名の結果と考えられたmandatedCertificateRef[0]CertRefReq DEFAULT signerOnly--強制されたCertificate Reference mandatedCertificateInfo[1]CertInfoReq DEFAULTはCertificate Info signPolExtensions[2]SignPolExtensions OPTIONALを強制します。
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CMSAttrs:、:= 物の識別子の系列
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust
-- point required
}
CertRefReq:、:= 列挙されます。signerOnly(1)--署名者の本命の強制されたfullPath(2)の唯一の参照--信用までの完全な本命道の参照--指すのが必要です。
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory requirements
signerOnly (1) ,
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a
-- trust point mandated
}
CertInfoReq:、:= 列挙されます。(0)--義務的な要件signerOnlyがありません(1)--署名者の本命の強制されたfullPath(2)の参照だけ--aまでの完全な本命道の参照--信用ポイントが強制しなかったなにも
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
VerifierRules:、:= 系列、mandatedUnsignedAttr MandatedUnsignedAttrの、そして、signPolExtensions SignPolExtensions任意のMandatedUnsignedAttr、:、:= CMSAttrs--結果と考えられて、無記名でCMSを強制します。
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustTrees:、:= CertificateTrustPointの系列
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
CertificateTrustPoint:、:= 系列trustpoint Certificate--自己署名入りの証書pathLenConstraint[0]PathLenConstraint OPTIONAL、acceptablePolicySet[1]AcceptablePolicySet OPTIONAL--Ifは「どんな方針も」nameConstraints[2]NameConstraints OPTIONALを寄贈しません、policyConstraints[3]PolicyConstraints OPTIONAL
Ross, et al. Experimental [Page 30] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[30ページ]RFC3125
PathLenConstraint ::= INTEGER (0..MAX)
PathLenConstraint:、:= 整数(0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
AcceptablePolicySet:、:= CertPolicyIdの系列
CertPolicyId ::= OBJECT IDENTIFIER
CertPolicyId:、:= 物の識別子
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
NameConstraints:、:= 系列permittedSubtrees[0]GeneralSubtrees任意であって、excludedSubtrees[1]GeneralSubtrees任意です。
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtrees:、:= GeneralSubtreeの系列サイズ(1..MAX)
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
GeneralSubtree:、:= 系列ベースGeneralName、最小限[0]BaseDistance DEFAULT0、最大[1]BaseDistance OPTIONAL
BaseDistance ::= INTEGER (0..MAX)
BaseDistance:、:= 整数(0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
PolicyConstraints:、:= 系列requireExplicitPolicy[0]SkipCerts任意であって、inhibitPolicyMapping[1]SkipCerts任意です。
SkipCerts ::= INTEGER (0..MAX)
SkipCerts:、:= 整数(0..MAX)
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
CertRevReq:、:= 系列endCertRevReq RevReq、caCerts[0]RevReq
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
RevReq:、:= 系列enuRevReq EnuRevReqで、exRevReq SignPolExtensions任意です。
EnuRevReq ::= ENUMERATED {
clrCheck (0),
-- Checks must be made against current CRLs
-- (or authority revocation lists)
ocspCheck (1),
-- The revocation status must be checked using
-- the Online Certificate Status Protocol (RFC 2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be
-- carried out
noCheck (4),
-- no check is mandated
EnuRevReq:、:= ENUMERATED、現在のCRLsに対してチェックをしなければなりません--eitherCheck(3)からCRLとOCSPチェックの両方を運ばなければならないという少なくともCRLかOCSPチェックの1つの取消し状態がチェックの使用であるに違いないという(または、権威取消しリスト)ocspCheck(1)のOnline Certificate Statusプロトコル(RFC2450)bothCheck(2)がそうであるに違いないというclrCheck(0)はnoCheck(4)を行いました--チェックは全く強制されません。
Ross, et al. Experimental [Page 31] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[31ページ]RFC3125
other (5)
-- Other mechanism as defined by signature policy
-- extension
}
他の(5)--署名方針で定義される他のメカニズム--拡大
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
SigningCertTrustCondition:、:= 系列signerTrustTrees CertificateTrustTrees、signerRevReq CertRevReq
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
TimestampTrustCondition:、:= 系列ttsCertificateTrustTrees[0]CertificateTrustTreesの任意の、そして、ttsRevReq[1]CertRevReqの任意の、そして、ttsNameConstraints[2]NameConstraints任意のcautionPeriod[3]DeltaTime任意のsignatureTimestampDelay[4]DeltaTime任意
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
DeltaTime:、:= 系列deltaSeconds整数、deltaMinutes整数、deltaHours整数、deltaDays整数
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
AttributeTrustCondition:、:= 系列ブールであることで、attributeMandatedされました--属性は現在のhowCertAttribute HowCertAttributeであるに違いありません、attrCertificateTrustTrees[0]CertificateTrustTrees OPTIONAL、attrRevReq[1]CertRevReq OPTIONAL、attributeConstraints[2]AttributeConstraints OPTIONAL
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
HowCertAttribute:、:= 列挙されます。claimedAttribute(0)、certifiedAttribtes(1)、(2)
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeConstraints:、:= 系列attributeTypeConstarints[0]AttributeTypeConstraints任意であって、attributeValueConstarints[1]AttributeValueConstraints任意です。
Ross, et al. Experimental [Page 32] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[32ページ]RFC3125
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeTypeConstraints:、:= AttributeTypeの系列
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AttributeValueConstraints:、:= AttributeTypeAndValueの系列
AlgorithmConstraintSet ::= SEQUENCE {
-- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- Time-Stamping Authority
}
AlgorithmConstraintSet:、:= 系列--アルゴリズムは以下でsignerAlgorithmConstraints[0]AlgorithmConstraints OPTIONALを抑制します--署名者eeCertAlgorithmConstraints[1]AlgorithmConstraints OPTIONAL--終わりの実体本命caCertAlgorithmConstraints[2]AlgorithmConstraints OPTIONALの発行人--カリフォルニアの発行人がaaCertAlgorithmConstraints[3]AlgorithmConstraints OPTIONAL--属性Authority tsaCertAlgorithmConstraints[4]AlgorithmConstraints OPTIONAL--時間を押し込むAuthorityを証明する
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgorithmConstraints:、:= AlgAndLengthの系列
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}
AlgAndLength:、:= 系列algID OBJECT IDENTIFIER、minKeyLength INTEGER OPTIONAL--、ビットもう一方SignPolExtensions OPTIONALの最小のキー長
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtensions:、:= SignPolExtnの系列
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
SignPolExtn:、:= 系列extnID物の識別子、extnValue八重奏ストリング
END -- ETS-ElectronicPolicies-97Syntax
終わり--ETS-ElectronicPolicies-97Syntax
Ross, et al. Experimental [Page 33] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[33ページ]RFC3125
Annex B (informative):
別館B(有益な):
B.1 Signature Policy and Signature Validation Policy
B.1署名方針と署名合法化方針
The definition of electronic signature mentions: "a commitment has been explicitly endorsed under a "Signature Policy", at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role."
電子署名言及の定義: 「委任が明らかに一時に例えば、識別子、名前の下における署名者による「署名方針」か匿名に、任意に是認された、役割、」
Electronic signatures are commonly applied within the context of a legal or contractual framework. This establishes the requirements on the electronic signatures and any special semantics (e.g., agreement, intent). These requirements may be defined in very general abstract terms or in terms of detailed rules. The specific semantics associated with an electronic signature implied by a legal or contractual framework are outside the scope of this document.
電子署名は法的であるか契約上の枠組みの文脈の中で一般的に適用されます。 これは電子署名とどんな特別な意味論(例えば、協定、意図)に関する要件も確立します。 これらの要件は非常に一般的な抽象名辞か細則で定義されるかもしれません。 このドキュメントの範囲の外に法的であるか契約上の枠組みによって含意される電子署名に関連している特定の意味論があります。
If the signature policy is recognized, within the legal/contractual context, as providing commitment, then the signer explicitly agrees with terms and conditions which are implicitly or explicitly part of the signed data.
署名方針が委任を提供すると法的であるか契約上の文脈の中で認識されるなら、署名者は明らかにそれとなくである明らかに離れているサインされたデータに関する条件に同意します。
When two independent parties want to evaluate an electronic signature, it is fundamental that they get the same result. It is therefore important that the conditions agreed by the signer at the time of signing are indicated to the verifier and any arbitrator. An aspect that enables this to be known by all parties is the signature policy. The technical implications of the signature policy on the electronic signature with all the validation data are called the "Signature Validation Policy". The signature validation policy specifies the rules used to validate the signature.
2回の独立しているパーティーが電子署名を評価したがっているとき、彼らが同じ結果を得るのは、基本的です。 したがって、調印時点で署名者によって同意された状態が検証とどんな仲裁者にも示されるのは、重要です。 これがすべてのパーティーによって知られているのを可能にする局面は署名方針です。 すべての合法化データがある電子署名に関する署名方針の技術的な含意は「署名合法化方針」と呼ばれます。 署名合法化方針は署名を有効にするのに使用される規則を指定します。
This document does not mandate the form and encoding of the specification of the signature policy. However, for a given signature policy there must be one definitive form that has a unique binary encoded value.
このドキュメントは署名方針の仕様のフォームとコード化を強制しません。 しかしながら、あるに違いない与えられた署名方針のために、ユニークなバイナリーを持っている1つの決定的なフォームが値をコード化しました。
This document includes, as an option, a formal structure for signature validation policy based on the use of Abstract Syntax Notation 1 (ASN.1).
このドキュメントはオプションとして抽象的なSyntax Notation1(ASN.1)の使用に基づく署名合法化方針のためのホルマール構造を含んでいます。
Given the specification of the signature policy and its hash value an implementation of a verification process must obey the rules defined in the specification.
署名方針の仕様とそのハッシュ値を考えて、検証の過程の実現は仕様に基づき定義された規則に従わなければなりません。
This document places no restriction on how it should be implemented. Provide the implementation conforms to the conformance requirements as define in section 5 implementation options include:
このドキュメントはそれがどう実行されるべきであるかに関する制限を全く置きません。 提供してください。実現オプションが含むセクション5で以下を定義するとき、実現は順応要件に従います。
Ross, et al. Experimental [Page 34] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[34ページ]RFC3125
A validation process that supports a specific signature policy as identified by the signature policy OID. Such an implementation should conform to a human readable description provided all the processing rules of the signature policy are clearly defined. However, if additional policies need to be supported, then such an implementation would need to be customized for each additional policy. This type of implementation may be simpler to implement initially, but can be difficult to enhance to support numerous additional signature policies.
署名方針OIDによって特定されるように特定の署名方針をサポートする合法化プロセス。 署名方針のすべての処理規則が明確に定義されるなら、そのような実装は人間の読み込み可能な記述に従うべきです。 しかしながら、追加方針が、サポートされる必要があるなら、そのような実装は、それぞれの追加方針のためにカスタム設計される必要があるでしょう。 このタイプの実装は、初めは実装するのが、より簡単であるかもしれませんが、多数の追加署名方針をサポートするために高めるのは難しい場合があります。
A validation process that is dynamically programmable and able to adapt its validation rules in accordance with a description of the signature policy provided in a computer-processable language. This present document defines such a policy using an ASN.1 structure (see 6.1). This type of implementation could support multiple signature policies without being modified every time, provided all the validation rules specified as part of the signature policy are known by the implementation. (i.e., only requires modification if there are additional rules specified).
ダイナミックにプログラマブルであって署名方針の記述によると、合法化規則を適合させることができる合法化プロセスはコンピュータ-「プロセス-可能」言語で提供されました。 この現在のドキュメントは、ASN.1構造を使用することでそのような方針を定義します(6.1を見てください)。 毎回変更されないで、このタイプの実装は、複数の署名が方針であるとサポートするかもしれません、署名方針の一部として指定されたすべての合法化規則が実装によって知られているなら。 (すなわち、指定された付則がある場合にだけ、変更を必要とします。)
The precise content of a signature policy is not mandated by the current document. However, a signature policy must be sufficiently definitive to avoid any ambiguity as to its implementation requirements. It must be absolutely clear under which conditions an electronic signature should be accepted. For this reason, it should contain the following information:
署名方針の正確な内容は現在のドキュメントによって強制されません。 しかしながら、署名方針は実装要件に関してどんなあいまいさも避けることができるくらい決定的でなければなりません。 電子署名を受け入れるべきであるのはどの状態の下で絶対に明確でなければならないか。 この理由で、以下の情報を含むべきです:
* General information about the signature policy which includes:
- a unique identifier of the policy;
- the name of the issuer of the policy;
- the date the policy was issued;
- the field of application of the policy.
* である:署名方針に関する一般情報 - 方針のユニークな識別子。 - 方針の発行人の名前。 - 方針が発行された日付。 - 方針の応用分野。
* The signature verification policy which includes:
- the signing period,
- a list of recognized commitment types;
- rules for Use of Certification Authorities;
- rules for Use of Revocation Status Information;
- rules for Use of Roles;
- rules for use of Time-Stamping and Timing;
- signature verification data to be provided by the
signer/collected by verifier;
- any constraints on signature algorithms and key lengths.
* Other signature policy rules required to meet the objectives of
the signature.
* である:署名照合方針 - 署名の期間--認識された委任のリストはタイプされます。 - Certification AuthoritiesのUseのための規則。 - Revocation Status情報のUseのための規則。 - RolesのUseのための規則。 - Time-押し込むことの使用のための規則とTiming。 - 署名者で提供するか、または検証で集める署名照合データ。 - 署名アルゴリズムとキー長におけるどんな規制。 * 他の署名政策ルールが署名の目的を満たすのが必要です。
Variations of the validation policy rules may apply to different commitment types.
合法化政策ルールの変化は異なった委任タイプに適用されるかもしれません。
Ross, et al. Experimental [Page 35] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[35ページ]RFC3125
B.2 Identification of Signature Policy
署名方針のB.2識別
When data is signed the signer indicates the signature policy applicable to that electronic signature by including an object identifier for the signature policy with the signature. The signer and verifier must apply the rules specified by the identified policy. In addition to the identifier of the signature policy the signer must include the hash of the signature policy, so it can be verified that the policy selected by the signer is the identical to the one being used the verifier.
データが署名されるとき、署名者は署名で署名方針のためのオブジェクト識別子を含んでいることによってその電子署名に適切な署名方針を示します。 署名者と検証は特定された方針で指定された規則を適用しなければなりません。 署名方針に関する識別子に加えて署名者は、署名方針署名者によって選択された方針が使用されるものと同じであることを確かめることができるようにハッシュを含まなければなりません。検証。
A signature policy may be qualified by additional information. This can includes:
署名方針は追加情報によって資格があるかもしれません。 この缶は:
* A URL where a copy of the Signature Policy may be obtained;
* A user notice that should be displayed when the signature is
verified;
* Signature Policyのコピーが入手されるかもしれないURL。 * 署名が確かめられるとき表示されるべきであるユーザ通知。
If no signature policy is identified then the signature may be assumed to have been generated/verified without any policy constraints, and hence may be given no specific legal or contractual significance through the context of a signature policy.
署名方針を全く特定しないなら、署名は、少しも方針規制なしで生成されたか、または確かめられたと思って、したがって、署名方針の文脈を通してどんな特定の法的であるか契約上の意味も与えないかもしれません。
A "Signature Policy" will be identifiable by an OID (Object Identifier) and verifiable using a hash of the signature policy.
「署名方針」は、署名方針のハッシュを使用することでOID(オブジェクトIdentifier)が身元保証可能であって証明可能になるでしょう。
B.3 General Signature Policy Information
B.3の一般署名方針情報
General information should be recorded about the signature policy along with the definition of the rules which form the signature policy as described in subsequent subsections. This should include:
一般情報はその後の小区分で説明されるように署名方針を形成する規則の定義に伴う署名方針に関して記録されるべきです。 これは以下を含むべきです。
* Policy Object Identifier: The "Signature Policy" will be
identifiable by an OID (Object Identifier) whose last component
(i.e., right most) is an integer that is specific to a
particular version issued on the given date.
* Date of issue: When the "Signature Policy" was issued.
* Signature Policy Issuer name: An identifier for the body
responsible for issuing the Signature Policy. This may be used
by the signer or verifying in deciding if a policy is to be
trusted, in which case the signer/verifier must authenticate
the origin of the signature policy as coming from the
identified issuer.
* Signing period: The start time and date, optionally with an end
time and date, for the period over which the signature policy
may be used to generate electronic signatures.
* 政策目的識別子: 最後のコンポーネント(すなわち、まさしく大部分)が与えられた期日に発行された特定のバージョンに特定の整数であるOID(オブジェクトIdentifier)は「署名方針」が身元保証可能になるでしょう。 * 発行日: 「署名方針」が発行されたとき。 * 署名Policy Issuer名: Signature Policyを発行するのに原因となるボディーのための識別子。 これは、署名者によって使用されるか、または決定で方針が信じられるかどうかことであることを確かめているかもしれません、その場合、署名者/検証が特定された発行人から来ると署名方針の発生源を認証しなければなりません。 * 署名の期間: 始めは、調節して、終わりの時間と日付で任意にデートします、署名方針が電子署名を生成するのに使用されるかもしれない期間。
Ross, et al. Experimental [Page 36] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[36ページ]RFC3125
* Field of application: This defines in general terms the general
legal/contract/application contexts in which the signature
policy is to be used and the specific purposes for which the
electronic signature is to be applied.
* 応用分野: これはあいまいな言葉で使用されている署名方針がことである一般法律業務/契約/アプリケーション文脈と適用されている電子署名がことである明確な目標を定義します。
B.4 Recognized Commitment Types
B.4は委任タイプを見分けました。
The signature validation policy may recognize one or more types of commitment as being supported by electronic signatures produced under the security policy. If an electronic signature does not contain a recognized commitment type then the semantics of the electronic signature is dependent on the data being signed and the context in which it is being used.
署名合法化方針は、1つ以上のタイプの委任が安全保障政策の下で起こされた電子署名でサポートすることにされるのであると認めるかもしれません。 電子署名が認識された委任タイプを含んでいないなら、電子署名の意味論は署名されるデータとそれが使用されている文脈に依存しています。
Only recognized commitment types are allowed in an electronic signature.
認識された委任タイプだけが電子署名で許容されています。
The definition of a commitment type includes:
委任タイプの定義は:
* the object identifier for the commitment;
* the contractual/legal/application context in which the
signature may be used (e.g., submission of messages);
* a description of the support provided within the terms of the
context (e.g., proof that the identified source submitted the
message if the signature is created when message submission is
initiated).
* 委任のためのオブジェクト識別子。 * 署名が使用されるかもしれない契約的であるか法的な/アプリケーション文脈(例えば、メッセージの服従)。 * サポートの記述は文脈(例えば、メッセージ提案が開始されるとき、署名が作成されるなら特定されたソースがメッセージを提出したという証拠)の用語以内に提供されました。
The definition of a commitment type can be registered:
委任タイプの定義を登録できます:
* as part of the validation policy;
* as part of the application/contract/legal environment;
* as part of generic register of definitions.
* 合法化方針の一部として。 * アプリケーション/契約/法的環境の一部として。 * 定義に関するジェネリックレジスタの一部として。
The legal/contractual context will determine the rules applied to the signature, as defined by the signature policy and its recognized commitment types, make it fit for purpose intended.
法的であるか契約上の文脈は、それが意図する目的のために署名方針とその認識された委任タイプによって定義されるように署名に適用された規則で合うことを決定するでしょう。
B.5 Rules for Use of Certification Authorities
証明当局の使用のためのB.5規則
The certificate validation process of the verifier, and hence the certificates that may be used by the signer for a valid electronic signature, may be constrained by the combination of the trust point and certificate path constraints in the signature validation policy.
検証の証明書合法化プロセス、およびしたがって、有効な電子署名に署名者によって使用されるかもしれない証明書は署名合法化方針における、信頼ポイントと証明書経路規制の組み合わせで抑制されるかもしれません。
Ross, et al. Experimental [Page 37] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[37ページ]RFC3125
B.5.1 Trust Points
B.5.1信頼ポイント
The signature validation policy defines the certification authority trust points that are to be used for signature verification. Several trust points may be specified under one signature policy. Specific trust points may be specified for a particular type of commitment defined under the signature policy. For a signature to be valid a certification path must exists between the Certification Authority that has granted the certificate selected by the signer (i.e., the used user-certificate) and one of the trust point of the "Signature Validation Policy".
署名合法化方針は署名照合に使用されることになっている証明権威信頼ポイントを定義します。 数個の信頼ポイントが1つの署名方針の下で指定されるかもしれません。 特定の信頼ポイントは署名方針の下で定義された特定のタイプの委任に指定されるかもしれません。 署名が有効であるように、経路がそうしなければならない証明は署名者(すなわち、中古のユーザー証明書)と「署名合法化方針」の信頼ポイントの1つによって選択された証明書を与えた認証局の間に存在しています。
B.5.2 Certification Path
B.5.2証明経路
There may be constraints on the use of certificates issued by one or more CA(s) in the certificate chain and trust points. The two prime constraints are certificate policy constraints and naming constraints:
証明書チェーンと信頼ポイントの1つ以上のカリフォルニアによって発行された証明書の使用には規制があるかもしれません。 2つの主要な規制が、証明書方針規制と規制を命名することです:
* Certificate policy constraints limit the certification chain
between the user certificate and the certificate of the trusted
point to a given set of certificate policies, or equivalents
identified through certificate policy mapping.
* The naming constraints limit the forms of names that the CA is
allowed to certify.
* 証明書方針規制はユーザー証明書と信じられたポイントの証明書の間の証明チェーンを与えられたセットの証明書方針、または証明書方針マッピングを通して特定された同等物に制限します。 * 命名規制はカリフォルニアが公認できる名前のフォームを制限します。
Name constraints are particularly important when a "Signature policy" identifies more than one trust point. In this case, a certificate of a particular trusted point may only be used to verify signatures from users with names permitted under the name constraint.
「署名方針」が1信頼ポイント以上を特定するとき、名前規制は特に重要です。 この場合、特定の信じられたポイントの証明書は、名前の規制という名で受入れにされるのでのユーザから署名について確かめるのに使用されるだけであるかもしれません。
Certificate Authorities may be organized in a tree structure, this tree structure may represent the trust relationship between various CA(s) and the users CA. Alternatively, a mesh relationship may exist where a combination of tree and peer cross-certificates may be used. The requirement of the certificate path in this document is that it provides the trust relationship between all the CAs and the signers user certificate. The starting point from a verification point of view, is the "trust point". A trust point is usually a CA that publishes self-certified certificates, is the starting point from which the verifier verifies the certificate chain. Naming constraints may apply from the trust point, in which case they apply throughout the set of certificates that make up the certificate path down to the signer's user certificate.
証明書Authoritiesは木構造で組織化されるかもしれなくて、この木構造は様々なカリフォルニアとユーザカリフォルニアとの信頼関係を表すかもしれません。 あるいはまた、メッシュ関係は木と同輩の交差している証明書の組み合わせが使用されるかもしれないところに存在するかもしれません。 証明書経路の要件は本書ではすべてのCAsと署名者ユーザー証明書との信頼関係を提供するということです。 検証観点からの出発点は「信頼ポイント」です。 信頼ポイントは通常、自己に公認された証明書を発表するカリフォルニアが検証が証明書チェーンについて確かめる出発点であるということです。 規制を命名するのは信頼ポイントから適用されるかもしれません、その場合、それらが証明書経路を署名者のユーザー証明書まで作る証明書のセットの間中適用します。
Policy constraints can be easier to process but to be effective require the presence of a certificate policy identifier in the certificates used in a certification path.
方針規制は処理するのが、より簡単である場合がありますが、有効に、なるように、証明経路で使用される証明書の証明書方針識別子を存在に要求してください。
Ross, et al. Experimental [Page 38] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[38ページ]RFC3125
Certificate path processing, thus generally starts with one of the trust point from the signature policy and ends with the user certificate. The certificate path processing procedures defined in RFC 2459 section 6 identifies the following initial parameters that are selected by the verifier in certificate path processing:
証明書経路処理、その結果、一般に信頼の1つがある始めはユーザー証明書で署名方針と終わりから指します。 現像処理がRFC2459部6で定義した証明書経路は証明書経路処理で検証によって選択される以下の初期値パラメタを特定します:
* acceptable certificate policies;
* naming constraints in terms of constrained and excluded naming
subtree;
* requirements for explicit certificate policy indication and
whether certificate policy mapping are allowed;
* restrictions on the certificate path length.
* 許容できる証明書方針。 * 強制的で除かれた命名下位木に関する命名規制。 * 明白な証明書方針指示と証明書方針マッピングが許容されているかどうか要件。 * 証明書経路の長さにおける制限。
The signature validation policy identifies constraints on these parameters.
署名合法化方針はこれらのパラメタで規制を特定します。
B.6 Revocation Rules
B.6取消し規則
The signature policy should defines rules specifying requirements for the use of certificate revocation lists (CRLs) and/or on-line certificate status check service to check the validity of a certificate. These rules specify the mandated minimum checks that must be carried out.
署名方針は定義するべきです。証明書失効リスト(CRLs)、そして/または、オンライン証明書状態チェックサービスの使用が証明書の正当性をチェックするという要件を指定しながら、規則を定義します。 これらの規則は行わなければならない強制された最小のチェックを指定します。
It is expected that in many cases either check may be selected with CRLs checks being carried out for certificate status that are unavailable from OCSP servers. The verifier may take into account information in the certificate in deciding how best to check the revocation status (e.g., a certificate extension field about authority information access or a CRL distribution point) provided that it does not conflict with the signature policy revocation rules.
CRLsチェックが証明書状態への外までOCSPサーバから入手できない状態で運ばれている状態で多くの場合どちらのチェックも選択されるかもしれないと予想されます。 検証は署名方針取消し規則と衝突しなければ取消し状態(例えば、権威情報アクセスに関する証明書拡大分野かCRL分配ポイント)を最もよく、チェックする方法を決める際に証明書の情報を考慮に入れるかもしれません。
B.7 Rules for the Use of Roles
役割の使用のためのB.7規則
Roles can be supported as claimed roles or as certified roles using Attribute Certificates.
役割であると主張されるか、または公認された役割としてAttribute Certificatesを使用するとして役割をサポートすることができます。
B.7.1 Attribute Values
B.7.1属性値
When signature under a role is mandated by the signature policy, then either Attribute Certificates may be used or the signer may provide a claimed role attribute. The acceptable attribute types or values may be dependent on the type of commitment. For example, a user may have several roles that allow the user to sign data that imply commitments based on one or more of his roles.
役割の下における署名が署名方針で強制されると、Attribute Certificatesが使用されるかもしれませんか、または署名者は要求された役割の属性を提供するかもしれません。 許容属性タイプか値が委任のタイプに依存しているかもしれません。 例えば、ユーザには、ユーザが彼の役割の1つ以上に基づく委任を含意するデータに署名することができるいくつかの役割があるかもしれません。
Ross, et al. Experimental [Page 39] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[39ページ]RFC3125
B.7.2 Trust Points for Certified Attributes
B.7.2は公認された属性のためにポイントを信じます。
When a signature under a certified role is mandated by the signature policy, Attribute Authorities are used and need to be validated as part of the overall validation of the electronic signature. The trust points for Attribute Authorities do not need to be the same as the trust points to evaluate a certificate from the CA of the signer. Thus the trust point for verifying roles need not be the same as trust point used to validate the certificate path of the user's key.
公認された役割の下における署名が署名方針で強制されるとき、Attribute Authoritiesは、使用されていて、電子署名の総合的な合法化の一部として有効にされる必要があります。 信頼が署名者のカリフォルニアからの証明書を評価するために指すとき、Attribute Authoritiesのための信頼ポイントは同じである必要はありません。 したがって、役割について確かめるための信頼ポイントは信頼ポイントが以前はよくユーザのキーの証明書経路を有効にしていたのと同じである必要はありません。
Naming and certification policy constraints may apply to the AA in similar circumstance to when they apply to CA. Constraints on the AA and CA need not be exactly the same.
命名と証明方針規制は同様の状況でAAにそれらがカリフォルニアに適用する時まで適用されるかもしれません。 AAとカリフォルニアにおける規制はまさに同じである必要はありません。
AA(s) may be used when a signer is creating a signature on behalf of an organization, they can be particularly useful when the signature represents an organizational role. AA(s) may or may not be the same authority as CA(s).
署名者が組織を代表して署名を作成しているとき、AA(s)は使用されるかもしれなくて、署名が組織上の任務を表すとき、それらは特に役に立つ場合があります。 AA(s)はカリフォルニアと同じ権威であるかもしれません。
Thus, the Signature Policy identifies trust points that can be used for Attribute Authorities, either by reference to the same trust points as used for Certification Authorities, or by an independent list.
したがって、Signature PolicyはAttribute Authorities、Certification Authoritiesに使用される同じ信頼ポイントの参照、または独立しているリストで使用できる信頼ポイントを特定します。
B.7.3 Certification Path for Certified Attributes
公認された属性のためのB.7.3証明経路
Attribute Authorities may be organized in a tree structure in similar way to CA where the AAs are the leafs of such a tree. Naming and other constraints may be required on attribute certificate paths in a similar manner to other electronic signature certificate paths.
属性AuthoritiesがカリフォルニアへのAAsがそうである同様の方法で木構造で組織化されるかもしれない、そのような木にページをめくらせます。 命名と他の規制が属性証明書経路で同じように他の電子署名証明書経路に必要であるかもしれません。
Thus, the Signature Policy identify constraints on the following parameters used as input to the certificate path processing:
したがって、Signature Policyは証明書経路処理に入力されるように使用される以下のパラメタで規制を特定します:
* acceptable certificate policies, including requirements for
explicit certificate policy indication and whether certificate
policy mapping is allowed;
* naming constraints in terms of constrained and excluded naming
subtrees;
* restrictions on the certificate path length.
* 明白な証明書方針指示のための要件と証明書方針マッピングが許容されているかどうかを含む許容できる証明書方針。 * 強制的で除かれた命名下位木に関する命名規制。 * 証明書経路の長さにおける制限。
B.8 Rules for the Use of Time-Stamping and Timing
時間の刻印とタイミングの使用のためのB.8規則
The following rules should be used when specifying, constraints on the certificate paths for time-stamping authorities, constraints on the time-stamping authority names and general timing constraints.
指定、証明書経路における時間の刻印当局の規制、時間の刻印権威名と一般的なタイミング規制の規制であるときに、以下の規則は使用されるべきです。
Ross, et al. Experimental [Page 40] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[40ページ]RFC3125
B.8.1 Trust Points and Certificate Paths
B.8.1信頼ポイントと証明書経路
Signature keys from time-stamping authorities will need to be supported by a certification path. The certification path used for time-stamping authorities requires a trustpoint and possibly path constraints in the same way that the certificate path for the signer's key.
時間の刻印当局からの署名キーは、証明経路によってサポートされる必要があるでしょう。 同様に、時間の刻印当局に使用される証明経路がtrustpointとことによると経路規制を必要とする、それ、署名者のキーのための証明書経路。
B.8.2 Time-Stamping Authority Names
B.8.2時間の刻印権威名
Restrictions may need to be placed by the validation policy on the named entities that may act a time-stamping authorities.
制限は、時間の刻印当局を演じるかもしれない命名された実体に関する合法化方針で置かれる必要があるかもしれません。
B.8.3 Timing Constraints - Caution Period
B.8.3タイミング規制--以上と警告してください。
Before an electronic signature may really be valid, the verifier has to be sure that the holder of the private key was really the only one in possession of key at the time of signing. However, there is an inevitable delay between a compromise or loss of key being noted, and a report of revocation being distributed. To allow greater confidence in the validity of a signature, a "cautionary period" may be identified before a signature may be said to be valid with high confidence. A verifier may revalidate a signature after this cautionary signature, or wait for this period before validating a signature.
電子署名が本当に有効になるかもしれない前に、検証は秘密鍵の所有者が本当に署名時点のキーの所持の唯一無二であったのを確信していなければなりません。 しかしながら、感染か注意される、キーの損失と、配布される取消しのレポートの間には、必然の遅れがあります。 署名の正当性における、よりすごい信用を許すために、署名が高い自信によって有効であると言われているかもしれない前に「警告的な期間」は特定されるかもしれません。 検証は、次々とこの警告的な署名を再有効にするか、または署名を有効にする前に、この期間、待つかもしれません。
The validation policy may specify such a cautionary period.
合法化方針はそのような警告的な期間を指定するかもしれません。
B.8.4 Timing Constraints - Time-Stamp Delay
B.8.4タイミング規制--タイムスタンプ遅れ
There will be some delay between the time that a signature is created and the time the signer's digital signature is time-stamped. However, the longer this elapsed period the greater the risk of the signature being invalidated due to compromise or deliberate revocation of its private signing key by the signer. Thus the signature policy should specify a maximum acceptable delay between the signing time as claimed by the signer and the time included within the time-stamp.
署名が作成される時、署名者のデジタル署名が時間によって押し込まれる時の間で何らかの遅れるでしょう。 しかしながら、この経過した期間にリスクが高ければ高いほど、署名者で主要な個人的な署名の感染か慎重な取消しのため無効にされる署名は、より長いです。 したがって、タイムスタンプの中に署名者によって要求される署名時間と時間の間の最大の許容できる遅れを含んでいる場合、署名方針は指定するべきです。
B.9 Rules for Verification Data to be followed
B.9は、Verification Dataが続かれるように統治します。
By specifying the requirements on the signer and verifier the responsibilities of the two parties can be clearly defined to establish all the necessary information.
署名者と検証に関する要件を指定することによって、すべての必要事項を証明するために明確に2回のパーティーの責任を定義できます。
Ross, et al. Experimental [Page 41] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[41ページ]RFC3125
These verification data rules should include:
これらの検証データ規則は以下を含むべきです。
* requirements on the signer to provide given signed attributes;
* requirements on the verifier to obtain additional certificates,
CRLs, results of on line certificate status checks and to use
time-stamps (if no already provided by the signer).
* 考えて、提供する署名者に関する要件は属性に署名しました。 * 追加証明書を入手するという検証に関する要件、CRLs、稼働中の結果は状態チェックと使用にタイムスタンプを証明します(署名者によって既に提供されないなら)。
B.10 Rules for Algorithm Constraints and Key Lengths
アルゴリズム規制とキー長のためのB.10規則
The signature validation policy may identify a set of signing algorithms (hashing, public key, combinations) and minimum key lengths that may be used:
署名合法化方針は1セットの署名アルゴリズム(論じ尽くす公開鍵、組み合わせ)と使用されるかもしれない最小のキー長を特定するかもしれません:
* by the signer in creating the signature;
* in end entity public key Certificates;
* CA Certificates;
* attribute Certificates;
* by the time-stamping authority.
* 署名を作成することにおける署名者で。 * 終わりの実体公開鍵Certificatesで。 * カリフォルニア証明書。 * Certificatesを結果と考えてください。 * 押し込むまでに権威。
B.11 Other Signature Policy Rules
他の署名方針が統治するB.11
The signature policy may specify additional policy rules, for example rules that relate to the environment used by the signer. These additional rules may be defined in computer processable and/or human readable form.
署名方針は追加政策ルール、例えば署名者によって使用される環境に関連する規則を指定するかもしれません。 これらの付則はコンピュータの「プロセス-可能」な、そして/または、人間の読み込み可能なフォームで定義されるかもしれません。
B.12 Signature Policy Protection
B.12署名方針保護
When signer or verifier obtains a copy of the Signature Policy from an issuer, the source should be authenticated (for example by using electronic signatures). When the signer references a signature policy the Object Identifier (OID) of the policy, the hash value and the hash algorithm OID of that policy must be included in the Electronic Signature.
署名者か検証が発行人からSignature Policyのコピーを入手すると、ソースは認証されるべきです(例えば、電子署名を使用することによって)。 署名者が署名方針に参照をつけるとき、Electronic Signatureにその方針の方針のObject Identifier(OID)、ハッシュ値、およびハッシュアルゴリズムOIDを含まなければなりません。
It is a mandatory requirement of this present document that the signature policy value computes to one, and only one hash value using the specified hash algorithm. This means that there must be a single binary value of the encoded form of the signature policy for the unique hash value to be calculated. For example, there may exist a particular file type, length and format on which the hash value is calculated which is fixed and definitive for a particular signature policy.
それは署名保険価額が1まで計算するこの現在のドキュメント、および指定されたハッシュアルゴリズムを使用する1つのハッシュ値だけの義務的な要件です。 これは、ユニークなハッシュ値が計算されるために署名方針のコード化されたフォームのただ一つの2進の値があるに違いないことを意味します。 例えば、ハッシュ値が計算される(特定の署名方針に、修理されていて決定的です)特定のファイルの種類、長さ、および形式は存在するかもしれません。
Ross, et al. Experimental [Page 42] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[42ページ]RFC3125
The hash value may be obtained by:
以下はハッシュ値を得るかもしれません。
the signer performing his own computation of the hash over the
signature policy using his preferred hash algorithm permitted by
the signature policy, and the definitive binary encoded form.
署名方針の上で彼の都合のよいハッシュアルゴリズムを使用することで彼自身のハッシュの計算を実行する署名者は署名方針で可能にしました、そして、決定的なバイナリーはフォームをコード化しました。
the signer, having verified the source of the policy, may use both
the hash algorithm and the hash value included in the computer
processable form of the policy (see section 6.1).
署名者は、方針の源について確かめたので、方針のコンピュータ「プロセス-可能」形に含まれていたハッシュアルゴリズムとハッシュ値の両方を使用するかもしれません(セクション6.1を見てください)。
Ross, et al. Experimental [Page 43] RFC 3125 Electronic Signature Policies September 2001
ロス、他 署名方針2001年9月の電子の実験的な[43ページ]RFC3125
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ross, et al. Experimental [Page 44]
ロス、他 実験的[44ページ]
一覧
スポンサーリンク
