[要約] RFC 5485は、インターネットドラフト文書におけるデジタル署名に関する標準仕様です。このRFCの目的は、インターネットドラフト文書の信頼性とセキュリティを向上させるために、デジタル署名の使用方法を定義することです。
Network Working Group R. Housley
Request for Comments: 5485 Vigil Security
Category: Informational March 2009
Digital Signatures on Internet-Draft Documents
インターネットドラフトドキュメントのデジタル署名
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.
このドキュメントは、インターネットドラフトのデジタル署名の規則を指定しています。暗号化メッセージ構文（CMS）は、デジタル署名の追加によって既存のユーティリティが影響を受けないように、別のコンパニオンファイルに保存されるデタッチされた署名を作成するために使用されます。
This document specifies the conventions for storing a digital signature on Internet-Drafts. The Cryptographic Message Syntax (CMS) [CMS] is used to create a detached signature. The signature is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.
このドキュメントは、インターネットドラフトにデジタル署名を保存するための規則を指定しています。暗号化メッセージ構文（CMS）[CMS]は、分離した署名を作成するために使用されます。署名は別のコンパニオンファイルに保存されているため、既存のユーティリティがデジタル署名の追加によって影響を受けません。
Shortly after the IETF Secretariat posts the Internet-Draft in the repository, the digital signature is generated and posted as a companion file in the same repository. The digital signature allows anyone to confirm that the contents of the Internet-Draft have not been altered since the time that the document was posted in the repository.
IETF事務局がリポジトリにインターネットドラフトを投稿した直後に、デジタル署名が生成され、同じリポジトリのコンパニオンファイルとして投稿されます。デジタル署名により、誰もがインターネットドラフトの内容がリポジトリに投稿されてから変更されていないことを確認できます。
The signature of the IETF Secretariat is intended to provide a straightforward way for anyone to determine whether a particular file contains the document that was made available by the IETF Secretariat. The signing-time included by the IETF Secretariat provides the wall-clock time; it is not intended to provide a trusted timestamp.
IETF事務局の署名は、特定のファイルがIETF事務局によって利用可能になったドキュメントが含まれているかどうかを判断するための簡単な方法を提供することを目的としています。IETF事務局に含まれる署名時間には、壁1杯の時間が提供されます。信頼できるタイムスタンプを提供することを意図したものではありません。
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 RFC 2119 [STDWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [stdwords]に記載されているとおりに解釈されます。
The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is a formal notation used for describing data protocols, regardless of the programming language used by the implementation. Encoding rules describe how the values defined in ASN.1 will be represented for transmission. The Basic Encoding Rules (BER) [X.690] are the most widely employed rule set, but they offer more than one way to represent data structures. For example, both definite-length encoding and indefinite-length encoding are supported. This flexibility is not desirable when digital signatures are used. As a result, the Distinguished Encoding Rules (DER) [X.690] were invented. DER is a subset of BER that ensures a single way to represent a given value. For example, DER always employs definite-length encoding.
CMSは、抽象的な構文表記1（asn.1）[x.680]を使用します。ASN.1は、実装で使用されるプログラミング言語に関係なく、データプロトコルの説明に使用される正式な表記です。エンコーディングルールは、ASN.1で定義されている値が送信のためにどのように表されるかを説明しています。基本的なエンコーディングルール（BER）[X.690]は、最も広く採用されているルールセットですが、データ構造を表現するための複数の方法を提供します。たとえば、明確な長さのエンコーディングと無期限の長さの両方のエンコードがサポートされています。この柔軟性は、デジタル署名を使用する場合、望ましくありません。その結果、著名なエンコードルール（der）[x.690]が発明されました。Derは、特定の値を表す単一の方法を保証するBERのサブセットです。たとえば、DERは常に明確な長さのエンコードを使用します。
All Internet-Draft file names begin with "draft-". The next portion of the file name depends on the source of the document. For example, documents from IETF working groups usually have "ietf-" followed by the working group abbreviation, and this is followed by a string that helps people figure out the subject of the document.
すべてのインターネットドラフトファイル名は「ドラフト」から始まります。ファイル名の次の部分は、ドキュメントのソースによって異なります。たとえば、IETFワーキンググループからのドキュメントには通常、「IETF」に続いてワーキンググループの略語が続き、これに続いて、人々がドキュメントの主題を把握するのに役立つ文字列が続きます。
All Internet-Draft file names end with a hyphen followed by a two-digit version number and a suffix. The suffix indicates the type of file. A plain text file with a suffix of ".txt" is required. Other formats may also be provided, and they employ the appropriate suffix for the file format.
すべてのインターネットドラフトファイル名はハイフンで終わり、2桁のバージョン番号とサフィックスが続きます。接尾辞はファイルのタイプを示します。「.txt」の接尾辞を備えたプレーンテキストファイルが必要です。他の形式も提供される場合があり、ファイル形式に適切なサフィックスを使用します。
The companion signature file has exactly the same file name as the Internet-Draft, except that ".p7s" is added to the end. This file name suffix conforms to the conventions in [MSG]. Here are a few example names:
コンパニオンシグネチャファイルのファイル名は、インターネットドラフトとまったく同じファイル名ですが、「.p7s」が最後に追加されます。このファイル名の接尾辞は、[MSG]の規則に準拠しています。ここにいくつかの例があります：
Internet-Draft: draft-ietf-example-widgets-03.txt Signature File: draft-ietf-example-widgets-03.txt.p7s
インターネットドラフト：draft-itef-example-widgets-03.txt署名ファイル：draft-itf-example-widgets-03.txt.p7s
Internet-Draft: draft-ietf-example-widgets-03.ps Signature File: draft-ietf-example-widgets-03.ps.p7s
インターネットドラフト：Draft-ITETF-Example-Widgets-03.PS Signature File：Draft-ITETF-Example-Widgets-03.PS.P7S
Internet-Draft: draft-housley-internet-draft-sig-file-00.txt Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s
インターネットドラフト：Draft-Housley-Internet-Draft-Sig-File-00.txt署名ファイル：Draft-Housley-Internet-Draft-Sig-File-00.txt.p7s
The IETF Secretariat will post the signature file in the repository shortly after the Internet-Draft is posted.
IETF事務局は、インターネットドラフトが投稿された直後に署名ファイルをリポジトリに投稿します。
In general, the content of the Internet-Draft is treated like a single octet string for the generation of the digital signature. Unfortunately, the plain text file requires canonicalization to avoid signature validation problems. The primary concern is the manner in which different operating systems indicate the end of a line of text. Some systems use a single new-line character, other systems use the combination of the carriage-return character followed by a line-feed character, and other systems use fixed-length records padded with space characters. For the digital signature to validate properly, a single convention must be employed.
一般に、インターネットドラフトのコンテンツは、デジタル署名の生成のための単一のオクテット文字列のように扱われます。残念ながら、プレーンテキストファイルでは、署名の検証の問題を回避するために標準化が必要です。主な関心事は、異なるオペレーティングシステムがテキストの行の終わりを示す方法です。一部のシステムでは、単一の新しいライン文字を使用し、他のシステムはキャリッジリターン文字の組み合わせに続いてラインフィード文字が使用され、他のシステムはスペース文字がパッド付きの固定長レコードを使用します。デジタル署名が適切に検証するには、単一の条約を採用する必要があります。
The canonicalization procedure follows the conventions used for text files in the File Transfer Protocol (FTP) [FTP]. Such files must be supported by FTP implementations, so code reuse seems likely.
標準化手順は、ファイル転送プロトコル（FTP）[FTP]のテキストファイルに使用される規則に従います。このようなファイルはFTP実装によってサポートされる必要があるため、コードの再利用の可能性が高いようです。
The canonicalization procedure converts the data from its internal character representation to the standard 8-bit NVT-ASCII representation (see TELNET [TELNET]). In accordance with the NVT standard, the <CRLF> sequence MUST be used to denote the end of a line of text. Using the standard NVT-ASCII representation means that data MUST be interpreted as 8-bit bytes.
標準化手順は、データをその内部文字表現から標準の8ビットNVT-ASCII表現に変換します（Telnet [Telnet]を参照）。NVT標準に従って、<CRLF>シーケンスを使用して、テキストの行の終わりを示す必要があります。標準のNVT-ASCII表現を使用すると、データは8ビットバイトとして解釈する必要があることを意味します。
Trailing space characters MUST NOT appear on a line of text. That is, the space character must not be followed by the <CRLF> sequence. Thus, a blank line is represented solely by the <CRLF> sequence.
トレーリングスペースの文字は、テキストの行に表示されてはなりません。つまり、スペース文字の後に<CRLF>シーケンスを続けてはなりません。したがって、空白線は<CRLF>シーケンスでのみ表されます。
The form-feed nonprintable character (0x0C) is expected in Internet-Drafts. Other nonprintable characters, such as tab and backspace, are not expected, but they do occur. For robustness, any nonprintable or non-ASCII characters (ones outside the range 0x20 to 0x7E) MUST NOT be changed in any way not covered by the rules for end-of-line handling in the previous paragraph.
インターネットドラフトでは、フォームフィードの非印刷可能な文字（0x0C）が予想されます。タブやバックスペースなどの他の印刷できない文字は予想されませんが、それらは発生します。堅牢性のために、前の段落での終了処理のルールでカバーされない方法で、印刷できないまたは非ASCII文字（範囲0x20〜0x7eの外側）を変更してはなりません。
Trailing blank lines MUST NOT appear at the end of the file. That is, the file must not end with multiple consecutive <CRLF> sequences.
後続の空白線は、ファイルの最後に表示されてはなりません。つまり、ファイルは複数の連続した<CRLF>シーケンスで終了してはなりません。
Any end-of-file marker used by an operating system is not considered to be part of the file content. When present, such end-of-file markers MUST NOT be processed by the digital signature algorithm.
オペレーティングシステムで使用されるファイル終了マーカーは、ファイルコンテンツの一部であるとは見なされません。存在する場合、そのようなファイル終了マーカーをデジタル署名アルゴリズムによって処理してはなりません。
Note: This text file canonicalization procedure is consistent with the ASCII NVT definition offered in Appendix B of RFC 5198 [UFNI].
注：このテキストファイルの正規化手順は、RFC 5198 [UFNI]の付録Bで提供されているASCII NVT定義と一致しています。
In accordance with the guidance of the World Wide Web Consortium (W3C) in Section 2.11 of [R20060816], a <LF> character MUST be used to denote the end of a line of text within an XML file. Any two-character <CRLF> sequence and any <CR> that is not followed by <LF> are to be translated to a single <LF> character.
[R20060816]のセクション2.11におけるWorld Wide Webコンソーシアム（W3C）のガイダンスに従って、XMLファイル内のテキスト行の終わりを示すために<LF>文字を使用する必要があります。2文字<CRLF>シーケンスと<CR>は、<LF>が続いていない<CR>は、単一の<LF>文字に翻訳されます。
No canonicalization is needed for file formats currently used for Internet-Drafts other than plain text files and XML files. Other file formats are treated as a simple sequence of octets by the digital signature algorithm.
プレーンテキストファイルやXMLファイル以外のインターネットドラフトに現在使用されているファイル形式には、標準化は必要ありません。他のファイル形式は、デジタル署名アルゴリズムによってオクテットの単純なシーケンスとして扱われます。
CMS is used to construct the detached signature of the Internet-Draft. The CMS ContentInfo content type MUST always be present, and it MUST encapsulate the CMS SignedData content type. Since a detached signature is being created, the CMS SignedData content type MUST NOT encapsulate the Internet-Draft. The CMS detached signature is summarized by:
CMSは、インターネットドラフトの分離署名を構築するために使用されます。CMS ContentInfoコンテンツタイプは常に存在する必要があり、CMS SignedDataコンテンツタイプをカプセル化する必要があります。分離された署名が作成されているため、CMS署名Dataコンテンツタイプはインターネットドラフトをカプセル化してはなりません。CMSデタッチされた署名は、次のように要約されています。
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Secretariat certificate(s)
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one signer
}
SignerInfo {
version CMSVersion, -- Always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Always present
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
EncapsulatedContentInfo {
eContentType id-ct-asciiTextWithCRLF,
-- (1.2.840.113549.1.9.16.1.27)
eContent OCTET STRING -- Always absent
}
The CMS requires the outer-most encapsulation to be ContentInfo [CMS]. The fields of ContentInfo are used as follows:
CMSでは、最も外側のカプセル化がcontentinfo [cms]である必要があります。ContentInfoのフィールドは次のように使用されます。
contentType indicates the type of the associated content. For the detached Internet-Draft signature file, the encapsulated type is always SignedData, so the id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field.
contentType関連するコンテンツのタイプを示します。分離されたインターネットドラフト署名ファイルの場合、カプセル化されたタイプは常に署名されているため、ID-SignedData（1.2.840.113549.1.7.2）オブジェクト識別子がこのフィールドに存在する必要があります。
content holds the content. For the detached Internet-Draft signature file, the content is always a SignedData content.
コンテンツはコンテンツを保持します。分離されたインターネットドラフト署名ファイルの場合、コンテンツは常にSignedDataコンテンツです。
The SignedData content type [CMS] contains the signature of the Internet-Draft and information to aid in the validation of that signature. The fields of SignedData are used as follows:
SignedDataコンテンツタイプ[CMS]には、インターネットドラフトの署名とその署名の検証を支援する情報が含まれています。SignedDataのフィールドは次のように使用されます。
version is the syntax version number. For this specification, the version number MUST be set to 3.
バージョンは構文バージョン番号です。この仕様では、バージョン番号を3に設定する必要があります。
digestAlgorithms is a collection of one-way hash function identifiers. It MUST contain the identifier used by the IETF Secretariat to generate the digital signature. See the discussion of digestAlgorithm in Section 3.2.1.
Digestalgorithmsは、一方向ハッシュ関数識別子のコレクションです。IETF事務局がデジタル署名を生成するために使用する識別子を含める必要があります。セクション3.2.1の消化器gorthmの説明を参照してください。
encapContentInfo is the signed content, including a content type identifier. Since a detached signature is being created, it does not encapsulate the Internet-Draft. The use of the EncapsulatedContentInfo type is discussed further in Section 3.2.2.
EncapContentInfoは、コンテンツタイプ識別子を含む署名されたコンテンツです。独立した署名が作成されているため、インターネットドラフトをカプセル化しません。concapsulatedContentInfoタイプの使用については、セクション3.2.2でさらに説明します。
certificates is an optional collection of certificates. It SHOULD include the X.509 certificate needed to validate the digital signature value. Certification Authority (CA) certificates and end entity certificates MUST conform to the certificate profile specified in [PKIX1].
証明書は、オプションの証明書のコレクションです。デジタル署名値を検証するために必要なX.509証明書を含める必要があります。認証局（CA）証明書およびエンティティ証明書は、[PKIX1]で指定された証明書プロファイルに準拠する必要があります。
crls is an optional collection of certificate revocation lists (CRLs). It SHOULD NOT include any CRLs; however, any CRLs that are present MUST conform to the CRL profile specified in [PKIX1].
CRLSは、証明書取消リスト（CRLS）のオプションのコレクションです。CRLSを含めるべきではありません。ただし、存在するCRLは、[PKIX1]で指定されたCRLプロファイルに適合する必要があります。
signerInfos is a collection of per-signer information. For this specification, each item in the collection must represent the IETF Secretariat. More than one SignerInfo MAY appear to facilitate transitions between keys or algorithms. The use of the SignerInfo type is discussed further in Section 3.2.1.
SignerInfosは、署名者ごとの情報のコレクションです。この仕様では、コレクション内の各アイテムはIETF事務局を表す必要があります。複数のSignerinfoがキーまたはアルゴリズム間の遷移を容易にするように見える場合があります。SignerINFOタイプの使用については、セクション3.2.1でさらに説明します。
The IETF Secretariat is represented in the SignerInfo type. The fields of SignerInfo are used as follows:
IETF事務局は、Signerinfoタイプで表されます。Signerinfoのフィールドは次のように使用されます。
version is the syntax version number. In this specification, the version MUST be set to 3.
バージョンは構文バージョン番号です。この仕様では、バージョンを3に設定する必要があります。
sid identifies the IETF Secretariat's public key. In this specification, the subjectKeyIdentifier alternative is always used, which identifies the public key directly. This identifier MUST match the value included in the subjectKeyIdentifier certificate extension in the IETF Secretariat's X.509 certificate.
SIDは、IETF事務局の公開鍵を識別します。この仕様では、SubjectKeyIdentifierの代替案が常に使用され、公開キーを直接識別します。この識別子は、IETF事務局のX.509証明書のSubjectKeyIdentifier証明書延長に含まれる値と一致する必要があります。
digestAlgorithm identifies the one-way hash function, and any associated parameters, used by the IETF Secretariat to generate the digital signature.
Digestalgorithmは、Digital Signatureを生成するためにIETF事務局が使用する一元配置ハッシュ関数と、関連するパラメーターを識別します。
signedAttrs is an optional set of attributes that are signed along with the content. The signedAttrs are optional in the CMS, but signedAttrs is required by this specification. The SET OF Attribute must be encoded with the distinguished encoding rules (DER) [X.690]. Section 3.2.3 of this document lists the signed attributes that MUST be included in the collection. Other signed attributes MAY also be included.
SigneDattrsは、コンテンツとともに署名されたオプションの属性セットです。SigneDattrsはCMSではオプションですが、この仕様ではSigneDattrsが必要です。一連の属性は、識別式エンコードルール（der）[x.690]でエンコードする必要があります。このドキュメントのセクション3.2.3には、コレクションに含める必要がある署名された属性をリストします。その他の署名された属性も含めることができます。
signatureAlgorithm identifies the digital signature algorithm, and any associated parameters, used by the IETF Secretariat to generate the digital signature.
SignatureAlgorithmは、IETF Secretariatがデジタル署名を生成するために使用するデジタル署名アルゴリズムと、関連するパラメーターを識別します。
signature is the digital signature value generated by the IETF Secretariat.
署名は、IETF事務局によって生成されたデジタル署名値です。
unsignedAttrs is an optional set of attributes that are not signed. Unsigned attributes are usually omitted; however, the unsigned attributes MAY hold a trusted timestamp generated in accordance with [TSP]. Appendix A of [TSP] provides more information about this unsigned attribute.
Unsignedattrsは、署名されていないオプションの属性セットです。通常、署名されていない属性は省略されています。ただし、署名されていない属性は、[TSP]に従って生成された信頼できるタイムスタンプを保持する場合があります。[TSP]の付録Aでは、この署名されていない属性の詳細について説明します。
The EncapsulatedContentInfo structure contains a content type identifier. Since a detached signature is being created, it does not encapsulate the Internet-Draft. The fields of EncapsulatedContentInfo are used as follows:
cancopturatedContentInfo構造には、コンテンツ型識別子が含まれています。独立した署名が作成されているため、インターネットドラフトをカプセル化しません。cankulatedContentInfoのフィールドは次のように使用されます。
eContentType is an object identifier that uniquely specifies the content type. The content type associated with the plain text file MUST be id-ct-asciiTextWithCRLF. Other file formats may also be posted, and the appropriate content type for each format is discussed in Section 4. Additional file formats can be added if the Internet community chooses.
EcontentTypeは、コンテンツタイプを一意に指定するオブジェクト識別子です。プレーンテキストファイルに関連付けられているコンテンツタイプは、ID-CT-ASCIITEXTWITHCRLFでなければなりません。他のファイル形式も投稿される場合があり、各形式の適切なコンテンツタイプについてセクション4で説明します。インターネットコミュニティが選択した場合、追加ファイル形式を追加できます。
eContent is optional. When an encapsulated signature is generated, the content to be signed is carried in this field. Since a detached signature is being created, eContent MUST be absent.
econtentはオプションです。カプセル化された署名が生成されると、署名されるコンテンツがこのフィールドで運ばれます。独立した署名が作成されているため、econtentは存在しない必要があります。
The IETF Secretariat MUST digitally sign a collection of attributes along with the Internet-Draft. Each attribute in the collection MUST be DER-encoded. The syntax for attributes is defined in [X.501], and the X.500 Directory provides a rich attribute syntax. A very simple subset of this syntax is used extensively in [CMS], where ATTRIBUTE.&Type and ATTRIBUTE.&id are the only parts of the ATTRIBUTE class that are employed.
IETF事務局は、インターネットドラフトとともに属性のコレクションにデジタル的に署名する必要があります。コレクション内の各属性は、der-Encodedでなければなりません。属性の構文は[x.501]で定義されており、x.500ディレクトリはリッチ属性構文を提供します。この構文の非常にシンプルなサブセットは、[CMS]で広く使用されています。ここでは、属性。＆タイプと属性。＆IDは、使用されている属性クラスの唯一の部分です。
Each of the attributes used with this CMS profile has a single attribute value. Even though the syntax is defined as a SET OF AttributeValue, there MUST be exactly one instance of AttributeValue present.
このCMSプロファイルで使用される各属性には、単一の属性値があります。構文は属性のセットとして定義されていますが、属性の存在の1つのインスタンスが正確に1つある必要があります。
The SignedAttributes syntax within signerInfo is defined as a SET OF Attribute. The SignedAttributes MUST include only one instance of any particular attribute.
SignerInfo内のSigneDattributes構文は、属性のセットとして定義されます。SigneDattributesには、特定の属性の1つのインスタンスのみを含める必要があります。
The IETF Secretariat MUST include the content-type, message-digest, and signing-time attributes. The IETF Secretariat MAY also include the binary-signing-time signed attribute as well as any other attribute that is deemed appropriate. The intent is to allow additional signed attributes to be included if a future need is identified. This does not cause an interoperability concern because unrecognized signed attributes are ignored at verification.
IETF事務局には、コンテンツタイプ、メッセージダイジスト、および署名時間属性を含める必要があります。IETF事務局には、適切と見なされる他の属性と同様に、バイナリ署名時間署名属性も含まれる場合があります。意図は、将来のニーズが特定された場合、追加の署名属性を含めることを許可することです。認識されていない署名された属性が検証時に無視されるため、これは相互運用性の懸念を引き起こしません。
A content-type attribute is required to contain the same object identifier as the content type contained in the EncapsulatedContentInfo. The appropriate content type for each format is discussed in Section 4. The IETF Secretariat MUST include a content-type attribute containing the appropriate content type. Section 11.1 of [CMS] defines the content-type attribute.
Content-Type属性は、capsulatedContentInfoに含まれるコンテンツタイプと同じオブジェクト識別子を含める必要があります。各形式の適切なコンテンツタイプについては、セクション4で説明します。IETF事務局には、適切なコンテンツタイプを含むコンテンツタイプの属性を含める必要があります。[CMS]のセクション11.1は、コンテンツタイプの属性を定義します。
The IETF Secretariat MUST include a message-digest attribute, having as its value the output of a one-way hash function computed on the Internet-Draft that is being signed. Section 11.2 of [CMS] defines the message-digest attribute.
IETF事務局には、署名されているインターネットドラフトで計算された一方向ハッシュ関数の出力を値として、メッセージダイジェスト属性を含める必要があります。[CMS]のセクション11.2は、メッセージダイジスト属性を定義しています。
The IETF Secretariat MUST include a signing-time attribute, specifying the time, based on the local system clock, at which the digital signature was applied to the Internet-Draft. Since the IETF Secretariat may choose to perform signatures in batches, the signing-time may be several hours or days after the time that the Internet-Draft was actually posted. Section 11.3 of [CMS] defines the content-type attribute.
IETF事務局には、インターネットドラフトにデジタル署名が適用されたローカルシステムクロックに基づいて、時間を指定する署名時間属性を含める必要があります。IETF事務局はバッチで署名を実行することを選択する可能性があるため、署名時間は、インターネットドラフトが実際に掲載された時間から数時間または数日後になる場合があります。[CMS]のセクション11.3は、コンテンツタイプの属性を定義します。
The IETF Secretariat MAY include a binary-signing-time attribute, specifying the time at which the digital signature was applied to the Internet-Draft. If present, the time that is represented MUST match the time represented in the signing-time attribute. The binary-signing-time attribute is defined in [BinTime].
IETF事務局には、デジタル署名がインターネットドラフトに適用された時間を指定するバイナリ署名時間属性が含まれる場合があります。存在する場合、表される時間は、署名時の属性で表される時間と一致する必要があります。バイナリ署名時間属性は[Bintime]で定義されます。
Unsigned attributes are usually omitted. However, an unsigned attribute MAY hold a trusted timestamp generated in accordance with [TSP]. The idea is to timestamp the IETF Secretariat digital signature to prove that it was created before a given time. If the IETF Secretariat's certificate is revoked the timestamp allows a verifier to know whether the signature was created before or after the revocation date. Appendix A of [TSP] defines the signature time-stamp attribute that can be used to timestamp a digital signature.
通常、署名されていない属性は省略されています。ただし、署名されていない属性は、[TSP]に従って生成された信頼できるタイムスタンプを保持する場合があります。アイデアは、IETF事務局のデジタル署名をタイムスタンプして、特定の時間より前に作成されたことを証明することです。IETF事務局の証明書が取り消された場合、タイムスタンプにより、Verifierは署名が取り消し日の前または後に作成されたかどうかを知ることができます。[TSP]の付録Aは、デジタル署名のタイムスタンプに使用できる署名タイムスタンプ属性を定義しています。
This section lists the content types that are used in this specification. The eContentType field as described in Section 3.2.2 contains a content type identifier, and the same value appears in the content-type attribute as described in Section 3.2.3.1.
このセクションには、この仕様で使用されるコンテンツタイプをリストします。セクション3.2.2で説明されているEcontentTypeフィールドには、コンテンツ型識別子が含まれており、セクション3.2.3.1で説明されているように、コンテンツタイプの属性に同じ値が表示されます。
The following table lists the file formats and the associated content type.
File Format Content Type
----------- ------------
Plain text id-ct-asciiTextWithCRLF
Extensible Markup Language (XML) id-ct-xml
Portable Document Format (PDF) id-ct-pdf
PostScript id-ct-postscript
The object identifiers associated with the content types listed in the above table are:
上記の表にリストされているコンテンツタイプに関連付けられているオブジェクト識別子は次のとおりです。
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 }
id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }
id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }
The IETF Secretariat MUST protect its private key. The use of a hardware security module (HSM) is strongly RECOMMENDED because compromise of the IETF Secretariat's private key permits masquerade.
IETF事務局は、秘密鍵を保護する必要があります。IETF事務局の秘密鍵の妥協が仮面舞踏会を許可するため、ハードウェアセキュリティモジュール（HSM）の使用は強くお勧めします。
The IETF Secretariat currently maintains servers at a primary location and a backup location. This configuration requires two HSMs, one at each location. However, the two HSMs do not need to use the same signing key. Each HSM can have a different signing key, as long as each one has their own certificate.
IETF事務局は現在、主要な場所とバックアップ場所にサーバーを維持しています。この構成には、各場所に1つずつ2つのHSMが必要です。ただし、2つのHSMは同じ署名キーを使用する必要はありません。各HSMには、それぞれが独自の証明書を持っている限り、異なる署名キーを持つことができます。
The generation of a public/private key pair for signature operations relies on random number generation. The use of an inadequate pseudo-random number generator (PRNG) can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the key pair, searching the resulting small set of possibilities, than to brute-force search the whole private key space. The generation of quality random numbers is difficult, but [RANDOM] offers important guidance in this area.
署名操作のためのパブリック/プライベートキーペアの生成は、乱数の生成に依存しています。不十分な擬似ランダム数ジェネレーター（PRNG）を使用すると、セキュリティがほとんどまたはまったくなりません。攻撃者は、主要なペアを検索して、主要なキーペア全体を検索するよりも、主要なペアを生成するPRNG環境を再現する方がはるかに簡単になる場合があります。品質の乱数の生成は困難ですが、[ランダム]はこの分野で重要なガイダンスを提供します。
The IETF Secretariat should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular digital signature algorithm or one-way hash function will be reduced. Therefore, it SHOULD be possible to migrate these algorithms. That is, the IETF Secretariat SHOULD be prepared for the supported algorithms to change over time.
IETF事務局は、暗号化アルゴリズムが時間とともに弱くなることに注意する必要があります。新しい暗号化技術が開発され、コンピューティングのパフォーマンスが向上すると、特定のデジタル署名アルゴリズムまたは一方向ハッシュ関数を破る作業要因が削減されます。したがって、これらのアルゴリズムを移行できるはずです。つまり、IETF事務局は、サポートされているアルゴリズムが時間の経過とともに変更されるために準備する必要があります。
The IETF Secretariat must take care to use the correct time in signing-time and binary-signing-time attributes. The inclusion of a date within the Internet-Draft by the authors that is shortly before the signing time attributes supplied by the IETF Secretariat provides confidence about the date that the Internet-Draft was posted to the repository. However, the IETF Secretariat may choose to perform signatures in batches, and the signing-time may be several hours or days after the time that the Internet-Draft was actually posted.
IETF事務局は、署名時およびバイナリ署名時間の属性で正しい時間を使用するように注意する必要があります。IETF事務局が提供する署名時間属性の直前にインターネットドラフト内に日付を含めることは、インターネットドラフトがリポジトリに掲載された日付について自信を与えます。ただし、IETF事務局はバッチで署名を実行することを選択する場合があり、署名時間は、インターネットドラフトが実際に掲載された時間から数時間または数日後になる場合があります。
As stated above, the IETF Secretariat may choose to sign Internet-Drafts in batches. This allows a single HSM to be used if multiple servers are located in one geographic location, and it allows the HSM to be off-line except when signatures are being generated. Further, this allows the IETF Secretariat to include manual steps, such as entering an HSM passphrase or inserting a smartcard, as part of the signing procedure to improve operations security.
上記のように、IETF事務局は、バッチでインターネットドラフトに署名することを選択できます。これにより、複数のサーバーが1つの地理的位置に配置されている場合、単一のHSMを使用でき、署名が生成されている場合を除き、HSMをオフラインにすることができます。さらに、これにより、IETF事務局は、運用セキュリティを改善するための署名手順の一部として、HSMパスフレーズの入力やSmartCardの挿入など、手動の手順を含めることができます。
The private key used to generate the IETF Secretariat signature ought to be stored in an HSM to provide protection from unauthorized disclosure. While the HSM will be operated by the IETF Secretariat, it ought to be owned by the IETF Trust. Accordingly, the Trustees of the IETF Trust will designate an appropriate certification authority to issue a certificate to the IETF Secretariat, and they will approve any procedures used by the IETF Secretariat for signing documents consistent with this specification.
IETF事務局の署名を生成するために使用される秘密鍵は、不正な開示からの保護を提供するためにHSMに保存されるべきです。HSMはIETF事務局によって運営されますが、IETF Trustが所有する必要があります。したがって、IETF Trustの受託者は、IETF事務局に証明書を発行する適切な認証機関を指定し、IETF事務局がこの仕様と一致する文書に署名するために使用する手順を承認します。
A detached signature is used for all file formats. Some file formats, such as PDF and XML, have file-format-specific ways of handling digital signatures. These file-format-specific approaches are not used for two reasons. First, a single way to sign Internet-Drafts will ease implementation by the IETF Secretariat. Second, if the author includes a signature using one of these file-format-specific approaches, the IETF Secretariat signature does not harm it in any way.
すべてのファイル形式に分離された署名が使用されます。PDFやXMLなどの一部のファイル形式には、デジタル署名を処理するファイル形式固有の方法があります。これらのファイル形式固有のアプローチは、2つの理由で使用されません。まず、インターネットドラフトに署名する単一の方法は、IETF事務局による実装を容易にします。第二に、著者がこれらのファイル形式固有のアプローチのいずれかを使用して署名を含めた場合、IETF事務局の署名はそれを決して害しません。
File names are the means linking the detached signature to the signed document. A CMS signed attribute could have been specified to include another form of linkage, and this could be added in the future. At this point in time, it is important to support signature validation of expired Internet-Drafts that are obtained from non-IETF repositories. Therefore, the appropriate value for such a signed attribute is unclear. This specification allows an Internet-Draft and companion signature file to be stored anywhere without hindering signature validation.
ファイル名は、分離された署名を署名されたドキュメントにリンクする手段です。CMS署名属性は、別の形式のリンケージを含めるように指定されている可能性があり、これは将来追加される可能性があります。この時点で、非ITFリポジトリから取得した期限切れのインターネットドラフトの署名検証をサポートすることが重要です。したがって、そのような署名された属性に対する適切な値は不明です。この仕様により、署名の検証を妨げることなく、インターネットドラフトとコンパニオン署名ファイルをどこにでも保存できます。
The idea for the Internet-Draft signature file came from a discussion with Scott Bradner at IETF 69 in Chicago. Many helpful suggestions came from Jim Schaad, Pasi Eronen, and Chris Newman.
インターネットドラフト署名ファイルのアイデアは、シカゴのIETF 69でのスコットブラッドナーとの議論から来ました。多くの有益な提案は、ジム・シャード、パシ・エロネン、クリス・ニューマンから来ました。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[PKIX1] 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.
[PKIX1] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、「Internet X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[stdwords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[X.680] ITU-T Recommendation X.680: ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation, 2002.
[X.680] ITU-T推奨X.680：ISO/IEC 8824-1：2002、情報技術 - 抽象的構文表記1（ASN.1）：基本表記の仕様、2002。
[X.690] ITU-T Recommendation X.690: ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 2002.
[X.690] ITU-Tの推奨X.690：ISO/IEC 8825-1：2002、情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、標準エンコーディングルール（CER）、および区別されたエンコードルールの仕様（der）、2002年。
[BinTime] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 4049, April 2005.
[Bintime] Housley、R。、「Binarytime：Asn.1で日付と時刻を表すための代替形式」、RFC 4049、2005年4月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[MSG] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[OpenSSL] "OpenSSL: The Open Source toolkit for SSL/TLS", http://www.openssl.org/.
[OpenSSL] "OpenSSL：SSL/TLS用のオープンソースツールキット"、http://www.openssl.org/。
[R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, 16 August 2006, http://www.w3.org/TR/2006/REC-xml-20060816/.
[R20060816] Bray、T.、J。Paoli、C。M。Sperberg-Mcqueen、E。Maler、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第4版）」、W3C推奨、2006年8月16日、http：//www.w3.org/tr/2006/rec-xml-20060816/
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[Telnet] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[TSP] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「インターネットX.509公開キーインフラストラクチャタイムスタンププロトコル（TSP）」、RFC 3161、2001年8月。
[UFNI] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[UFNI] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年3月。
[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
[X.501] ITU -Tの推奨X.501：情報技術 - オープンシステムの相互接続 - ディレクトリ：モデル、1993。
Appendix: A
付録：a
OpenSSL 0.9.9 [OpenSSL] includes an implementation of CMS. The following command line can be used to verify an Internet-Draft signature:
OpenSSL 0.9.9 [OpenSSL]には、CMSの実装が含まれます。次のコマンドラインを使用して、インターネットドラフトの署名を確認できます。
openssl cms -verify -CAfile <cert-file> -content <internet-draft> /
-inform DER -in <p7s-file> -out /dev/null
The arguments need to be provided as follows:
引数は次のように提供する必要があります。
<cert-file> the name of the file containing the trust anchor, which is typically the self-signed certificate of the certification authority that issued a certificate to the IETF Secretariat.
<cert-file>トラストアンカーを含むファイルの名前。これは通常、IETF事務局に証明書を発行した認証当局の自己署名証明書です。
<internet-draft> the name of the file containing the Internet-Draft after canonicalization.
<Internet-Draft>標準化後のインターネットドラフトを含むファイルの名前。
<p7s-file> the name of the file containing the detached signature that was generated in accordance with this specification.
<p7s-file>この仕様に従って生成された分離した署名を含むファイルの名前。
Author's Address
著者の連絡先
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: housley@vigilsec.com