[要約] RFC 5698は、暗号アルゴリズムのセキュリティ適合性のためのデータ構造（DSSC）に関する要約と目的を提供します。このRFCの目的は、セキュリティ要件を満たすための暗号アルゴリズムの選択と評価を支援することです。
Network Working Group T. Kunz
Request for Comments: 5698 Fraunhofer SIT
Category: Standards Track S. Okunick
pawisda systems GmbH
U. Pordesch
Fraunhofer Gesellschaft
November 2009
Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)
暗号アルゴリズム（DSSC）のセキュリティ適合性のためのデータ構造
Abstract
概要
Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future.
暗号アルゴリズムは長年にわたって弱体化する可能性があるため、セキュリティの適合性を評価する必要があります。データに署名または検証するとき、またはデータを暗号化または復号するときは、これらの評価を考慮する必要があります。このドキュメントでは、過去、現在、または将来の特定の時点における特定の暗号化アルゴリズムのセキュリティ適合性の自動分析を可能にするデータ構造を指定します。
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eで説明されているように、簡略化されたBSDライセンスのテキストが含まれている必要があり、BSDライセンスで説明されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Motivation .................................................4
1.2. Terminology ................................................5
1.2.1. Conventions Used in This Document ...................5
1.3. Use Cases ..................................................5
2. Requirements and Assumptions ....................................5
2.1. Requirements ...............................................6
2.2. Assumptions ................................................6
3. Data Structures .................................................7
3.1. SecuritySuitabilityPolicy ..................................7
3.2. PolicyName .................................................8
3.3. Publisher ..................................................9
3.4. PolicyIssueDate ............................................9
3.5. NextUpdate .................................................9
3.6. Usage ......................................................9
3.7. Algorithm ..................................................9
3.8. AlgorithmIdentifier .......................................10
3.9. Evaluation ................................................10
3.10. Parameter ................................................11
3.11. Validity .................................................12
3.12. Information ..............................................12
3.13. Signature ................................................12
4. DSSC Policies ..................................................13
5. Definition of Parameters .......................................13
6. Processing .....................................................14
6.1. Inputs ....................................................14
6.2. Verify Policy .............................................14
6.3. Algorithm Evaluation ......................................15
6.4. Evaluation of Parameters ..................................15
6.5. Output ....................................................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................18
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................24
Appendix A. DSSC and ERS .........................................27
A.1. Verification of Evidence Records Using DSSC
(Informative) .............................................27
A.2. Storing DSSC Policies in Evidence Records (Normative) .....27
Appendix B. XML Schema (Normative) ...............................28
Appendix C. ASN.1 Module in 1988 Syntax (Informative) ............30
Appendix D. ASN.1 Module in 1997 Syntax (Normative) ..............32
Appendix E. Example ..............................................34
Digital signatures can provide data integrity and authentication. They are based on cryptographic algorithms that are required to have certain security properties. For example, hash algorithms must be resistant to collisions, and in case of public key algorithms, computation of the private key that corresponds to a given public key must be infeasible. If algorithms lack the required properties, signatures could be forged, unless they are protected by a strong cryptographic algorithm.
デジタル署名は、データの整合性と認証を提供します。これらは、特定のセキュリティプロパティを必要とする暗号化アルゴリズムに基づいています。たとえば、ハッシュアルゴリズムは衝突に対して耐性がなければならず、公開鍵アルゴリズムの場合、特定の公開鍵に対応する秘密鍵の計算は実行不可能でなければなりません。アルゴリズムに必要なプロパティがない場合、強力な暗号化アルゴリズムで保護されていない限り、署名が偽造される可能性があります。
Cryptographic algorithms that are used in signatures shall be selected to resist such attacks during their period of use. For signature keys included in public key certificates, this period of use is the validity period of the certificate. Cryptographic algorithms that are used for encryption shall resist such attacks during the period it is planned to keep the information confidential.
署名で使用される暗号アルゴリズムは、その使用期間中のそのような攻撃に対抗するように選択されるものとします。公開鍵証明書に含まれる署名鍵の場合、この使用期間は証明書の有効期間です。暗号化に使用される暗号化アルゴリズムは、情報の機密を保持するように計画されている間、このような攻撃に抵抗します。
Only very few algorithms satisfy the security requirements. Besides, because of the increasing performance of computers and progresses in cryptography, algorithms or their parameters become insecure over the years. The hash algorithm MD5, for example, is unsuitable today for many purposes. A digital signature using a "weak" algorithm has no probative value, unless the "weak" algorithm has been protected by a strong algorithm before the time it was considered to be weak. Many kinds of digital signed data (including signed documents, timestamps, certificates, and revocation lists) are affected, particularly in the case of long-term archiving. Over long periods of time, it is assumed that the algorithms used in signatures become insecure.
セキュリティ要件を満たすアルゴリズムはほとんどありません。さらに、コンピューターのパフォーマンスの向上と暗号化の進歩により、アルゴリズムまたはそのパラメーターは長年にわたって安全ではなくなります。たとえば、ハッシュアルゴリズムMD5は、今日の多くの目的には適していません。 「弱い」アルゴリズムを使用するデジタル署名は、弱いと見なされる前に「弱い」アルゴリズムが強力なアルゴリズムによって保護されていない限り、証拠的な価値はありません。特に長期間のアーカイブの場合、多くの種類のデジタル署名付きデータ（署名付きドキュメント、タイムスタンプ、証明書、失効リストを含む）が影響を受けます。長期間にわたって、署名で使用されるアルゴリズムが安全でなくなることが想定されます。
For this reason, it is important to periodically evaluate an algorithm's fitness and to consider the results of these evaluations when creating and verifying signatures, or when maintaining the validity of signatures made in the past. One result is a projected validity period for the algorithm, i.e., a prediction of the period of time during which the algorithm is fit for use. This prediction can help to detect whether a weak algorithm is used in a signature and whether that signature has been properly protected in due time by another signature made using an algorithm that is suitable at the present point of time. Algorithm evaluations are made by expert committees. In Germany, the Federal Network Agency annually publishes evaluations of cryptographic algorithms [BNetzAg.2008]. Examples of other European and international evaluations are [ETSI-TS102176-1-2005] and [NIST.800-57-Part1.2006].
このため、アルゴリズムの適合性を定期的に評価し、これらの評価の結果を、署名を作成および検証するとき、または過去に作成された署名の有効性を維持するときに考慮することが重要です。 1つの結果は、アルゴリズムの予測有効期間、つまり、アルゴリズムが使用に適している期間の予測です。この予測は、弱いアルゴリズムが署名で使用されているかどうか、およびその署名が現時点で適切なアルゴリズムを使用して作成された別の署名によって期限内に適切に保護されているかどうかを検出するのに役立ちます。アルゴリズムの評価は専門委員会によって行われます。ドイツでは、連邦ネットワーク庁が毎年暗号アルゴリズムの評価を公開しています[BNetzAg.2008]。他のヨーロッパおよび国際的な評価の例は、[ETSI-TS102176-1-2005]および[NIST.800-57-Part1.2006]です。
These evaluations are published in documents intended to be read by humans. Therefore, to enable automated processing, it is necessary to define a data structure that expresses the content of the evaluations. This standardized data structure can be used for publication and can be interpreted by signature generation and verification tools. Algorithm evaluations are pooled in a security suitability policy. In this document, a data structure for a security suitability policy is specified. Therefore, the document provides a framework for expressing evaluations of cryptographic algorithms. This document does not attempt to catalog the security properties of cryptographic algorithms. Furthermore, no guidelines are made about which kind of algorithms shall be evaluated, for example, security suitability policies may be used to evaluate public key and hash algorithms, signature schemes, and encryption schemes.
これらの評価は、人間が読むことを目的としたドキュメントで公開されます。したがって、自動処理を可能にするためには、評価の内容を表すデータ構造を定義する必要があります。この標準化されたデータ構造は公開に使用でき、署名生成および検証ツールで解釈できます。アルゴリズムの評価は、セキュリティ適合性ポリシーにプールされます。このドキュメントでは、セキュリティ適合性ポリシーのデータ構造が指定されています。したがって、このドキュメントは、暗号アルゴリズムの評価を表現するためのフレームワークを提供します。このドキュメントでは、暗号化アルゴリズムのセキュリティプロパティのカタログは作成されません。さらに、評価するアルゴリズムの種類についてガイドラインは作成されません。たとえば、セキュリティ適合性ポリシーを使用して、公開鍵とハッシュアルゴリズム、署名スキーム、および暗号化スキームを評価できます。
Algorithm: A cryptographic algorithm, i.e., a public key or hash algorithm. For public key algorithms, this is the algorithm with its parameters, if any. Furthermore, the term "algorithm" is used for cryptographic schemes and for actually padding functions.
アルゴリズム：暗号化アルゴリズム、つまり公開鍵またはハッシュアルゴリズム。公開鍵アルゴリズムの場合、これは、もしあれば、そのパラメーターを持つアルゴリズムです。さらに、「アルゴリズム」という用語は、暗号化スキームと実際にパディング機能に使用されます。
Operator: Instance that uses and interprets a policy, e.g., a signature-verification component.
オペレーター：署名検証コンポーネントなどのポリシーを使用および解釈するインスタンス。
Policy: An abbreviation for security suitability policy.
ポリシー：セキュリティ適合性ポリシーの略語。
Publisher: Instance that publishes the policy containing the evaluation of algorithms.
発行元：アルゴリズムの評価を含むポリシーを発行するインスタンス。
Security suitability policy: The evaluation of cryptographic algorithms with regard to their security in a specific application area, e.g., signing or verifying data. The evaluation is published in an electronic format.
セキュリティ適合性ポリシー：特定のアプリケーション領域でのセキュリティに関する暗号化アルゴリズムの評価（データの署名や検証など）。評価は電子形式で公開されます。
Suitable algorithm: An algorithm that is evaluated against a policy and determined to be valid, i.e., resistant against attacks, at a particular point of time.
適切なアルゴリズム：ポリシーに対して評価され、特定の時点で有効である、つまり攻撃に対して耐性があると判断されたアルゴリズム。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Some use cases for a security suitability policy are presented here.
ここでは、セキュリティ適合性ポリシーのいくつかの使用例を示します。
Long-term archiving: The most important use case is long-term archiving of signed data. Algorithms or their parameters become insecure over long periods of time. Therefore, signatures of archived data and timestamps have to be periodically renewed. A policy provides information about suitable and threatened algorithms. Additionally, the policy assists in verifying archived as well as re-signed documents.
長期アーカイブ：最も重要なユースケースは、署名されたデータの長期アーカイブです。アルゴリズムまたはそのパラメーターは、長期間にわたって安全でなくなります。したがって、アーカイブされたデータとタイムスタンプの署名は定期的に更新する必要があります。ポリシーは、適切で脅威にさらされているアルゴリズムに関する情報を提供します。さらに、このポリシーは、アーカイブされたドキュメントと再署名されたドキュメントの検証を支援します。
Services: Services may provide information about cryptographic algorithms. On the basis of a policy, a service is able to provide the date when an algorithm became insecure or presumably will become insecure, as well as information regarding which algorithms are presently valid. Verification tools or long-term archiving systems can request such services and therefore do not need to deal with the algorithm security by themselves.
サービス：サービスは、暗号アルゴリズムに関する情報を提供する場合があります。ポリシーに基づいて、サービスは、アルゴリズムが安全でなくなった、またはおそらく安全でなくなる日付と、現在有効なアルゴリズムに関する情報を提供できます。検証ツールまたは長期アーカイブシステムは、このようなサービスを要求できるため、アルゴリズムのセキュリティを自分で処理する必要はありません。
Long-term Archive Services (LTA) as defined in [RFC4810] may use the policy for signature renewal.
[RFC4810]で定義されている長期アーカイブサービス（LTA）は、署名の更新にポリシーを使用できます。
Signing and verifying: When signing documents or certificates, it must be assured that the algorithms used for signing or verifying are suitable. Accordingly, when verifying Cryptographic Message Syntax (CMS) [RFC5652] or XML signatures ([RFC3275], [ETSI-TS101903]), not only the validity of the certificates but also the validity of all involved algorithms may be checked.
署名と検証：ドキュメントまたは証明書に署名する場合、署名または検証に使用されるアルゴリズムが適切であることを確認する必要があります。したがって、暗号化メッセージ構文（CMS）[RFC5652]またはXML署名（[RFC3275]、[ETSI-TS101903]）を検証するときに、証明書の有効性だけでなく、関連するすべてのアルゴリズムの有効性もチェックできます。
Re-encryption: A security suitability policy can also be used to decide if encrypted documents must be re-encrypted because the encryption algorithm is no longer secure.
再暗号化：セキュリティ適合性ポリシーを使用して、暗号化アルゴリズムが安全でなくなったために、暗号化されたドキュメントを再暗号化する必要があるかどうかを決定することもできます。
Section 2.1 describes general requirements for a data structure containing the security suitability of algorithms. In Section 2.2, assumptions are specified concerning both the design and the usage of the data structure.
セクション2.1では、アルゴリズムのセキュリティ適合性を含むデータ構造の一般的な要件について説明します。セクション2.2では、データ構造の設計と使用法の両方に関する仮定が指定されています。
A policy contains a list of algorithms that have been evaluated by a publisher. An algorithm evaluation is described by its identifier, security constraints, and validity period. By these constraints, the requirements for algorithm properties must be defined, e.g., a public key algorithm is evaluated on the basis of its parameters.
ポリシーには、発行元によって評価されたアルゴリズムのリストが含まれています。アルゴリズムの評価は、その識別子、セキュリティ制約、および有効期間によって記述されます。これらの制約により、アルゴリズムのプロパティの要件を定義する必要があります。たとえば、公開鍵アルゴリズムはそのパラメーターに基づいて評価されます。
Automatic interpretation: The data structure of the policy must allow automated evaluation of the security suitability of an algorithm.
自動解釈：ポリシーのデータ構造は、アルゴリズムのセキュリティ適合性の自動評価を可能にする必要があります。
Flexibility: The data structure must be flexible enough to support new algorithms. Future policy publications may include evaluations of algorithms that are currently unknown. It must be possible to add new algorithms with the corresponding security constraints in the data structure. Additionally, the data structure must be independent of the intended use, e.g., encryption, signing, verifying, and signature renewing. Thus, the data structure is usable in every use case.
柔軟性：データ構造は、新しいアルゴリズムをサポートするのに十分な柔軟性が必要です。将来のポリシーの公開には、現在不明なアルゴリズムの評価が含まれる可能性があります。データ構造に対応するセキュリティ制約を持つ新しいアルゴリズムを追加できる必要があります。さらに、データ構造は、暗号化、署名、検証、署名の更新など、使用目的とは無関係である必要があります。したがって、データ構造はすべてのユースケースで使用できます。
Source authentication: Policies may be published by different institutions, e.g., on the national or European Union (EU) level, whereas one policy needs not to be in agreement with the other one. Furthermore, organizations may undertake their own evaluations for internal purposes. For this reason a policy must be attributable to its publisher.
ソース認証：ポリシーは、国や欧州連合（EU）レベルなど、さまざまな機関によって公開される場合がありますが、一方のポリシーは他方のポリシーと一致している必要はありません。さらに、組織は内部目的で独自の評価を行う場合があります。このため、ポリシーは発行元に帰属する必要があります。
Integrity and authenticity: It must be possible to assure the integrity and authenticity of a published security suitability policy. Additionally, the date of issue must be identifiable.
完全性と信頼性：公開されたセキュリティ適合性ポリシーの完全性と信頼性を保証できる必要があります。さらに、発行日を特定できる必要があります。
It is assumed that a policy contains the evaluations of all currently known algorithms, including the expired ones.
ポリシーには、期限切れのアルゴリズムを含む、現在知られているすべてのアルゴリズムの評価が含まれていると想定されています。
An algorithm is suitable at a time of interest if it is contained in the current policy and the time of interest is within the validity period. Additionally, if the algorithm has any parameters, these parameters must meet the requirements defined in the security constraints.
アルゴリズムが現在のポリシーに含まれていて、対象の時間が有効期間内にある場合、アルゴリズムは対象の時間に適しています。さらに、アルゴリズムにパラメータがある場合、これらのパラメータはセキュリティ制約で定義された要件を満たす必要があります。
If an algorithm appears in a policy for the first time, it may be assumed that the algorithm has already been suitable in the past. Generally, algorithms are used in practice prior to evaluation.
アルゴリズムが初めてポリシーに表示される場合、そのアルゴリズムは過去にすでに適切であったと見なされる場合があります。一般的に、アルゴリズムは評価の前に実際に使用されます。
To avoid inconsistencies, multiple instances of the same algorithm are prohibited. The publisher must take care to prevent conflicts within a policy.
不整合を避けるために、同じアルゴリズムの複数のインスタンスは禁止されています。出版社は、ポリシー内の競合を防ぐように注意する必要があります。
Assertions made in the policy are suitable at least until the next policy is published.
ポリシーで作成されたアサーションは、少なくとも次のポリシーが公開されるまで適切です。
Publishers may extend the lifetime of an algorithm prior to reaching the end of the algorithm's validity period by publishing a revised policy. Publishers should not resurrect algorithms that are expired at the time a revised policy is published.
発行者は、改訂されたポリシーを発行することにより、アルゴリズムの有効期間の終わりに達する前に、アルゴリズムの寿命を延ばすことができます。出版社は、改訂されたポリシーが発行された時点で期限切れになったアルゴリズムを復活させないでください。
This section describes the syntax of a security suitability policy defined as an XML schema [W3C.REC-xmlschema-1-20041028]. ASN.1 modules are defined in Appendix C and Appendix D. The schema uses the following XML namespace [W3C.REC-xml-names-20060816]:
このセクションでは、XMLスキーマとして定義されているセキュリティ適合性ポリシーの構文について説明します[W3C.REC-xmlschema-1-20041028]。 ASN.1モジュールは付録Cと付録Dで定義されています。スキーマは次のXML名前空間を使用します[W3C.REC-xml-names-20060816]：
urn:ietf:params:xml:ns:dssc
Within this document, the prefix "dssc" is used for this namespace. The schema starts with the following schema definition:
このドキュメントでは、この名前空間に接頭辞「dssc」が使用されています。スキーマは、次のスキーマ定義で始まります。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dssc="urn:ietf:params:xml:ns:dssc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:dssc"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="xmldsig-core-schema.xsd"/>
The SecuritySuitabilityPolicy element is the root element of a policy. It has an optional id attribute, which MUST be used as a reference when signing the policy (Section 3.13). The optional lang attribute defines the language according to [RFC5646]. The language is applied to all human-readable text within the policy. If the lang attribute is omitted, the default language is English ("en"). The element is defined by the following schema:
SecuritySuitabilityPolicy要素は、ポリシーのルート要素です。これにはオプションのid属性があり、ポリシーに署名するときに参照として使用する必要があります（セクション3.13）。オプションのlang属性は、[RFC5646]に従って言語を定義します。言語は、ポリシー内の人間が読めるすべてのテキストに適用されます。 lang属性を省略した場合、デフォルトの言語は英語（ "en"）です。要素は、次のスキーマによって定義されます。
<xs:element name="SecuritySuitabilityPolicy"
type="dssc:SecuritySuitabilityPolicyType"/>
<xs:complexType name="SecuritySuitabilityPolicyType">
<xs:sequence>
<xs:element ref="dssc:PolicyName"/>
<xs:element ref="dssc:Publisher"/>
<xs:element name="PolicyIssueDate" type="xs:dateTime"/>
<xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Usage" type="xs:string" minOccurs="0"/>
<xs:element ref="dssc:Algorithm" maxOccurs="unbounded"/>
<xs:element ref="ds:Signature" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="1"/>
<xs:attribute name="lang" default="en"/>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
The PolicyName element contains an arbitrary name for the policy. The optional elements Object Identifier (OID) and Uniform Resource Identifier (URI) MAY be used for the identification of the policy. OIDs MUST be expressed in the dot notation.
PolicyName要素には、ポリシーの任意の名前が含まれています。オプションの要素であるオブジェクト識別子（OID）とURI（Uniform Resource Identifier）は、ポリシーの識別に使用できます（MAY）。 OIDはドット表記で表現する必要があります。
<xs:element name="PolicyName" type="dssc:PolicyNameType"/>
<xs:complexType name="PolicyNameType">
<xs:sequence>
<xs:element ref="dssc:Name"/>
<xs:element ref="dssc:ObjectIdentifier" minOccurs="0"/>
<xs:element ref="dssc:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Name" type="xs:string"/>
<xs:element name="ObjectIdentifier">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="(\d+\.)+\d+"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="URI" type="xs:anyURI"/>
The Publisher element contains information about the publisher of the policy. It is composed of the name (e.g., name of institution), an optional address, and an optional URI. The Address element contains arbitrary free-format text not intended for automatic processing.
Publisher要素には、ポリシーの発行者に関する情報が含まれています。これは、名前（施設の名前など）、オプションのアドレス、オプションのURIで構成されます。 Address要素には、自動処理を目的としていない任意の自由形式のテキストが含まれています。
<xs:element name="Publisher" type="dssc:PublisherType"/>
<xs:complexType name="PublisherType">
<xs:sequence>
<xs:element ref="dssc:Name"/>
<xs:element name="Address" type="xs:string" minOccurs="0"/>
<xs:element ref="dssc:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
The PolicyIssueDate element indicates the point of time when the policy was issued.
PolicyIssueDate要素は、ポリシーが発行された時点を示します。
The optional NextUpdate element MAY be used to indicate when the next policy will be issued.
オプションのNextUpdate要素は、次のポリシーがいつ発行されるかを示すために使用される場合があります。
The optional Usage element determines the intended use of the policy (e.g., certificate validation, signing and verifying documents). The element contains free-format text intended only for human readability.
オプションのUsage要素は、ポリシーの目的とする用途（証明書の検証、ドキュメントの署名と検証など）を決定します。要素には、人間が読みやすくすることのみを目的とした自由形式のテキストが含まれています。
A security suitability policy MUST contain at least one Algorithm element. An algorithm is identified by an AlgorithmIdentifier element. Additionally, the Algorithm element contains all evaluations of the specific cryptographic algorithm. More than one evaluation may be necessary if the evaluation depends on the parameter constraints. The optional Information element MAY be used to provide additional information like references on algorithm specifications. In order to give the option to extend the Algorithm element, it additionally contains a wildcard. The Algorithm element is defined by the following schema:
セキュリティ適合性ポリシーには、少なくとも1つのアルゴリズム要素を含める必要があります。アルゴリズムは、AlgorithmIdentifier要素によって識別されます。さらに、アルゴリズム要素には、特定の暗号化アルゴリズムのすべての評価が含まれます。評価がパラメーターの制約に依存する場合、複数の評価が必要になることがあります。オプションの情報要素を使用して、アルゴリズム仕様の参照などの追加情報を提供できます。 Algorithm要素を拡張するオプションを提供するために、それにはさらにワイルドカードが含まれています。 Algorithm要素は、次のスキーマによって定義されています。
<xs:element name="Algorithm" type="dssc:AlgorithmType"/>
<xs:complexType name="AlgorithmType">
<xs:sequence>
<xs:element ref="dssc:AlgorithmIdentifier"/>
<xs:element ref="dssc:Evaluation" maxOccurs="unbounded"/>
<xs:element ref="dssc:Information" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
The AlgorithmIdentifier element is used to identify a cryptographic algorithm. It consists of the algorithm name, at least one OID, and optional URIs. The algorithm name is not intended to be parsed by automatic processes. It is only intended to be read by humans. The OID MUST be expressed in dot notation (e.g., "1.3.14.3.2.26"). The element is defined as follows:
AlgorithmIdentifier要素は、暗号化アルゴリズムを識別するために使用されます。これは、アルゴリズム名、少なくとも1つのOID、およびオプションのURIで構成されます。アルゴリズム名は、自動プロセスによって解析されることを意図していません。人間が読むことのみを目的としています。 OIDはドット表記で表現する必要があります（例：「1.3.14.3.2.26」）。要素は次のように定義されます。
<xs:element name="AlgorithmIdentifier"
type="dssc:AlgorithmIdentifierType"/>
<xs:complexType name="AlgorithmIdentifierType">
<xs:sequence>
<xs:element ref="dssc:Name"/>
<xs:element ref="dssc:ObjectIdentifier" maxOccurs="unbounded"/>
<xs:element ref="dssc:URI" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
The Evaluation element contains the evaluation of one cryptographic algorithm in dependence of its parameter constraints. For example, the suitability of the RSA algorithm depends on the modulus length (RSA with a modulus length of 1024 may have another suitability period as RSA with a modulus length of 2048). Current hash algorithms like SHA-1 or RIPEMD-160 do not have any parameters. Therefore, the Parameter element is optional. The suitability of the algorithm is expressed by a validity period, which is defined by the Validity element. An optional wildcard MAY be used to extend the Evaluation element.
Evaluation要素には、パラメータの制約に応じた1つの暗号化アルゴリズムの評価が含まれています。たとえば、RSAアルゴリズムの適性は、モジュラス長に依存します（モジュラス長が1024のRSAには、モジュラス長が2048のRSAと同様に別の適性期間がある場合があります）。 SHA-1やRIPEMD-160などの現在のハッシュアルゴリズムにはパラメーターがありません。したがって、Parameter要素はオプションです。アルゴリズムの適合性は、有効性要素によって定義される有効期間によって表されます。オプションのワイルドカードを使用して、評価要素を拡張できます。
<xs:element name="Evaluation" type="dssc:EvaluationType"/>
<xs:complexType name="EvaluationType">
<xs:sequence>
<xs:element ref="dssc:Parameter" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="dssc:Validity"/>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
The Parameter element is used to express constraints on algorithm-specific parameters.
Parameter要素は、アルゴリズム固有のパラメーターに対する制約を表すために使用されます。
The Parameter element has a name attribute, which holds the name of the parameter (e.g., "moduluslength" for RSA [RFC3447]). Section 5 defines parameter names for currently known public key algorithms; these parameter names SHOULD be used. For the actual parameter, a range of values or an exact value may be defined. These constraints are expressed by the following elements:
Parameter要素には、パラメーターの名前を保持するname属性があります（RSAの場合は「moduluslength」[RFC3447]など）。セクション5では、現在知られている公開鍵アルゴリズムのパラメーター名を定義します。これらのパラメータ名を使用する必要があります。実際のパラメータについては、値の範囲または正確な値を定義できます。これらの制約は、次の要素によって表されます。
Min: The Min element defines the minimum value of the parameter. That means values equal or greater than the given value meet the requirements.
Min：Min要素は、パラメーターの最小値を定義します。つまり、指定された値以上の値が要件を満たしています。
Max: The Max element defines the maximum value the parameter may take.
Max：Max要素は、パラメータが取り得る最大値を定義します。
At least one of both elements MUST be set to define a range of values. A range MAY also be specified by a combination of both elements, whereas the value of the Min element MUST be less than or equal to the value of the Max element. The parameter may have any value within the defined range, including the minimum and maximum values. An exact value is expressed by using the same value in both the Min and the Max element.
値の範囲を定義するには、両方の要素の少なくとも1つを設定する必要があります。範囲は両方の要素の組み合わせによっても指定できますが、Min要素の値はMax要素の値以下でなければなりません（MUST）。パラメータは、最小値と最大値を含め、定義された範囲内の任意の値を持つことができます。正確な値は、最小要素と最大要素の両方で同じ値を使用することによって表されます。
These constraints are sufficient for all current algorithms. If future algorithms need constraints that cannot be expressed by the elements above, an arbitrary XML structure MAY be inserted that meets the new constraints. For this reason, the Parameter element contains a wildcard. A parameter MUST contain at least one constraint. The schema for the Parameter element is as follows:
これらの制約は、現在のすべてのアルゴリズムに十分です。将来のアルゴリズムで上記の要素では表現できない制約が必要な場合は、新しい制約を満たす任意のXML構造を挿入することができます（MAY）。このため、Parameter要素にはワイルドカードが含まれています。パラメータには少なくとも1つの制約が含まれている必要があります。 Parameter要素のスキーマは次のとおりです。
<xs:element name="Parameter" type="dssc:ParameterType"/>
<xs:complexType name="ParameterType">
<xs:sequence>
<xs:element name="Min" type="xs:int" minOccurs="0"/>
<xs:element name="Max" type="xs:int" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
The Validity element is used to define the period of the (predicted) suitability of the algorithm. It is composed of an optional start date and an optional end date. Defining no end date means the algorithm has an open-end validity. Of course, this may be restricted by a future policy that sets an end date for the algorithm. If the end of the validity period is in the past, the algorithm was suitable until that end date. The element is defined by the following schema:
Validity要素は、アルゴリズムの（予測される）適合性の期間を定義するために使用されます。これは、オプションの開始日とオプションの終了日で構成されます。終了日を定義しないことは、アルゴリズムに有効期限があることを意味します。もちろん、これは、アルゴリズムの終了日を設定する将来のポリシーによって制限される場合があります。有効期間の終了が過去の場合、その終了日までアルゴリズムは適切でした。要素は、次のスキーマによって定義されます。
<xs:element name="Validity" type="dssc:ValidityType"/>
<xs:complexType name="ValidityType">
<xs:sequence>
<xs:element name="Start" type="xs:date" minOccurs="0"/>
<xs:element name="End" type="xs:date" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
The Information element MAY be used to give additional textual information about the algorithm or the evaluation, e.g., references on algorithm specifications. The element is defined as follows:
情報要素は、アルゴリズムまたは評価に関する追加のテキスト情報を提供するために使用される場合があります。要素は次のように定義されます。
<xs:element name="Information" type="dssc:InformationType"/>
<xs:complexType name="InformationType">
<xs:sequence>
<xs:element name="Text" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
The optional Signature element MAY be used to guarantee the integrity and authenticity of the policy. It is an XML signature specified in [RFC3275]. The signature MUST relate to the SecuritySuitabilityPolicy element. If the Signature element is set, the SecuritySuitabilityPolicy element MUST have the optional id attribute. This attribute MUST be used to reference the SecuritySuitabilityPolicy element within the Signature element. Since it is an enveloped signature, the signature MUST use the transformation algorithm identified by the following URI:
オプションの署名要素は、ポリシーの完全性と信頼性を保証するために使用される場合があります。 [RFC3275]で規定されているXML署名です。署名はSecuritySuitabilityPolicy要素に関連している必要があります。 Signature要素が設定されている場合、SecuritySuitabilityPolicy要素にはオプションのid属性が必要です。この属性は、Signature要素内のSecuritySuitabilityPolicy要素を参照するために使用する必要があります。これはエンベロープされた署名であるため、署名は次のURIで識別される変換アルゴリズムを使用する必要があります。
http://www.w3.org/2000/09/xmldsig#enveloped-signature
DSSC policies MUST be expressed either in XML or ASN.1. However, in order to reach interoperability, DSSC policies SHOULD be published in both XML and ASN.1.
DSSCポリシーは、XMLまたはASN.1で表現する必要があります。ただし、相互運用性を実現するために、DSSCポリシーはXMLとASN.1の両方で公開する必要があります。
In the case of XML, a DSSC policy is an XML document that MUST be well-formed and SHOULD be valid. XML-encoded DSSC policies MUST be based on XML 1.0 [W3C.REC-xml-20081126] and MUST be encoded using UTF-8 [RFC3629]. This specification makes use of XML namespaces [W3C.REC-xml-names-20060816] for identifying DSSC policies. The namespace URI for elements defined by this specification is a URN [RFC2141] using the namespace prefix "dssc". This URN is:
XMLの場合、DSSCポリシーは、整形式であり、有効でなければならないXMLドキュメントです。 XMLでエンコードされたDSSCポリシーは、XML 1.0 [W3C.REC-xml-20081126]に基づく必要があり、UTF-8 [RFC3629]を使用してエンコードする必要があります。この仕様では、DSSCポリシーを識別するためにXML名前空間[W3C.REC-xml-names-20060816]を利用しています。この仕様で定義されている要素の名前空間URIは、名前空間接頭辞「dssc」を使用したURN [RFC2141]です。このURNは次のとおりです。
urn:ietf:params:xml:ns:dssc
XML-encoded DSSC policies are identified with the MIME type "application/dssc+xml" and are instances of the XML schema [W3C.REC-xmlschema-1-20041028] defined in Appendix B.
XMLエンコードされたDSSCポリシーは、MIMEタイプ "application / dssc + xml"で識別され、付録Bで定義されているXMLスキーマ[W3C.REC-xmlschema-1-20041028]のインスタンスです。
A file containing a DSSC policy in ASN.1 representation (for specification of ASN.1 refer to [CCITT.x208.1988], [CCITT.x209.1988], [CCITT.x680.2002] and [CCITT.x690.2002]) MUST contain only the DER encoding of one DSSC policy, i.e., there MUST NOT be extraneous header or trailer information in the file. ASN.1-based DSSC policies are identified with the MIME type "application/dssc+der". Appropriate ASN.1 modules are defined in Appendices C (1988-ASN.1 syntax) and D (1997-ASN.1 syntax).
ASN.1表現のDSSCポリシーを含むファイル（ASN.1の仕様については、[CCITT.x208.1988]、[CCITT.x209.1988]、[CCITT.x680.2002]および[CCITT.x690.2002を参照してください。 ]）1つのDSSCポリシーのDERエンコーディングのみを含める必要があります。つまり、ファイルに無関係なヘッダーまたはトレーラー情報があってはなりません。 ASN.1ベースのDSSCポリシーは、MIMEタイプ「application / dssc + der」で識別されます。適切なASN.1モジュールは、付録C（1988-ASN.1構文）およびD（1997-ASN.1構文）で定義されています。
This section defines the parameter names for the currently known public key algorithms. The following parameters also refer to cryptographic schemes based on these public key algorithms (e.g., the PKCS#1 v1.5 signature scheme SHA-256 with RSA [RFC3447]).
このセクションでは、現在知られている公開鍵アルゴリズムのパラメーター名を定義します。次のパラメータは、これらの公開鍵アルゴリズムに基づく暗号化スキーム（たとえば、RSAを使用したPKCS＃1 v1.5署名スキームSHA-256 [RFC3447]）も参照します。
The parameter of RSA [RFC3447] SHOULD be named "moduluslength".
RSA [RFC3447]のパラメータは、 "moduluslength"と命名されるべきです（SHOULD）。
The parameters for the Digital Signature Algorithm (DSA) [FIPS186-2] SHOULD be "plength" and "qlength".
デジタル署名アルゴリズム（DSA）[FIPS186-2]のパラメーターは、「plength」と「qlength」にする必要があります。
These parameter names have been registered by IANA (see Section 8). It may be necessary to register further algorithms not given in this section (in particular, future algorithms). The process for registering parameter names of further algorithms is described in Section 8. Publishers of policies SHOULD use these parameter names so that the correct interpretation is guaranteed.
これらのパラメーター名はIANAによって登録されています（セクション8を参照）。このセクションに記載されていない追加のアルゴリズム（特に、将来のアルゴリズム）を登録する必要がある場合があります。さらなるアルゴリズムのパラメーター名を登録するプロセスは、セクション8で説明されています。ポリシーの発行者は、正しい解釈が保証されるように、これらのパラメーター名を使用する必要があります。
Evaluation of an algorithm's security suitability is described in three parts: verification of the policy, determination of algorithm validity, and evaluation of algorithm parameters, if any.
アルゴリズムのセキュリティ適合性の評価は、ポリシーの検証、アルゴリズムの有効性の決定、およびアルゴリズムパラメータの評価（ある場合）の3つの部分で説明されています。
In the following sections, a process is described
次のセクションでは、プロセスについて説明します
o to determine if an algorithm was suitable at a particular point of time, and
o アルゴリズムが特定の時点で適切であったかどうかを判断するため、および
o to determine until what time an algorithm was or will be suitable.
o アルゴリズムが適切であった、または適切になる時刻を決定する。
To determine the security suitability of an algorithm, the following information is required:
アルゴリズムのセキュリティ適合性を判断するには、次の情報が必要です。
o Policy
o 方針
o Current time
o 現在の時刻
o Algorithm identifier and parameter constraints (if associated)
o アルゴリズム識別子とパラメーター制約（関連付けられている場合）
o Time of interest (optional). Providing no time of interest means determination of the validity end date of the algorithm.
o 関心のある時間（オプション）。興味のある時間を提供しないことは、アルゴリズムの有効終了日の決定を意味します。
The signature on the policy SHOULD be verified and a certification path from the policy signer's certificate to a current trust anchor SHOULD be constructed and validated [RFC5280]. The algorithms used to verify the digital signature and validate the certification path MUST be suitable per the contents of the policy being verified. If signature verification fails, certification path validation fails or an unsuitable algorithm is required to perform these checks, then the policy MUST be rejected.
ポリシーの署名を検証し、ポリシー署名者の証明書から現在のトラストアンカーへの証明書パスを構築して検証する必要があります[RFC5280]。デジタル署名を検証し、認証パスを検証するために使用されるアルゴリズムは、検証されるポリシーの内容ごとに適切でなければなりません。署名の検証が失敗した場合、証明書パスの検証が失敗した場合、またはこれらのチェックを実行するには不適切なアルゴリズムが必要な場合は、ポリシーを拒否する必要があります。
The nextUpdate time in the policy MUST be either greater than the current time or absent. If the nextUpdate time is less than the current time, the policy MUST be rejected.
ポリシーのnextUpdate時間は、現在の時間よりも大きいか、存在しない必要があります。 nextUpdateの時刻が現在の時刻よりも短い場合、ポリシーは拒否される必要があります。
To determine the validity period of an algorithm, locate the Algorithm element in the policy that corresponds to the algorithm identifier provided as input. The Algorithm element is located by comparing the OID in the element to the OID included in the algorithm identifier provided as input.
アルゴリズムの有効期間を決定するには、入力として提供されたアルゴリズム識別子に対応するポリシー内のアルゴリズム要素を見つけます。 Algorithm要素は、要素内のOIDを、入力として提供されたアルゴリズム識別子に含まれるOIDと比較することによって配置されます。
If no matching Algorithm element is found, then the algorithm is unknown.
一致するAlgorithm要素が見つからない場合、アルゴリズムは不明です。
If the time of interest was provided as input, the validity of each Evaluation element MUST be checked in order to determine if the algorithm was suitable at the time of interest. For each Evaluation element:
関心のある時間が入力として提供された場合、各評価要素の有効性をチェックして、アルゴリズムが関心のある時間に適しているかどうかを判断する必要があります。評価要素ごとに：
o Confirm the Start time is either less than the time of interest or absent. Discard the entry if the Start time is present and greater than the time of interest.
o 開始時刻が対象の時刻よりも短いか、または存在しないことを確認します。開始時間が存在し、対象の時間よりも長い場合は、エントリを破棄します。
o Confirm the End time is either greater than the time of interest or absent. Discard the entry if the End time is present and less than the time of interest.
o 終了時刻が目的の時刻よりも長いか、または存在しないことを確認します。終了時間が存在し、対象の時間よりも短い場合は、エントリを破棄します。
If all Evaluation elements were rejected, the algorithm is not suitable according to the policy.
すべての評価要素が拒否された場合、アルゴリズムはポリシーに従って適切ではありません。
Any entries not rejected will be used for the evaluation of the parameters, if any.
拒否されなかったエントリがあれば、パラメータの評価に使用されます。
Any necessary parameters of the entries not rejected MUST be evaluated within the context of the type and usage of the algorithm. Details of parameter evaluation are defined on a per-algorithm basis.
拒否されないエントリの必要なパラメータは、アルゴリズムのタイプと使用法のコンテキスト内で評価する必要があります。パラメータ評価の詳細は、アルゴリズムごとに定義されます。
To evaluate the parameters, the Parameter elements of each Evaluation element that has not been rejected in the process described in Section 6.3 MUST be checked. For each Parameter element:
パラメータを評価するには、セクション6.3で説明されているプロセスで拒否されていない各評価要素のパラメータ要素をチェックする必要があります。各Parameter要素について：
o Confirm that the parameter was provided as input. Discard the Evaluation element if the parameter does not match to any of the parameters provided as input.
o パラメータが入力として提供されたことを確認します。パラメータが入力として提供されたどのパラメータとも一致しない場合は、評価要素を破棄します。
o If the Parameter element has a Min element, confirm that the parameter value is less than or equal to the corresponding parameter provided as input. Discard the Evaluation element if the parameter value does not meet the constraint.
o ParameterエレメントにMinエレメントがある場合は、パラメーター値が、入力として提供された対応するパラメーター以下であることを確認してください。パラメータ値が制約を満たさない場合は、評価要素を破棄します。
o If the Parameter element has a Max element, confirm that the parameter value is greater than or equal to the corresponding parameter provided as input. Discard the Evaluation element if the parameter value does not meet the constraint.
o ParameterエレメントにMaxエレメントがある場合は、パラメーター値が、入力として提供された対応するパラメーター以上であることを確認してください。パラメータ値が制約を満たさない場合は、評価要素を破棄します。
o If the Parameter has another constraint, confirm that the value of the corresponding parameter provided as input meets this constraint. If it does not or if the constraint is unrecognized, discard the Evaluation element.
o パラメーターに別の制約がある場合は、入力として提供された対応するパラメーターの値がこの制約を満たしていることを確認してください。そうでない場合、または制約が認識されない場合は、評価要素を破棄します。
If all Evaluation elements were rejected, the algorithm is not suitable according to the policy.
すべての評価要素が拒否された場合、アルゴリズムはポリシーに従って適切ではありません。
Any entries not rejected will be provided as output.
拒否されなかったエントリは、出力として提供されます。
If the algorithm is not in the policy, return an error "algorithm unknown".
アルゴリズムがポリシーにない場合は、「アルゴリズム不明」のエラーを返します。
If no time of interest was provided as input, return the maximum End time of the Evaluation elements that were not discarded. If at least one End time of these Evaluation elements is absent, return "algorithm has an indefinite End time".
関心のある時間が入力として提供されなかった場合、破棄されなかった評価要素の最大終了時間を返します。これらの評価要素の少なくとも1つの終了時間が存在しない場合は、「アルゴリズムには無期限の終了時間があります」を返します。
Otherwise, if the algorithm is not suitable relative to the time of interest, return an error "algorithm unsuitable".
それ以外の場合、アルゴリズムが対象の時間に対して適切でない場合は、「アルゴリズムが不適切」というエラーを返します。
If the algorithm is suitable relative to the time of interest, return the Evaluation elements that were not discarded.
アルゴリズムが対象の時間に対して適切である場合は、破棄されなかったEvaluation要素を返します。
The policy for an algorithm's security suitability has a great impact on the quality of the results of signature generation and verification operations. If an algorithm is incorrectly evaluated against a policy, signatures with a low probative force could be created or verification results could be incorrect. The following security considerations have been identified:
アルゴリズムのセキュリティ適合性に関するポリシーは、署名の生成と検証の結果の品質に大きな影響を与えます。アルゴリズムがポリシーに対して誤って評価されると、証拠力の低い署名が作成されたり、検証結果が不正確になったりする可能性があります。次のセキュリティに関する考慮事項が確認されています。
1. Publishers MUST ensure unauthorized manipulation of any security suitability is not possible prior to a policy being signed and published. There is no mechanism provided to revoke a policy after publication. Since the algorithm evaluations change infrequently, the lifespan of a policy should be carefully considered prior to publication.
1. パブリッシャーは、ポリシーが署名および発行される前に、セキュリティの適合性の不正な操作が不可能であることを確認する必要があります。公開後にポリシーを取り消すメカニズムは提供されていません。アルゴリズムの評価はめったに変更されないため、ポリシーの有効期間は公開前に慎重に検討する必要があります。
2. Operators SHOULD only accept policies issued by a trusted publisher. Furthermore, the validity of the certificate used to sign the policy SHOULD be verifiable by Certificate Revocation List (CRL) [RFC5280] or Online Certificate Status Protocol (OCSP) [RFC2560]. The certificate used to sign the policy SHOULD be revoked if the algorithms used in this certificate are no longer suitable. It MUST NOT be possible to alter or replace a policy once accepted by an operator.
2. オペレーターは、信頼できる発行元によって発行されたポリシーのみを受け入れる必要があります。さらに、ポリシーの署名に使用される証明書の有効性は、証明書失効リスト（CRL）[RFC5280]またはオンライン証明書ステータスプロトコル（OCSP）[RFC2560]によって検証可能である必要があります（SHOULD）。ポリシーの署名に使用された証明書は、この証明書で使用されているアルゴリズムが適切でなくなった場合、取り消す必要があります（SHOULD）。オペレーターがいったん承認すると、ポリシーを変更または置換することはできません。
3. Operators SHOULD periodically check to see if a new policy has been published to avoid using obsolete policy information. For publishers, it is suggested not to omit the NextUpdate element in order to give operators a hint regarding when the next policy will be published.
3. オペレーターは、古いポリシー情報の使用を避けるために、新しいポリシーが公開されているかどうかを定期的に確認する必要があります（SHOULD）。パブリッシャーの場合、次のポリシーがいつ公開されるかについてオペレーターにヒントを与えるために、NextUpdate要素を省略しないことをお勧めします。
4. When signing a policy, algorithms that are suitable according to this policy SHOULD be used.
4. ポリシーに署名するときは、このポリシーに従って適切なアルゴリズムを使用する必要があります（SHOULD）。
5. The processing rule described in Section 6 is about one cryptographic algorithm independent of the use case. Depending upon the use case, an algorithm that is no longer suitable at the time of interest, does not necessarily mean that the data structure where it is used is no longer secure. For example, a signature has been made with an RSA signer's key of 1024 bits. This signature is timestamped with a timestamp token that uses an RSA key of 2048 bits, before an RSA key size of 1024 bits will be broken. The fact that the signature key of 1024 bits is no longer suitable at the time of interest does not mean that the whole data structure is no longer secure, if an RSA key size of 2048 bits is still suitable at the time of interest.
5.セクション6で説明されている処理ルールは、ユースケースに依存しない約1つの暗号化アルゴリズムです。ユースケースによっては、対象の時点でもはや適切ではないアルゴリズムが、それが使用されているデータ構造がもはや安全でないことを必ずしも意味しません。たとえば、1024ビットのRSA署名者の鍵を使用して署名が作成されています。この署名には、1024ビットのRSAキーサイズが壊れる前に、2048ビットのRSAキーを使用するタイムスタンプトークンでタイムスタンプが付けられます。 2048ビットのRSAキーサイズがまだ適切である場合、1024ビットの署名キーがもはや適切ではないという事実は、データ構造全体が安全ではなくなったことを意味しません。
6. In addition to the key size considerations, other considerations must be applied, like whether a timestamp token has been provided by a trusted authority. This means that the simple use of a suitability policy is not the single element to consider when evaluating the security of a complex data structure that uses several cryptographic algorithms.
6. キーサイズの考慮事項に加えて、タイムスタンプトークンが信頼できる機関によって提供されているかどうかなど、他の考慮事項を適用する必要があります。これは、複数の暗号化アルゴリズムを使用する複雑なデータ構造のセキュリティを評価する際に、適合性ポリシーの単純な使用が考慮すべき単一の要素ではないことを意味します。
7. The policies described in this document are suitable to evaluate basic cryptographic algorithms, like public key or hash algorithms, as well as cryptographic schemes (e.g., the PKCS#1 v1.5 signature schemes [RFC3447]). But it MUST be kept in mind that a basic cryptographic algorithm that is suitable according to the policy does not necessarily mean that any cryptographic schemes based on this algorithm are also secure. For example, a signature scheme based on RSA must not necessarily be secure if RSA is suitable. In case of a complete signature verification, including validation of the certificate path, various algorithms have to be checked against the policy (i.e., signature schemes of signed data objects and revocation information, public key algorithms of the involved certificates, etc.). Thus, a policy SHOULD contain evaluations of public key and hash algorithms as well as of signature schemes.
7. このドキュメントで説明されているポリシーは、公開鍵やハッシュアルゴリズムなどの基本的な暗号化アルゴリズム、および暗号化スキーム（PKCS＃1 v1.5署名スキーム[RFC3447]など）を評価するのに適しています。ただし、ポリシーに従って適切な基本的な暗号化アルゴリズムが、このアルゴリズムに基づく暗号化スキームも安全であることを必ずしも意味しないことに留意する必要があります。たとえば、RSAが適している場合、RSAに基づく署名方式は必ずしも安全である必要はありません。証明書パスの検証を含む完全な署名検証の場合、さまざまなアルゴリズムをポリシーに対してチェックする必要があります（つまり、署名されたデータオブジェクトと失効情報の署名スキーム、関連する証明書の公開鍵アルゴリズムなど）。したがって、ポリシーには、公開鍵とハッシュアルゴリズム、および署名方式の評価が含まれる必要があります（SHOULD）。
8. Re-encrypting documents that were originally encrypted using an algorithm that is no longer suitable will not protect the semantics of the document if the document has been intercepted. However, for documents stored in an encrypted form, re-encryption must be considered, unless the document has lost its original value.
8. 元々適切でなくなったアルゴリズムを使用して暗号化されていたドキュメントを再暗号化しても、ドキュメントが傍受された場合、ドキュメントのセマンティクスは保護されません。ただし、暗号化された形式で保存されたドキュメントの場合、ドキュメントが元の値を失っていない限り、再暗号化を検討する必要があります。
This document defines the XML namespace "urn:ietf:params:xml:ns:dssc" according to the guidelines in [RFC3688]. This namespace has been registered in the IANA XML Registry.
このドキュメントは、[RFC3688]のガイドラインに従って、XML名前空間「urn：ietf：params：xml：ns：dssc」を定義します。この名前空間は、IANA XMLレジストリに登録されています。
This document defines an XML schema (see Appendix B) according to the guidelines in [RFC3688]. This XML schema has been registered in the IANA XML Registry and can be identified with the URN "urn:ietf:params:xml:schema:dssc".
このドキュメントは、[RFC3688]のガイドラインに従ってXMLスキーマ（付録Bを参照）を定義します。このXMLスキーマはIANA XMLレジストリに登録されており、URN "urn：ietf：params：xml：schema：dssc"で識別できます。
This document defines the MIME type "application/dssc+xml". This MIME type has been registered by IANA under "MIME Media Types" according to the procedures of [RFC4288].
このドキュメントでは、MIMEタイプ「application / dssc + xml」を定義しています。このMIMEタイプは、[RFC4288]の手順に従って、「MIMEメディアタイプ」の下でIANAによって登録されています。
Type name: application
タイプ名：アプリケーション
Subtype name: dssc+xml
サブタイプ名：dssc + xml
Required parameters: none
必須パラメーター：なし
Optional parameters: "charset" as specified for "application/xml" in [RFC3023].
オプションパラメータ：[RFC3023]の「application / xml」で指定されている「charset」。
Encoding considerations: Same as specified for "application/xml" in [RFC3023].
エンコーディングに関する考慮事項：[RFC3023]の「application / xml」で指定されたものと同じです。
Security considerations: Same as specified for "application/xml" in Section 10 of [RFC3023]. For further security considerations, see Section 7 of this document.
セキュリティに関する考慮事項：[RFC3023]のセクション10の「application / xml」に指定されたものと同じです。セキュリティに関するその他の考慮事項については、このドキュメントのセクション7を参照してください。
Interoperability considerations: Same as specified for "application/xml" in [RFC3023].
相互運用性に関する考慮事項：[RFC3023]の「application / xml」で指定されたものと同じです。
Published specification: This document.
公開された仕様：このドキュメント。
Applications that use this media: Applications for long-term archiving of signed data, applications for signing data / verifying signed data, and applications for encrypting / decrypting data.
このメディアを使用するアプリケーション：署名済みデータの長期アーカイブ用のアプリケーション、データの署名/署名済みデータの検証用のアプリケーション、およびデータの暗号化/復号化用のアプリケーション。
Additional information:
追加情報：
Magic number(s): none
マジックナンバー：なし
File extension(s): .xdssc
ファイル拡張子：.xdssc
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「TEXT」
Object Identifiers: none
オブジェクト識別子：なし
Person to contact for further information: Thomas Kunz (thomas.kunz@sit.fraunhofer.de)
詳細については連絡先：Thomas Kunz（thomas.kunz@sit.fraunhofer.de）
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: none
使用上の制限：なし
Author/Change controller: IETF
作成者/変更コントローラ：IETF
This document defines the MIME type "application/dssc+der". This MIME type has been registered by IANA under "MIME Media Types" according to the procedures of [RFC4288].
このドキュメントでは、MIMEタイプ「application / dssc + der」を定義しています。このMIMEタイプは、[RFC4288]の手順に従って、「MIMEメディアタイプ」の下でIANAによって登録されています。
Type name: application
タイプ名：アプリケーション
Subtype name: dssc+der
サブタイプ名：dssc + der
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: binary
エンコーディングに関する考慮事項：バイナリ
Security considerations: See Section 7 of this document.
セキュリティに関する考慮事項：このドキュメントのセクション7を参照してください。
Interoperability considerations: none
相互運用性に関する考慮事項：なし
Published specification: This document.
公開された仕様：このドキュメント。
Applications that use this media: Applications for long-term archiving of signed data, applications for signing data / verifying signed data, and applications for encrypting / decrypting data.
このメディアを使用するアプリケーション：署名済みデータの長期アーカイブ用のアプリケーション、データの署名/署名済みデータの検証用のアプリケーション、およびデータの暗号化/復号化用のアプリケーション。
Additional information:
追加情報：
Magic number(s): none
マジックナンバー：なし
File extension(s): .dssc
ファイル拡張子：.dssc
Macintosh file type code: none
Macintoshファイルタイプコード：なし
Object Identifiers: none
オブジェクト識別子：なし
Person to contact for further information: Thomas Kunz (thomas.kunz@sit.fraunhofer.de)
詳細については連絡先：Thomas Kunz（thomas.kunz@sit.fraunhofer.de）
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: none
使用上の制限：なし
Author/Change controller: IETF
作成者/変更コントローラ：IETF
This specification creates a new IANA registry entitled "Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)". This registry contains two sub-registries entitled "Parameter Definitions" and "Cryptographic Algorithms". The policy for future assignments to the sub-registry "Parameter Definitions" is "RFC Required".
この仕様は、「暗号化アルゴリズムのセキュリティ適合性（DSSC）のデータ構造」というタイトルの新しいIANAレジストリを作成します。このレジストリには、「パラメータ定義」と「暗号化アルゴリズム」という2つのサブレジストリが含まれています。サブレジストリ「パラメータ定義」への今後の割り当てのポリシーは「RFC必須」です。
The initial values for the "Parameter Definitions" sub-registry are:
「パラメータ定義」サブレジストリの初期値は次のとおりです。
Value Description Reference
-------------- ------------------------------- ------------------
moduluslength Parameter for RSA RFC 5698
(integer value)
plength Parameter for DSA RFC 5698
(integer value, used together
with parameter "qlength")
qlength Parameter for DSA RFC 5698
(integer value, used together
with parameter "plength")
The sub-registry "Cryptographic Algorithms" contains textual names as well as Object Identifiers (OIDs) and Uniform Resource Identifiers (URIs) of cryptographic algorithms. It serves as assistance when creating a new policy. The policy for future assignments is "First Come First Served". When registering a new algorithm, the following information MUST be provided:
サブレジストリ「Cryptographic Algorithms」には、テキスト名のほか、暗号アルゴリズムのオブジェクト識別子（OID）とURI（Uniform Resource Identifier）が含まれています。新しいポリシーを作成するときに役立ちます。今後の課題の方針は、「先着順」です。新しいアルゴリズムを登録するときは、次の情報を提供する必要があります。
o The textual name of the algorithm.
o アルゴリズムのテキスト名。
o The OID of the algorithm.
o アルゴリズムのOID。
o A reference to a publicly available specification that defines the algorithm and its identifiers.
o アルゴリズムとその識別子を定義する公開されている仕様への参照。
Optionally, a URI MAY be provided if possible.
オプションで、可能であればURIを指定できます。
The initial values for the "Cryptographic Algorithms" sub-registry are:
「暗号化アルゴリズム」サブレジストリの初期値は次のとおりです。
Name OID / URI Reference
----------------------- --------------------------------- ----------
rsaEncryption 1.2.840.113549.1.1.1 [RFC3447]
dsa 1.2.840.10040.4.1 [RFC3279]
dsa 1.2.840.10040.4.1 [RFC3279]
md2 1.2.840.113549.2.2 [RFC3279]
イルミネーター1.840.113549.A.A。[Refa'ahs]
md5 1.2.840.113549.2.5 [RFC3279]
http://www.w3.org/2001/04/xmldsig-more#md5 [RFC4051]
sha-1 1.3.14.3.2.26 [RFC3279]
http://www.w3.org/2000/09/xmldsig#sha1 [RFC3275]
sha-224 2.16.840.1.101.3.4.2.4 [RFC4055]
http://www.w3.org/2001/04/xmldsig-more#sha224 [RFC4051]
sha-256 2.16.840.1.101.3.4.2.1 [RFC4055]
しゃー２５６ ２。１６。８４０。１。１０１。３。４。２。１ 「ＲＦＣ４０５５」
sha-384 2.16.840.1.101.3.4.2.2 [RFC4055]
http://www.w3.org/2001/04/xmldsig-more#sha384 [RFC4051]
sha-512 2.16.840.1.101.3.4.2.3 [RFC4055]
しゃー５１２ ２。１６。８４０。１。１０１。３。４。２。３ 「ＲＦＣ４０５５」
md2WithRSAEncryption 1.2.840.113549.1.1.2 [RFC3443]
md2WithRSAEncryption 1.2.840.113549.1.1.2 [RFC3443]
md5WithRSAEncryption 1.2.840.113549.1.1.4 [RFC3443]
http://www.w3.org/2001/04/xmldsig-more#rsa-md5 [RFC4051]
sha1WithRSAEncryption 1.2.840.113549.1.1.5 [RFC3443]
http://www.w3.org/2000/09/xmldsig#rsa-sha1 [RFC3275]
sha256WithRSAEncryption 1.2.840.113549.1.1.11 [RFC3443]
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [RFC4051]
sha384WithRSAEncryption 1.2.840.113549.1.1.12 [RFC3443]
http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 [RFC4051]
sha512WithRSAEncryption 1.2.840.113549.1.1.13 [RFC3443]
http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 [RFC4051]
sha1WithDSA 1.2.840.10040.4.3 [RFC3279]
http://www.w3.org/2000/09/xmldsig#dsa-sha1 [RFC3275]
[CCITT.x680.2002] International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", CCITT Recommendation X.680, July 2002.
[CCITT.x680.2002]国際電話および電信諮問委員会、「Abstract Syntax Notation One（ASN.1）：Specification of basic notation」、CCITT勧告X.680、2002年7月。
[CCITT.x690.2002] International Telephone and Telegraph Consultative Committee, "AASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[CCITT.x690.2002] International Telephone and Telegraph Consultative Committee、 "AASN.1 encoding rules：Specification of basic encoding Rules（BER）、Canonical encoding rules（CER）and Distinguished encoding rules（DER）"、CCITT Recommendation X.690 、2002年7月。
[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月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141] Moats、R。、「URN Syntax」、RFC 2141、1997年5月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]マイヤーズ、M。、アンクニー、R。、マルパニ、A。、ガルペリン、S。、およびC.アダムス、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」、RFC 2560、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] Eastlake、D.、Reagle、J。、およびD. Solo、「（Extensible Markup Language）XML-Signature Syntax and Processing」、RFC 3275、2002年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 4288、2005年12月。
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007.
[RFC4998] Gondrom、T.、Brandner、R。、およびU. Pordesch、「Evidence Record Syntax（ERS）」、RFC 4998、2007年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「Tags for Identificationing Languages」、BCP 47、RFC 5646、2009年9月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 5652、2009年9月。
[W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126] Yergeau、F.、Maler、E.、Paoli、J.、Sperberg-McQueen、C。、およびT. Bray、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation REC-xml-20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。
[W3C.REC-xml-names-20060816] Layman, A., Hollander, D., Tobin, R., and T. Bray, "Namespaces in XML 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names-20060816>.
[W3C.REC-xml-names-20060816] Layman、A.、Hollander、D.、Tobin、R。、およびT. Bray、「Namespaces in XML 1.0（Second Edition）」、World Wide Web Consortium Recommendation REC-xml -names-20060816、2006年8月、<http://www.w3.org/TR/2006/REC-xml-names-20060816>。
[W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-1-20041028] Thompson、H.、Beech、D.、Mendelsohn、N.、and M. Maloney、 "XML Schema Part 1：Structures Second Edition"、World Wide Web Consortium Recommendation REC-xmlschema -1-20041028、2004年10月、<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>。
[BNetzAg.2008] Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway, "Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Uebersicht ueber geeignete Algorithmen)", December 2007, <http://www.bundesnetzagentur.de/media/archive/12198.pdf>.
[BNetzAg.2008] Federal Network Agency for Electricity、Gas、Telecommunications、Post and Railway、「Announcement on the Electronic Signing by the Signature Act and the Signature Ordinance（overview of適切なアルゴリズム）」、2007年12月、<http：//www.bundesnetzagentur。 de / media / archive / 12198.pdf>。
[CCITT.x208.1988] International Telephone and Telegraph Consultative Committee, "Specification of Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.208, November 1988.
[CCITT.x208.1988]国際電話および電信諮問委員会、「抽象構文記法1（ASN.1）の仕様」、CCITT勧告X.208、1988年11月。
[CCITT.x209.1988] International Telephone and Telegraph Consultative Committee, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.209, November 1988.
[CCITT.x209.1988] International Telephone and Telegraph Consultative Committee、 "Specification Basic Basic Encoding Rules for Abstract Syntax Notation One（ASN.1）"、CCITT Recommendation X.209、November 1988。
[ETSI-TS101903] European Telecommunication Standards Institute (ETSI), "XML Advanced Electronic Signatures (XAdES)", ETSI TS 101 903 V1.3.2, March 2006.
[ETSI-TS101903] European Telecommunication Standards Institute（ETSI）、「XML Advanced Electronic Signatures（XAdES）」、ETSI TS 101 903 V1.3.2、2006年3月。
[ETSI-TS102176-1-2005] European Telecommunication Standards Institute (ETSI), "Electronic Signatures and Infrastructures (ESI); "Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms"", ETSI TS 102 176-1 V2.0.0, November 2007.
[ETSI-TS102176-1-2005] European Telecommunication Standards Institute（ETSI）、「Electronic Signatures and Infrastructures（ESI）;」、「Algorithms and Parameters for Secure Electronic Signatures;パート1：ハッシュ関数と非対称アルゴリズム ""、ETSI TS 102 176-1 V2.0.0、2007年11月。
[FIPS186-2] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-2 with Change Notice, January 2000.
[FIPS186-2]米国国立標準技術研究所、「デジタル署名標準（DSS）」、FIPS PUB 186-2、変更通知付き、2000年1月。
[NIST.800-57-Part1.2006] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST 800-57 Part 1, May 2006.
[NIST.800-57-Part1.2006]国立標準技術研究所、「鍵管理の推奨事項-パート1：一般（改訂）」、NIST 800-57パート1、2006年5月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279] Bassham、L.、Polk、W.、and R. Housley、 "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile"、RFC 3279、April 2002。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwal、P。およびB. Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワークにおけるTime To Live（TTL）処理」、RFC 3443、2003年1月
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月。
[RFC4051] Eastlake, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4051] Eastlake、D。、「Additional XML Security Uniform Resource Identifiers（URIs）」、RFC 4051、2005年4月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」、RFC 4055 、2005年6月。
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007.
[RFC4810] Wallace、C.、Pordesch、U。、およびR. Brandner、「Long-Term Archive Service Requirements」、RFC 4810、2007年3月。
This section describes the verification of an Evidence Record according to the Evidence Record Syntax (ERS, [RFC4998]), using the presented data structure.
このセクションでは、提示されたデータ構造を使用して、証拠レコード構文（ERS、[RFC4998]）に従って証拠レコードを検証する方法について説明します。
An Evidence Record contains a sequence of ArchiveTimeStampChains, which consist of ArchiveTimeStamps. For each ArchiveTimeStamp the hash algorithm used for the hash tree (digestAlgorithm) as well as the public key algorithm and hash algorithm in the timestamp signature have to be examined. The relevant date is the time information in the timestamp (date of issue). Starting with the first ArchiveTimeStamp, it has to be assured that:
エビデンスレコードには、ArchiveTimeStampsで構成されるArchiveTimeStampChainsのシーケンスが含まれています。 ArchiveTimeStampごとに、ハッシュツリー（digestAlgorithm）に使用されるハッシュアルゴリズム、およびタイムスタンプ署名の公開鍵アルゴリズムとハッシュアルゴリズムを調べる必要があります。関連する日付は、タイムスタンプ（発行日）の時間情報です。最初のArchiveTimeStampから始めて、次のことを保証する必要があります。
1. The timestamp uses public key and hash algorithms that were suitable at the date of issue.
1. タイムスタンプは、発行日に適した公開鍵とハッシュアルゴリズムを使用します。
2. The hashtree was built with a hash algorithm that was suitable at the date of issue as well.
2. ハッシュツリーは、発行日にも適したハッシュアルゴリズムを使用して作成されました。
3. Algorithms for timestamp and hashtree in the preceding ArchiveTimeStamp must have been suitable at the issuing date of considered ArchiveTimeStamp.
3. 前述のArchiveTimeStampのタイムスタンプとハッシュツリーのアルゴリズムは、考慮されたArchiveTimeStampの発行日に適している必要があります。
4. Algorithms in the last ArchiveTimeStamp have to be suitable now.
4. 最後のArchiveTimeStampのアルゴリズムは、現在適切である必要があります。
If the check of one of these items fails, this will lead to a failure of the verification.
これらの項目のいずれかのチェックが失敗すると、検証が失敗します。
This section describes how to store a policy in an Evidence Record. ERS provides the field cryptoInfos for the storage of additional verification data. For the integration of a security suitability policy in an Evidence Record, the following content types are defined for both ASN.1 and XML representation:
このセクションでは、ポリシーを証拠レコードに格納する方法について説明します。 ERSは、追加の検証データを格納するためのフィールドcryptoInfosを提供します。セキュリティ適合性ポリシーをエビデンスレコードに統合するために、ASN.1とXMLの両方の表現に対して次のコンテンツタイプが定義されています。
DSSC_ASN1 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-ct(1) id-ct-dssc-asn1(2) }
DSSC_XML {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-ct(1) id-ct-dssc-xml(3) }
Appendix B. XML Schema (Normative)
付録B. XMLスキーマ（規定）
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dssc="urn:ietf:params:xml:ns:dssc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:dssc"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="xmldsig-core-schema.xsd"/>
<xs:element name="SecuritySuitabilityPolicy"
type="dssc:SecuritySuitabilityPolicyType"/>
<xs:complexType name="SecuritySuitabilityPolicyType">
<xs:sequence>
<xs:element ref="dssc:PolicyName"/>
<xs:element ref="dssc:Publisher"/>
<xs:element name="PolicyIssueDate" type="xs:dateTime"/>
<xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Usage" type="xs:string" minOccurs="0"/>
<xs:element ref="dssc:Algorithm" maxOccurs="unbounded"/>
<xs:element ref="ds:Signature" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="1"/>
<xs:attribute name="lang" default="en"/>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
<xs:element name="PolicyName" type="dssc:PolicyNameType"/>
<xs:complexType name="PolicyNameType">
<xs:sequence>
<xs:element ref="dssc:Name"/>
<xs:element ref="dssc:ObjectIdentifier" minOccurs="0"/>
<xs:element ref="dssc:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Publisher" type="dssc:PublisherType"/>
<xs:complexType name="PublisherType">
<xs:sequence>
<xs:element ref="dssc:Name"/>
<xs:element name="Address" type="xs:string" minOccurs="0"/>
<xs:element ref="dssc:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Name" type="xs:string"/>
<xs:element name="ObjectIdentifier">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="(\d+\.)+\d+"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="URI" type="xs:anyURI"/>
<xs:element name="Algorithm" type="dssc:AlgorithmType"/>
<xs:complexType name="AlgorithmType">
<xs:sequence>
<xs:element ref="dssc:AlgorithmIdentifier"/>
<xs:element ref="dssc:Evaluation" maxOccurs="unbounded"/>
<xs:element ref="dssc:Information" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="AlgorithmIdentifier"
type="dssc:AlgorithmIdentifierType"/>
<xs:complexType name="AlgorithmIdentifierType">
<xs:sequence>
<xs:element ref="dssc:Name"/>
<xs:element ref="dssc:ObjectIdentifier" maxOccurs="unbounded"/>
<xs:element ref="dssc:URI" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Validity" type="dssc:ValidityType"/>
<xs:complexType name="ValidityType">
<xs:sequence>
<xs:element name="Start" type="xs:date" minOccurs="0"/>
<xs:element name="End" type="xs:date" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Information" type="dssc:InformationType"/>
<xs:complexType name="InformationType">
<xs:sequence>
<xs:element name="Text" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Evaluation" type="dssc:EvaluationType"/>
<xs:complexType name="EvaluationType">
<xs:sequence>
<xs:element ref="dssc:Parameter" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="dssc:Validity"/>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Parameter" type="dssc:ParameterType"/>
<xs:complexType name="ParameterType">
<xs:sequence>
<xs:element name="Min" type="xs:int" minOccurs="0"/>
<xs:element name="Max" type="xs:int" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
</xs:schema>
Appendix C. ASN.1 Module in 1988 Syntax (Informative)
付録C.1988年版ASN.1モジュールの構文（参考）
ASN.1-Module
ASN.1-モジュール
DSSC {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-dssc88(6) id-mod-dssc88-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORT ALL --
-すべてエクスポート-
IMPORTS
輸入
-- Import from RFC 5280 [RFC5280]
-- Delete following import statement
-- if "new" types are supported
UTF8String FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Import from RFC 5652 [RFC5652]
-RFC 5652 [RFC5652]からのインポート
ContentInfo FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24)}
;
；
SecuritySuitabilityPolicy ::= ContentInfo
-- contentType is id-signedData as defined in [RFC5652]
-- content is SignedData as defined in [RFC5652]
-- eContentType within SignedData is id-ct-dssc
-- eContent within SignedData is TBSPolicy
id-ct-dssc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) }
TBSPolicy ::= SEQUENCE {
version INTEGER DEFAULT {v1(1)},
language UTF8String DEFAULT "en",
policyName PolicyName,
publisher Publisher,
policyIssueDate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
usage UTF8String OPTIONAL,
algorithms SEQUENCE OF Algorithm
}
PolicyName ::= SEQUENCE {
name UTF8String,
oid OBJECT IDENTIFIER OPTIONAL,
uri IA5String OPTIONAL
}
Publisher ::= SEQUENCE {
name UTF8String,
address [0] UTF8String OPTIONAL,
uri [1] IA5String OPTIONAL
}
Algorithm ::= SEQUENCE {
algorithmIdentifier AlgID,
evaluations SEQUENCE OF Evaluation,
information [0] SEQUENCE OF UTF8String OPTIONAL,
other [1] Extension OPTIONAL
}
Extension ::= SEQUENCE {
extensionType OBJECT IDENTIFIER,
extension ANY DEFINED BY extensionType
}
AlgID ::= SEQUENCE {
name UTF8String,
oid [0] SEQUENCE OF OBJECT IDENTIFIER,
uri [1] SEQUENCE OF IA5String OPTIONAL
}
Evaluation ::= SEQUENCE {
parameters [0] SEQUENCE OF Parameter OPTIONAL,
validity [1] Validity,
other [2] Extension OPTIONAL
}
Parameter ::= SEQUENCE {
name UTF8String,
min [0] INTEGER OPTIONAL,
max [1] INTEGER OPTIONAL,
other [2] Extension OPTIONAL
}
Validity ::= SEQUENCE {
start [0] GeneralizedTime OPTIONAL,
end [1] GeneralizedTime OPTIONAL
}
END
終わり
Appendix D. ASN.1 Module in 1997 Syntax (Normative)
付録D. 1997年のASN.1モジュールの構文（規範的）
ASN.1-Module
ASN.1-モジュール
DSSC {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-dssc(7) id-mod-dssc-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORT ALL --
-すべてエクスポート-
IMPORTS
輸入
-- Import from RFC 5280 [RFC5280]
-- Delete following import statement
-- if "new" types are supported
UTF8String FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Import from RFC 5652 [RFC5652]
-RFC 5652 [RFC5652]からのインポート
ContentInfo FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24)}
;
；
SecuritySuitabilityPolicy ::= ContentInfo
-- contentType is id-signedData as defined in [RFC5652]
-- content is SignedData as defined in [RFC5652]
-- eContentType within SignedData is id-ct-dssc
-- eContent within SignedData is TBSPolicy
id-ct-dssc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) }
TBSPolicy ::= SEQUENCE {
version INTEGER DEFAULT {v1(1)},
language UTF8String DEFAULT "en",
policyName PolicyName,
publisher Publisher,
policyIssueDate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
usage UTF8String OPTIONAL,
algorithms SEQUENCE OF Algorithm
}
PolicyName ::= SEQUENCE {
name UTF8String,
oid OBJECT IDENTIFIER OPTIONAL,
uri IA5String OPTIONAL
}
Publisher ::= SEQUENCE {
name UTF8String,
address [0] UTF8String OPTIONAL,
uri [1] IA5String OPTIONAL
}
Algorithm ::= SEQUENCE {
algorithmIdentifier AlgID,
evaluations SEQUENCE OF Evaluation,
information [0] SEQUENCE OF UTF8String OPTIONAL,
other [1] Extension OPTIONAL
}
Extension ::= SEQUENCE {
extensionType EXTENSION-TYPE.&id ({SupportedExtensions}),
extension EXTENSION-TYPE.&Type
({SupportedExtensions}{@extensionType})
}
｝
EXTENSION-TYPE ::= TYPE-IDENTIFIER
SupportedExtensions EXTENSION-TYPE ::= {...}
AlgID ::= SEQUENCE {
name UTF8String,
oid [0] SEQUENCE OF OBJECT IDENTIFIER,
uri [1] SEQUENCE OF IA5String OPTIONAL
}
Evaluation ::= SEQUENCE {
parameters [0] SEQUENCE OF Parameter OPTIONAL,
validity [1] Validity,
other [2] Extension OPTIONAL
}
Parameter ::= SEQUENCE {
name UTF8String,
min [0] INTEGER OPTIONAL,
max [1] INTEGER OPTIONAL,
other [2] Extension OPTIONAL
}
Validity ::= SEQUENCE {
start [0] GeneralizedTime OPTIONAL,
end [1] GeneralizedTime OPTIONAL
}
END
終わり
The following example shows a policy that may be used for signature verification. It contains hash algorithms, public key algorithms, and signature schemes. SHA-1 as well as RSA with modulus length of 1024 are examples for expired algorithms.
次の例は、署名の検証に使用できるポリシーを示しています。ハッシュアルゴリズム、公開鍵アルゴリズム、および署名方式が含まれています。有効期限が切れたアルゴリズムの例として、SHA-1および1024のモジュラス長のRSAがあります。
<SecuritySuitabilityPolicy xmlns="urn:ietf:params:xml:ns:dssc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PolicyName>
<Name>Evaluation of cryptographic algorithms</Name>
</PolicyName>
<Publisher>
<Name>Some Evaluation Authority</Name>
</Publisher>
<PolicyIssueDate>2009-01-01T00:00:00</PolicyIssueDate>
<Usage>Digital signature verification</Usage>
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-1</Name>
<ObjectIdentifier>1.3.14.3.2.26</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Validity>
<End>2008-06-30</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-256</Name>
<ObjectIdentifier>2.16.840.1.101.3.4.2.1</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-512</Name>
<ObjectIdentifier>2.16.840.1.101.3.4.2.3</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>RSA</Name>
<ObjectIdentifier>1.2.840.113549.1.1.1</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="moduluslength">
<Min>1024</Min>
</Parameter>
<Validity>
<End>2008-03-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>2048</Min>
</Parameter>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>DSA</Name>
<ObjectIdentifier>1.2.840.10040.4.1</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="plength">
<Min>1024</Min>
</Parameter>
<Parameter name="qlength">
<Min>160</Min>
</Parameter>
<Validity>
<End>2007-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="plength">
<Min>2048</Min>
</Parameter>
<Parameter name="qlength">
<Min>224</Min>
</Parameter>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>PKCS#1 v1.5 SHA-1 with RSA</Name>
<ObjectIdentifier>1.2.840.113549.1.1.5</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="moduluslength">
<Min>1024</Min>
</Parameter>
<Validity>
<End>2008-03-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>2048</Min>
</Parameter>
<Validity>
<End>2008-06-30</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>PKCS#1 v1.5 SHA-256 with RSA</Name>
<ObjectIdentifier>1.2.840.113549.1.1.11</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="moduluslength">
<Min>1024</Min>
</Parameter>
<Validity>
<End>2008-03-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>2048</Min>
</Parameter>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>PKCS#1 v1.5 SHA-512 with RSA</Name>
<ObjectIdentifier>1.2.840.113549.1.1.13</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="moduluslength">
<Min>1024</Min>
</Parameter>
<Validity>
<End>2008-03-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>2048</Min>
</Parameter>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-1 with DSA</Name>
<ObjectIdentifier>1.2.840.10040.4.3</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="plength">
<Min>1024</Min>
</Parameter>
<Parameter name="qlength">
<Min>160</Min>
</Parameter>
<Validity>
<End>2007-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="plength">
<Min>2048</Min>
</Parameter>
<Parameter name="qlength">
<Min>224</Min>
</Parameter>
<Validity>
<End>2008-06-30</End>
</Validity>
</Evaluation>
</Algorithm>
</SecuritySuitabilityPolicy>
Authors' Addresses
著者のアドレス
Thomas Kunz Fraunhofer Institute for Secure Information Technology Rheinstrasse 75 Darmstadt D-64295 Germany
Thomas Kunz Fraunhofer Institute for Secure Information Technology Rheinstrasse 75ダルムシュタットD-64295ドイツ
EMail: thomas.kunz@sit.fraunhofer.de
Susanne Okunick pawisda systems GmbH Robert-Koch-Strasse 9 Weiterstadt D-64331 Germany
Susanne Okunick pawisda Systems GmbH Robert-Koch-Strasse 9ヴァイターシュタットD-64331ドイツ
EMail: susanne.okunick@pawisda.de
Ulrich Pordesch Fraunhofer Gesellschaft Rheinstrasse 75 Darmstadt D-64295 Germany
Ulrich Pordesch Fraunhofer Society Rheinstrasse 75ダルムシュタットD-64295ドイツ
EMail: ulrich.pordesch@zv.fraunhofer.de