[要約] RFC 8463は、DomainKeys Identified Mail (DKIM) における新しい暗号署名方式を導入する文書です。このRFCの目的は、Ed25519署名アルゴリズムを使用した新たな署名オプションを提供することにより、DKIMのセキュリティと効率を向上させることです。この署名方法は、特にリソースが限られている環境や、高速な署名と検証が求められる場面での利用が想定されています。関連するRFCとしては、DKIMを定義するRFC 6376や、Ed25519アルゴリズムを詳述するRFC 8032などがあります。
Internet Engineering Task Force (IETF) J. Levine Request for Comments: 8463 Taughannock Networks Updates: 6376 September 2018 Category: Standards Track ISSN: 2070-1721
A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail(DKIM)の新しい暗号署名方式
Abstract
概要
This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm.
このドキュメントでは、新しい署名アルゴリズムEd25519-SHA256を「DomainKeys Identified Mail(DKIM)Signatures」(RFC 6376)に追加します。このアルゴリズムを実装するには、DKIMベリファイアが必要です。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(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/rfc8463.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8463で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 3. Ed25519-SHA256 Signing Algorithm . . . . . . . . . . . . . . 3 4. Signature and Key Syntax . . . . . . . . . . . . . . . . . . 3 4.1. Signature Syntax . . . . . . . . . . . . . . . . . . . . 3 4.2. Key Syntax . . . . . . . . . . . . . . . . . . . . . . . 3 5. Choice and Strength of Keys and Algorithms . . . . . . . . . 4 6. Transition Considerations . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8.1. "DKIM Key Type" Registry . . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Example of a Signed Message . . . . . . . . . . . . 6 A.1. Secret Keys . . . . . . . . . . . . . . . . . . . . . . . 6 A.2. Public Key DNS Records . . . . . . . . . . . . . . . . . 6 A.3. Signed Message . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
DKIM [RFC6376] signs email messages by creating hashes of selected message header fields and body and signing the header hash with a digital signature. Message recipients fetch the signature verification key from the DNS. The defining documents specify a single signing algorithm, RSA [RFC3447] (which has since been obsoleted by [RFC8017]).
DKIM [RFC6376]は、選択されたメッセージヘッダーフィールドと本文のハッシュを作成し、ヘッダーハッシュにデジタル署名で署名することにより、電子メールメッセージに署名します。メッセージの受信者は、署名検証キーをDNSからフェッチします。定義するドキュメントは、RSA [RFC3447]([RFC8017]によって廃止された)の単一署名アルゴリズムを指定しています。
This document adds a new, stronger signing algorithm, Edwards-Curve Digital Signature Algorithm, using the Curve25519 curve (Ed25519), which has much shorter keys than RSA for similar levels of security.
このドキュメントでは、Curve25519曲線(Ed25519)を使用した新しい強力な署名アルゴリズムであるEdwards-Curve Digital Signature Algorithmを追加しています。
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 [RFC2119] [RFC8174] 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 [RFC2119] [RFC8174]で説明されているように解釈されます。
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. The ABNF tokens sig-a-tag-k and key-k-tag-type are imported from [RFC6376].
構文の説明では、拡張BNF(ABNF)[RFC5234]を使用しています。 ABNFトークンsig-a-tag-kおよびkey-k-tag-typeは[RFC6376]からインポートされます。
The Ed25519-SHA256 signing algorithm computes a message hash as defined in Section 3 of [RFC6376] using SHA-256 [FIPS-180-4-2015] as the hash-alg. It signs the hash with the PureEdDSA variant Ed25519, as defined in RFC 8032, Section 5.1 [RFC8032]. Example keys and signatures in Appendix A are based on the test vectors in RFC 8032, Section 7.1 [RFC8032].
Ed25519-SHA256署名アルゴリズムは、ハッシュアルゴリズムとしてSHA-256 [FIPS-180-4-2015]を使用して、[RFC6376]のセクション3で定義されているメッセージハッシュを計算します。 RFC 8032、セクション5.1 [RFC8032]で定義されているように、PureEdDSAバリアントEd25519でハッシュに署名します。付録Aのキーと署名の例は、RFC 8032、セクション7.1 [RFC8032]のテストベクトルに基づいています。
The DNS record for the verification public key has a "k=ed25519" tag to indicate that the key is an Ed25519 rather than an RSA key.
検証公開鍵のDNSレコードには、鍵がRSA鍵ではなくEd25519であることを示す「k = ed25519」タグがあります。
This is an additional DKIM signature algorithm added to Section 3.3 of [RFC6376] as envisioned in Section 3.3.4 of that document.
これは、そのドキュメントのセクション3.3.4で想定されているように、[RFC6376]のセクション3.3に追加された追加のDKIM署名アルゴリズムです。
Note: since Ed25519 public keys are 256 bits long, the base64-encoded key is only 44 octets, so DNS key record data will generally fit in a single 255-byte TXT string and work even with DNS provisioning software that doesn't handle multistring TXT records.
注:Ed25519公開鍵は256ビット長であるため、base64でエンコードされた鍵は44オクテットしかないため、DNS鍵レコードデータは通常、単一の255バイトTXT文字列に収まり、マルチ文字列を処理しないDNSプロビジョニングソフトウェアでも機能しますTXTレコード。
The syntax of DKIM signatures and DKIM keys are updated as follows.
DKIM署名とDKIMキーの構文は、次のように更新されます。
The syntax of DKIM algorithm tags in Section 3.5 of [RFC6376] is updated by adding this rule to the existing rule for sig-a-tag-k:
[RFC6376]のセクション3.5のDKIMアルゴリズムタグの構文は、sig-a-tag-kの既存のルールにこのルールを追加することで更新されています。
ABNF:
ABNF:
sig-a-tag-k =/ "ed25519"
sig-a-tag-k = / "ed25519"
The syntax of DKIM key tags in Section 3.6.1 of [RFC6376] is updated by adding this rule to the existing rule for key-k-tag-type:
[RFC6376]のセクション3.6.1のDKIMキータグの構文は、key-k-tag-typeの既存のルールにこのルールを追加することで更新されています。
ABNF:
ABNF:
key-k-tag-type =/ "ed25519"
key-k-tag-type = / "ed25519"
The p= value in the key record is the Ed25519 public key encoded in base64. Since the key is 256 bits long, the base64 text is 44 octets long. See Appendix A.2 for a sample key record using the public key in [RFC8032], Section 7.1, Test 1.
鍵レコードのp =値は、base64でエンコードされたEd25519公開鍵です。キーは256ビット長であるため、base64テキストは44オクテット長です。 [RFC8032]のセクション7.1、テスト1の公開キーを使用したサンプルキーレコードについては、付録A.2を参照してください。
Section 3.3 of [RFC6376] describes DKIM's hash and signature algorithms. It is updated as follows:
[RFC6376]のセクション3.3では、DKIMのハッシュアルゴリズムと署名アルゴリズムについて説明しています。次のように更新されます。
Signers SHOULD implement and verifiers MUST implement the Ed25519-SHA256 algorithm.
署名者は実装する必要があり、検証者はEd25519-SHA256アルゴリズムを実装する必要があります。
For backward compatibility, signers can add multiple signatures that use old and new signing algorithms. Since there can only be a single key record in the DNS for each selector, the signatures have to use different selectors, although they can use the same d= and i= identifiers.
下位互換性のために、署名者は新旧の署名アルゴリズムを使用する複数の署名を追加できます。 DNSには各セレクターに対して単一のキーレコードしか存在できないため、署名は同じd =およびi =識別子を使用できますが、異なるセレクターを使用する必要があります。
The example message in Appendix A has two signatures with the same d= and i= identifiers but different a= algorithms and s= selectors.
付録Aのメッセージ例には、d =とi =の識別子は同じであるが、a =アルゴリズムとs =セレクターが異なる2つの署名があります。
All of the security advice in [RFC6376] continues to apply, except that the security advice about Ed25519 in Section 8 of [RFC8032] supplants the advice about RSA threats.
[RFC6376]のセキュリティアドバイスはすべて適用され続けますが、[RFC8032]のセクション8のEd25519に関するセキュリティアドバイスは、RSAの脅威に関するアドバイスに取って代わるものです。
IANA has updated a registry as follows.
IANAは次のようにレジストリを更新しました。
The following value has been added to the "DKIM Key Type" registry:
次の値が「DKIMキータイプ」レジストリに追加されました。
+---------+-----------+--------+ | TYPE | REFERENCE | STATUS | +---------+-----------+--------+ | ed25519 | [RFC8032] | active | +---------+-----------+--------+
Table 1: Value Added to the "DKIM Key Type" Registry
表1:「DKIMキータイプ」レジストリに追加される値
[FIPS-180-4-2015] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[FIPS-180-4-2015]米国国立標準技術研究所、「Secure Hash Standard(SHS)」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<http:// nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[RFC2119] 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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF:ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376] Crocker、D.、Ed。、Hansen、T.、Ed。、and M. Kucherawy、Ed。、 "DomainKeys Identified Mail(DKIM)Signatures"、STD 76、RFC 6376、DOI 10.17487 / RFC6376、September 2011 、<https://www.rfc-editor.org/info/rfc6376>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、and A. Rusch、 "PKCS#1:RSA Cryptography Specifications Version 2.2"、RFC 8017、DOI 10.17487 / RFC8017、November 2016、< https://www.rfc-editor.org/info/rfc8017>。
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032] Josefsson、S。およびI. Liusvaara、「Edwards-Curve Digital Signature Algorithm(EdDSA)」、RFC 8032、DOI 10.17487 / RFC8032、2017年1月、<https://www.rfc-editor.org/info/ rfc8032>。
[RFC8174] 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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <https://www.rfc-editor.org/info/rfc3447>.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards(PKCS)#1:RSA Cryptography Specifications Version 2.1」、RFC 3447、DOI 10.17487 / RFC3447、2003年2月、<https://www.rfc -editor.org/info/rfc3447>。
This is a small message with both RSA-SHA256 and Ed25519-SHA256 DKIM signatures. The signatures are independent of each other, so either signature would be valid if the other were not present.
これは、RSA-SHA256とEd25519-SHA256 DKIM署名の両方を含む小さなメッセージです。署名は相互に独立しているため、どちらかが存在しない場合はどちらの署名も有効です。
Ed25519 secret key in base64. This is the secret key from [RFC8032], Section 7.1, Test 1, converted from hex to base64.
Ed6419 base64の秘密鍵。これは、[RFC8032]、セクション7.1、テスト1の16進数からbase64に変換された秘密鍵です。
nWGxne/9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A=
nWGxne / 9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A =
RSA secret key in PEM format.
PEM形式のRSA秘密鍵。
-----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDkHlOQoBTzWRiGs5V6NpP3idY6Wk08a5qhdR6wy5bdOKb2jLQi Y/J16JYi0Qvx/byYzCNb3W91y3FutACDfzwQ/BC/e/8uBsCR+yz1Lxj+PL6lHvqM KrM3rG4hstT5QjvHO9PzoxZyVYLzBfO2EeC3Ip3G+2kryOTIKT+l/K4w3QIDAQAB AoGAH0cxOhFZDgzXWhDhnAJDw5s4roOXN4OhjiXa8W7Y3rhX3FJqmJSPuC8N9vQm 6SVbaLAE4SG5mLMueHlh4KXffEpuLEiNp9Ss3O4YfLiQpbRqE7Tm5SxKjvvQoZZe zHorimOaChRL2it47iuWxzxSiRMv4c+j70GiWdxXnxe4UoECQQDzJB/0U58W7RZy 6enGVj2kWF732CoWFZWzi1FicudrBFoy63QwcowpoCazKtvZGMNlPWnC7x/6o8Gc uSe0ga2xAkEA8C7PipPm1/1fTRQvj1o/dDmZp243044ZNyxjg+/OPN0oWCbXIGxy WvmZbXriOWoSALJTjExEgraHEgnXssuk7QJBALl5ICsYMu6hMxO73gnfNayNgPxd WFV6Z7ULnKyV7HSVYF0hgYOHjeYe9gaMtiJYoo0zGN+L3AAtNP9huqkWlzECQE1a licIeVlo1e+qJ6Mgqr0Q7Aa7falZ448ccbSFYEPD6oFxiOl9Y9se9iYHZKKfIcst o7DUw1/hz2Ck4N5JrgUCQQCyKveNvjzkkd8HjYs0SwM0fPjK16//5qDZ2UiDGnOe uEzxBDAr518Z8VFbR41in3W4Y3yCDgQlLlcETrS+zYcL -----END RSA PRIVATE KEY-----
The public key p= value in the first record is the public key from [RFC8032], Section 7.1, Test 1, converted from hex to base64.
最初のレコードの公開鍵p =の値は、[RFC8032]、セクション7.1、テスト1の公開鍵で、16進数からbase64に変換されています。
brisbane._domainkey.football.example.com. IN TXT ( "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=")
test._domainkey.football.example.com. IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDkHlOQoBTzWR" "iGs5V6NpP3idY6Wk08a5qhdR6wy5bdOKb2jLQiY/J16JYi0Qvx/byYzCNb3W91y3FutAC" "DfzwQ/BC/e/8uBsCR+yz1Lxj+PL6lHvqMKrM3rG4hstT5QjvHO9PzoxZyVYLzBfO2EeC3" "Ip3G+2kryOTIKT+l/K4w3QIDAQAB")
The text in each line of the message starts at the first position except for the continuation lines on the DKIM-Signature header fields, which start with a single space. A blank line follows the "Joe." line.
メッセージの各行のテキストは、単一のスペースで始まるDKIM-Signatureヘッダーフィールドの継続行を除き、最初の位置から始まります。 「ジョー」の後に空白行が続きます。ライン。
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=football.example.com; i=@football.example.com; q=dns/txt; s=brisbane; t=1528637909; h=from : to : subject : date : message-id : from : subject : date; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=/gCrinpcQOoIfuHNQIbq4pgh9kyIK3AQUdt9OdqQehSwhEIug4D11Bus Fa3bT3FY5OsU7ZbnKELq+eXdp1Q1Dw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=football.example.com; i=@football.example.com; q=dns/txt; s=test; t=1528637909; h=from : to : subject : date : message-id : from : subject : date; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=F45dVWDfMbQDGHJFlXUNB2HKfbCeLRyhDXgFpEL8GwpsRe0IeIixNTe3 DhCVlUrSjV4BwcVcOF6+FF3Zo9Rpo1tFOeS9mPYQTnGdaSGsgeefOsk2Jz dA+L10TeYt9BgDfQNZtKdN1WO//KgIqXP7OdEFE4LjFYNcUxZQ4FADY+8= From: Joe SixPack <joe@football.example.com> To: Suzie Q <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com>
Hi.
日。
We lost the game. Are you hungry yet?
ゲームに負けました。あなたはもうお腹が空いていますか?
Joe.
ジョー。
Author's Address
著者のアドレス
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 United States of America
John Levine Taughannock Networks PO Box 727 Trumansburg、NY 14886アメリカ合衆国
Phone: +883.5100.01196712 Email: standards@taugh.com