draft-ietf-dkim-rfc4871bis-04.txt | draft-ietf-dkim-rfc4871bis-05.txt | |||
---|---|---|---|---|
Network Working Group D. Crocker, Ed. | Network Working Group D. Crocker, Ed. | |||
Internet-Draft Brandenburg InternetWorking | Internet-Draft Brandenburg InternetWorking | |||
Obsoletes: 4871 (if approved) T. Hansen, Ed. | Obsoletes: 4871 (if approved) T. Hansen, Ed. | |||
Intended status: Standards Track AT&T Laboratories | Intended status: Standards Track AT&T Laboratories | |||
Expires: September 29, 2011 M. Kucherawy, Ed. | Expires: September 29, 2011 M. Kucherawy, Ed. | |||
Cloudmark | Cloudmark | |||
March 28, 2011 | March 28, 2011 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-04 | draft-ietf-dkim-rfc4871bis-05 | |||
Abstract | Abstract | |||
DomainKeys Identified Mail (DKIM) permits a person, role, or | DomainKeys Identified Mail (DKIM) permits a person, role, or | |||
organization that owns the signing domain to claim some | organization that owns the signing domain to claim some | |||
responsibility for a message by associating the domain with the | responsibility for a message by associating the domain with the | |||
message. This can be an author's organization, an operational relay | message. This can be an author's organization, an operational relay | |||
or one of their agents. DKIM separates the question of the identity | or one of their agents. DKIM separates the question of the identity | |||
of the signer of the message from the purported author of the | of the signer of the message from the purported author of the | |||
message. Assertion of responsibility is validated through a | message. Assertion of responsibility is validated through a | |||
skipping to change at page 3, line 18 | skipping to change at page 3, line 18 | |||
5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 | 5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 | |||
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
6.1. Extract Signatures from the Message . . . . . . . . . . . 46 | 6.1. Extract Signatures from the Message . . . . . . . . . . . 46 | |||
6.2. Communicate Verification Results . . . . . . . . . . . . . 51 | 6.2. Communicate Verification Results . . . . . . . . . . . . . 51 | |||
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | |||
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | |||
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | |||
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54 | 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 | |||
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55 | 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 | |||
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | |||
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | |||
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56 | 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 | |||
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 | 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | |||
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 | 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 | |||
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 | 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 | |||
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 | 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 | |||
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 | 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 | |||
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 | 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 | |||
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 | 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 61 | |||
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 | 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 61 | |||
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 | 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 | |||
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 | 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 | |||
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 | 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 | |||
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 | 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 | |||
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 | 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 | 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 | |||
8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 | 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 | |||
8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 | 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 65 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 65 | |||
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 | Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 | |||
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 | A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 | |||
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 | A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67 | |||
A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 | A.3. The Email Signature is Verified . . . . . . . . . . . . . 68 | |||
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 | Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69 | |||
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 | B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 | |||
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | |||
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | |||
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 | Appendix D. Removal of Key Granularity . . . . . . . . . . . . . 74 | |||
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74 | Appendix E. MUA Considerations . . . . . . . . . . . . . . . . . 74 | |||
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 75 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 | |||
1. Introduction | 1. Introduction | |||
DomainKeys Identified Mail (DKIM) permits a person, role, or | DomainKeys Identified Mail (DKIM) permits a person, role, or | |||
organization to claim some responsibility for a message by | organization to claim some responsibility for a message by | |||
associating a domain name [RFC1034] with the message [RFC5322], which | associating a domain name [RFC1034] with the message [RFC5322], which | |||
they are authorized to use. This can be an author's organization, an | they are authorized to use. This can be an author's organization, an | |||
operational relay or one of their agents. Assertion of | operational relay or one of their agents. Assertion of | |||
responsibility is validated through a cryptographic signature and | responsibility is validated through a cryptographic signature and | |||
skipping to change at page 20, line 40 | skipping to change at page 20, line 40 | |||
the value "1". Note that verifiers must do a string comparison on | the value "1". Note that verifiers must do a string comparison on | |||
this value; for example, "1" is not the same as "1.0". | this value; for example, "1" is not the same as "1.0". | |||
ABNF: | ABNF: | |||
sig-v-tag = %x76 [FWS] "=" [FWS] "1" | sig-v-tag = %x76 [FWS] "=" [FWS] "1" | |||
INFORMATIVE NOTE: DKIM-Signature version numbers are expected | INFORMATIVE NOTE: DKIM-Signature version numbers are expected | |||
to increase arithmetically as new versions of this | to increase arithmetically as new versions of this | |||
specification are released. | specification are released. | |||
a= The algorithm used to generate the signature (plain-text; | a= The algorithm used to generate the signature (plain-text; | |||
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | |||
signers SHOULD sign using "rsa-sha256". | signers SHOULD sign using "rsa-sha256". | |||
ABNF: | ABNF: | |||
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg | sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg | |||
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h | sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h | |||
sig-a-tag-k = "rsa" / x-sig-a-tag-k | sig-a-tag-k = "rsa" / x-sig-a-tag-k | |||
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h | sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h | |||
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) | x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) | |||
skipping to change at page 53, line 14 | skipping to change at page 53, line 14 | |||
transit? If the signature line is missing, is that because it was | transit? If the signature line is missing, is that because it was | |||
never there, or was it removed by an overzealous filter? For | never there, or was it removed by an overzealous filter? For | |||
diagnostic purposes, the exact reason why the verification fails | diagnostic purposes, the exact reason why the verification fails | |||
SHOULD be made available to the policy module and possibly recorded | SHOULD be made available to the policy module and possibly recorded | |||
in the system logs. If the email cannot be verified, then it SHOULD | in the system logs. If the email cannot be verified, then it SHOULD | |||
be rendered the same as all unverified email regardless of whether or | be rendered the same as all unverified email regardless of whether or | |||
not it looks like it was signed. | not it looks like it was signed. | |||
7. IANA Considerations | 7. IANA Considerations | |||
DKIM has registered new namespaces with IANA. In all cases, new | DKIM has registered namespaces with IANA. In all cases, new values | |||
values are assigned only for values that have been documented in a | are assigned only for values that have been documented in a published | |||
published RFC that has IETF Consensus [RFC5226]. | RFC that has IETF Consensus [RFC5226]. | |||
This memo updates these registries as described below. Of note is | ||||
the addition of a new "status" column. All registrations into these | ||||
namespaces MUST include the name being registered, the document in | ||||
which it was registered or updated, and an indication of its current | ||||
status which MUST be one of "active" (in current use) or "historic" | ||||
(no longer in current use). | ||||
7.1. DKIM-Signature Tag Specifications | 7.1. DKIM-Signature Tag Specifications | |||
A DKIM-Signature provides for a list of tag specifications. IANA has | A DKIM-Signature provides for a list of tag specifications. IANA has | |||
established the DKIM-Signature Tag Specification Registry for tag | established the DKIM-Signature Tag Specification Registry for tag | |||
specifications that can be used in DKIM-Signature fields. | specifications that can be used in DKIM-Signature fields. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+--------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------------+ | +------+-----------------+--------+ | |||
| v | (this document) | | | v | (this document) | active | | |||
| a | (this document) | | | a | (this document) | active | | |||
| b | (this document) | | | b | (this document) | active | | |||
| bh | (this document) | | | bh | (this document) | active | | |||
| c | (this document) | | | c | (this document) | active | | |||
| d | (this document) | | | d | (this document) | active | | |||
| h | (this document) | | | h | (this document) | active | | |||
| i | (this document) | | | i | (this document) | active | | |||
| l | (this document) | | | l | (this document) | active | | |||
| q | (this document) | | | q | (this document) | active | | |||
| s | (this document) | | | s | (this document) | active | | |||
| t | (this document) | | | t | (this document) | active | | |||
| x | (this document) | | | x | (this document) | active | | |||
| z | (this document) | | | z | (this document) | active | | |||
+------+-----------------+ | +------+-----------------+--------+ | |||
Table 1: DKIM-Signature Tag Specification Registry Initial | Table 1: DKIM-Signature Tag Specification Registry Initial | |||
Values | Values | |||
7.2. DKIM-Signature Query Method Registry | 7.2. DKIM-Signature Query Method Registry | |||
The "q=" tag-spec (specified in Section 3.5) provides for a list of | The "q=" tag-spec (specified in Section 3.5) provides for a list of | |||
query methods. | query methods. | |||
IANA has established the DKIM-Signature Query Method Registry for | IANA has established the DKIM-Signature Query Method Registry for | |||
mechanisms that can be used to retrieve the key that will permit | mechanisms that can be used to retrieve the key that will permit | |||
validation processing of a message signed using DKIM. | validation processing of a message signed using DKIM. | |||
The initial entry in the registry comprises: | The initial entry in the registry comprises: | |||
+------+--------+-----------------+ | +------+--------+-----------------+--------+ | |||
| TYPE | OPTION | REFERENCE | | | TYPE | OPTION | REFERENCE | STATUS | | |||
+------+--------+-----------------+ | +------+--------+-----------------+--------+ | |||
| dns | txt | (this document) | | | dns | txt | (this document) | active | | |||
+------+--------+-----------------+ | +------+--------+-----------------+--------+ | |||
DKIM-Signature Query Method Registry Initial Values | DKIM-Signature Query Method Registry Initial Values | |||
7.3. DKIM-Signature Canonicalization Registry | 7.3. DKIM-Signature Canonicalization Registry | |||
The "c=" tag-spec (specified in Section 3.5) provides for a specifier | The "c=" tag-spec (specified in Section 3.5) provides for a specifier | |||
for canonicalization algorithms for the header and body of the | for canonicalization algorithms for the header and body of the | |||
message. | message. | |||
IANA has established the DKIM-Signature Canonicalization Algorithm | IANA has established the DKIM-Signature Canonicalization Algorithm | |||
Registry for algorithms for converting a message into a canonical | Registry for algorithms for converting a message into a canonical | |||
form before signing or verifying using DKIM. | form before signing or verifying using DKIM. | |||
The initial entries in the header registry comprise: | ||||
+---------+-----------------+--------+ | ||||
| TYPE | REFERENCE | STATUS | | ||||
+---------+-----------------+--------+ | ||||
| simple | (this document) | active | | ||||
| relaxed | (this document) | active | | ||||
+---------+-----------------+--------+ | ||||
DKIM-Signature Header Canonicalization Algorithm Registry | ||||
Initial Values | ||||
The initial entries in the body registry comprise: | The initial entries in the body registry comprise: | |||
+---------+-----------------+ | +---------+-----------------+--------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | STATUS | | |||
+---------+-----------------+ | +---------+-----------------+--------+ | |||
| simple | (this document) | | | simple | (this document) | active | | |||
| relaxed | (this document) | | | relaxed | (this document) | active | | |||
+---------+-----------------+ | +---------+-----------------+--------+ | |||
DKIM-Signature Body Canonicalization Algorithm Registry | DKIM-Signature Body Canonicalization Algorithm Registry | |||
Initial Values | Initial Values | |||
7.4. _domainkey DNS TXT Record Tag Specifications | 7.4. _domainkey DNS TXT Record Tag Specifications | |||
A _domainkey DNS TXT record provides for a list of tag | A _domainkey DNS TXT record provides for a list of tag | |||
specifications. IANA has established the DKIM _domainkey DNS TXT Tag | specifications. IANA has established the DKIM _domainkey DNS TXT Tag | |||
Specification Registry for tag specifications that can be used in DNS | Specification Registry for tag specifications that can be used in DNS | |||
TXT Records. | TXT Records. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+----------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------------+ | +------+-----------------+----------+ | |||
| v | (this document) | | | v | (this document) | active | | |||
| g | (this document) | | | g | [RFC4871] | historic | | |||
| h | (this document) | | | h | (this document) | active | | |||
| k | (this document) | | | k | (this document) | active | | |||
| n | (this document) | | | n | (this document) | active | | |||
| p | (this document) | | | p | (this document) | active | | |||
| s | (this document) | | | s | (this document) | active | | |||
| t | (this document) | | | t | (this document) | active | | |||
+------+-----------------+ | +------+-----------------+----------+ | |||
DKIM _domainkey DNS TXT Record Tag Specification Registry | DKIM _domainkey DNS TXT Record Tag Specification Registry | |||
Initial Values | Initial Values | |||
The initial entries in the body registry comprise: | ||||
+---------+-----------------+ | ||||
| TYPE | REFERENCE | | ||||
+---------+-----------------+ | ||||
| simple | (this document) | | ||||
| relaxed | (this document) | | ||||
+---------+-----------------+ | ||||
DKIM-Signature Body Canonicalization Algorithm Registry | ||||
Initial Values | ||||
7.5. DKIM Key Type Registry | 7.5. DKIM Key Type Registry | |||
The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- | |||
a-tag-k> (specified in Section 3.5) tags provide for a list of | a-tag-k> (specified in Section 3.5) tags provide for a list of | |||
mechanisms that can be used to decode a DKIM signature. | mechanisms that can be used to decode a DKIM signature. | |||
IANA has established the DKIM Key Type Registry for such mechanisms. | IANA has established the DKIM Key Type Registry for such mechanisms. | |||
The initial entry in the registry comprises: | The initial entry in the registry comprises: | |||
+------+-----------+ | +------+-----------+--------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------+ | +------+-----------+--------+ | |||
| rsa | [RFC3447] | | | rsa | [RFC3447] | active | | |||
+------+-----------+ | +------+-----------+--------+ | |||
DKIM Key Type Initial Values | DKIM Key Type Initial Values | |||
7.6. DKIM Hash Algorithms Registry | 7.6. DKIM Hash Algorithms Registry | |||
The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | |||
a-tag-h> (specified in Section 3.5) tags provide for a list of | a-tag-h> (specified in Section 3.5) tags provide for a list of | |||
mechanisms that can be used to produce a digest of message data. | mechanisms that can be used to produce a digest of message data. | |||
IANA has established the DKIM Hash Algorithms Registry for such | IANA has established the DKIM Hash Algorithms Registry for such | |||
mechanisms. | mechanisms. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+--------+-------------------+ | +--------+-------------------+--------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | STATUS | | |||
+--------+-------------------+ | +--------+-------------------+--------+ | |||
| sha1 | [FIPS-180-2-2002] | | | sha1 | [FIPS-180-2-2002] | active | | |||
| sha256 | [FIPS-180-2-2002] | | | sha256 | [FIPS-180-2-2002] | active | | |||
+--------+-------------------+ | +--------+-------------------+--------+ | |||
DKIM Hash Algorithms Initial Values | DKIM Hash Algorithms Initial Values | |||
7.7. DKIM Service Types Registry | 7.7. DKIM Service Types Registry | |||
The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a | The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a | |||
list of service types to which this selector may apply. | list of service types to which this selector may apply. | |||
IANA has established the DKIM Service Types Registry for service | IANA has established the DKIM Service Types Registry for service | |||
types. | types. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+-------+-----------------+ | +-------+-----------------+--------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | STATUS | | |||
+-------+-----------------+ | +-------+-----------------+--------+ | |||
| email | (this document) | | | email | (this document) | active | | |||
| * | (this document) | | | * | (this document) | active | | |||
+-------+-----------------+ | +-------+-----------------+--------+ | |||
DKIM Service Types Registry Initial Values | DKIM Service Types Registry Initial Values | |||
7.8. DKIM Selector Flags Registry | 7.8. DKIM Selector Flags Registry | |||
The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | |||
list of flags to modify interpretation of the selector. | list of flags to modify interpretation of the selector. | |||
IANA has established the DKIM Selector Flags Registry for additional | IANA has established the DKIM Selector Flags Registry for additional | |||
flags. | flags. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+--------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------------+ | +------+-----------------+--------+ | |||
| y | (this document) | | | y | (this document) | active | | |||
| s | (this document) | | | s | (this document) | active | | |||
+------+-----------------+ | +------+-----------------+--------+ | |||
DKIM Selector Flags Registry Initial Values | DKIM Selector Flags Registry Initial Values | |||
7.9. DKIM-Signature Header Field | 7.9. DKIM-Signature Header Field | |||
IANA has added DKIM-Signature to the "Permanent Message Header | IANA has added DKIM-Signature to the "Permanent Message Header | |||
Fields" registry (see [RFC3864]) for the "mail" protocol, using this | Fields" registry (see [RFC3864]) for the "mail" protocol, using this | |||
document as the reference. | document as the reference. | |||
8. Security Considerations | 8. Security Considerations | |||
skipping to change at page 63, line 34 | skipping to change at page 64, line 5 | |||
include From: and Subject:, | include From: and Subject:, | |||
The resulting message violates section 3.6 of [RFC5322]. The way | The resulting message violates section 3.6 of [RFC5322]. The way | |||
such input will be handled and displayed by an MUA is unpredictable, | such input will be handled and displayed by an MUA is unpredictable, | |||
but in some cases it might display the newly added header fields | but in some cases it might display the newly added header fields | |||
rather than those that are part of the originally signed message | rather than those that are part of the originally signed message | |||
alongside some "valid DKIM signature" annotation. This might allow | alongside some "valid DKIM signature" annotation. This might allow | |||
an attacker to replay a previously sent, signed message with a | an attacker to replay a previously sent, signed message with a | |||
different Subject:, From: or To: field. | different Subject:, From: or To: field. | |||
Because of this, DKIM implementers are strongly advised to reject or | Because of this, implementers are strongly advised to reject or treat | |||
treat as suspicious any message that has multiple copies of header | as suspicious any message that has multiple copies of header fields | |||
fields that are disallowed by section 3.6 of [MAIL], particularly | that are disallowed by Section 3.6 of [RFC5322] particularly those | |||
those that are typically displayed to end users (From:, To:, Cc:, | that are typically displayed to end users (From:, To:, Cc:, | |||
Subject:). A signing module could return an error rather than | Subject:). A signing module could return an error rather than | |||
generate a signature; a verifying module might return a syntax error | generate a signature; a verifying module might return a syntax error | |||
code or arrange not to return a positive result even if the signature | code or arrange not to return a positive result even if the signature | |||
technically validates. | technically validates. | |||
Senders concerned that their messages might be particularly | Senders concerned that their messages might be particularly | |||
vulnerable to this sort of attack and who do not wish to rely on | vulnerable to this sort of attack and who do not wish to rely on | |||
receiver filtering of invalid messages can ensure that adding | receiver filtering of invalid messages can ensure that adding | |||
additional header fields will break the DKIM signature by including | additional header fields will break the DKIM signature by including | |||
two copies of the header fields about which they are concerned in the | two copies of the header fields about which they are concerned in the | |||
signature (e.g. "h= ... from:from:to:to:subject:subject ...). See | signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See | |||
Sections 3.5 and 5.4 for further discussion of this mechanism. | Sections 3.5 and 5.4 for further discussion of this mechanism. | |||
Specific validity rules for all known header fields can be gleaned | Specific validity rules for all known header fields can be gleaned | |||
from the IANA "Permanent Header Field Registry" and the reference | from the IANA "Permanent Header Field Registry" and the reference | |||
documents it identifies. | documents it identifies. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
skipping to change at page 74, line 4 | skipping to change at page 74, line 16 | |||
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM | $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM | |||
This results in the file rsa.public containing the key information | This results in the file rsa.public containing the key information | |||
similar to this: | similar to this: | |||
-----BEGIN PUBLIC KEY----- | -----BEGIN PUBLIC KEY----- | |||
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM | MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM | |||
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R | oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R | |||
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI | tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI | |||
MmPSPDdQPNUYckcQ2QIDAQAB | MmPSPDdQPNUYckcQ2QIDAQAB | |||
-----END PUBLIC KEY----- | -----END PUBLIC KEY----- | |||
This public-key data (without the BEGIN and END tags) is placed in | This public-key data (without the BEGIN and END tags) is placed in | |||
the DNS: | the DNS: | |||
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | |||
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | |||
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | |||
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | |||
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | |||
Appendix D. MUA Considerations | Appendix D. Removal of Key Granularity | |||
An important change since [RFC4871] is the removal of the "g=" tag | ||||
from key records, which enabled signers to constrain use of a signing | ||||
key to specific users by requiring a match to the local-part of the | ||||
"i=" tag. [RFC4871] also discussed enabling backward compatibility | ||||
with DomainKeys [RFC4870] when "g=" is present without a value. | ||||
As use of "g=" is now deprecated, a verifier compliant with this | ||||
document will now ignore that tag completely for records that still | ||||
contain it. Signers should thus be aware that compliant verifiers | ||||
will no longer constrain use of the key based on any value found in a | ||||
"g=" tag. | ||||
Appendix E. MUA Considerations | ||||
When a DKIM signature is verified, the processing system sometimes | When a DKIM signature is verified, the processing system sometimes | |||
makes the result available to the recipient user's MUA. How to | makes the result available to the recipient user's MUA. How to | |||
present this information to the user in a way that helps them is a | present this information to the user in a way that helps them is a | |||
matter of continuing human factors usability research. The tendency | matter of continuing human factors usability research. The tendency | |||
is to have the MUA highlight the SDID, in an attempt to show the user | is to have the MUA highlight the SDID, in an attempt to show the user | |||
the identity that is claiming responsibility for the message. An MUA | the identity that is claiming responsibility for the message. An MUA | |||
might do this with visual cues such as graphics, or it might include | might do this with visual cues such as graphics, or it might include | |||
the address in an alternate view, or it might even rewrite the | the address in an alternate view, or it might even rewrite the | |||
original From address using the verified information. Some MUAs | original From address using the verified information. Some MUAs | |||
skipping to change at page 74, line 39 | skipping to change at page 75, line 20 | |||
unsigned header fields in a way that might be construed by the end | unsigned header fields in a way that might be construed by the end | |||
user as having been signed. If the message has an l= tag whose value | user as having been signed. If the message has an l= tag whose value | |||
does not extend to the end of the message, the MUA might also hide or | does not extend to the end of the message, the MUA might also hide or | |||
mark the portion of the message body that was not signed. | mark the portion of the message body that was not signed. | |||
The aforementioned information is not intended to be exhaustive. The | The aforementioned information is not intended to be exhaustive. The | |||
MUA may choose to highlight, accentuate, hide, or otherwise display | MUA may choose to highlight, accentuate, hide, or otherwise display | |||
any other information that may, in the opinion of the MUA author, be | any other information that may, in the opinion of the MUA author, be | |||
deemed important to the end user. | deemed important to the end user. | |||
Appendix E. Acknowledgements | Appendix F. Acknowledgements | |||
The previous IETF version of DKIM [RFC4871] was edited by: Eric | The previous IETF version of DKIM [RFC4871] was edited by: Eric | |||
Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael | Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael | |||
Thomas. | Thomas. | |||
That specification was the result of an extended, collaborative | That specification was the result of an extended, collaborative | |||
effort, including participation by: Russ Allbery, Edwin Aoki, Claus | effort, including participation by: Russ Allbery, Edwin Aoki, Claus | |||
Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve | Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve | |||
Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis | Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis | |||
Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark | Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark | |||
End of changes. 24 change blocks. | ||||
99 lines changed or deleted | 122 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |