7Internet Engineering Task Force (IETF) J. Levine
8Request for Comments: 8463 Taughannock Networks
9Updates: 6376 September 2018
10Category: Standards Track
14 A New Cryptographic Signature Method for
15 DomainKeys Identified Mail (DKIM)
19 This document adds a new signing algorithm, Ed25519-SHA256, to
20 "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM
21 verifiers are required to implement this algorithm.
25 This is an Internet Standards Track document.
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 7841.
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 https://www.rfc-editor.org/info/rfc8463.
39 Copyright (c) 2018 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
58Levine Standards Track [Page 1]
60RFC 8463 DKIM Crypto Update September 2018
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
67 3. Ed25519-SHA256 Signing Algorithm . . . . . . . . . . . . . . 3
68 4. Signature and Key Syntax . . . . . . . . . . . . . . . . . . 3
69 4.1. Signature Syntax . . . . . . . . . . . . . . . . . . . . 3
70 4.2. Key Syntax . . . . . . . . . . . . . . . . . . . . . . . 3
71 5. Choice and Strength of Keys and Algorithms . . . . . . . . . 4
72 6. Transition Considerations . . . . . . . . . . . . . . . . . . 4
73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
75 8.1. "DKIM Key Type" Registry . . . . . . . . . . . . . . . . 4
76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
77 9.1. Normative References . . . . . . . . . . . . . . . . . . 5
78 9.2. Informative References . . . . . . . . . . . . . . . . . 5
79 Appendix A. Example of a Signed Message . . . . . . . . . . . . 6
80 A.1. Secret Keys . . . . . . . . . . . . . . . . . . . . . . . 6
81 A.2. Public Key DNS Records . . . . . . . . . . . . . . . . . 6
82 A.3. Signed Message . . . . . . . . . . . . . . . . . . . . . 7
83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
87 DKIM [RFC6376] signs email messages by creating hashes of selected
88 message header fields and body and signing the header hash with a
89 digital signature. Message recipients fetch the signature
90 verification key from the DNS. The defining documents specify a
91 single signing algorithm, RSA [RFC3447] (which has since been
92 obsoleted by [RFC8017]).
94 This document adds a new, stronger signing algorithm, Edwards-Curve
95 Digital Signature Algorithm, using the Curve25519 curve (Ed25519),
96 which has much shorter keys than RSA for similar levels of security.
982. Conventions Used in This Document
100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
102 "OPTIONAL" in this document are to be interpreted as described in
103 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
104 capitals, as shown here.
106 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. The ABNF
107 tokens sig-a-tag-k and key-k-tag-type are imported from [RFC6376].
114Levine Standards Track [Page 2]
116RFC 8463 DKIM Crypto Update September 2018
1193. Ed25519-SHA256 Signing Algorithm
121 The Ed25519-SHA256 signing algorithm computes a message hash as
122 defined in Section 3 of [RFC6376] using SHA-256 [FIPS-180-4-2015] as
124 as defined in RFC 8032, Section 5.1 [RFC8032]. Example keys and
125 signatures in Appendix A are based on the test vectors in RFC 8032,
126 Section 7.1 [RFC8032].
128 The DNS record for the verification public key has a "k=ed25519" tag
129 to indicate that the key is an Ed25519 rather than an RSA key.
131 This is an additional DKIM signature algorithm added to Section 3.3
132 of [RFC6376] as envisioned in Section 3.3.4 of that document.
134 Note: since Ed25519 public keys are 256 bits long, the base64-encoded
135 key is only 44 octets, so DNS key record data will generally fit in a
136 single 255-byte TXT string and work even with DNS provisioning
137 software that doesn't handle multistring TXT records.
1394. Signature and Key Syntax
141 The syntax of DKIM signatures and DKIM keys are updated as follows.
145 The syntax of DKIM algorithm tags in Section 3.5 of [RFC6376] is
146 updated by adding this rule to the existing rule for sig-a-tag-k:
150 sig-a-tag-k =/ "ed25519"
154 The syntax of DKIM key tags in Section 3.6.1 of [RFC6376] is updated
155 by adding this rule to the existing rule for key-k-tag-type:
159 key-k-tag-type =/ "ed25519"
161 The p= value in the key record is the Ed25519 public key encoded in
162 base64. Since the key is 256 bits long, the base64 text is 44 octets
163 long. See Appendix A.2 for a sample key record using the public key
164 in [RFC8032], Section 7.1, Test 1.
170Levine Standards Track [Page 3]
172RFC 8463 DKIM Crypto Update September 2018
1755. Choice and Strength of Keys and Algorithms
177 Section 3.3 of [RFC6376] describes DKIM's hash and signature
178 algorithms. It is updated as follows:
180 Signers SHOULD implement and verifiers MUST implement the
181 Ed25519-SHA256 algorithm.
1836. Transition Considerations
185 For backward compatibility, signers can add multiple signatures that
186 use old and new signing algorithms. Since there can only be a single
187 key record in the DNS for each selector, the signatures have to use
188 different selectors, although they can use the same d= and i=
191 The example message in Appendix A has two signatures with the same d=
192 and i= identifiers but different a= algorithms and s= selectors.
1947. Security Considerations
196 All of the security advice in [RFC6376] continues to apply, except
197 that the security advice about Ed25519 in Section 8 of [RFC8032]
198 supplants the advice about RSA threats.
2008. IANA Considerations
202 IANA has updated a registry as follows.
2048.1. "DKIM Key Type" Registry
206 The following value has been added to the "DKIM Key Type" registry:
208 +---------+-----------+--------+
209 | TYPE | REFERENCE | STATUS |
210 +---------+-----------+--------+
211 | ed25519 | [RFC8032] | active |
212 +---------+-----------+--------+
214 Table 1: Value Added to the "DKIM Key Type" Registry
226Levine Standards Track [Page 4]
228RFC 8463 DKIM Crypto Update September 2018
2339.1. Normative References
236 National Institute of Standards and Technology, "Secure
237 Hash Standard (SHS)", FIPS PUB 180-4,
238 DOI 10.6028/NIST.FIPS.180-4, August 2015,
239 <http://nvlpubs.nist.gov/nistpubs/FIPS/
240 NIST.FIPS.180-4.pdf>.
242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
243 Requirement Levels", BCP 14, RFC 2119,
244 DOI 10.17487/RFC2119, March 1997,
245 <https://www.rfc-editor.org/info/rfc2119>.
247 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
248 Specifications: ABNF", STD 68, RFC 5234,
249 DOI 10.17487/RFC5234, January 2008,
250 <https://www.rfc-editor.org/info/rfc5234>.
252 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
253 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
254 RFC 6376, DOI 10.17487/RFC6376, September 2011,
255 <https://www.rfc-editor.org/info/rfc6376>.
257 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
258 "PKCS #1: RSA Cryptography Specifications Version 2.2",
259 RFC 8017, DOI 10.17487/RFC8017, November 2016,
260 <https://www.rfc-editor.org/info/rfc8017>.
262 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
263 Signature Algorithm (EdDSA)", RFC 8032,
264 DOI 10.17487/RFC8032, January 2017,
265 <https://www.rfc-editor.org/info/rfc8032>.
267 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
268 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
269 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
2719.2. Informative References
273 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
274 Standards (PKCS) #1: RSA Cryptography Specifications
275 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
276 2003, <https://www.rfc-editor.org/info/rfc3447>.
282Levine Standards Track [Page 5]
284RFC 8463 DKIM Crypto Update September 2018
289 This is a small message with both RSA-SHA256 and Ed25519-SHA256 DKIM
290 signatures. The signatures are independent of each other, so either
291 signature would be valid if the other were not present.
295 Ed25519 secret key in base64. This is the secret key from [RFC8032],
296 Section 7.1, Test 1, converted from hex to base64.
298 nWGxne/9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A=
300 RSA secret key in PEM format.
302 -----BEGIN RSA PRIVATE KEY-----
303 MIICXQIBAAKBgQDkHlOQoBTzWRiGs5V6NpP3idY6Wk08a5qhdR6wy5bdOKb2jLQi
304 Y/J16JYi0Qvx/byYzCNb3W91y3FutACDfzwQ/BC/e/8uBsCR+yz1Lxj+PL6lHvqM
305 KrM3rG4hstT5QjvHO9PzoxZyVYLzBfO2EeC3Ip3G+2kryOTIKT+l/K4w3QIDAQAB
306 AoGAH0cxOhFZDgzXWhDhnAJDw5s4roOXN4OhjiXa8W7Y3rhX3FJqmJSPuC8N9vQm
307 6SVbaLAE4SG5mLMueHlh4KXffEpuLEiNp9Ss3O4YfLiQpbRqE7Tm5SxKjvvQoZZe
308 zHorimOaChRL2it47iuWxzxSiRMv4c+j70GiWdxXnxe4UoECQQDzJB/0U58W7RZy
309 6enGVj2kWF732CoWFZWzi1FicudrBFoy63QwcowpoCazKtvZGMNlPWnC7x/6o8Gc
310 uSe0ga2xAkEA8C7PipPm1/1fTRQvj1o/dDmZp243044ZNyxjg+/OPN0oWCbXIGxy
311 WvmZbXriOWoSALJTjExEgraHEgnXssuk7QJBALl5ICsYMu6hMxO73gnfNayNgPxd
312 WFV6Z7ULnKyV7HSVYF0hgYOHjeYe9gaMtiJYoo0zGN+L3AAtNP9huqkWlzECQE1a
313 licIeVlo1e+qJ6Mgqr0Q7Aa7falZ448ccbSFYEPD6oFxiOl9Y9se9iYHZKKfIcst
314 o7DUw1/hz2Ck4N5JrgUCQQCyKveNvjzkkd8HjYs0SwM0fPjK16//5qDZ2UiDGnOe
315 uEzxBDAr518Z8VFbR41in3W4Y3yCDgQlLlcETrS+zYcL
316 -----END RSA PRIVATE KEY-----
318A.2. Public Key DNS Records
320 The public key p= value in the first record is the public key from
321 [RFC8032], Section 7.1, Test 1, converted from hex to base64.
323brisbane._domainkey.football.example.com. IN TXT (
324 "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=")
326test._domainkey.football.example.com. IN TXT (
327 "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDkHlOQoBTzWR"
328 "iGs5V6NpP3idY6Wk08a5qhdR6wy5bdOKb2jLQiY/J16JYi0Qvx/byYzCNb3W91y3FutAC"
329 "DfzwQ/BC/e/8uBsCR+yz1Lxj+PL6lHvqMKrM3rG4hstT5QjvHO9PzoxZyVYLzBfO2EeC3"
330 "Ip3G+2kryOTIKT+l/K4w3QIDAQAB")
338Levine Standards Track [Page 6]
340RFC 8463 DKIM Crypto Update September 2018
345 The text in each line of the message starts at the first position
346 except for the continuation lines on the DKIM-Signature header
347 fields, which start with a single space. A blank line follows the
350 DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
351 d=football.example.com; i=@football.example.com;
352 q=dns/txt; s=brisbane; t=1528637909; h=from : to :
353 subject : date : message-id : from : subject : date;
354 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
355 b=/gCrinpcQOoIfuHNQIbq4pgh9kyIK3AQUdt9OdqQehSwhEIug4D11Bus
356 Fa3bT3FY5OsU7ZbnKELq+eXdp1Q1Dw==
357 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
358 d=football.example.com; i=@football.example.com;
359 q=dns/txt; s=test; t=1528637909; h=from : to : subject :
360 date : message-id : from : subject : date;
361 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
362 b=F45dVWDfMbQDGHJFlXUNB2HKfbCeLRyhDXgFpEL8GwpsRe0IeIixNTe3
363 DhCVlUrSjV4BwcVcOF6+FF3Zo9Rpo1tFOeS9mPYQTnGdaSGsgeefOsk2Jz
364 dA+L10TeYt9BgDfQNZtKdN1WO//KgIqXP7OdEFE4LjFYNcUxZQ4FADY+8=
365 From: Joe SixPack <joe@football.example.com>
366 To: Suzie Q <suzie@shopping.example.net>
367 Subject: Is dinner ready?
368 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
369 Message-ID: <20030712040037.46341.5F8J@football.example.com>
373 We lost the game. Are you hungry yet?
382 Trumansburg, NY 14886
383 United States of America
385 Phone: +883.5100.01196712
386 Email: standards@taugh.com
394Levine Standards Track [Page 7]