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/