[要約] RFC 8358は、インターネットドラフト文書のデジタル署名に関するアップデートです。その目的は、ドキュメントの信頼性とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8358 Vigil Security
Updates: 5485 March 2018
Category: Informational
ISSN: 2070-1721
Update to Digital Signatures on Internet-Draft Documents
インターネットドラフトドキュメントのデジタル署名の更新
Abstract
概要
RFC 5485 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.
RFC 5485は、インターネットドラフトのデジタル署名の規則を指定しています。暗号化メッセージ構文（CMS）を使用して分離された署名を作成します。分離された署名は別のコンパニオンファイルに保存されるため、デジタル署名の追加による既存のユーティリティへの影響はありません。
The RFC Editor recently published the first RFC that includes non-ASCII characters in a text file. The conventions specified in RFC 7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.
RFC Editorは最近、テキストファイルに非ASCII文字を含む最初のRFCを公開しました。 RFC 7997で指定された規則に従いました。非ASCII文字もまもなくInternet-Draftsに表示されるようになると想定しています。このドキュメントでは、テキストファイルに非ASCII文字を含むInternet-Draftのデジタル署名の処理を更新します。
This document updates RFC 5485.
このドキュメントはRFC 5485を更新します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8358.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8358で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detached Signature Files . . . . . . . . . . . . . . . . . . 4
3. Additional Content Types . . . . . . . . . . . . . . . . . . 4
4. Need for Canonicalization . . . . . . . . . . . . . . . . . . 5
4.1. ASCII, UTF-8, and HTML File Canonicalization . . . . . . 6
4.2. XML File Canonicalization . . . . . . . . . . . . . . . . 6
4.3. No Canonicalization of Other File Formats . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Deployment and Operational Considerations . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
RFC 5485 [IDSIG] specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) [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.
RFC 5485 [IDSIG]は、インターネットドラフトのデジタル署名の規則を指定しています。暗号化メッセージ構文（CMS）[CMS]は、独立した署名を作成するために使用されます。独立した署名は、既存のユーティリティがデジタル署名の追加による影響を受けないように、別のコンパニオンファイルに格納されます。
The RFC Editor recently published the first RFC that includes non-ASCII characters in a text file. The conventions specified in RFC 7997 [RFCED] were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.
RFC Editorは最近、テキストファイルに非ASCII文字を含む最初のRFCを公開しました。 RFC 7997 [RFCED]で指定された規則に従いました。非ASCII文字もまもなくInternet-Draftsに表示されるようになると想定しています。このドキュメントでは、テキストファイルに非ASCII文字を含むInternet-Draftのデジタル署名の処理を更新します。
This document updates RFC 5485 [IDSIG], which contains the conventions that have been used by the IETF Secretariat to digitally sign Internet-Drafts for the past few years. The IETF Secretariat generates the digital signature shortly after the Internet-Draft is posted in the repository.
このドキュメントはRFC 5485 [IDSIG]を更新します。これには、過去数年間、インターネットドラフトにデジタル署名するためにIETF事務局によって使用されてきた規約が含まれています。 IETF事務局は、インターネットドラフトがリポジトリに投稿された直後にデジタル署名を生成します。
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 signed.
デジタル署名により、誰もが、インターネットドラフトの内容が文書に署名されてから変更されていないことを確認できます。
The digital signature is intended to provide a straightforward way for anyone to determine whether a particular file contains the Internet-Draft that was made available by the IETF Secretariat. The signing-time associated with the signature provides the wall clock time at which the signature was generated; it is not intended to provide a trusted timestamp.
デジタル署名は、特定のファイルにIETF事務局から提供されたインターネットドラフトが含まれているかどうかを誰でも簡単に判断できる方法を提供することを目的としています。署名に関連付けられた署名時刻は、署名が生成された実時間を提供します。信頼できるタイムスタンプを提供することは意図されていません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [STDWORDS] [STDWORDS2] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントでは、BCP 14 [STDWORDS] [STDWORDS2]で説明されているように解釈されます。
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, 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で定義された値が送信のためにどのように表されるかを記述します。 Basic Encoding Rules（BER）[X.690]は、最も広く採用されているルールセットですが、データ構造を表現する方法が複数あります。たとえば、定長エンコーディングと不定長エンコーディングがサポートされています。デジタル署名を使用する場合、この柔軟性は望ましくありません。その結果、Distinguished Encoding Rules（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.
すべてのInternet-Draftファイル名は、「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. For example, a text file will have a suffix of ".txt". Today, plain text files are the most common, but the RFC Editor has announced plans to make use of other formats [RFCSERIES]. Each file format employs a different suffix.
すべてのインターネットドラフトファイル名は、ハイフンで終わり、その後に2桁のバージョン番号とサフィックスが続きます。接尾辞はファイルのタイプを示します。たとえば、テキストファイルのサフィックスは「.txt」になります。今日、プレーンテキストファイルが最も一般的ですが、RFCエディターは他の形式[RFCSERIES]を利用する計画を発表しました。各ファイル形式は異なるサフィックスを採用しています。
Going forward, one cannot assume that a text file with a suffix of ".txt" will contain only ASCII characters.
今後、「。txt」のサフィックスが付いたテキストファイルにASCII文字のみが含まれると想定することはできません。
The companion signature file has exactly the same file name as the RFC or Internet-Draft, except that ".p7s" is added to the end. This file name suffix conforms to the conventions in RFC 5751 [MSG]. Here are a few example names:
コンパニオンシグニチャファイルは、末尾に「.p7s」が追加されていることを除いて、RFCまたはInternet-Draftとまったく同じファイル名です。このファイル名のサフィックスは、RFC 5751 [MSG]の規則に準拠しています。以下にいくつかの名前の例を示します。
Internet-Draft: draft-ietf-example-widgets-03.txt Signature File: draft-ietf-example-widgets-03.txt.p7s
Internet-Draft：draft-ietf-example-widgets-03.txt署名ファイル：draft-ietf-example-widgets-03.txt.p7s
Internet-Draft: draft-ietf-example-widgets-03.pdf Signature File: draft-ietf-example-widgets-03.pdf.p7s
インターネットドラフト：draft-ietf-example-widgets-03.pdf署名ファイル：draft-ietf-example-widgets-03.pdf.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 CMS is used to construct the detached signatures for Internet-Drafts. 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 in RFC 5485 [IDSIG].
CMSは、インターネットドラフトの分離署名を構築するために使用されます。 CMS ContentInfoコンテンツタイプは常に存在する必要があり、CMS SignedDataコンテンツタイプをカプセル化する必要があります。デタッチされた署名が作成されているため、CMS SignedDataコンテンツタイプはInternet-Draftをカプセル化してはなりません（MUST NOT）。 CMS分離署名はRFC 5485 [IDSIG]に要約されています。
The SignedData.SignerInfo.EncapsulatedContentInfo.eContentType value MUST identify the format of the Internet-Draft that is being signed. Section 5 of RFC 5485 [IDSIG] lists the file formats and the associated content type. This document expands that list as follows:
SignedData.SignerInfo.EncapsulatedContentInfo.eContentType値は、署名されているInternet-Draftのフォーマットを識別しなければなりません（MUST）。 RFC 5485 [IDSIG]のセクション5には、ファイル形式と関連するコンテンツタイプがリストされています。このドキュメントでは、そのリストを次のように拡張しています。
File Format Content Type
----------- ------------
ASCII text id-ct-asciiTextWithCRLF
UTF-8 text (includes non-ASCII) id-ct-utf8TextWithCRLF
HyperText Markup Language (HTML) id-ct-htmlWithCRLF
EPUB id-ct-epub
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 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-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct 37 }
id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct 38 }
id-ct-epub OBJECT IDENTIFIER ::= { id-ct 39 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }
id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }
In general, the content of an Internet-Draft is treated like a single octet string for the generation of the digital signature. Unfortunately, the text and HTML files require 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.
一般に、インターネットドラフトのコンテンツは、デジタル署名の生成では単一のオクテット文字列のように扱われます。残念ながら、テキストおよびHTMLファイルは、署名検証の問題を回避するために正規化が必要です。主な関心事は、さまざまなオペレーティングシステムがテキストの行の終わりを示す方法です。一部のシステムは単一の改行文字を使用し、他のシステムは復帰文字とそれに続く改行文字の組み合わせを使用し、他のシステムは空白文字で埋められた固定長レコードを使用します。デジタル署名を適切に検証するには、単一の規則を採用する必要があります。
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.
末尾のスペース文字はテキスト行に表示してはなりません。つまり、スペース文字の後に<CRLF>シーケンスを続けてはなりません。
Thus, a blank line is represented solely by the <CRLF> sequence.
したがって、空白行は<CRLF>シーケンスのみで表されます。
The form-feed nonprintable character (0x0C) is expected in Internet-Drafts. Other non-printable characters, such as tab and backspace, are not expected, but they do occur. Non-printable 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>シーケンスで終わってはなりません。
In some environments, a Byte Order Mark (BOM) (U+FEFF) is used at the beginning of a file to indicate that it contains non-ASCII characters. In UTF-8 or HTML files, a BOM at the beginning of the file is not considered to be part of the file content. One or more consecutive leading BOMs, if present, MUST NOT be processed by the digital signature algorithm.
一部の環境では、ファイルの先頭でバイトオーダーマーク（BOM）（U + FEFF）を使用して、ASCII以外の文字が含まれていることを示します。 UTF-8またはHTMLファイルでは、ファイルの先頭にあるBOMはファイルコンテンツの一部とは見なされません。存在する場合、1つ以上の連続する先行BOMがデジタル署名アルゴリズムによって処理されてはなりません（MUST NOT）。
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.
オペレーティングシステムで使用されるファイル終了マーカーは、ファイルコンテンツの一部とは見なされません。存在する場合、そのようなファイルの終わりマーカーは、デジタル署名アルゴリズムによって処理されてはなりません（MUST NOT）。
Note: This text file canonicalization procedure is consistent with the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI].
注：このテキストファイルの正規化手順は、RFC 5198 [UFNI]の付録Bで提供されているNVT-ASCII定義と一致しています。
Utilities that produce XML files are expected to follow the guidance provided by the World Wide Web Consortium (W3C) in Section 2.11 of [R20081126]. If this guidance is followed, no canonicalization is needed.
XMLファイルを生成するユーティリティは、[R20081126]のセクション2.11のWorld Wide Web Consortium（W3C）によって提供されるガイダンスに従うことが期待されています。このガイダンスに従う場合、正規化は必要ありません。
A robust signature generation process MAY perform canonicalization to ensure that the W3C guidance has been followed. This guidance says that a <LF> character MUST be used to denote the end of a line of text within an XML file. Therefore, any two-character <CRLF> sequence and any <CR> that is not followed by <LF> are to be translated to a single <LF> character.
堅牢な署名生成プロセスは、W3Cガイダンスに従っていることを確認するために正規化を実行する場合があります。このガイダンスでは、XMLファイル内のテキスト行の終わりを示すために<LF>文字を使用する必要があると述べています。したがって、2文字の<CRLF>シーケンスと、<LF>が後に続かない<CR>は、1つの<LF>文字に変換されます。
No canonicalization is needed for file formats currently used or planned for Internet-Drafts other than ASCII, UTF-8, HTML, and XML files. Other file formats, including PDF [PDF], PostScript [PS], and EPUB [EPUB] are treated as a simple sequence of octets by the digital signature algorithm.
ASCII、UTF-8、HTML、およびXMLファイル以外のインターネットドラフトで現在使用または計画されているファイル形式の正規化は必要ありません。 PDF [PDF]、PostScript [PS]、EPUB [EPUB]などの他のファイル形式は、デジタル署名アルゴリズムによってオクテットの単純なシーケンスとして扱われます。
IANA has registered object identifiers for three content types in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows:
IANAは、次のように「SMI Security for S / MIME CMS Content Type（1.2.840.113549.1.9.16.1）」レジストリに3つのコンテンツタイプのオブジェクト識別子を登録しています。
Description OID Specification
-----------------------------------------------------------------
id-ct-utf8TextWithCRLF 1.2.840.113549.1.9.16.1.37 [RFC8358]
id-ct-htmlWithCRLF 1.2.840.113549.1.9.16.1.38 [RFC8358]
id-ct-epub 1.2.840.113549.1.9.16.1.39 [RFC8358]
The security considerations in RFC 5485 [IDSIG] are unchanged.
RFC 5485 [IDSIG]のセキュリティに関する考慮事項は変更されていません。
The deployment considerations in RFC 5485 [IDSIG] are unchanged.
RFC 5485 [IDSIG]の展開に関する考慮事項は変更されていません。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[EPUB] International Digital Publishing Forum, "EPUB Content Documents 3.1", January 2017, <http://www.idpf.org/epub/31/spec/epub-contentdocs.html>.
[EPUB] International Digital Publishing Forum、「EPUB Content Documents 3.1」、2017年1月、<http://www.idpf.org/epub/31/spec/epub-contentdocs.html>。
[IDSIG] Housley, R., "Digital Signatures on Internet-Draft Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, <https://www.rfc-editor.org/info/rfc5485>.
[IDSIG] Housley、R。、「インターネットドラフトドキュメントのデジタル署名」、RFC 5485、DOI 10.17487 / RFC5485、2009年3月、<https://www.rfc-editor.org/info/rfc5485>。
[PDF] International Organization for Standardization, "Document management -- Electronic document file format for long-term preservation -- Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)", ISO 19005-3:2012, 2012.
[PDF]国際標準化機構、「ドキュメント管理-長期保存のための電子ドキュメントファイル形式-パート3：埋め込みファイルをサポートするISO 32000-1の使用（PDF / A-3）」、ISO 19005- 3：2012、2012。
[PS] Adobe Systems Incorporated, "PostScript Language Reference Manual, third edition", Addison-Wesley Publishing Company, ISBN 0-201-37922-8, 1999.
[PS] Adobe Systems Incorporated、「PostScript言語リファレンスマニュアル、第3版」、Addison-Wesley Publishing Company、ISBN 0-201-37922-8、1999。
[R20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "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>.
[R20081126]ブレイ、T。、パオリ、J.、Sperberg-McQueen、M.、Maler、E。、およびF. Yergeau、「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>。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[STDWORDS] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[STDWORDS2] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[STDWORDS2] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation One: Specification of Basic Notation", Recommendation X.680, ISO/IEC 8824-1:2002, 2002.
[X.680] ITU-T、「Information Technology-Abstract Syntax Notation One：Specification of Basic Notation」、Recommendation X.680、ISO / IEC 8824-1：2002、2002。
[X.690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC International Standard 8825-1:2008, November 2008.
[X.690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X。 690、ISO / IEC国際規格8825-1：2008、2008年11月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>.
[FTP] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、DOI 10.17487 / RFC0959、1985年10月、<https://www.rfc-editor.org/info/rfc959>。
[MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[MSG] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<https：//www.rfc- editor.org/info/rfc5751>。
[RFCED] Flanagan, H., Ed., "The Use of Non-ASCII Characters in RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, <https://www.rfc-editor.org/info/rfc7997>.
[RFCED] Flanagan、H。、編、「RFCでの非ASCII文字の使用」、RFC 7997、DOI 10.17487 / RFC7997、2016年12月、<https://www.rfc-editor.org/info/rfc7997 >。
[RFCSERIES] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <https://www.rfc-editor.org/info/rfc6949>.
[RFCSERIES] Flanagan、H。およびN. Brownlee、「RFCシリーズフォーマットの要件と将来の開発」、RFC 6949、DOI 10.17487 / RFC6949、2013年5月、<https://www.rfc-editor.org/info/rfc6949> 。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, <https://www.rfc-editor.org/info/rfc854>.
[TELNET] Postel、J。およびJ. Reynolds、「Telnet Protocol Specification」、STD 8、RFC 854、DOI 10.17487 / RFC0854、1983年5月、<https://www.rfc-editor.org/info/rfc854>。
[UFNI] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[UFNI] Klensin、J。およびM. Padlipsky、「Unicode Format for Network Interchange」、RFC 5198、DOI 10.17487 / RFC5198、2008年3月、<https://www.rfc-editor.org/info/rfc5198>。
Acknowledgements
謝辞
The idea for the Internet-Draft signature file came from a discussion with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful suggestions came from Jim Schaad, Pasi Eronen, Chris Newman, and Glen Barney. Glen Barney also played a key role in implementing Internet-Draft signatures as specified in RFC 5485 [IDSIG].
Internet-Draft署名ファイルのアイデアは、米国イリノイ州シカゴのIETF 69でのスコットブラドナーとの話し合いから生まれました。ジムシャード、パシエロネン、クリスニューマン、グレンバーニーから、多くの役立つ提案が寄せられました。 Glen Barneyは、RFC 5485 [IDSIG]で指定されているインターネットドラフト署名の実装においても重要な役割を果たしました。
Author's Address
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States of America
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ合衆国
Email: housley@vigilsec.com