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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書では、電子署名のための署名ポリシーを定義します。署名ポリシーは、署名の有効性を決定することができるの下で電子署名の生成及び検証のための規則のセットです。与えられた法的/契約コンテキストは、その要件を満たすように特定の署名ポリシーを認識することができます。
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.
署名ポリシーは、適用された法的及び契約コンテキストの要件を満たすように評価することができるように人間が読める形式で利用可能である必要があります。
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.
電子署名の自動処理を可能にするために、署名ポリシーの別の部分は、コンピュータ処理可能形式で電子署名の生成及び検証のための電子規則を指定します。現在のドキュメントに署名ポリシーのフォーマットは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.
この文書の内容は、ETSI TS 101 733 V.1.2.2（2000-12）、著作権（C）で定義された署名ポリシーに基づいています。このETSIの成果の個々のコピーがhttp://www.etsi.orgからダウンロードすることができます。
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.はじめに3 2.主要政党3 3.署名ポリシー仕様5 3.1総合ASN.1構造体5 3.2署名検証方針6つの3.3共通のルール7つの3.4コミットメントルール8 3.5署名者と検証ルール9つの3.5.1署名者ルール9 3.5.2検証ルール11の3.6証明書及び失効条件11の3.6.1証明書の要件証明書信頼条件14 3.8タイムスタンプ信託条件15の3.9属性信託条件16 3.10アルゴリズム制約17の3.11署名ポリシー拡張18 4の署名11の3.6.2失効要件13 3.7。セキュリティの考慮事項18アルゴリズム18の5.適合要件の秘密鍵18 4.2 Choiceの19 6.参考文献19本の7.著者のアドレス20附属書A（規定）の4.1保護：X.208を使用して21のA.1定義（1988）ASN.1 34 B.1署名ポリシーと署名署名ポリシー36 B.3一般的な署名ポリシーInformatの検証方針34 B.2同定：X.680（1997）ASN.1構文27附属書B（参考）を使用して構文21のA.2定義イオン36 B.4認知されたコミットメントタイプ37 B.5.1トラストは38 B.5.2証明のパス38 B.6失効が役割39 B.7.1の使用のための39のB.7ルールをルールポイント証明機関の利用のための37のB.5ルール認定は、認定のための40 B.7.3証明のパスが40のB.8のタイムスタンプの使用のためのルールとタイミング40個のB.8.1トラストポイントと証明書パス41 B.8.2タイムスタンプ属性の属性の属性は、39個のB.7.2トラストポイント値権限名41のB.8.3タイミング制約 - 41のB.8.4タイミング制約注意期間 - タイムスタンプの検証データの遅延41 B.9ルールが41を踏襲します
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ルールとキーの長さ42のB.11その他の署名ポリシールール42 B.12署名ポリシーの保護42完全な著作権声明44
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.
この文書は、ビジネストランザクション（例えば、購買依頼、契約、および請求書のアプリケーション）を含むトランザクションの様々なタイプのために電子署名とともに使用することができる署名ポリシーをカバーすることを意図しています。電子署名は、この文書では、どのような環境には依存しないなど個人や政府機関の間で、両社の間で、個人と会社との間の取引に使用することができます。これは、例えば、スマートカードは、GSM SIMカード、電子署名のための特別なプログラム等の任意の環境に適用することができます
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、（図示のように、大文字で）この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" は可能になっています[RFC2119]で説明されるように解釈されます。
The document uses the following terms:
文書には、次の用語を使用しています：
* 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.
署名（信頼できるサービスプロバイダである（TSP））方針発行者の問題は、特定のビジネスニーズを満たすために、電子署名の作成、および妥当性確認/検証のための技術的および手続き上の要件を定義するポリシーをシグネチャ。
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.
検証は、それが単一のエンティティまたは複数のエンティティであってもよいし、電子署名を検証するエンティティです。署名が有効であるために検証者は、電子署名ポリシーによって定義されたルールの下で電子署名を検証しなければなりません。
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.
信頼できるサービスプロバイダー（TSPのは）署名者と検証の間に信頼関係を構築するのに役立つ一つ以上のエンティティです。 TSP特定のサービスの利用には、署名ポリシーによって義務付けられるかもしれません。 TSPのサポートサービスが含まれます：ユーザー証明書、クロス証明書、タイムスタンプトークン、CRLを、ARLs、OCSP応答を。
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.
信頼できるサービスプロバイダー（TSPの）は、署名ポリシー発行できるような、TSPは、特定のビジネスニーズを満たすために、電子署名の作成と検証のための技術的および手続き上の要件を定義しなければなりません。
The following other TSPs are used to support the functions defined in this document:
以下の他のTSPは、このドキュメントで定義された関数をサポートするために使用されています。
* 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.
認証機関は、公開鍵証明書をユーザーに提供します。
Registration Authorities allows the registration of entities before a CA generates certificates.
CAが証明書を生成する前に、登録機関は、エンティティの登録を可能にします。
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.
リポジトリ当局は、CAによって発行されたCAによって発行されたCRL、相互認証（即ち、CA証明書）、署名ポリシー発行者および必要に応じて公開鍵証明書のCAによって発行された（すなわち、リーフ証明書）によって発行された署名ポリシーを発行します。
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.
ワンライン証明書状態プロトコルレスポンダ（OSCPレスポンダ）は、特定の証明書の状態（すなわち、取り消され、失効していない、未知の）に関する情報を提供します。
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.
仲裁人は署名者と検証者との間の紛争を調停エンティティです。
A signature policy specification includes general information about the policy, the validation policy rules and other signature policy information.
署名ポリシーの仕様は、一般的なポリシーに関する情報、検証ポリシールール及び他の署名ポリシー情報を含みます。
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.
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.
*人間の解釈のための自由形式の文書で、または*構造化形で合意された構文とエンコーディングを使用しました。
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.
この文書は、構造化署名ポリシーを定義するために使用することができるASN.1ベースの構文を定義します。このドキュメントの将来のバージョンでは、XMLを使用して署名ポリシーの仕様を構造化含むことができます。
The overall structure of a signature policy defined using ASN.1 is given in this section. Use of this ASN.1 structure is optional.
ASN.1を使用して定義された署名ポリシーの全体的な構造は、このセクションに記載されています。このASN.1構造の使用はオプションです。
This ASN.1 syntax is encoded using the Distinguished Encoding Rules (DER).
このASN.1構文は、識別符号化規則（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.
この構造では、ポリシー情報を再計算し、署名ポリシーは、発行者と署名/検証の間を通過するたびにチェックされなければならないハッシュ値によって署名ポリシーを保護するために使用され、続いてハッシュアルゴリズムの識別子が先行します。
The hash is calculated without the outer type and length fields.
ハッシュは、外型と長さフィールドなしで計算されます。
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
The policyIssuerName field identifies the policy issuer in one or more of the general name forms.
policyIssuerNameフィールドは、一般的な名前形式の一つ以上のポリシー発行者を識別します。
The fieldofApplication is a description of the expected application of this policy.
fieldofApplicationは、このポリシーの予想されるアプリケーションの説明です。
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.
signPolExtensionsは、署名ポリシーの任意のサブコンポーネントの定義を拡張するための一般的な方法です。
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:
次のように署名検証ポリシーが記載されています。
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.
signingPeriod日付と時刻署名ポリシーは、署名を作成するために使用されるべきではない前に、それが署名を作成するために使用すべきではない、その後の任意の日付を識別する。
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
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
}
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.
The CommitmentRules consists of the validation rules which apply to given commitment types:
CommitmentRulesは、与えられたコミットメントタイプに適用検証ルールで構成されています。
CommitmentRules ::= SEQUENCE OF 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
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty 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.
具体的なコミットメントタイプ識別子は、複数のコミットメントルールに現れてはなりません。
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
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と意味論の分野では、ポリシーのために定義されたアプリケーションの全体的なフィールド内のコミットメントの特定の使用と意味を定義します。
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 }
The signer rules identify:
署名者のルールは、特定します：
* if the eContent is empty and the signature is calculated using a hash of signed data external to CMS structure.
* e-コンテンツは空であり、署名は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
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
CMSattrs ::= SEQUENCE OF OBJECT IDENTIFIER
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)
-- 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.
mandatedCertificateInfoフィールドは、トラストポイントへの署名者の証明書、または証明のパスにあるすべての証明書がSignedDataの証明書の欄に署名者によって提供されなければならないかどうかを識別する。
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
}
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
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
The SigningCertTrustCondition, TimestampTrustCondition and AttributeTrustCondition (defined in subsequent sub-sections) make use of two ASN1 structures which are defined below: CertificateTrustTrees and CertRevReq.
CertificateTrustTreesとCertRevReq：（次のサブセクションで定義）SigningCertTrustCondition、TimestampTrustConditionとAttributeTrustConditionは以下に定義されている2つのASN1構造を利用します。
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 [7]セクション4.このASN1構造はのためのポリシーを定義するために使用される定義されたRFC 2459のように証明書パス処理及び認証パス検証のための初期条件を開始（または終了）するために使用されるトラストポイントの自己署名証明書のセットを識別する署名証明書、TSAの証明書と属性証明書を検証します。
CertificateTrustTrees ::= SEQUENCE OF 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 }
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.
トラストポイントフィールドは、証明書パス処理の開始の信頼点として使用されるCAの自己署名証明書を与えます。
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フィールドは、トラスト以下認証パスであってもよく、CA証明書の最大数を与えます。ゼロの値は、与えられたトラストポイント証明書とエンドエンティティ証明書を使用することができることを示しています。存在する場合、pathLenConstraintフィールドはゼロ以上でなければなりません。 pathLenConstraintが存在しない場合、認証パスの許容長さに制限はありません。
PathLenConstraint ::= INTEGER (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
CertPolicyId ::= OBJECT IDENTIFIER
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 }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (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.
2つの方法でポリシー制約拡張制約パス処理。ポリシーマッピングを禁止するために使用されるか、またはパス内の各証明書が許容可能なポリシー識別子を含むことを必要とすることができます。
The policyConstraints field, if present specifies requirement for explicit indication of the certificate policy and/or the constraints on policy mapping.
PolicyConstraintsのフィールド、現在は、証明書ポリシーおよび/またはポリシーマッピングの制約の明示的な指示のための要件を指定している場合。
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (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フィールドが存在する場合、値は、ポリシーマッピングはもはや許可される前に（トラストポイントの自己証明書を含む）のパスに表示されないことがあり、追加の証明書の数を示します。例えば、一つの値は、ポリシーマッピングがこの証明書のサブジェクトによって発行された証明書で処理ではなく、パスに追加の証明書であってもよいことを示しています。
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の値は、明示的なポリシーが要求される前（トラストポイントの自己証明書を含む）のパスに表示される場合があり、追加の証明書の数を示します。許容されるポリシー識別子は、認証パスのユーザまたはポリシーマッピングを介して等価宣言されたポリシーの識別子によって必要とされるポリシーの識別子です。
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フィールドは、証明書の失効ステータスを確認するに使用するのCRLおよび/またはOCSPの応答によって得られた失効情報の最小要件を、指定します。このASN1構造は、署名証明書、TSAの証明書と属性証明書を検証するためのポリシーを定義するために使用されます。
CertRevReq ::= SEQUENCE {
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：CA証明書。
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
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].
タイムスタンプ局（TSA）は、データが特定の時点で存在していたことを示すためのタイムスタンプトークンを作成し、信頼できるサードパーティです。 [TSP]を参照してください。
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
}
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.
The SigningCertTrustCondition field identifies trust conditions for certificate path processing used to validate the signing certificate.
SigningCertTrustConditionフィールドは、署名証明書を検証するために使用される証明書パス処理のために信頼条件を識別する。
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
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 }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
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中に存在しなければならないタイムスタンプの失効状態を確認に使用するのCRLおよび/または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フィールドは、検証者が署名者のキーの有効性の高い保証を得るために待つ必要があり義務付けされ、任意の関連取消しが通知されたことを署名時間後の注意期間を指定します。完全な検証データと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 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フィールドは、署名時間および署名タイムスタンプの時刻との間の最大許容時間を指定し、ESタイムスタンプを形成するために使用されるように、検証のために作成されます。署名タイムスタンプがsignatureTimestampDelayに与えられた値よりも多くすることにより、署名時刻属性の時間という以降の場合、署名は無効と見なされなければなりません。
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 }
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がtrueの場合は、以下の制約の中で認定属性が、存在しなければなりません。何の属性が指定されていない場合はfalseの場合、署名はまだ有効です。
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フィールドは属性未認証の属性かどうかを指定する署名者が「請求」、または認定された属性（すなわち、属性証明書）、またはいずれかの署名を使用して[ES-FORMATS]セクション3.12.3で定義された属性を属性。
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (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は、属性証明書の失効状態を確認に使用する、のCRLおよび/または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フィールドが定義されています。
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
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
If present, the attributeTypeConstraints field specifies the specific attribute values which are considered valid under the signature policy.
存在する場合、attributeTypeConstraintsフィールドには、署名ポリシーの下で有効と考えられている特定の属性値を指定します。
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
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
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}
An Attribute Authority (AA)is authority which assigns privileges by issuing attribute certificates
属性認証局（AA）、属性証明書を発行することにより、権限を割り当て権威であります
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.
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
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
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フィールドは、拡張の符号化された値（[4] ITU-T勧告X.690参照）DERを含んでいなければなりません。 extnIDによって識別される拡張の定義は、拡張の構文とセマンティクスの定義を含める必要があります。
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.
この文書で定義された電子署名メカニズムのセキュリティは、署名者の秘密鍵のプライバシーに依存します。実装は秘密鍵が危殆化することができないことを保証するための措置をとる必要があります。
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 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.
実装者は、暗号化アルゴリズムは、時間とともに弱くなることに注意する必要があります。新しい暗号解読技術が開発され、コンピューティング性能が向上しているように、特定の暗号アルゴリズムを破る仕事率が低下します。したがって、暗号アルゴリズムの実装を容易に挿入するモジュラー可能新しいアルゴリズムであるべきです。これは、実装者は、時間の経過とともに変化するアルゴリズムを実装するために必須のセットのために準備されるべきです。
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.
署名者と検証者システムは、セクション3を参照して、オブジェクト識別子により識別可能な参照署名ポリシー署名ポリシーの仕様に応じて、電子署名を処理できなければなりません。
[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標準TS 101 733 V.1.2.2（2000-12）電子署名フォーマット。注意：ETSI TS 101 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-FORMATS]ピンカス、D.、ロス、J.およびN.ポープ、 "長期電子署名する電子署名フォーマット"、RFC 3126、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.
[TSP]アダムス、C、ピンカス、D.、Zuccherato、R.とP.カイン、 "インターネットX.509公開鍵インフラストラクチャタイムスタンププロトコル（TSP）"、RFC 3161、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.、Galperin、S.、およびC.アダムス、 "オンラインステータス認証プロトコル"、RFC 2560、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、 "S / MIMEのためのセキュリティサービスの強化"、RFC 2634、1999年6月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、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.およびD.ソロ、 "インターネットX.509公開鍵インフラストラクチャ、証明書とCRLプロファイル、" RFC 2459、1999年1月。
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release.
[PKCS9] RSA Laboratories社、 "公開鍵暗号規格（PKCS）"、RSAデータセキュリティ社は、カリフォルニア州レッドウッド・シティ、1993年11月リリース。
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997.
[ISONR] ISO / IEC 10181から5：オープンシステムのセキュリティフレームワーク。否認防止の枠組み。 1997年4月。
This Experimental RFC has been produced in ETSI TC-SEC.
この実験的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ソフィアアンティポリス、セデックス - FRANCE 650ルートデLucioles - ソフィアアンティポリスヴァルボンヌ - FranceTel：+33 4 92 94 42 00ファックス：+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 ETSI 650ルートデLucioles F-06921ソフィアアンティポリスセデックスFRANCE
EMail: harri.rasilainen@etsi.fr
メールアドレス：harri.rasilainen@etsi.fr
John Ross Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom
ジョン・ロスセキュリティ・規格192 Moulshamストリートチェルムズフォード、エセックスCM2 0LGイギリス
EMail: ross@secstan.com
メールアドレス：ross@secstan.com
Denis Pinkas Integris, Bull. 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE
デニスピンカスIntegris、ブル。 68、ルート・ド・ベルサイユ78434ルーヴシエンヌFRANCE 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
ニック・ポープセキュリティ・規格192 Moulshamストリートチェルムズフォード、エセックスCM2 0LGイギリスメールアドレス：pope@secstan.com
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.1定義この附属書は、この文書で定義された新しい構文のASN.1構文署名ポリシーの定義の参照定義を提供します。
A.1 Definitions Using X.208 (1988) ASN.1 Syntax
A.1定義X.208（1988）ASN.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.1モジュールは、矛盾する場合には、附属書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-88syntax {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）ID-MOD（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プロフィール：RFC 2560証明書、のAlgorithmIdentifier、CertificateListの、名前、GeneralNames、のGeneralName、DirectoryString、属性、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)} ;
PKIX1Explicit88 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-明示-88（1）} FROM ;
-- Signature Policy Specification
-- ==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName, fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions
OPTIONAL
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
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
}
CommitmentRules ::= SEQUENCE OF 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
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE {
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}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust point required
}
｝
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 }
なし（0）、 - いいえ必須要件はsignerOnly（1）、 - 署名者の証明書への参照のみを義務付けていないをフルパス（2） - 義務信頼ポイントへの完全な証明書パスアップのための参考文献を}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
CertificateTrustTrees ::= SEQUENCE OF 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 }
PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL, inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
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
}
SigningCertTrustCondition ::= SEQUENCE {
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 }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER, deltaHours INTEGER,
deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF 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
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits other
SignPolExtensions OPTIONAL
}
｝
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
END -- ETS-ElectronicSignaturePolicies-88syntax --
END - ETS-ElectronicSignaturePolicies-88syntax -
A.2 Definitions Using X.680 1997 ASN.1 Syntax
X.680 1997 ASN.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-97Syntax {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）ID-MOD（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プロフィール：RFC 2560証明書、のAlgorithmIdentifier、CertificateListの、名前、GeneralNames、のGeneralName、DirectoryString、属性、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)} ;
PKIX1Explicit93 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）NID-pkix1-明示-88（1）} ;
-- S/MIME Object Identifier arcs used in the present document
-- ==================================================================
-- 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 Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules
-- 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
-- ==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
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
}
CommitmentRules ::= SEQUENCE OF 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
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE {
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
}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust
-- point required
}
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
}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
CertificateTrustTrees ::= SEQUENCE OF 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 }
PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
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
}
SigningCertTrustCondition ::= SEQUENCE {
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 }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF 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
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
END -- ETS-ElectronicPolicies-97Syntax
END - ETS-電子方針-97構文
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.
二つの独立した当事者が電子署名を評価したい場合には、彼らが同じ結果を得ることを基本です。署名時の署名者によって合意された条件を検証し、任意の仲裁人に指示されていることが重要です。すべての当事者によって知られるように、これを有効に側面は、署名ポリシーです。すべての検証データと電子署名の署名ポリシーの技術的な意味は「署名確認ポリシー」と呼ばれています。署名検証ポリシーは、署名を検証するために使用されるルールを指定します。
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.
この文書は、署名ポリシーの仕様の形式とエンコーディングを強制しません。しかし、与えられた署名ポリシーに一意のバイナリ符号化された値を有するもの決定的な形態が存在しなければなりません。
This document includes, as an option, a formal structure for signature validation policy based on the use of Abstract Syntax Notation 1 (ASN.1).
この文書は、オプションで、抽象構文記法1（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つの実装オプションには、セクションで定義したよう適合性要件に準拠して実装を提供します
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.
Variations of the validation policy rules may apply to different commitment types.
検証ポリシールールのバリエーションはさまざまなコミットメントタイプに適用される場合があります。
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;
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（オブジェクト識別子）と検証によって識別可能であろう。
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（オブジェクト識別子）によって識別可能であろう。 *発行日：「署名ポリシーは、」発行されました。 *署名ポリシー発行者名：署名ポリシーを発行するボディのための識別子。これは、署名者によって使用されるか、またはポリシーは、署名/検証が特定の発行者から来たように署名ポリシーの起源を認証する必要がある場合には、信頼すべきかどうかを決定するに検証することができます。 *署名期間：開始日時、必要に応じて署名ポリシーは、電子署名を生成するために使用することができるれる期間の終了日時を有します。
* 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.
検証者の証明書検証プロセス、ひいては有効な電子署名のための署名者によって使用することができる証明書は、署名検証ポリシーのトラストポイントと認証パス制約の組み合わせによって制約されてもよいです。
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".
署名検証ポリシーは、署名検証のために使用される認証局のトラスト・ポイントを定義します。いくつかのトラスト・ポイントは、一つの署名ポリシーで指定されてもよいです。特定のトラスト・ポイントは、署名ポリシーの下で定義されたコミットメントの特定のタイプに指定されてもよいです。署名証明書パス有効であるためには、署名者（すなわち、使用するユーザ証明書）と「署名検証方針」の信頼ポイントのいずれかで選択した証明書を付与した認証局との間に存在しなければなりません。
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つまたは複数のCA（複数可）によって発行された証明書の使用上の制約があるかもしれません。 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.
*証明書ポリシーの制約は、ユーザ証明書と証明書ポリシーマッピングを介して識別された証明書ポリシー、または同等物の所与のセットに信頼ポイントの証明書の間の証明書チェーンを制限します。 *名前の制約は、CAが証明するために許可されている名前の形式を制限します。
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.
「署名ポリシーは、」複数のトラストポイントを特定する際に名前の制約が特に重要です。この場合には、特定の信頼されたポイントの証明書は、名前制約の下で許可された名前のユーザーからの署名を検証するために使用されてもよいです。
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.
認証局は、ツリー構造で編成することができる、このツリー構造は、さまざまなCA（S）と、ユーザのCA間の信頼関係を表すことができますあるいは、メッシュ関係ツリーとピア相互認証の組み合わせを使用することができる場合に存在してもよいです。この文書に記載されている証明書パスの要件は、それがすべてのCAと署名者のユーザ証明書との信頼関係を提供することです。ビューの検証ポイントからの出発点は、「信頼ポイント」です。トラストポイントは、通常、自己認定証明書を発行し、検証は、証明書チェーンを検証し、そこからの出発点であるCAです。制約に名前を付けると、彼らは署名者のユーザー証明書までの証明書パスを構成する証明書のセット全体に適用された場合には、トラストポイントから適用される場合があります。
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.
ポリシーの制約は、処理するために、より簡単にすることができますが有効であることが証明のパスに使用される証明書で証明書ポリシー識別子の存在を必要とします。
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:
証明書パス処理は、従って、一般に署名ポリシーからトラストポイントのいずれかで開始し、ユーザ証明書で終わります。 RFC 2459で定義された証明書パス処理手順部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.
署名ポリシーは、証明書の有効性を確認する証明書失効リスト（CRL）および/またはオンライン証明書ステータス確認サービスを使用するための要件を指定するルールを定義しなければなりません。これらのルールは実行されなければならない義務最低限のチェックを指定します。
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.
多くの場合、チェックのいずれかが、OCSPサーバーから使用できない証明書ステータスのために行われたCRLのチェックを選択することができることが期待されます。検証者は、失効状態（機関情報アクセスや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.
役割は、特許請求の役割として、または属性証明書を使用して認定された役割としてサポートすることができます。
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.
役割の下の署名が署名ポリシーによって義務付けられている場合は、その属性証明書のいずれかを使用することができるか、署名者が主張role属性を提供することができます。許容可能な属性タイプまたは値はコミットメントの種類に依存してもよいです。例えば、ユーザは、ユーザが自分の役割の一つ以上に基づいて約束を意味するものではデータに署名することを可能にするいくつかの役割を有することができます。
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.
認定ロールの下の署名が署名ポリシーによって義務付けられている場合には、当局が使用されている属性と電子署名の全体的な検証の一環として検証する必要があります。属性機関のためのトラストポイントは、署名者のCAから証明書を評価するトラストポイントと同じである必要はありません。このように検証する役割のトラストポイントは、ユーザーのキーの証明書パスを検証するために使用するトラストポイントと同じである必要はありません。
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.
ネーミングと認証ポリシーの制約は、彼らがCAに適用する場合と同様の状況でAAに適用される場合がありますAAとCA上の制約がまったく同じである必要はありません。
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（複数可）またはCA（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.
したがって、署名ポリシーは、属性機関のため、いずれかの認証局のために用いたのと同じトラスト・ポイントを参照することによって、または独立したリストで使用することができるトラスト・ポイントを識別する。
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.
当局はのAAは、このようなツリーの葉あるCAと同じように、ツリー構造で編成することができる属性。命名及び他の制約は、他の電子署名証明書パスと同様に、属性証明書パスに必要とされ得ます。
Thus, the Signature Policy identify constraints on the following parameters used as input to the certificate path processing:
したがって、署名ポリシーは、証明書パス処理への入力として使用される次のパラメータに対する制約を識別する。
* 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.
タイムスタンプ局の証明書パス上、制約を指定するときは、次の規則が、タイムスタンプ機関名と一般的なタイミング制約上の制約を使用する必要があります。
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.
タイムスタンプ局から署名鍵は、証明書パスでサポートされる必要があります。タイムスタンプ当局に使用する証明書パスは、署名者の鍵の証明書のパスと同じように、トラストポイントとおそらくパス制約が必要です。
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ルールに従うことにします
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.
署名者と検証上の要件を指定することにより、両当事者の責任が明確に必要なすべての情報を確立するために定義することができます。
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).
*与えられた署名の属性を提供するために、署名者の要件。 *検証に関する要件は、追加の証明書、CRLを、ライン証明書ステータスチェックでの結果を得て、（何既に署名者によって提供された場合）、タイムスタンプを使用しないこと。
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:
署名検証ポリシーは、署名アルゴリズム（ハッシュ、公開鍵、組み合わせ）とを使用することができる最小の鍵長の組を識別することができます。
* by the signer in creating the signature;
* in end entity public key Certificates;
* CA Certificates;
* attribute Certificates;
* by the time-stamping authority.
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.
署名者または検証者は、発行者から署名ポリシーのコピーを取得すると、ソース（電子署名を用いて、例えば）に認証されなければなりません。署名者は、ポリシーの署名ポリシーオブジェクト識別子（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を計算し、そして唯一のハッシュ値が指定されたハッシュアルゴリズムを使用して、この本文書の必須要件です。これは、計算する固有のハッシュ値に対する署名ポリシーの符号化された形式の単一のバイナリ値が存在しなければならないことを意味します。例えば、ハッシュ値は、特定の署名ポリシーのための固定および決定的である計算された特定のファイルタイプ、長さおよびフォーマットが存在してもよいです。
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を参照）に含まれるハッシュ値の両方を使用することができます。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。