[要約] RFC 3125は、電子署名ポリシーに関するガイドラインであり、電子署名の信頼性とセキュリティを向上させることを目的としています。要約すると、このRFCは電子署名の実装と運用に関するポリシーを提案し、信頼性のある電子文書の交換を促進します。
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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 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. はじめに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証明書の要件11 3.6.2取消要件13 3.7署名証明書信頼条件14 3.8タイムスタンプ信頼条件15 3.9属性信頼条件16 3.10アルゴリズムの制約17 3.11署名ポリシー拡張18 4.セキュリティ考慮事項18 4.1秘密鍵の保護18 4.2アルゴリズムの選択18 5.適合要件19 6.参考文献19 7.著者のアドレス20付録A（規範）：21 A.1 X.208（1988）ASN.1 Syntax 21を使用した定義A.2 X.680を使用した定義（1997）ASN.1構文27付録B（情報）：34 B.1署名ポリシーと署名検証ポリシー34 B.2署名ポリシーの識別36 B.3一般的な署名ポリシー情報36 B B B.4認識されたコミットメントタイプ37 B.5認証当局の使用規則37 B.5.1信託ポイント38 B.5.2認証パス38b.7.2認定属性の信託ポイント40 b.7.3認定属性の認定パス40 b.8タイムスタンピングとタイミングの使用に関するルール40 b.8.1信託ポイントと証明書パスb.8.3タイミング制約 - 注意期間41 b.8.4タイミング制約 - タイムスタンプ遅延41 B.9検証データに従うべき規則41 B.10アルゴリズムの制約とキー長の規則42 B.11その他の署名ポリシールール42b.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.
このドキュメントは、ビジネストランザクション（購入要求、契約、請求書アプリケーションなど）など、さまざまなタイプのトランザクションの電子署名で使用できる署名ポリシーをカバーすることを目的としています。電子署名は、個人と会社の間の任意の取引、2つの企業間、個人と政府機関などの取引に使用できます。この文書は、あらゆる環境とは無関係です。あらゆる環境に適用できます。たとえば、スマートカード、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].
「必須」、「必要」、「必須」、「必要」、「必要はない」、「推奨」、「5月」、および「オプション」（図のように大文字で）は次のとおりです。[RFC2119]で説明されているように解釈されます。
The document uses the following terms:
ドキュメントは次の用語を使用しています。
* the Signature Policy Issuer;
* the Signer;
* the Verifier;
* the Arbitrator;
* Trusted Service Providers (TSP);
*署名ポリシー発行者。
*署名者。
*検証剤;
*仲裁人。
*信頼できるサービスプロバイダー（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）は、署名者と検証者の間の信頼関係を構築するのに役立つ1つ以上のエンティティです。TSP固有のサービスの使用は、署名ポリシーによって義務付けられる場合があります。TSPサポートサービスには、ユーザー証明書、クロス認証、タイムスタンプトークン、CRLS、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.
*認定当局。
*登録当局。
*リポジトリ当局（例：ディレクトリ）;
*タイムスタンピング当局。
* 1行証明書ステータスプロトコルレスポンダー。
*属性当局。
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.
リポジトリ当局は、CASによって発行されたCRLを発行します。
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.
1行の証明書ステータスプロトコルレスポンズ（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.
*電子署名は、署名者が参照する署名ポリシーに従って、署名者と検証者によって処理される必要があります。
*署名者が参照する署名ポリシーは、オブジェクト識別子によって識別可能でなければなりません。
*署名ポリシーの仕様が存在する必要があります。
*特定の署名ポリシーには、一意のバイナリエンコーディングがある仕様の決定的な形式が1つありなければなりません。
*合意されたアルゴリズムを使用した決定的な仕様のハッシュは、署名者によって提供され、検証剤によってチェックされる必要があります。
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フィールドは、1つ以上の一般名フォームでポリシー発行者を識別します。
The fieldofApplication is a description of the expected application of this policy.
Field -Opapplicationは、このポリシーの予想される適用の説明です。
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 ::= 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に存在しない場合、各コミットメントルールに存在する必要があります。
* signerAndVeriferRules;
* signingCertTrustCondition;
* timeStampTrustCondition.
* Signerandveriferrules;
* signingcerttrustCondition;
* TimestAmptrustCondition。
The CommitmentRules consists of the validation rules which apply to given commitment types:
コミットメントルルは、指定されたコミットメントタイプに適用される検証ルールで構成されています。
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 ::= 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.
選択されたCommitmentTypesが「空」を示す場合、このルールはコミットメントタイプが存在しないときに適用されます（つまり、コミットメントのタイプはメッセージのセマンティクスに示されています）。それ以外の場合、電子署名には、CommitmentTypeで言及されているコミットメントタイプの1つに適合する必要があるコミットメントタイプの表示が含まれている必要があります。
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.
Field -OpapplicationおよびSemanticsフィールドは、ポリシーに定義されたアプリケーション全体のフィールド内でのコミットメントの特定の使用と意味を定義します。
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.
* 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
mandatedCertificateInfo [1] CertInfoReq DEFAULT none, -- Mandated Certificate Info signPolExtensions [2] SignPolExtensions OPTIONAL }
MandatedCertificateInfo [1] certinforeqデフォルトなし、 - 義務付けられている証明書情報signpolextensions [2] signpextensionsオプション}
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.
SigningCerttrustCondition、TimestAmptrustCondition、およびAttributetRustContictition（後続のサブセクションで定義）は、以下に定義されている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.
Certificatetetrusttreeは、定義されたRFC 2459 [7]セクション4として、証明書パス処理を開始（または終了）するために使用される（または終了）証明書パス検証の初期条件のセルフ署名証明書のセットを識別します。このASN1構造は、ポリシーを定義するために使用されます。署名証明書、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.
TrustPointフィールドは、証明書パス処理の開始の信頼ポイントとして使用される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フィールドは、TrustPointに続いて認定パスにある可能性のあるCA証明書の最大数を提供します。ゼロの値は、指定されたTrustPoint証明書とエンドエンティティ証明書のみが使用できることを示します。存在する場合、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.
制限は、許可または除外された名前のサブツリーの観点から定義されます。expluedSubtreesフィールドの制限に一致する名前は、許可されたサブツリーに表示される情報に関係なく無効です。
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.
阻害ポリックマッピングフィールドが存在する場合、値は、ポリシーマッピングが許可されなくなる前にパス（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.
rexeexplicitPolicyフィールドが存在する場合、後続の証明書には許容可能なポリシー識別子を含める必要があります。requeseexplicitPolicyの値は、明示的なポリシーが必要になる前に（TrustPointの自己証明書を含む）パスに表示される可能性のある追加の証明書の数を示します。許容可能なポリシー識別子は、認証パスのユーザーが要求するポリシーの識別子またはポリシーマッピングを通じて同等であると宣言されたポリシーの識別子です。
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.
RebocRequirementsフィールドは、CRLSおよび/または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：End証明書（つまり、署名者証明書、属性証明書、またはタイムスタンピング機関証明書）。
* 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.
* clrcheck：現在のCRL（または権限の取り消しリスト）に対してチェックを行う必要があります。
* OCSPCHECK：取り消しステータスは、オンライン証明書ステータスプロトコル（RFC 2450）を使用して確認する必要があります。
* BothCheck：OCSPとCRLの両方のチェックを実行する必要があります。
* CHECHECK：OCSPまたはCRLチェックのいずれかを実行する必要があります。
* NoCheck：チェックは義務付けられていません。
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フィールドは、タイムスタンピング当局の名前のティムスタンピング権限と制約を認証するために使用される証明書パス処理の信頼条件を特定します。これは、すべての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.
ttscertificAtetrusttreeが存在しない場合、証明書の条件で定義されているのと同じルールが、タイムスタンピング当局の公開鍵の認証に適用されます。
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が存在しない場合、ttscertificatetrusttreeによって暗示されているもの以外の信頼できるタイムスタンプ機関に追加の命名制約はありません。
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:
astibutetrustConditionフィールドが存在しない場合、この検証ポリシーでは認定された属性は有効であると見なされない場合があります。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.
属性が真である場合、次の制約内で認定された属性が存在する必要があります。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フィールドは、署名者が「請求」した属性または認定属性（つまり、属性証明書）が属性を指定します。
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.
attrcertificatetrusttreeは、属性証明書の証明書パス条件を指定します。ない場合は、emperimatetetrustConditionと同じルールが適用されます。
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は、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フィールドが存在しない場合、このポリシーで検証される可能性のある属性に制約はありません。AtributeConstraintsフィールドは次のように定義されています。
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.
存在する場合、AtributETYPECONSTRAINTSフィールドは、署名ポリシーで有効と見なされる特定の属性値を指定します。
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.
AlgorithMCがフィールドを制約している場合、存在する場合、特定の目的および最小長さに使用できる署名アルゴリズム（ハッシュ、公開キーの暗号、ハッシュ、および公開キー暗号化の組み合わせ）を識別します。このフィールドが存在しない場合、ポリシーは制約を適用しません。
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.
* セクション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:
これらの署名ポリシールールの拡張は、以下に定義されているように、SINGPOLEXTNに掲載された関連するオブジェクト識別子を使用した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フィールドには、der（ITU-T推奨x.690 [4]を参照）を拡張値のエンコード値を含める必要があります。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 Webサイト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] Pinkas、D.、Ross、J。and N. Pope、「長期電子署名の電子署名形式」、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] Adams、C、Pinkas、D.、Zuccherato、R。、およびP. Cain、「Internet 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] Myers、M.、Ankney、R.、Malpani、R.、Galperin、S。、およびC. Adams、「オンラインステータス証明書プロトコル」、RFC 2560、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、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.、Ford、W.、Polk、W。and D. Solo、「インターネット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、「The Public-Key Cryptography Standards（PKCS）」、RSA Data Security Inc.、Redwood City、California、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
Contact Point
コンタクトポイント
Harri Rasilainen ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex FRANCE
Harri Rasilainen Etsi 650ルートDes Lucioles F-06921 Sophia Antipolis Cedex France
EMail: harri.rasilainen@etsi.fr
John Ross Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom
ジョンロスセキュリティ＆標準192ムルシャムストリートチェルムスフォード、エセックスCM2 0LGイギリス
EMail: ross@secstan.com
Denis Pinkas Integris, Bull. 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE
デニス・ピンカス・インテグリス、ブル。68、ルート・デ・ヴェルサイユ78434ルーベシエンヌ・セデックス・フランス
EMail: Denis.Pinkas@bull.net
Nick Pope Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom EMail: pope@secstan.com
Nick Pope Security＆Standards 192 Moulsham Street Chelmsford、Essex CM2 0LG United Kingdom Email：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構文署名ポリシー定義の参照定義を提供します。
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}
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証明書、アルゴリズム監督、名前、名前、一般名、一般名、ディレクトリストリング、属性、属性、属性、属性、属性、政策情報、bmpstring、utf8stringtring
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)}
;
-- 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
}
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-
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}
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
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)}
;
-- 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 }
signingcerttrustCondition [1] SigningCertTrustConditionオプション、TimestAmpTrustCondition [2] TimestAmpTrustCondition Optional、AttributeTrustCondition Optional、AlgorithMConstraintset [4] AlgorithMConstrintionsオプション[5] SIGNPOLEXTENSION [5] SIGNPOLEXTENSION [5]
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-97SyntaxAnnex B (informative):
End-ETS-ElectronicPolicies-97Syntax Annex B（Informative）：
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).
このドキュメントには、オプションとして、抽象的構文表記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: 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.
このドキュメントは、どのように実装すべきかについて制限を課していません。セクション5の実装オプションで定義するように、適合要件への実装の適合を提供します。このような実装は、署名ポリシーのすべての処理ルールが明確に定義されている場合、人間の読み取り可能な説明に準拠する必要があります。ただし、追加のポリシーをサポートする必要がある場合は、追加のポリシーごとにそのような実装をカスタマイズする必要があります。このタイプの実装は、最初に実装するのが簡単かもしれませんが、多数の追加の署名ポリシーをサポートするために強化するのが難しい場合があります。
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.
* 以下を含む署名検証ポリシー - 署名期間、認められたコミットメントタイプのリスト。 - 認証当局の使用規則。 - 取り消しステータス情報の使用に関する規則。 - 役割の使用規則。 - タイムスタンプとタイミングの使用のルール。 - 署名者/Verifierによって収集された署名検証データ。 - 署名アルゴリズムとキー長の制約。*署名の目的を満たすために必要なその他の署名ポリシールール。
Variations of the validation policy rules may apply to different commitment types.
検証ポリシールールのバリエーションは、さまざまなコミットメントタイプに適用される場合があります。
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;
*署名ポリシーのコピーが取得できる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（オブジェクト識別子）によって識別可能であり、署名ポリシーのハッシュを使用して検証可能です。
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.
* アプリケーションの分野：これは、一般的な用語で、署名ポリシーを使用する一般的な法的/契約/アプリケーションのコンテキストと、電子署名が適用される特定の目的を定義します。
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.
法的/契約上のコンテキストは、署名ポリシーとその認識されたコミットメントタイプで定義されているように、署名に適用される規則を決定し、目的の目的に適合します。
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.
検証者の証明書検証プロセス、したがって、署名者が有効な電子署名に使用できる証明書は、署名検証ポリシーの信頼ポイントと証明書パスの制約の組み合わせによって制約される場合があります。
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つによって認定された認証機関の間に認定パスが存在する必要があります。
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とユーザーの間の信頼関係を表す場合があります。あるいは、ツリーとピアの相互認証の組み合わせが使用される場合があるメッシュ関係が存在する場合があります。このドキュメントの証明書パスの要件は、すべてのCASと署名者ユーザー証明書との間の信頼関係を提供することです。検証の観点からの出発点は、「信頼ポイント」です。信託ポイントは通常、自己認証証明書を公開する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:
したがって、証明書のパス処理は、通常、署名ポリシーからの信頼ポイントの1つから始まり、ユーザー証明書で終了します。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.
署名検証ポリシーは、これらのパラメーターの制約を識別します。
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サーバーから利用できない証明書ステータスのCRLSチェックが実行されると、いずれかのチェックが選択される場合があります。Verifierは、署名ポリシー取消規則と矛盾しない場合、取消しステータス（たとえば、権限の情報アクセスまたはCRL配信ポイントに関する証明書拡張フィールドなど）を確認する最善の方法を決定する際に、証明書の情報を考慮することができます。
Roles can be supported as claimed roles or as certified roles using Attribute Certificates.
役割は、請求された役割として、または属性証明書を使用して認定された役割としてサポートできます。
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.
役割に基づく署名が署名ポリシーによって義務付けられている場合、いずれかの属性証明書を使用するか、署名者が請求された役割属性を提供する場合があります。許容可能な属性タイプまたは値は、コミットメントのタイプに依存する場合があります。たとえば、ユーザーは、1つ以上の役割に基づいてコミットメントを暗示するデータに署名できるいくつかの役割を持つ場合があります。
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から証明書を評価するために信託ポイントと同じである必要はありません。したがって、役割を検証するための信頼ポイントは、ユーザーのキーの証明書パスを検証するために使用されるTrustポイントと同じである必要はありません。
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は、署名者が組織に代わって署名を作成している場合に使用できます。これらは、署名が組織の役割を表す場合に特に役立ちます。AA（s）は、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.
したがって、署名ポリシーは、認証当局に使用されるのと同じ信頼ポイントを参照するか、独立したリストによって、属性当局に使用できる信託ポイントを特定します。
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.
属性当局は、AASがそのような木の葉である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.
*明示的な証明書の指示の要件と、証明書のポリシーマッピングが許可されているかどうかを含む、許容可能な証明書ポリシー。
*制約の制約と除外された命名サブツリーの命名制約。
*証明書パス長の制限。
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.
指定する際には、次のルールを使用する必要があります。時間刻印当局の証明書パスの制約、タイムスタンプ当局名の制約、一般的なタイミングの制約を使用する必要があります。
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.
タイムスタンプ当局からの署名キーは、認証パスによってサポートされる必要があります。タイムスタンプ当局に使用される認証パスには、署名者のキーの証明書パスと同じ方法で、信頼ポイントと場合によってはパスの制約が必要です。
Restrictions may need to be placed by the validation policy on the named entities that may act a time-stamping authorities.
制限は、タイムスタンピング当局を行う可能性のある指定されたエンティティの検証ポリシーによって配置する必要がある場合があります。
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.
検証ポリシーは、そのような注意期間を指定する場合があります。
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.
署名が作成されるまでの遅延と、署名者のデジタル署名がタイムスタンプされるまでの間にあります。ただし、この経過期間が長くなればなるほど、署名者によるプライベート署名キーの妥協または意図的な取り消しにより、署名が無効になるリスクが高くなります。したがって、署名ポリシーは、署名者が主張する署名時間とタイムスタンプ内に含まれる時間の間に最大許容遅延を指定する必要があります。
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.
署名者とVerifierの要件を指定することにより、必要なすべての情報を確立するために、2つの当事者の責任を明確に定義できます。
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、オンライン証明書のステータスチェックの結果を取得し、タイムスタンプを使用するための検証者の要件（署名者が既に提供していない場合）。
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.
*署名者が署名を作成する。
*エンティティの公開証明書。
* CA証明書。
*属性証明書。
*タイムスタンピング当局による。
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.
署名ポリシーは、署名者が使用する環境に関連する規則など、追加のポリシールールを指定する場合があります。これらの追加のルールは、コンピューター加工可能および/または人間の読み取り可能なフォームで定義される場合があります。
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つに計算され、指定されたハッシュアルゴリズムを使用して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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。