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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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事務局によって含ま署名タイムは、壁時計時間を提供します。信頼できるタイムスタンプを提供するものではありません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
すべてのインターネットドラフトのファイル名は「draft-」で始まります。ファイル名の次の部分は、文書のソースに依存します。例えば、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
インターネットドラフト：ドラフト-IETF-例-ウィジェット-03.txtシグネチャファイル：ドラフト-IETF-例 - ウィジェット - 03.txt.p7s
Internet-Draft: draft-ietf-example-widgets-03.ps Signature File: draft-ietf-example-widgets-03.ps.p7s
インターネットドラフトは：ドラフト-IETF-例 - ウィジェット - 03.ps.p7s：署名ファイルをdraft-ietf-example-widgets-03.ps
Internet-Draft: draft-housley-internet-draft-sig-file-00.txt Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s
インターネットドラフト：ドラフト-Housleyの-インターネットドラフト-SIG-FILE-00.txtシグネチャファイル：ドラフト-Housleyの-インターネットドラフト-SIG-ファイル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文字（0x7Eにまで範囲は0x20外のもの）は、前の段落の行末処理するためのルールが適用されない任意の方法で変更してはなりません。
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）の指導に従い、<LF>文字は、XMLファイル内のテキストの行の終わりを示すために使用しなければなりません。任意の2文字<CRLF>配列と任意<CR> <LF>続いて単一の<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のSignedDataコンテンツタイプは、インターネットドラフトをカプセル化してはなりません。 CMS分離署名をすることによって要約されます。
ContentInfo { contentType id-signedData, -- (1.2.840.113549.1.7.2) content SignedData }
ContentInfo {contentTypeのID-たsignedData、 - （1.2.840.113549.1.7.2）コンテンツの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 }
SignedData {バージョンCMSVersion、 - 事務局証明書（複数可）のCRLのCertificateRevocationLists、 - - のSignerInfoの随意signerInfos SET - つのみ署名者は、必ず3 digestAlgorithmsのDigestAlgorithmIdentifiers、encapContentInfo EncapsulatedContentInfo、証明書が証明書群に設定}
SignerInfo { version CMSVersion, -- Always set to 3 sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs SignedAttributes, -- Always present signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs UnsignedAttributes -- Optional }
SignerInfo {バージョンCMSVersion、 - 常に存在のsignatureAlgorithm SignatureAlgorithmIdentifier、署名SignatureValue、unsignedAttrs UnsignedAttributes - - オプションは、必ず3のSID SignerIdentifier、digestAlgorithm DigestAlgorithmIdentifier、signedAttrs signedAttributesのに設定}
EncapsulatedContentInfo { eContentType id-ct-asciiTextWithCRLF, -- (1.2.840.113549.1.9.16.1.27) eContent OCTET STRING -- Always absent }
EncapsulatedContentInfo {のeContentType ID-CT-asciiTextWithCRLF、 - （1.2.840.113549.1.9.16.1.27）e-コンテンツオクテットSTRING - 常に存在しません}
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のは、関連するコンテンツのタイプを示します。剥離インターネットドラフト署名ファイルを、密閉型は常にのSignedDataので、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項でdigestAlgorithmの説明を参照してください。
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コンテンツタイプ識別子を含む署名されたコンテンツです。分離署名が作成されているので、それはインターネットドラフトをカプセル化しません。 EncapsulatedContentInfo型の使用は、セクション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].
CRLは証明書失効リスト（CRL）のオプションのコレクションです。これは、任意のCRLを含めるべきではありません。しかし、存在する任意の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は、一方向ハッシュ関数を特定し、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事務局によって使用されるデジタル署名アルゴリズム、および任意の関連するパラメータを識別する。
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:
EncapsulatedContentInfo構造は、コンテンツタイプ識別子が含まれています。分離署名が作成されているので、それはインターネットドラフトをカプセル化しません。次のようにEncapsulatedContentInfoのフィールドが使用されます。
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.
e-コンテンツはオプションです。カプセル化された署名が生成されると、署名されるべきコンテンツは、この分野で実施されます。分離署名が作成されるので、e-コンテンツが存在してはなりません。
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でエンコードされなければなりません。属性の構文は[X.501]で定義されており、X.500ディレクトリは、豊富な属性構文を提供します。この構文の非常に単純なサブセットは、[CMS]、ATTRIBUTE。＆タイプで広く使用されている属性。＆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のプロファイルで使用される属性のそれぞれは、単一の属性値を持っています。構文はAttributeValueのセットとして定義されているにもかかわらず、AttributeValueの存在のうちの正確に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.
コンテンツタイプ属性はEncapsulatedContentInfoに含まれるコンテンツタイプと同じオブジェクト識別子を含むことが要求されます。各フォーマットのための適切なコンテンツタイプは、IETF事務局は、適切なコンテンツ・タイプを含むコンテンツ・タイプ属性を含まなければならないセクション4に記載されています。 [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事務局の証明書が失効した場合、タイムスタンプは、検証者は署名が失効日の前か後に作成されたかどうかを知ることができます。 [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項で説明したように同じ値がコンテンツ-type属性に表示されます。
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事務局は現在、主要な場所とバックアップ場所でサーバを維持しています。この構成では、二つのHSM、各位置に1つが必要です。しかし、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環境を再現するかもしれません。品質の乱数の生成は困難ですが、[RANDOM]はこの領域で重要な指導を提供しています。
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パスフレーズを入力するか、スマートカードを挿入するなどの手動手順を含むことができます。
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トラストが所有されるべきです。したがって、IETFトラストの管理委員会は、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事務局で実装を容易にします。著者はこれらのファイル形式固有のいずれかの方法を使用して署名を含んでいる場合には、第2、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署名属性は、リンケージの別のフォームを含めるように指定されている可能性があり、これは将来的に追加することができます。この時点で、非IETFのリポジトリから取得され、期限切れのインターネットドラフトの署名検証をサポートすることが重要です。したがって、そのような署名された属性の適切な値は不明です。この仕様はインターネットドラフトとコンパニオンの署名ファイルは、署名の検証を妨げることなく、任意の場所に保存することができます。
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のスコット・ブラッドナーとの議論から来ました。多くの有用な提案はジムSchaad、パシEronen、およびクリスニューマンから来ました。
[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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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）の仕様、Canonicalの符号化規則（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]ポステル、J.とJ.レイノルズ、 "ファイル転送プロトコル"、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.、エド。、 "/セキュア多目的インターネットメール拡張（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]ブレイ、T.、J.パオリ、CM Sperberg・マックイーン、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.
[ランダム]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TELNET]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、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]アダムス、C.、カイン、P.、ピンカス、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、 "ネットワークインターチェンジのUnicodeフォーマット"、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
付録：
OpenSSL 0.9.9 [OpenSSL] includes an implementation of CMS. The following command line can be used to verify an Internet-Draft signature:
OpenSSLは[OpenSSLの】CMSの実装を含む0.9.9。次のコマンドラインは、インターネットドラフトの署名を検証するために使用することができます。
openssl cms -verify -CAfile <cert-file> -content <internet-draft> / -inform DER -in <p7s-file> -out /dev/null
opensslのCMS -verify -CAfile <証明書ファイル> - 含有量<インターネットドラフト> <P7Sファイル> -in / -inform DER -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.
<証明書ファイル>通常、IETF事務局に証明書を発行した認証局の自己署名証明書であるトラストアンカーを含むファイルの名前。
<internet-draft> the name of the file containing the Internet-Draft after canonicalization.
<インターネットドラフト>正規化した後、インターネットドラフトを含むファイルの名前。
<p7s-file> the name of the file containing the detached signature that was generated in accordance with this specification.
<P7Sファイル>本仕様に従って生成された分離署名を含むファイルの名前。
Author's Address
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com