--- 1/draft-ietf-dkim-base-09.txt 2007-02-20 22:12:11.000000000 +0100 +++ 2/draft-ietf-dkim-base-10.txt 2007-02-20 22:12:11.000000000 +0100 @@ -1,25 +1,25 @@ DKIM E. Allman Internet-Draft Sendmail, Inc. Intended status: Standards Track J. Callas -Expires: August 15, 2007 PGP Corporation +Expires: August 19, 2007 PGP Corporation M. Delany M. Libbey Yahoo! Inc J. Fenton M. Thomas Cisco Systems, Inc. - February 11, 2007 + February 15, 2007 DomainKeys Identified Mail (DKIM) Signatures - draft-ietf-dkim-base-09 + draft-ietf-dkim-base-10 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -30,21 +30,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 15, 2007. + This Internet-Draft will expire on August 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and @@ -66,98 +66,99 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. White Space . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 - 2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 + 2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 3.3. Signing and Verification Algorithms . . . . . . . . . . . 12 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 3.5. The DKIM-Signature header field . . . . . . . . . . . . . 18 3.6. Key Management and Representation . . . . . . . . . . . . 26 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 30 3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 32 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 33 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 33 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 34 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 35 5.1. Determine if the Email Should be Signed and by Whom . . . 35 5.2. Select a Private Key and Corresponding Selector - Information . . . . . . . . . . . . . . . . . . . . . . . 35 + Information . . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Normalize the Message to Prevent Transport Conversions . . 36 - 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36 + 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 37 5.5. Recommended Signature Content . . . . . . . . . . . . . . 39 5.6. Compute the Message Hash and Signature . . . . . . . . . . 40 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 41 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 41 6.1. Extract Signatures from the Message . . . . . . . . . . . 42 6.2. Communicate Verification Results . . . . . . . . . . . . . 47 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 48 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 49 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 50 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 50 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 51 - 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 51 + 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 52 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 52 - 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 52 + 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 53 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 53 - 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 53 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 53 - 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 53 - 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 54 - 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 55 - 8.4. Attacks Against DNS . . . . . . . . . . . . . . . . . . . 55 - 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 56 - 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 56 + 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 54 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 54 + 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 54 + 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 55 + 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 56 + 8.4. Attacks Against DNS . . . . . . . . . . . . . . . . . . . 56 + 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 57 + 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 57 8.7. Intentionally malformed Key Records . . . . . . . . . . . 57 - 8.8. Intentionally Malformed DKIM-Signature header fields . . . 57 - 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 57 - 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 57 - 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 57 - 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 57 + 8.8. Intentionally Malformed DKIM-Signature header fields . . . 58 + 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 58 + 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 58 + 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 58 + 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 58 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 58 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 58 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 59 - Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60 - A.1. The user composes an email . . . . . . . . . . . . . . . . 60 - A.2. The email is signed . . . . . . . . . . . . . . . . . . . 60 - A.3. The email signature is verified . . . . . . . . . . . . . 61 - Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62 - B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63 - B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65 - Appendix C. Creating a public key (INFORMATIVE) . . . . . . . . . 67 - Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 69 - Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69 - Appendix F. Edit History . . . . . . . . . . . . . . . . . . . . 70 - F.1. Changes since -ietf-08 version . . . . . . . . . . . . . . 70 - F.2. Changes since -ietf-07 version . . . . . . . . . . . . . . 70 - F.3. Changes since -ietf-06 version . . . . . . . . . . . . . . 72 - F.4. Changes since -ietf-05 version . . . . . . . . . . . . . . 72 - F.5. Changes since -ietf-04 version . . . . . . . . . . . . . . 73 - F.6. Changes since -ietf-03 version . . . . . . . . . . . . . . 73 - F.7. Changes since -ietf-02 version . . . . . . . . . . . . . . 74 - F.8. Changes since -ietf-01 version . . . . . . . . . . . . . . 75 - F.9. Changes since -ietf-00 version . . . . . . . . . . . . . . 76 - F.10. Changes since -allman-01 version . . . . . . . . . . . . . 77 - F.11. Changes since -allman-00 version . . . . . . . . . . . . . 77 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 - Intellectual Property and Copyright Statements . . . . . . . . . . 80 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 59 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 60 + Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 61 + A.1. The user composes an email . . . . . . . . . . . . . . . . 61 + A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61 + A.3. The email signature is verified . . . . . . . . . . . . . 62 + Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 63 + B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 64 + B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 66 + Appendix C. Creating a public key (INFORMATIVE) . . . . . . . . . 68 + Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 70 + Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 70 + Appendix F. Edit History . . . . . . . . . . . . . . . . . . . . 71 + F.1. Changes since -ietf-09 version . . . . . . . . . . . . . . 71 + F.2. Changes since -ietf-08 version . . . . . . . . . . . . . . 71 + F.3. Changes since -ietf-07 version . . . . . . . . . . . . . . 72 + F.4. Changes since -ietf-06 version . . . . . . . . . . . . . . 73 + F.5. Changes since -ietf-05 version . . . . . . . . . . . . . . 74 + F.6. Changes since -ietf-04 version . . . . . . . . . . . . . . 74 + F.7. Changes since -ietf-03 version . . . . . . . . . . . . . . 75 + F.8. Changes since -ietf-02 version . . . . . . . . . . . . . . 76 + F.9. Changes since -ietf-01 version . . . . . . . . . . . . . . 77 + F.10. Changes since -ietf-00 version . . . . . . . . . . . . . . 77 + F.11. Changes since -allman-01 version . . . . . . . . . . . . . 78 + F.12. Changes since -allman-00 version . . . . . . . . . . . . . 78 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79 + Intellectual Property and Copyright Statements . . . . . . . . . . 81 1. Introduction [[Note: text in double square brackets (such as this text) will be deleted before publication.]] DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying @@ -517,35 +516,35 @@ INFORMATIVE NOTE: Although sha256 is strongly encouraged, some senders of low-security messages (such as routine newsletters) may prefer to use sha1 because of reduced CPU requirements to compute a sha1 hash. In general, sha256 should always be used whenever possible. 3.3.1. The rsa-sha1 Signing Algorithm The rsa-sha1 Signing Algorithm computes a message hash as described - in Section 3.7 below using SHA-1 [SHA] as the hash-alg. That hash is - then signed by the signer using the RSA algorithm (defined in PKCS#1 - version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. - The hash MUST NOT be truncated or converted into any form other than - the native binary form before being signed. The signing algorithm - SHOULD use an exponent of 65537. + in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg. + That hash is then signed by the signer using the RSA algorithm + (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the + signer's private key. The hash MUST NOT be truncated or converted + into any form other than the native binary form before being signed. + The signing algorithm SHOULD use an exponent of 65537. 3.3.2. The rsa-sha256 Signing Algorithm The rsa-sha256 Signing Algorithm computes a message hash as described - in Section 3.7 below using SHA-256 [SHA] as the hash-alg. That hash - is then signed by the signer using the RSA algorithm (defined in - PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's - private key. The hash MUST NOT be truncated or converted into any - form other than the native binary form before being signed. + in Section 3.7 below using SHA-256 [FIPS.180-2.2002] as the hash-alg. + That hash is then signed by the signer using the RSA algorithm + (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the + signer's private key. The hash MUST NOT be truncated or converted + into any form other than the native binary form before being signed. 3.3.3. Key sizes Selecting appropriate key sizes is a trade-off between cost, performance and risk. Since short RSA keys more easily succumb to off-line attacks, signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. Verifier policies may use the length of the signing key as one metric for determining whether a @@ -1208,21 +1207,21 @@ ABNF: key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg 0*( [FWS] ":" [FWS] key-h-tag-alg ) key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg x-key-h-tag-alg = hyphenated-word ; for future extension k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and verifiers MUST support the "rsa" key type. The "rsa" key type - indicates that an ASN.1 DER-encoded [X.660] RSAPublicKey + indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey [RFC3447] (see sections 3.1 and A.1.1) is being used in the p= tag. (Note: the p= tag further encodes the value using the base64 algorithm.) ABNF: key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type key-k-tag-type = "rsa" / x-key-k-tag-type x-key-k-tag-type = hyphenated-word ; for future extension @@ -1530,20 +1529,26 @@ When evaluating a message with multiple signatures, a verifier SHOULD evaluate signatures independently and on their own merits. For example, a verifier that by policy chooses not to accept signatures with deprecated cryptographic algorithms would consider such signatures invalid. Verifiers MAY process signatures in any order of their choice; for example, some verifiers might choose to process signatures corresponding to the From field in the message header before other signatures. See Section 6.1 for more information about signature choices. + INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate + valid signatures with invalid signatures in an attempt to guess + why a signature failed are ill-advised. In particular, there is + no general way that a verifier can determine that an invalid + signature was ever valid. + Verifiers SHOULD ignore failed signatures as though they were not present in the message. Verifiers SHOULD continue to check signatures until a signature successfully verifies to the satisfaction of the verifier. To limit potential denial-of-service attacks, verifiers MAY limit the total number of signatures they will attempt to verify. 5. Signer Actions The following steps are performed in order by signers. @@ -1975,21 +1980,22 @@ MUST ignore the DKIM-Signature header field and return PERMFAIL (From field not signed). Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (signature expired) if it contains an "x=" tag and the signature has expired. Verifiers MAY ignore the DKIM-Signature header field if the domain used by the signer in the d= tag is not associated with a valid signing entity. For example, signatures with d= values such as "com" - and "co.uk" may be ignored. + and "co.uk" may be ignored. The list of unacceptable domains SHOULD + be configurable. Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (unacceptable signature header) for any other reason, for example, if the signature does not sign header fields that the verifier views to be essential. As a case in point, if MIME header fields are not signed, certain attacks may be possible that the verifier would prefer to avoid. 6.1.2. Get the Public Key @@ -2343,26 +2350,26 @@ The "h=" list (specified in Section 3.6.1) and the "a=" (Section 3.5) provide for a list of mechanisms that can be used to produce a digest of message data. IANA is requested to establish the DKIM Hash Algorithms Registry, for such mechanisms that have been specified in any published RFC. The initial entries in the registry comprise: - +--------+-----------+ + +--------+-------------------+ | TYPE | REFERENCE | - +--------+-----------+ - | sha1 | [SHA] | - | sha256 | [SHA] | - +--------+-----------+ + +--------+-------------------+ + | sha1 | [FIPS.180-2.2002] | + | sha256 | [FIPS.180-2.2002] | + +--------+-------------------+ DKIM Hash Algorithms Initial Values 7.7. DKIM Service Types Registry The "s=" list (specified in Section 3.6.1) provides for a list of service types to which this selector may apply. IANA is requested to establish the DKIM Service Types Registry, for service types that have been specified in any published RFC. @@ -2642,20 +2650,30 @@ example, in the example above any of the domains could potentially simply delegate "example.podunk.ca.us" to a server of their choice and completely replace all DNS-served information. Note that a verifier MAY ignore signatures that come from an unlikely domain such as ".com", as discussed in Section 6.1.1. 9. References 9.1. Normative References + [FIPS.180-2.2002] + U.S. Department of Commerce, "Secure Hash Standard", FIPS + PUB 180-2, August 2002. + + [ITU.X660.1997] + "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.660, 1997. + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message header field Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -2665,38 +2683,29 @@ [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", - March 2003. + RFC 3490, March 2003. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. - [SHA] U.S. Department of Commerce, "Secure Hash Standard", FIPS - PUB 180-2, August 2002. - - [X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 - encoding rules: Specification of Basic Encoding Rules - (BER), Canonical Encoding Rules (CER) and Distinguished - Encoding Rules (DER)", 1997. - 9.2. Informative References [BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing - Attacks are Practical", 2003, . + Attacks are Practical", 2003. [RFC-DK] "DomainKeys specification (to be published with this RFC)", 2005. [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considers Section in RFCs", BCP 26, October 1998. @@ -3167,21 +3176,36 @@ constructive criticism. The DomainKeys specification was a primary source from which this specification has been derived. Further information about DomainKeys is at [RFC-DK]. Appendix F. Edit History [[This section to be removed before publication.]] -F.1. Changes since -ietf-08 version +F.1. Changes since -ietf-09 version + + The following changes were made between draft-ietf-dkim-base-09 and + draft-ietf-dkim-base-10: + + o Section 6.1.1, clarify that the list of unlikely domains should be + configurable in some fashion. + + o Section 4.2, add informative note about the dangers of trying to + correlate valid and invalid signatures. + + o Reference details added in XML (may not show up in .txt versions). + + o Some XML adjustments for formatting. + +F.2. Changes since -ietf-08 version The following changes were made between draft-ietf-dkim-base-08 and draft-ietf-dkim-base-09: o Section 3.3.1, recommend use of an RSA exponent of 65537. o Section 3.4.4, mention theoretical "ASCII Art" attack for relaxed body canonicalization. o Section 5.4.1 moved to 5.5 (with old 5.5 et seq. pushed down) to @@ -3192,21 +3216,21 @@ signatures from unlikely domains such as "com" and "co.uk". o Section 6.3, try to clarify the wording about SMTP rejections. o Section 7, change IANA registration requirement to be any RFC having "IETF Consensus" (as defined in RFC2434), not necessarily standards-track, as a result of overwhelming WG consensus. o Informative References, add RFC 2434. -F.2. Changes since -ietf-07 version +F.3. Changes since -ietf-07 version The following changes were made between draft-ietf-dkim-base-07 and draft-ietf-dkim-base-08: o Drop reference to "trusted third party" in section 1; it was redundant with existing bullet points and created confusion. o Drop the wording on re-using keys from normative to an operational note. @@ -3253,21 +3277,21 @@ o Add sentence in section 8.11 to emphasize that signing existing DKIM-Signature header fields may result in incorrect validation failures, as requested by Security Area review. o Added section 8.14 (RSA Attacks) based on DNS-dir review from Olafur Gu[eth]mundsson. o Added section 8.15 (Inappropriate Signing by Parent Domains). -F.3. Changes since -ietf-06 version +F.4. Changes since -ietf-06 version The following changes were made between draft-ietf-dkim-base-06 and draft-ietf-dkim-base-07: o Added section 8.11 regarding header reordering. o Added informative note to section 3.3 regarding use of sha256. o Added informative rationale to section 3.6.1, "p=", regarding key revocation. @@ -3277,21 +3301,21 @@ o Minor modification of the second informative note in section 6.1 regarding DoS attacks. o Added explicit mention of v= to section 6.1.2, step 5. o Updated paragraph 3 of section 8.4 regarding DNS attacks. o Added section 7.9 (DKIM-Signature IANA Registry) per IANA request. -F.4. Changes since -ietf-05 version +F.5. Changes since -ietf-05 version The following changes were made between draft-ietf-dkim-base-05 and draft-ietf-dkim-base-06: o Fix an error in an example in Appendix C. o Substantial updates to Appendixes B and D. o Clarify ABNF for tag-value. @@ -3301,21 +3325,21 @@ o Add normative reference to SHA1/SHA256 FIPS publication 180-2. o Several minor edits based on AD Review. o Move discussion of not re-using a selector (i.e., changing the public key for a single selector) from informational to normative. o Assorted wordsmithing based on external review. -F.5. Changes since -ietf-04 version +F.6. Changes since -ietf-04 version The following changes were made between draft-ietf-dkim-base-04 and draft-ietf-dkim-base-05: o Clarified definition of "plain text" in section 3.2 (issue 1316). o Added some clarification about multiple listings of non-existent header field names in h= in section 5.4 (issue 1316). o Finished filling out IANA registries in section 7 (issue 1320). @@ -3323,21 +3347,21 @@ o Clarified handling of bare CR and LF in section 5.3 (issue 1326). o Listed the required tags in section 6.1.1 as an informational note (issue 1330). o Changed IDNA reference from 3492 to 3490 (issue 1331). o Changed the reference for WSP to 4234; changed the definition of SWSP to exclude bare CR and LF (issue 1332). -F.6. Changes since -ietf-03 version +F.7. Changes since -ietf-03 version The following changes were made between draft-ietf-dkim-base-03 and draft-ietf-dkim-base-04: o Re-worded Abstract to avoid use of "prove" and "non-repudiation". o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. o Capitalize Selector throughout. @@ -3370,30 +3394,29 @@ o Add several examples; update some others. o Considerable minor editorial updating to clarify language, delete redundant text, fix spelling errors, etc. Still to be resolved: o How does "simple" body canonicalization interact with BINARYMIME data? - o Deal with "relaxed" body canonicalizations, especially in regard to bare CRs and NLs. o How to handle "*" in g= dot-atom-text (which allows "*" as a literal character). o The IANA Considerations need to be completed and cleaned up. -F.7. Changes since -ietf-02 version +F.8. Changes since -ietf-02 version The following changes were made between draft-ietf-dkim-base-02 and draft-ietf-dkim-base-03: o Section 5.2: changed key expiration text to be informational; drop "seven day" wording in favor of something vaguer. o Don't indicate that the "i=" tag value should be passed to the key lookup service; this can be added as an extension if required. @@ -3427,21 +3450,21 @@ may contain the content. o Use dkim-quoted-printable as the encoding used in z= rather than referring to RFC2045, since they are different. o Rewrite description of g= tag in the key record. o Deleted use of Domain in ABNF, which permits address-literals; define domain-name to act in stead. -F.8. Changes since -ietf-01 version +F.9. Changes since -ietf-01 version The following changes were made between draft-ietf-dkim-base-01 and draft-ietf-dkim-base-02: o Change wording on "x=" tag in DKIM-Signature header field regarding verifier handling of expired signatures from MUST to MAY (per 20 April Jabber session). Also, make it clear that received time is to be preferred over current time if reliably available. o Several changes to limit wording that would intrude into verifier @@ -3458,21 +3481,21 @@ o Change "q=dns" query access method to "q=dnstxt" to emphasize the use of the TXT record. The expectation is that a later extension will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 May Jabber session.) o Several typos fixed, including removing a paragraph that implied that the DKIM-Signature header field should be hashed with the body (it should not). -F.9. Changes since -ietf-00 version +F.10. Changes since -ietf-00 version The following changes were made between draft-ietf-dkim-base-00 and draft-ietf-dkim-base-01: o Added section 8.9 (Information Leakage). o Replace section 4 (Multiple Signatures) with much less vague text. o Fixed ABNF for base64string. @@ -3482,36 +3505,36 @@ o Changed signing algorithm to use separate hash of the body of the message; this is represented as the "bh=" tag in the DKIM- Signature header field. o Changed "z=" tag so that it need not have the same header field names as the "h=" tag. o Significant wordsmithing. -F.10. Changes since -allman-01 version +F.11. Changes since -allman-01 version The following changes were made between draft-allman-dkim-base-01 and draft-ietf-dkim-base-00: o Remove references to Sender Signing Policy document. Such consideration is implicitly included in Section 6.3. o Added ABNF for all tags. o Updated references (still includes some references to expired drafts, notably ID-AUTH-RES. o Significant wordsmithing. -F.11. Changes since -allman-00 version +F.12. Changes since -allman-00 version The following changes were made between draft-allman-dkim-base-00 and draft-allman-dkim-base-01: o Changed "c=" tag to separate out header from body canonicalization. o Eliminated "nowsp" canonicalization in favor of "relaxed", which is somewhat less relaxed (but more secure) than "nowsp".