draft-ietf-dkim-base-00.txt | draft-ietf-dkim-base-01.txt | |||
---|---|---|---|---|
DKIM E. Allman | DKIM E. Allman | |||
Internet-Draft Sendmail, Inc. | Internet-Draft Sendmail, Inc. | |||
Expires: August 6, 2006 J. Callas | Expires: October 15, 2006 J. Callas | |||
PGP Corporation | PGP Corporation | |||
M. Delany | M. Delany | |||
M. Libbey | M. Libbey | |||
Yahoo! Inc | Yahoo! Inc | |||
J. Fenton | J. Fenton | |||
M. Thomas | M. Thomas | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
February 2, 2006 | April 13, 2006 | |||
DomainKeys Identified Mail Signatures (DKIM) | DomainKeys Identified Mail Signatures (DKIM) | |||
draft-ietf-dkim-base-00 | draft-ietf-dkim-base-01 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 41 | skipping to change at page 1, line 41 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on August 6, 2006. | This Internet-Draft will expire on October 15, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
DomainKeys Identified Mail (DKIM) defines a domain-level | DomainKeys Identified Mail (DKIM) defines a domain-level | |||
authentication framework for email using public-key cryptography and | authentication framework for email using public-key cryptography and | |||
key server technology to permit verification of the source and | key server technology to permit verification of the source and | |||
skipping to change at page 3, line 20 | skipping to change at page 3, line 20 | |||
1.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.4 Simple Key Management . . . . . . . . . . . . . . . . . . 6 | 1.4 Simple Key Management . . . . . . . . . . . . . . . . . . 6 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 | |||
2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | 2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | |||
2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 | 2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.2 Tag=Value Format for DKIM header fields . . . . . . . . . 10 | 3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.3 Signing and Verification Algorithms . . . . . . . . . . . 10 | 3.3 Signing and Verification Algorithms . . . . . . . . . . . 11 | |||
3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 12 | 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 12 | |||
3.5 The DKIM-Signature header field . . . . . . . . . . . . . 16 | 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 16 | |||
3.6 Key Management and Representation . . . . . . . . . . . . 22 | 3.6 Key Management and Representation . . . . . . . . . . . . 23 | |||
3.7 Computing the Message Hash . . . . . . . . . . . . . . . . 26 | 3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 27 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 28 | 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 29 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 28 | 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
5.1 Determine if the Email Should be Signed and by Whom . . . 29 | 5.1 Determine if the Email Should be Signed and by Whom . . . 30 | |||
5.2 Select a private-key and corresponding selector | 5.2 Select a private-key and corresponding selector | |||
information . . . . . . . . . . . . . . . . . . . . . . . 29 | information . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
5.3 Normalize the Message to Prevent Transport Conversions . . 29 | 5.3 Normalize the Message to Prevent Transport Conversions . . 31 | |||
5.4 Determine the header fields to Sign . . . . . . . . . . . 30 | 5.4 Determine the header fields to Sign . . . . . . . . . . . 31 | |||
5.5 Compute the Message Hash . . . . . . . . . . . . . . . . . 32 | 5.5 Compute the Message Hash and Signature . . . . . . . . . . 33 | |||
5.6 Insert the DKIM-Signature header field . . . . . . . . . . 32 | 5.6 Insert the DKIM-Signature header field . . . . . . . . . . 34 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 33 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
6.1 Extract the Signature from the Message . . . . . . . . . . 33 | 6.1 Extract the Signature from the Message . . . . . . . . . . 35 | |||
6.2 Get the Public Key . . . . . . . . . . . . . . . . . . . . 34 | 6.2 Get the Public Key . . . . . . . . . . . . . . . . . . . . 36 | |||
6.3 Compute the Verification . . . . . . . . . . . . . . . . . 35 | 6.3 Compute the Verification . . . . . . . . . . . . . . . . . 37 | |||
6.4 Insert the Authentication-Results Header Field . . . . . . 36 | 6.4 Communicate Verification Results . . . . . . . . . . . . . 39 | |||
6.5 Interpret Results/Apply Local Policy . . . . . . . . . . . 37 | 6.5 Interpret Results/Apply Local Policy . . . . . . . . . . . 39 | |||
6.6 MUA Considerations . . . . . . . . . . . . . . . . . . . . 38 | 6.6 MUA Considerations . . . . . . . . . . . . . . . . . . . . 40 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 | |||
8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 39 | 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 42 | |||
8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 40 | 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 42 | |||
8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 41 | 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 43 | |||
8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 41 | 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 43 | |||
8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 42 | 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 44 | |||
8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 42 | 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 44 | |||
8.7 Intentionally malformed Key Records . . . . . . . . . . . 42 | 8.7 Intentionally malformed Key Records . . . . . . . . . . . 45 | |||
8.8 Intentionally Malformed DKIM-Signature header fields . . . 43 | 8.8 Intentionally Malformed DKIM-Signature header fields . . . 45 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | 8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 45 | |||
9.1 Normative References . . . . . . . . . . . . . . . . . . . 43 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
9.2 Informative References . . . . . . . . . . . . . . . . . . 44 | 9.1 Normative References . . . . . . . . . . . . . . . . . . . 45 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45 | 9.2 Informative References . . . . . . . . . . . . . . . . . . 46 | |||
A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . . 46 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47 | |||
A.1 The user composes an email . . . . . . . . . . . . . . . . 46 | A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . . 48 | |||
A.2 The email is signed . . . . . . . . . . . . . . . . . . . 46 | A.1 The user composes an email . . . . . . . . . . . . . . . . 49 | |||
A.3 The email signature is verified . . . . . . . . . . . . . 47 | A.2 The email is signed . . . . . . . . . . . . . . . . . . . 49 | |||
B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . . 48 | A.3 The email signature is verified . . . . . . . . . . . . . 50 | |||
B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 48 | B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . . 51 | |||
B.2 Outsourced Business Functions . . . . . . . . . . . . . . 48 | B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 51 | |||
B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 49 | B.2 Outsourced Business Functions . . . . . . . . . . . . . . 51 | |||
B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 49 | B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 51 | |||
B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 50 | B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 52 | |||
B.6 Third-party Message Transmission . . . . . . . . . . . . . 50 | B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 52 | |||
C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . . 51 | B.6 Third-party Message Transmission . . . . . . . . . . . . . 53 | |||
D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 | C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . . 53 | |||
E. Edit History . . . . . . . . . . . . . . . . . . . . . . . . . 52 | D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
E.1 Changes since -allman-01 version . . . . . . . . . . . . . 52 | E. Edit History . . . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
E.2 Changes since -allman-00 version . . . . . . . . . . . . . 53 | E.1 Changes since -ietf-00 version . . . . . . . . . . . . . . 55 | |||
Intellectual Property and Copyright Statements . . . . . . . . 54 | E.2 Changes since -allman-01 version . . . . . . . . . . . . . 56 | |||
E.3 Changes since -allman-00 version . . . . . . . . . . . . . 56 | ||||
Intellectual Property and Copyright Statements . . . . . . . . 57 | ||||
1. Introduction | 1. Introduction | |||
[[Note: text in double square brackets (such as this text) will be | ||||
deleted before publication.]] | ||||
1.1 Overview | 1.1 Overview | |||
DomainKeys Identified Mail (DKIM) defines a mechanism by which email | DomainKeys Identified Mail (DKIM) defines a mechanism by which email | |||
messages can be cryptographically signed, permitting a signing domain | messages can be cryptographically signed, permitting a signing domain | |||
to claim responsibility for the introduction of a message into the | to claim responsibility for the introduction of a message into the | |||
mail stream. Message recipients can verify the signature by querying | mail stream. Message recipients can verify the signature by querying | |||
the signer's domain directly to retrieve the appropriate public key, | the signer's domain directly to retrieve the appropriate public key, | |||
and thereby confirm that the message was attested to by a party in | and thereby confirm that the message was attested to by a party in | |||
possession of the private key for the signing domain. | possession of the private key for the signing domain. | |||
skipping to change at page 5, line 36 | skipping to change at page 5, line 39 | |||
issued by well-known, trusted certificate authorities, | issued by well-known, trusted certificate authorities, | |||
o there is no dependency on the deployment of any new Internet | o there is no dependency on the deployment of any new Internet | |||
protocols or services for public key distribution or revocation, | protocols or services for public key distribution or revocation, | |||
o it makes no attempt to include encryption as part of the | o it makes no attempt to include encryption as part of the | |||
mechanism. | mechanism. | |||
DKIM: | DKIM: | |||
o is transparent to and compatible with the existing email | o is compatible with the existing email infrastructure and | |||
infrastructure | transparent to the fullest extent possible | |||
o requires minimal new infrastructure | o requires minimal new infrastructure | |||
o can be implemented independently of clients in order to reduce | o can be implemented independently of clients in order to reduce | |||
deployment time | deployment time | |||
o does not require the use of a trusted third party (such as a | o does not require the use of a trusted third party (such as a | |||
certificate authority or other entity) which might impose | certificate authority or other entity) which might impose | |||
significant costs or introduce delays to deployment | significant costs or introduce delays to deployment | |||
skipping to change at page 5, line 49 | skipping to change at page 6, line 4 | |||
o requires minimal new infrastructure | o requires minimal new infrastructure | |||
o can be implemented independently of clients in order to reduce | o can be implemented independently of clients in order to reduce | |||
deployment time | deployment time | |||
o does not require the use of a trusted third party (such as a | o does not require the use of a trusted third party (such as a | |||
certificate authority or other entity) which might impose | certificate authority or other entity) which might impose | |||
significant costs or introduce delays to deployment | significant costs or introduce delays to deployment | |||
o can be deployed incrementally | o can be deployed incrementally | |||
o allows delegation of signing to third parties. | o allows delegation of signing to third parties. | |||
A "selector" mechanism allows multiple keys per domain, including | A "selector" mechanism allows multiple keys per domain, including | |||
delegation of the right to authenticate a portion of the namespace to | delegation of the right to authenticate a portion of the namespace to | |||
a trusted third party. | a trusted third party. | |||
1.2 Signing Identity | 1.2 Signing Identity | |||
DKIM separates the question of the signer of the message from the | DKIM separates the question of the identity of the signer of the | |||
purported author of the message. In particular, a signature includes | message from the purported author of the message. In particular, a | |||
the identity of the signer. Recipients can use the signing | signature includes the identity of the signer. Verifiers can use the | |||
information to decide how they want to process the message. | signing information to decide how they want to process the message. | |||
INFORMATIVE RATIONALE: The signing address associated with a DKIM | INFORMATIVE RATIONALE: The signing address associated with a DKIM | |||
signature is not required to match a particular header field | signature is not required to match a particular header field | |||
because of the broad methods of interpretation by recipient mail | because of the broad methods of interpretation by recipient mail | |||
systems, including MUAs. | systems, including MUAs. | |||
1.3 Scalability | 1.3 Scalability | |||
The email identification problem is characterized by extreme | The email identification problem is characterized by extreme | |||
scalability requirements. There are currently over 70 million | scalability requirements. There are currently over 70 million | |||
skipping to change at page 7, line 36 | skipping to change at page 7, line 39 | |||
space, to be joined. | space, to be joined. | |||
The formal ABNF for SWSP is: | The formal ABNF for SWSP is: | |||
SWSP = CR / LF / WSP ; streaming white space | SWSP = CR / LF / WSP ; streaming white space | |||
2.4 Common ABNF Tokens | 2.4 Common ABNF Tokens | |||
The following ABNF tokens are used elsewhere in this document. | The following ABNF tokens are used elsewhere in this document. | |||
hyphenated-word = ALPHA *(ALPHA / DIGIT / "-") | hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | |||
base64string = 1*(ALPHA / DIGIT / "+" / "/" / SWSP) | base64string = 1*(ALPHA / DIGIT / "+" / "/" / "=" / SWSP) | |||
2.5 Imported ABNF Tokens | 2.5 Imported ABNF Tokens | |||
The following tokens are imported from other RFCs as noted. Those | The following tokens are imported from other RFCs as noted. Those | |||
RFCs should be considered definitive. However, all tokens having | RFCs should be considered definitive. However, all tokens having | |||
names beginning with "obs-" should be excluded from this import. | names beginning with "obs-" should be excluded from this import, as | |||
they have been obsoleted and are expected to go away in future | ||||
editions of those RFCs. | ||||
The following tokens are imported from [RFC2821]: | The following tokens are imported from [RFC2821]: | |||
o Local-part (implementation warning: this permits quoted strings) | o Local-part (implementation warning: this permits quoted strings) | |||
o Domain (implementation warning: this permits address-literals) | o Domain (implementation warning: this permits address-literals) | |||
o sub-domain | o sub-domain | |||
The following definitions are imported from [RFC2822]: | The following definitions are imported from [RFC2822]: | |||
skipping to change at page 9, line 51 | skipping to change at page 10, line 6 | |||
verification. At the start of the transition period, the outbound | verification. At the start of the transition period, the outbound | |||
email servers are configured to sign with the "february2005" private- | email servers are configured to sign with the "february2005" private- | |||
key. At the end of the transition period, the "january2005" public | key. At the end of the transition period, the "january2005" public | |||
key is removed from the public-key repository. | key is removed from the public-key repository. | |||
While some domains may wish to make selector values well known, | While some domains may wish to make selector values well known, | |||
others will want to take care not to allocate selector names in a way | others will want to take care not to allocate selector names in a way | |||
that allows harvesting of data by outside parties. E.g., if per-user | that allows harvesting of data by outside parties. E.g., if per-user | |||
keys are issued, the domain owner will need to make the decision as | keys are issued, the domain owner will need to make the decision as | |||
to whether to make this selector associated directly with the user | to whether to make this selector associated directly with the user | |||
name, or make it some unassociated random value, such as the | name, or make it some unassociated random value, such as a | |||
fingerprint of the public key. | fingerprint of the public key. | |||
3.2 Tag=Value Format for DKIM header fields | 3.2 Tag=Value Lists | |||
DKIM uses a simple "tag=value" syntax in several contexts, including | DKIM uses a simple "tag=value" syntax in several contexts, including | |||
in messages, domain signature records, and policy records. | in messages, domain signature records, and policy records. | |||
Values are a series of strings containing either base64 text, plain | Values are a series of strings containing either base64 text, plain | |||
text, or quoted printable text, as defined in [RFC2045], section 6.7. | text, or quoted printable text, as defined in [RFC2045], section 6.7. | |||
The name of the tag will determine the encoding of each value; | The name of the tag will determine the encoding of each value; | |||
however, no encoding may include the semicolon (";") character, since | however, no encoding may include the semicolon (";") character, since | |||
that separates tag-specs. | that separates tag-specs. | |||
Formally, the syntax rules are: | Formally, the syntax rules are: | |||
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | |||
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | |||
tag-name = ALPHA 0*ALNUMPUNC | tag-name = ALPHA 0*ALNUMPUNC | |||
tag-value = *VALCHAR ; SWSP prohibited at beginning and end | tag-value = 0*VALCHAR ; SWSP prohibited at beginning and end | |||
VALCHAR = %9 / %d32 - %d58 / %d60 - %d126 | VALCHAR = %9 / %d32 - %d58 / %d60 - %d126 | |||
; HTAB and SP to TILDE except SEMICOLON | ; HTAB and SP to TILDE except SEMICOLON | |||
ALNUMPUNC = ALPHA / DIGIT / "_" | ALNUMPUNC = ALPHA / DIGIT / "_" | |||
Note that WSP is allowed anywhere around tags; in particular, WSP | Note that WSP is allowed anywhere around tags; in particular, WSP | |||
between the tag-name and the "=", and any WSP before the terminating | between the tag-name and the "=", and any WSP before the terminating | |||
";" is not part of the value. | ";" is not part of the value. | |||
Tags MUST be interpreted in a case-sensitive manner. Values MUST be | Tags MUST be interpreted in a case-sensitive manner. Values MUST be | |||
processed as case sensitive unless the specific tag description of | processed as case sensitive unless the specific tag description of | |||
skipping to change at page 10, line 52 | skipping to change at page 11, line 8 | |||
Unrecognized tags MUST be ignored. | Unrecognized tags MUST be ignored. | |||
Tags that have an empty value are not the same as omitted tags. An | Tags that have an empty value are not the same as omitted tags. An | |||
omitted tag is treated as having the default value; a tag with an | omitted tag is treated as having the default value; a tag with an | |||
empty value explicitly designates the empty string as the value. For | empty value explicitly designates the empty string as the value. For | |||
example, "g=" does not mean "g=*", even though "g=*" is the default | example, "g=" does not mean "g=*", even though "g=*" is the default | |||
for that tag. | for that tag. | |||
3.3 Signing and Verification Algorithms | 3.3 Signing and Verification Algorithms | |||
DKIM supports multiple key signing/verification algorithms. The only | DKIM supports multiple key signing/verification algorithms. Two | |||
algorithm defined by this specification at this time is rsa-sha1, | algorithms are defined by this specification at this time: rsa-sha1, | |||
which is the default if no algorithm is specified and which MUST be | and rsa-sha256. The rsa-sha256 algorithm is the default if no | |||
supported by all implementations. | algorithm is specified. Verifiers MUST implement both rsa-sha1 and | |||
rsa-sha256. Signers MUST implement and SHOULD sign using rsa-sha256. | ||||
3.3.1 The rsa-sha1 Signing Algorithm | 3.3.1 The rsa-sha1 Signing Algorithm | |||
The rsa-sha1 Signing Algorithm computes a SHA-1 hash of the message | The rsa-sha1 Signing Algorithm computes a message hash as described | |||
header field and body as described in Section 3.7 below. That hash | in Section 3.7 below using SHA-1 as the hash-alg. That hash is then | |||
is then encrypted by the signer using the RSA algorithm (actually | encrypted by the signer using the RSA algorithm (defined in PKCS#1 | |||
PKCS#1 version 1.5 [RFC3447]) and the signer's private key. The hash | version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | |||
MUST NOT be truncated or converted into any form other than the | The hash MUST NOT be truncated or converted into any form other than | |||
native binary form before being signed. | the native binary form before being signed. | |||
More formally, the algorithm for the signature using rsa-sha1 is: | 3.3.2 The rsa-sha256 Signing Algorithm | |||
RSA(SHA1(canon_message || DKIM-SIG), key) | ||||
where canon_message is the canonicalized message header and body as | The rsa-sha256 Signing Algorithm computes a message hash as described | |||
defined in Section 3.4 and DKIM-SIG is the canonicalized DKIM- | in Section 3.7 below using SHA-256 as the hash-alg. That hash is | |||
Signature header field sans the signature value itself. | then encrypted by the signer using the RSA algorithm (actually 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.2 Other algorithms | 3.3.3 Other algorithms | |||
Other algorithms MAY be defined in the future. Verifiers MUST ignore | Other algorithms MAY be defined in the future. Verifiers MUST ignore | |||
any signatures using algorithms that they do not understand. | any signatures using algorithms that they do not understand. | |||
3.3.3 Key sizes | 3.3.4 Key sizes | |||
Selecting appropriate key sizes is a trade-off between cost, | Selecting appropriate key sizes is a trade-off between cost, | |||
performance and risk. All implementations MUST support keys of sizes | performance and risk. Since short RSA keys more easily succumb to | |||
512, 768, 1024, 1536 and 2048 bits and MAY support larger keys. | 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. Security policies may use the | ||||
length of the signing key as one metric for determining whether a | ||||
signature is acceptable. | ||||
Factors that should influence the key size choice include: | Factors that should influence the key size choice include: | |||
o The practical constraint that a 2048 bit key is the largest key | o The practical constraint that large keys may not fit within a 512 | |||
that fits within a 512 byte DNS UDP response packet | byte DNS UDP response packet | |||
o The security constraint that keys smaller than 1024 bits are | o The security constraint that keys smaller than 1024 bits are | |||
subject to brute force attacks. | subject to off-line attacks | |||
o Larger keys impose higher CPU costs to verify and sign email | o Larger keys impose higher CPU costs to verify and sign email | |||
o Keys can be replaced on a regular basis, thus their lifetime can | o Keys can be replaced on a regular basis, thus their lifetime can | |||
be relatively short | be relatively short | |||
o The security goals of this specification are modest compared to | o The security goals of this specification are modest compared to | |||
typical goals of public-key systems | typical goals of public-key systems | |||
See RFC3766 [RFC3766] for further discussion of selecting key sizes. | ||||
3.4 Canonicalization | 3.4 Canonicalization | |||
Empirical evidence demonstrates that some mail servers and relay | Empirical evidence demonstrates that some mail servers and relay | |||
systems modify email in transit, potentially invalidating a | systems modify email in transit, potentially invalidating a | |||
signature. There are two competing perspectives on such | signature. There are two competing perspectives on such | |||
modifications. For most signers, mild modification of email is | modifications. For most signers, mild modification of email is | |||
immaterial to the authentication status of the email. For such | immaterial to the authentication status of the email. For such | |||
signers a canonicalization algorithm that survives modest in-transit | signers a canonicalization algorithm that survives modest in-transit | |||
modification is preferred. | modification is preferred. | |||
skipping to change at page 12, line 31 | skipping to change at page 12, line 43 | |||
that are within the bounds of email standards such as [RFC2822], but | that are within the bounds of email standards such as [RFC2822], but | |||
are unwilling to accept any modification to the body of messages. | are unwilling to accept any modification to the body of messages. | |||
To satisfy all requirements, two canonicalization algorithms are | To satisfy all requirements, two canonicalization algorithms are | |||
defined for each of the header and the body: a "simple" algorithm | defined for each of the header and the body: a "simple" algorithm | |||
that tolerates almost no modification and a "relaxed" algorithm that | that tolerates almost no modification and a "relaxed" algorithm that | |||
tolerates common modifications such as white-space replacement and | tolerates common modifications such as white-space replacement and | |||
header field line re-wrapping. A signer MAY specify either algorithm | header field line re-wrapping. A signer MAY specify either algorithm | |||
for header or body when signing an email. If no canonicalization | for header or body when signing an email. If no canonicalization | |||
algorithm is specified by the signer, the "simple" algorithm defaults | algorithm is specified by the signer, the "simple" algorithm defaults | |||
for both header and body. A verifier MUST be able to process email | for both header and body. Verifiers MUST implement both | |||
using either canonicalization algorithm. Further canonicalization | canonicalization algorithms. Further canonicalization algorithms MAY | |||
algorithms MAY be defined in the future; verifiers MUST ignore any | be defined in the future; verifiers MUST ignore any signatures that | |||
signatures that use unrecognized canonicalization algorithms. | use unrecognized canonicalization algorithms. | |||
In all cases, the header fields of the message are presented to the | In all cases, the header fields of the message are presented to the | |||
signing algorithm first in the order indicated by the signature | signing algorithm first in the order indicated by the signature | |||
header field and canonicalized using the indicated algorithm. Only | header field and canonicalized using the indicated algorithm. Only | |||
header fields listed as signed in the signature header field are | header fields listed as signed in the signature header field are | |||
included. The CRLF separating the header field from the body is then | included. The CRLF separating the header field from the body is then | |||
presented, followed by the canonicalized body. Note that the header | presented, followed by the canonicalized body. Note that the header | |||
and body may use different canonicalization algorithms. | and body may use different canonicalization algorithms. | |||
Canonicalization simply prepares the email for presentation to the | Canonicalization simply prepares the email for presentation to the | |||
skipping to change at page 13, line 11 | skipping to change at page 13, line 24 | |||
normal" format (e.g., text is ASCII encoded, lines are separated with | normal" format (e.g., text is ASCII encoded, lines are separated with | |||
CRLF characters, etc.). See also Section 5.3 for information about | CRLF characters, etc.). See also Section 5.3 for information about | |||
normalizing the message. | normalizing the message. | |||
3.4.1 The "simple" Header Field Canonicalization Algorithm | 3.4.1 The "simple" Header Field Canonicalization Algorithm | |||
The "simple" header canonicalization algorithm does not change header | The "simple" header canonicalization algorithm does not change header | |||
fields in any way. Header fields MUST be presented to the signing or | fields in any way. Header fields MUST be presented to the signing or | |||
verification algorithm exactly as they are in the message being | verification algorithm exactly as they are in the message being | |||
signed or verified. In particular, header field names MUST NOT be | signed or verified. In particular, header field names MUST NOT be | |||
case folded. | case folded and white space MUST NOT be changed. | |||
3.4.2 The "relaxed" Header Field Canonicalization Algorithm | 3.4.2 The "relaxed" Header Field Canonicalization Algorithm | |||
The "relaxed" header canonicalization algorithm MUST apply the | The "relaxed" header canonicalization algorithm MUST apply the | |||
following steps in order: | following steps in order: | |||
o Convert all header field names (not the header field values) to | o Convert all header field names (not the header field values) to | |||
lower case. For example, convert "SUBJect: AbC" to "subject: | lower case. For example, convert "SUBJect: AbC" to "subject: | |||
AbC". | AbC". | |||
skipping to change at page 13, line 51 | skipping to change at page 14, line 17 | |||
previous version of this draft is that nowsp reduces all strings | previous version of this draft is that nowsp reduces all strings | |||
of streaming white space to zero characters while "relaxed" | of streaming white space to zero characters while "relaxed" | |||
reduces strings of white space to one space.] | reduces strings of white space to one space.] | |||
3.4.3 The "simple" Body Canonicalization Algorithm | 3.4.3 The "simple" Body Canonicalization Algorithm | |||
The "simple" body canonicalization algorithm ignores all empty lines | The "simple" body canonicalization algorithm ignores all empty lines | |||
at the end of the message body. An empty line is a line of zero | at the end of the message body. An empty line is a line of zero | |||
length after removal of the line terminator. It makes no other | length after removal of the line terminator. It makes no other | |||
changes to the message body. In more formal terms, the "simple" body | changes to the message body. In more formal terms, the "simple" body | |||
canonicalization algorithm reduces "CRLF 0*CRLF" to a single "CRLF" | canonicalization algorithm reduces "CRLF 0*CRLF" at the end of the | |||
at the end of the body. | body to a single "CRLF". | |||
3.4.4 The "relaxed" Body Canonicalization Algorithm | 3.4.4 The "relaxed" Body Canonicalization Algorithm | |||
[[This section may be deleted; see discussion below.]] The "relaxed" | [[This section may be deleted; see discussion below.]] The "relaxed" | |||
body canonicalization algorithm: | body canonicalization algorithm: | |||
o Ignores all white space at the end of lines. Implementations MUST | o Ignores all white space at the end of lines. Implementations MUST | |||
NOT remove the CRLF at the end of the line. | NOT remove the CRLF at the end of the line. | |||
o Reduces all sequences of WSP within a line to a single SP | o Reduces all sequences of WSP within a line to a single SP | |||
character. | character. | |||
o Ignores all empty lines at the end of the message body. "Empty | o Ignores all empty lines at the end of the message body. "Empty | |||
line" is defined in Section 3.4.3. | line" is defined in Section 3.4.3. | |||
[[NON-NORMATIVE DISCUSSION: The authors are undecided whether to | [[NON-NORMATIVE DISCUSSION: The authors are undecided whether to | |||
leave the "relaxed" body canonicalization algorithm in to the | leave the "relaxed" body canonicalization algorithm in to the | |||
specification or delete it entirely. We believe that for the vast | specification or delete it entirely. We believe that for the vast | |||
majority of cases, the "simple" body canonicalization algorithm | majority of cases, the "simple" body canonicalization algorithm | |||
should be sufficient. We simply do not have enough data to know | should be sufficient. We simply do not have enough data to know | |||
whether retain the "relaxed" body canonicalization algorithm or | whether to retain the "relaxed" body canonicalization algorithm or | |||
not.]] | not.]] | |||
3.4.5 Body Length Limits | 3.4.5 Body Length Limits | |||
A body length count MAY be specified to limit the signature | A body length count MAY be specified to limit the signature | |||
calculation to an initial prefix of the body text. If the body | calculation to an initial prefix of the body text. If the body | |||
length count is not specified then the entire message body is signed | length count is not specified then the entire message body is signed | |||
and verified. | and verified. | |||
INFORMATIVE IMPLEMENTATION NOTE: Body length limits could be | INFORMATIVE IMPLEMENTATION NOTE: Body length limits could be | |||
useful in increasing signature robustness when sending to a | useful in increasing signature robustness when sending to a | |||
mailing list that both appends to content sent to it and does not | mailing list that both appends to content sent to it and does not | |||
sign its messages. However, using such limits enables an attack | sign its messages. However, using such limits enables an attack | |||
in which a sender with malicious intent modifies a message to | in which a sender with malicious intent modifies a message to | |||
include content that solely benefits the attacker. It is possible | include content that solely benefits the attacker. It is possible | |||
for the appended content to completely replace the original | for the appended content to completely replace the original | |||
content in the end recipient's eyes and to defeat duplicate | content in the end recipient's eyes and to defeat duplicate | |||
message detection algorithms. To avoid this attack, signers | message detection algorithms. To avoid this attack, signers | |||
should be wary of using this tag, and verifiers might wish to | should be wary of using this tag, and verifiers might wish to | |||
ignore the tag or remove text that appears after the specified | ignore the tag or remove text that appears after the specified | |||
content length. | content length, perhaps based on other criteria. | |||
The body length count allows the signer of a message to permit data | The body length count allows the signer of a message to permit data | |||
to be appended to the end of the body of a signed message. The body | to be appended to the end of the body of a signed message. The body | |||
length count is made following the canonicalization algorithm; for | length count is made following the canonicalization algorithm; for | |||
example, any white space ignored by a canonicalization algorithm is | example, any white space ignored by a canonicalization algorithm is | |||
not included as part of the body length count. | not included as part of the body length count. | |||
INFORMATIVE RATIONALE: This capability is provided because it is | INFORMATIVE RATIONALE: This capability is provided because it is | |||
very common for mailing lists to add trailers to messages (e.g., | very common for mailing lists to add trailers to messages (e.g., | |||
instructions how to get off the list). Until those messages are | instructions how to get off the list). Until those messages are | |||
skipping to change at page 15, line 36 | skipping to change at page 15, line 50 | |||
unsigned. | unsigned. | |||
Note that verifiers MAY choose to reject or truncate messages that | Note that verifiers MAY choose to reject or truncate messages that | |||
have body content beyond that specified by the body length count. | have body content beyond that specified by the body length count. | |||
Signers wishing to ensure that no modification of any sort can occur | Signers wishing to ensure that no modification of any sort can occur | |||
should specify the "simple" algorithm and omit the body length count. | should specify the "simple" algorithm and omit the body length count. | |||
3.4.6 Example | 3.4.6 Example | |||
Assuming a "c=relaxes/relaxed" canonicalization algorithm, a message | (In the following examples, actual white space is used only for | |||
reading: | clarity. The actual input and output text is designated using | |||
bracketed descriptors: "<SP>" for a space character, "<TAB>" for a | ||||
tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | ||||
For example, "X <SP> Y" and "X<SP>Y" represent the same three | ||||
characters.) | ||||
A message reading: | ||||
A: <SP> X <CRLF> | A: <SP> X <CRLF> | |||
B <SP> : <SP> Y <TAB><CRLF> | B <SP> : <SP> Y <TAB><CRLF> | |||
<TAB> Z <SP><SP><CRLF> | <TAB> Z <SP><SP><CRLF> | |||
<CRLF> | <CRLF> | |||
<SP> C <SP><CRLF> | <SP> C <SP><CRLF> | |||
D <SP><TAB><SP> E <CRLF> | D <SP><TAB><SP> E <CRLF> | |||
<CRLF> | <CRLF> | |||
<CRLF> | <CRLF> | |||
when canonicalized using "relaxed" for both header and body results | ||||
in: | ||||
when canonicalized using relaxed canonicalization for both header and | ||||
body results in: | ||||
a:X<CRLF> | a:X<CRLF> | |||
b:Y<SP>Z<CRLF> | b:Y<SP>Z<CRLF> | |||
<CRLF> | <CRLF> | |||
<SP>C<CRLF> | <SP>C<CRLF> | |||
D<SP>E<CRLF> | D<SP>E<CRLF> | |||
The same message canonicalized using simple canonicalization for both | ||||
header and body results in: | ||||
A: <SP> X <CRLF> | ||||
B <SP> : <SP> Y <TAB><CRLF> | ||||
<TAB> Z <SP><SP><CRLF> | ||||
<CRLF> | ||||
<SP> C <SP><CRLF> | ||||
D <SP><TAB><SP> E <CRLF> | ||||
When processed using relaxed header canonicalization and simple body | ||||
canonicalization, the canonicalized version reads: | ||||
a:X <CRLF> | ||||
b:Y <SP> Z <CRLF> | ||||
<CRLF> | ||||
<SP> C <SP><CRLF> | ||||
D <SP><TAB><SP> E <CRLF> | ||||
3.5 The DKIM-Signature header field | 3.5 The DKIM-Signature header field | |||
The signature of the email is stored in the "DKIM-Signature:" header | The signature of the email is stored in the "DKIM-Signature:" header | |||
field. This header field contains all of the signature and key- | field. This header field contains all of the signaturee and key- | |||
fetching data. The DKIM-Signature value is a tag-list as described | fetching data. The DKIM-Signature value is a tag-list as described | |||
in Section 3.2. | in Section 3.2. | |||
The "DKIM-Signature:" header field SHOULD be treated as though it | The "DKIM-Signature:" header field SHOULD be treated as though it | |||
were a trace header field as defined in section 3.6 of [RFC2822], and | were a trace header field as defined in section 3.6 of [RFC2822], and | |||
hence SHOULD NOT be reordered and SHOULD be kept in blocks prepended | hence SHOULD NOT be reordered and SHOULD be prepended to the message. | |||
to the message. In particular, the "DKIM-Signature" header field | In particular, the "DKIM-Signature" header field SHOULD precede the | |||
SHOULD precede the original email header fields presented to the | original email header fields presented to the canonicalization and | |||
canonicalization and signature algorithms. | signature algorithms. | |||
The "DKIM-Signature:" header field is always included in the | The "DKIM-Signature:" header field is always included in the | |||
signature calculation, after the body of the message; however, when | signature calculation, after the body of the message; however, when | |||
calculating or verifying the signature, the b= (signature value) | calculating or verifying the signature, the value of the b= tag | |||
value MUST be treated as though it were the null string. Unknown | (signature value) MUST be treated as though it were the null string. | |||
tags MUST be signed but MUST be otherwise ignored by verifiers. | Unknown tags MUST be signed and verified but MUST be otherwise | |||
ignored by verifiers. | ||||
The encodings for each field type are listed below. Tags described | The encodings for each field type are listed below. Tags described | |||
as quoted-printable are as described in section 6.7 of MIME Part One | as quoted-printable are as described in section 6.7 of MIME Part One | |||
[RFC2045], with the additional conversion of semicolon characters to | [RFC2045], with the additional conversion of semicolon characters to | |||
"=3B". | "=3B". | |||
Tags on the DKIM-Signature header field along with their type and | Tags on the DKIM-Signature header field along with their type and | |||
requirement status are shown below. Valid tags are: | requirement status are shown below. Defined tags are described | |||
below. Unrecognized tags MUST be ignored. | ||||
v= Version (MUST NOT be included). This tag is reserved for future | v= Version (MUST NOT be included). This tag is reserved for future | |||
use to indicate a possible new, incompatible version of the | use to indicate a possible new, incompatible version of the | |||
specification. It MUST NOT be included in the DKIM-Signature | specification. It MUST NOT be included in the DKIM-Signature | |||
header field. | header field. | |||
ABNF: | ABNF: | |||
sig-v-tag = | sig-v-tag = | |||
a= The algorithm used to generate the signature (plain-text; | ||||
REQUIRED). Signers and verifiers MUST support "rsa-sha1", an | ||||
RSA-signed SHA-1 digest. See Section 3.3 for a description of | ||||
algorithms. | ||||
INFORMATIVE RATIONALE: The authors understand that SHA-1 has | a= The algorithm used to generate the signature (plain-text; | |||
been theoretically compromised. However, viable attacks | REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | |||
require the attacker to choose both sets of input text; given | signers SHOULD sign using "rsa-sha256". See Section 3.3 for a | |||
a preexisting input (a "preimaging" attack), it is still hard | description of algorithms. | |||
to determine another input that produces an SHA-1 collision, | ||||
and the chance that such input would be of value to an | ||||
attacker is minimal. Also, there is broad library support | ||||
for SHA-1, whereas alternatives such as SHA-256 are just | ||||
emerging. Finally, DKIM is not intended to have legal- or | ||||
military-grade requirements. There is nothing inherent in | ||||
using SHA-1 here other than implementer convenience. See | ||||
<http://www3.ietf.org/proceedings/05mar/slides/saag-3.pdf> | ||||
for a discussion of the security issues. | ||||
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 = "rsa-sha1" / x-sig-a-tag-alg | sig-a-tag-alg = "rsa-sha1" / "rsa-sha256" / x-sig-a-tag-alg | |||
x-sig-a-tag-alg = hyphenated-word ; for later extension | x-sig-a-tag-alg = hyphenated-word ; for later extension | |||
b= The signature data (base64; REQUIRED). Whitespace is ignored in | b= The signature data (base64; REQUIRED). Whitespace is ignored in | |||
this value and MUST be ignored when re-assembling the original | this value and MUST be ignored when re-assembling the original | |||
signature. In particular, the signing process can safely insert | signature. In particular, the signing process can safely insert | |||
FWS in this value in arbitrary places to conform to line-length | FWS in this value in arbitrary places to conform to line-length | |||
limits. See Signer Actions (Section 5) for how the signature is | limits. See Signer Actions (Section 5) for how the signature is | |||
computed. | computed. | |||
ABNF: | ABNF: | |||
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | |||
skipping to change at page 17, line 39 | skipping to change at page 18, line 14 | |||
b= The signature data (base64; REQUIRED). Whitespace is ignored in | b= The signature data (base64; REQUIRED). Whitespace is ignored in | |||
this value and MUST be ignored when re-assembling the original | this value and MUST be ignored when re-assembling the original | |||
signature. In particular, the signing process can safely insert | signature. In particular, the signing process can safely insert | |||
FWS in this value in arbitrary places to conform to line-length | FWS in this value in arbitrary places to conform to line-length | |||
limits. See Signer Actions (Section 5) for how the signature is | limits. See Signer Actions (Section 5) for how the signature is | |||
computed. | computed. | |||
ABNF: | ABNF: | |||
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | |||
sig-b-tag-data = base64string | sig-b-tagg-data = base64string | |||
c= Body canonicalization (plain-text; OPTIONAL, default is "simple/ | bh= The hash of the body part of the message (base64; REQUIRED). | |||
simple"). This tag informs the verifier of the type of | Whitespace is ignored in this value and MUST be ignored when re- | |||
assembling the original signature. In particular, the signing | ||||
process can safely insert FWS in this value in arbitrary places | ||||
to conform to line-length limits. See Section 3.7 for how the | ||||
body hash is computed. | ||||
c= Message canonicalization (plain-text; OPTIONAL, default is | ||||
"simple/simple"). This tag informs the verifier of the type of | ||||
canonicalization used to prepare the message for signing. It | canonicalization used to prepare the message for signing. It | |||
consists of two names separated by a "slash" (%d47) character, | consists of two names separated by a "slash" (%d47) character, | |||
corresponding to the header and body canonicalization algorithms | corresponding to the header and body canonicalization algorithms | |||
respectively. These algorithms are described in Section 3.4. If | respectively. These algorithms are described in Section 3.4. If | |||
only one algorithm is named, that algorithm is used for the | only one algorithm is named, that algorithm is used for the | |||
header and "simple" is used for the body. For example, "relaxed" | header and "simple" is used for the body. For example, | |||
is treated the same as "relaxed/simple". | "c=relaxed" is treated the same as "c=relaxed/simple". | |||
ABNF: | ABNF: | |||
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg | sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg | |||
["/" sig-c-tag-alg] | ["/" sig-c-tag-alg] | |||
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg | sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg | |||
x-sig-c-tag-alg = hyphenated-word ; for later extension | x-sig-c-tag-alg = hyphenated-word ; for later extension | |||
d= The domain of the signing entity (plain-text; REQUIRED). This | d= The domain of the signing entity (plain-text; REQUIRED). This | |||
is the domain that will be queried for the public key. This | is the domain that will be queried for the public key. This | |||
domain MUST be the same as or a parent domain of the "i=" tag. | domain MUST be the same as or a parent domain of the "i=" tag | |||
When presented with a signature that does not meet this | (the signing identity, as described below). When presented with | |||
requirement, verifiers MUST either ignore the signature or reject | a signature that does not meet this requirement, verifiers MUST | |||
the message. | either ignore the signature or reject the message. | |||
ABNF: | ABNF: | |||
sig-d-tag = %x64 [FWS] "=" [FWS] Domain | sig-d-tag = %x64 [FWS] "=" [FWS] Domain | |||
h= Signed header fields (plain-text, but see description; | h= Signed header fields (plain-text, but see description; | |||
REQUIRED). A colon-separated list of header field names that | REQUIRED). A colon-separated list of header field names that | |||
identify the header fields presented to the signing algorithm. | identify the header fields presented to the signing algorithm. | |||
The field MUST contain the complete list of header fields in the | The field MUST contain the complete list of header fields in the | |||
order presented to the signing algorithm. The field MAY contain | order presented to the signing algorithm. The field MAY contain | |||
names of header fields that do not exist when signed; nonexistent | names of header fields that do not exist when signed; nonexistent | |||
header fields do not contribute to the signature computation | header fields do not contribute to the signature computation | |||
(that is, they are treated as the null input, including the | (that is, they are treated as the null input, including the | |||
header field name, the separating colon, the header field value, | header field name, the separating colon, the header field value, | |||
and any CRLF terminator), and when verified non-existent header | and any CRLF terminator). The field MUST NOT include the DKIM- | |||
fields MUST be treated in the same way. The field MUST NOT | Signature header field that is being created or verified. | |||
include the DKIM-Signature header field that is being created or | Folding white space (FWS) MAY be included on either side of the | |||
verified. Folding white space (FWS) MAY be included on either | colon separator. Header ffield names MUST be compared against | |||
side of the colon separator. Header field names MUST be compared | actual header field names in a case insensitive manner. This | |||
against actual header field names in a case insensitive manner. | list MUST NOT be empty. See Section 5.4 for a discussion of | |||
choosing header fields to sign. | ||||
ABNF: | ABNF: | |||
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | |||
0*( *FWS ":" *FWS hdr-name ) | 0*( *FWS ":" *FWS hdr-name ) | |||
hdr-name = field-name | hdr-name = field-name | |||
INFORMATIVE EXPLANATION: By "signing" header fields that do | INFORMATIVE EXPLANATION: By "signing" header fields that do | |||
not actually exist, a signer can prevent insertion of those | not actually exist, a signer can prevent insertion of those | |||
header fields before verification. However, since a sender | header fields before verification. However, since a sender | |||
skipping to change at page 19, line 16 | skipping to change at page 19, line 49 | |||
INFORMATIVE EXPLANATION: The exclusion of the header field | INFORMATIVE EXPLANATION: The exclusion of the header field | |||
name and colon as well as the header field value for non- | name and colon as well as the header field value for non- | |||
existent header fields prevents an attacker from inserting an | existent header fields prevents an attacker from inserting an | |||
actual header field with a null value. | actual header field with a null value. | |||
i= Identity of the user or agent (e.g., a mailing list manager) on | i= Identity of the user or agent (e.g., a mailing list manager) on | |||
behalf of which this message is signed (quoted-printable; | behalf of which this message is signed (quoted-printable; | |||
OPTIONAL, default is an empty local-part followed by an "@" | OPTIONAL, default is an empty local-part followed by an "@" | |||
followed by the domain from the "d=" tag). The syntax is a | followed by the domain from the "d=" tag). The syntax is a | |||
standard email address where the local-part is optional. If the | standard email address where the local-part MAY be omitted. The | |||
signing domain is unable or unwilling to commit to an individual | domain part of the address MUST be the same as or a subdomain of | |||
user name within their domain, the local-part of the address MUST | the value of the "d=" tag. | |||
be omitted. If the local-part of the address is omitted or the | ||||
"i=" tag is not present, the key used to sign MUST be valid for | ||||
any address in the domain. The domain part of the address MUST | ||||
be the same as or a subdomain of the value of the "d=" tag. | ||||
ABNF: | ABNF: | |||
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" Domain | sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" Domain | |||
INFORMATIVE NOTE: The local-part of the "i=" tag is optional | ||||
because in some cases a signer may not be able to establish a | ||||
verified individual identity. In such cases, the signer may | ||||
wish to assert that although it is willing to go as far as | ||||
signing for the domain, it is unable or unwilling to commit | ||||
to an individual user name within their domain. It can do so | ||||
by including the domain part but not the local-part of the | ||||
identity. | ||||
INFORMATIVE DISCUSSION: This document does not require the | INFORMATIVE DISCUSSION: This document does not require the | |||
value of the "i=" tag to match the identity in any message | value of the "i=" tag to match the identity in any message | |||
header field fields. This is considered to be a verifier | header field fields. This is considered to be a verifier | |||
policy issue, described in another document [XREF-TBD]. | policy issue, described in another document [XREF-TBD]. | |||
Constraints between the value of the "i=" tag and other | Constraints between the value of the "i=" tag and other | |||
identities in other header fields seek to apply basic | identities in other header fields seek to apply basic | |||
authentication into the semantics of trust associated with a | aauthentication into the semantics of trust associated with a | |||
role such as content author. Trust is a broad and complex | role such as content author. Trust is a broad and complex | |||
topic and trust mechanisms are subject to highly creative | topic and trust mechanisms are subject to highly creative | |||
attacks. The real-world efficacy of any but the most basic | attacks. The real-world efficacy of any but the most basic | |||
bindings between the "i=" value and other identities is not | bindings between the "i=" value and other identities is not | |||
well established, nor is its vulnerability to subversion by | well established, nor is its vulnerability to subversion by | |||
an attacker. Hence reliance on the use of these options | an attacker. Hence reliance on the use of these options | |||
should be strictly limited. In particular it is not at all | should be strictly limited. In particular it is not at all | |||
clear to what extent a typical end-user recipient can rely on | clear to what extent a typical end-user recipient can rely on | |||
any assurances that might be made by successful use of the | any assurances that might be made by successful use of the | |||
"i=" options. | "i=" options. | |||
skipping to change at page 20, line 32 | skipping to change at page 21, line 24 | |||
ABNF: | ABNF: | |||
sig-l-tag = %x6c [FWS] "=" [FWS] 1*DIGIT | sig-l-tag = %x6c [FWS] "=" [FWS] 1*DIGIT | |||
q= A colon-separated list of query methods used to retrieve the | q= A colon-separated list of query methods used to retrieve the | |||
public key (plain-text; OPTIONAL, default is "dns"). Each query | public key (plain-text; OPTIONAL, default is "dns"). Each query | |||
method is of the form "type[/options]", where the syntax and | method is of the form "type[/options]", where the syntax and | |||
semantics of the options depends on the type. If there are | semantics of the options depends on the type. If there are | |||
multiple query mechanisms listed, the choice of query mechanism | multiple query mechanisms listed, the choice of query mechanism | |||
MUST NOT change the interpretation of the signature. Currently | MUST NOT change the interpretation of the signature. Currently | |||
the only valid value is "dns" which defines the DNS lookup | the only valid value iis "dns" which defines the DNS lookup | |||
algorithm described elsewhere in this document. No options are | algorithm described elsewhere in this document. No options are | |||
defined for the "dns" query type, but the string "dns" MAY have a | defined for the "dns" query type, but the string "dns" MAY have a | |||
trailing "/" character. Verifiers and signers MUST support | trailing "/" character. Verifiers and signers MUST support | |||
"dns". | "dns". | |||
INFORMATIVE RATIONALE: Explicitly allowing a trailing "/" on | INFORMATIVE RATIONALE: Explicitly allowing a trailing "/" on | |||
"dns" allows for the possibility of adding options later and | "dns" allows for the possibility of adding options later and | |||
makes it clear that matching of the query type must terminate | makes it clear that matching of the query type must terminate | |||
on either "/" or end of string. | on either "/" or end of string. | |||
skipping to change at page 21, line 4 | skipping to change at page 21, line 43 | |||
on either "/" or end of string. | on either "/" or end of string. | |||
ABNF: | ABNF: | |||
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method | sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method | |||
*([FWS] ":" [FWS] sig-q-tag-method) | *([FWS] ":" [FWS] sig-q-tag-method) | |||
sig-q-tag-method = sig-q-tag-type ["/" sig-q-tag-args] | sig-q-tag-method = sig-q-tag-type ["/" sig-q-tag-args] | |||
sig-q-tag-type = "dns" / x-sig-q-tag-type | sig-q-tag-type = "dns" / x-sig-q-tag-type | |||
x-sig-q-tag-type = hyphenated-word ; for future extension | x-sig-q-tag-type = hyphenated-word ; for future extension | |||
x-sig-q-tag-args = qp-hdr-value | x-sig-q-tag-args = qp-hdr-value | |||
s= The selector subdividing the namespace for the "d=" (domain) tag | s= The selector subdividing the namespace for the "d=" (domain) tag | |||
(plain-text; REQUIRED). | (plain-text; REQUIRED). | |||
ABNF: | ABNF: | |||
sig-s-tag = %x73 [FWS] "=" [FWS] Domain | sig-s-tag = %x73 [FWS] "=" [FWS] Domain | |||
t= Signature Timestamp (plain-text; RECOMMENDED, default is an | t= Signature Timestamp (plain-text; RECOMMENDED, default is an | |||
unknown creation time). The time that this signature was | unknown creation time). The time that this signature was | |||
created. The format is the standard Unix seconds-since-1970. | created. The format is the number of seconds since 00:00:00 on | |||
The value is expressed as an unsigned integer in decimal ASCII. | January 1, 1970 in the UTC time zone. The value is expressed as | |||
This value is not constrained to fit into a 31- or 32-bit | an unsigned integer in decimal ASCII. This value is not | |||
integer. Implementations SHOULD be prepared to handle values up | constrained to fit into a 31- or 32-bit integer. Implementations | |||
to at least 10^12 (until approximately AD 200,000; this fits into | SHOULD be prepared to handle values up to at least 10^12 (until | |||
40 bits). To avoid denial of service attacks, implementations | approximately AD 200,000; this fits into 40 bits). To avoid | |||
MAY consider any value longer than 12 digits to be infinite. | denial of service attacks, implementations MAY consider any value | |||
longer than 12 digits to be infinite. | ||||
ABNF: | ABNF: | |||
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT | sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT | |||
x= Signature Expiration (plain-text; RECOMMENDED, default is no | x= Signature Expiration (plain-text; RECOMMENDED, default is no | |||
expiration). Signature expiration in seconds-since-1970 format | expiration). The format is the same as in the "t=" tag, | |||
as an absolute date, not as a time delta from the signing | represented as an absolute date, not as a time delta from the | |||
timestamp. Signatures MUST NOT be considered valid if the | signing timestamp. Signatures MUST NOT be considered valid if | |||
current time at the verifier is past the expiration date. The | the current time at the verifier is past the expiration date. | |||
value is expressed as an unsigned integer in decimal ASCII, with | The value is expressed as an unsigned integer in decimal ASCII, | |||
the same contraints on the value in the "t=" tag. | with the same contraints on the value in the "t=" tag. The value | |||
of the "x=" tag MUST be greater than the value of the "t=" tag if | ||||
both are present. | ||||
INFORMATIVE NOTE: The x= tag is not intended as an anti- | INFORMATIVE NOTE: The x= tag is not intended as an anti- | |||
replay defense. | replay defense. | |||
ABNF: | ABNF: | |||
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT | sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT | |||
z= Copied header fields (plain-text, but see description; OPTIONAL, | z= Copied header fields (plain-text, but see description; OPTIONAL, | |||
default is null). A vertical-bar-separated list of header field | default is null). A vertical-bar-separated list of header field | |||
names and copies of header field values that identify the header | names and copies of header field values that identify the header | |||
fields presented to the signing algorithm. The field MUST | fields present when the message was signed. This field need not | |||
contain the complete list of header fields in the order presented | contain the same header fields listed in the "h=" tag. Copied | |||
to the signing algorithm. Copied header field values MUST | header field values MUST immediately follow the header field name | |||
immediately follow the header field name with a colon separator | with a colon separator (no white space permitted). Header field | |||
(no white space permitted). Header field values MUST be | values MUST be represented as Quoted-Printable [RFC2045] with | |||
represented as Quoted-Printable [RFC2045] with vertical bars, | vertical bars, colons, semicolons, and white space encoded in | |||
colons, semicolons, and white space encoded in addition to the | addition to the usual requirements. | |||
usual requirements. | ||||
Verifiers MUST NOT use the copied header field values for | Verifiers MUST NOT use the header field names or copied values | |||
verification should they be present in the h= field. Copied | for checking the signature in any way. Copied header field | |||
header field values are for forensic use only. | values are for diagnostic use only. | |||
Header fields with characters requiring conversion (perhaps from | Header fields with characters requiring conversion (perhaps from | |||
legacy MTAs which are not [RFC2822] compliant) SHOULD be | legacy MTAs which are not [RFC2822] compliant) SHOULD be | |||
converted as described in MIME Part Three [RFC2047]. | converted as described in MIME Part Three [RFC2047]. | |||
ABNF: | ABNF: | |||
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy | sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy | |||
*( [FWS] "|" sig-z-tag-copy ) | *( [FWS] "|" sig-z-tag-copy ) | |||
sig-z-tag-copy = hdr-name ":" [FWS] qp-hdr-value | sig-z-tag-copy = hdr-name ":" [FWS] qp-hdr-value | |||
qp-hdr-value = <quoted-printable text with WS, "|", ":", | qp-hdr-value = <quoted-printable text with WS, "|", ":", | |||
skipping to change at page 22, line 37 | skipping to change at page 23, line 35 | |||
DKIM-Signature: a=rsa-sha1; d=example.net; s=brisbane | DKIM-Signature: a=rsa-sha1; d=example.net; s=brisbane | |||
c=simple; q=dns; i=@eng.example.net; t=1117574938; x=1118006938; | c=simple; q=dns; i=@eng.example.net; t=1117574938; x=1118006938; | |||
h=from:to:subject:date; | h=from:to:subject:date; | |||
z=From:foo@eng.example.net|To:joe@example.com| | z=From:foo@eng.example.net|To:joe@example.com| | |||
Subject:demo%20run|Date:July%205,%202005%203:44:08%20PM%20-0700 | Subject:demo%20run|Date:July%205,%202005%203:44:08%20PM%20-0700 | |||
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | |||
VoG4ZHRNiYzR | VoG4ZHRNiYzR | |||
3.6 Key Management and Representation | 3.6 Key Management and Representation | |||
DKIM keys do not require third party signatures by Certificate | Signature applications require some level of assurance that the | |||
Authorities in order to be trusted, since the public key is retrieved | verification public key is associated with the claimed signer. Many | |||
directly from the signer. | applications achieve this by using public key certificates issued by | |||
a trusted third party. However, DKIM can achieve a sufficient level | ||||
of security, with significantly enhanced scalability, by simply | ||||
having the verifier query the purported signer's DNS entry (or some | ||||
security-equivalent) in order to retrieve the public key. | ||||
DKIM keys can potentially be stored in multiple types of key servers | DKIM keys can potentially be stored in multiple types of key servers | |||
and in multiple formats. The storage and format of keys are | and in multiple formats. The storage and format of keys are | |||
irrelevant to the remainder of the DKIM algorithm. | irrelevant to the remainder of the DKIM algorithm. | |||
Parameters to the key lookup algorithm are the type of the lookup | Parameters to the key lookup algorithm are the type of the lookup | |||
(the "q=" tag), the domain of the responsible signer (the "d=" tag of | (the "q=" tag), the domain of the responsible signer (the "d=" tag of | |||
the DKIM-Signature header field), the signing identity (the "i=" | the DKIM-Signature header field), the signing identity (the "i=" | |||
tag), and the selector (the "s=" tag). The "i=" tag value could be | tag), and the selector (the "s=" tag). The "i=" tag value could be | |||
ignored by some key services. | ignored by some key services. | |||
public_key = dkim_find_key(q_val, d_val, i_val, s_val) | public_key = dkim_find_key(q_val, d_val, i_val, s_val) | |||
This document defines a single binding, using DNS to distribute the | This document defines a single binding, using DNS to distribute the | |||
keys. | keys. | |||
3.6.1 Textual Representation | 3.6.1 Textual Representation | |||
It is expected that many key servers will choose to present the keys | It is expected that many key servers will choose to present the keys | |||
in a text format. The following definition MUST be used for any DKIM | in an otherwise unstructured text format (for example, an XML form | |||
key represented in textual form. | would not be considered to be unstructured text for this purpose). | |||
The following definition MUST be used for any DKIM key represented in | ||||
an otherwise unstructured textual form. | ||||
The overall syntax is a key-value-list as described above. The | The overall syntax is a key-value-list as described in Section 3.2. | |||
current valid tags are: | The current valid tags are described below. Other tags MAY be | |||
present and MUST be ignored by any implementation that does not | ||||
understand them. | ||||
v= Version of the DKIM key record (plain-text; RECOMMENDED, default | v= Version of the DKIM key record (plain-text; RECOMMENDED, default | |||
is "DKIM1"). If specified, this tag MUST be set to "DKIM1" | is "DKIM1"). If specified, this tag MUST be set to "DKIM1" | |||
(without the quotes). This tag MUST be the first tag in the | (without the quotes). This tag MUST be the first tag in the | |||
response. Responses beginning with a "v=" tag with any other | response. Responses beginning with a "v=" tag with any other | |||
value MUST be discarded. | value MUST be discarded. | |||
ABNF: | ABNF: | |||
key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" | key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" | |||
skipping to change at page 24, line 4 | skipping to change at page 25, line 6 | |||
ABNF: | ABNF: | |||
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | |||
key-g-tag-lpart = [dot-atom] ["*"] [dot-atom] | key-g-tag-lpart = [dot-atom] ["*"] [dot-atom] | |||
[[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a dot- | [[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a dot- | |||
atom. This should probably use a different character for | atom. This should probably use a different character for | |||
wildcarding. Unfortunately, the options are non-mnemonic | wildcarding. Unfortunately, the options are non-mnemonic | |||
(e.g., "@", "(", ":"). Alternatively we could insist on | (e.g., "@", "(", ":"). Alternatively we could insist on | |||
escaping a "*" intended as a literal "*" in the address.]] | escaping a "*" intended as a literal "*" in the address.]] | |||
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | ||||
h= Accceptable hash algorithms (plain-text; OPTIONAL, defaults to | ||||
allowing all algorithms). A colon-separated list of hash | allowing all algorithms). A colon-separated list of hash | |||
algorithms that might be used. Signers and Verifiers MUST | algorithms that might be used. Signers and Verifiers MUST | |||
support the "sha1" hash algorithm. | support the "sha1" hash algorithm. | |||
ABNF: | ABNF: | |||
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | |||
0*( [FWS] ":" [FWS] key-h-tag-alg ) | 0*( [FWS] ":" [FWS] key-h-tag-alg ) | |||
key-h-tag-alg = "sha1" / x-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 | x-key-h-tag-alg = hyphenated-word ; for future extension | |||
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | |||
verifiers MUST support the "rsa" key type. The "rsa" key type | verifiers MUST support the "rsa" key type. The "rsa" key type | |||
indicates that an RSA public key, as defined in [RFC3447], | indicates that an RSA public key, as defined in [RFC3447], | |||
sections 3.1 and A.1.1, is being used in the p= tag. (Note: the | 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.) | p= tag further encodes the value using the base64 algorithm.) | |||
ABNF: | ABNF: | |||
skipping to change at page 25, line 22 | skipping to change at page 26, line 26 | |||
appropriate type is not listed. Currently defined service types | appropriate type is not listed. Currently defined service types | |||
are: | are: | |||
* matches all service types | * matches all service types | |||
email electronic mail (not necessarily limited to SMTP) | email electronic mail (not necessarily limited to SMTP) | |||
This tag is intended to permit senders to constrain the use of | This tag is intended to permit senders to constrain the use of | |||
delegated keys, e.g., where a company is willing to delegate the | delegated keys, e.g., where a company is willing to delegate the | |||
right to send mail in their name to an outsourcer, but not to | right to send mail in their name to an outsourcer, but not to | |||
send IM or make VoIP calls. (This of course presumes that these | send IM or make VoIP calls. (This of courrse presumes that these | |||
keys are used in other services in the future.) | keys are used in other services in the future.) | |||
ABNF: | ABNF: | |||
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type | key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type | |||
key-s-tag-type = "email" / "*" / x-key-s-tag-type | key-s-tag-type = "email" / "*" / x-key-s-tag-type | |||
x-key-s-tag-type = hyphenated-word ; for future extension | x-key-s-tag-type = hyphenated-word ; for future extension | |||
t= Flags, represented as a colon-separated list of names (plain- | t= Flags, represented as a colon-separated list of names (plain- | |||
text; OPTIONAL, default is no flags set). The defined flags are: | text; OPTIONAL, default is no flags set). The defined flags are: | |||
skipping to change at page 26, line 4 | skipping to change at page 27, line 9 | |||
unsigned email, even should the signature fail to verify. | unsigned email, even should the signature fail to verify. | |||
Verifiers MAY wish to track testing mode results to assist | Verifiers MAY wish to track testing mode results to assist | |||
the signer. | the signer. | |||
ABNF: | ABNF: | |||
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | |||
0*( [FWS] ":" [FWS] key-t-tag-flag ) | 0*( [FWS] ":" [FWS] key-t-tag-flag ) | |||
key-t-tag-flag = "y" / x-key-t-tag-flag | key-t-tag-flag = "y" / x-key-t-tag-flag | |||
x-key-t-tag-flag = hyphenated-word ; for future extension | x-key-t-tag-flag = hyphenated-word ; for future extension | |||
Unrecognized flags MUST be ignored. | Unrecognized flags MUST be ignored. | |||
3.6.2 DNS binding | 3.6.2 DNS binding | |||
A binding using DNS as a key service is hereby defined. All | A binding using DNS as a key service is hereby defined. All | |||
implementations MUST support this binding. | implementations MUST support this binding. | |||
3.6.2.1 Name Space | 3.6.2.1 Name Space | |||
All DKIM keys are stored in a "_domainkey" subdomain. Given a DKIM- | All DKIM keys are stored in a subdomain named ""_domainkey"". Given | |||
Signature field with a "d=" tag of "domain" and an "s=" tag of | a DKIM-Signature field with a "d=" tag of ""example.com"" and an "s=" | |||
"selector", the DNS query will be for "selector."_domainkey".domain". | tag of ""sample"", the DNS query will be for | |||
""sample._domainkey.example.com"". | ||||
The value of the "i=" tag is not used by the DNS binding. | The value of the "i=" tag is not used by the DNS binding. | |||
3.6.2.2 Resource Record Types for Key Storage | 3.6.2.2 Resource Record Types for Key Storage | |||
[[This section needs to be fleshed out. ACTUALLY: will be addressed | [[This section needs to be fleshed out. ACTUALLY: will be addressed | |||
in another document.]] | in another document.]] | |||
Two RR types are used: DKK and TXT. | Two RR types are used: DKK and TXT. | |||
skipping to change at page 26, line 37 | skipping to change at page 27, line 44 | |||
intended to allow the largest possible keys to be represented and | intended to allow the largest possible keys to be represented and | |||
transmitted in a UDP DNS packet. Details of this RR are described in | transmitted in a UDP DNS packet. Details of this RR are described in | |||
[ID-DKIM-RR]. | [ID-DKIM-RR]. | |||
TXT records are encoded as described in Section 3.6.1. | TXT records are encoded as described in Section 3.6.1. | |||
Verifiers SHOULD search for a DKK RR first, if possible, followed by | Verifiers SHOULD search for a DKK RR first, if possible, followed by | |||
a TXT RR. If the verifier is unable to search for a DKK RR or a DKK | a TXT RR. If the verifier is unable to search for a DKK RR or a DKK | |||
RR is not found, the verifier MUST search for a TXT RR. | RR is not found, the verifier MUST search for a TXT RR. | |||
3.7 Computing the Message Hash | 3.7 Computing the Message Hashes | |||
Both signing and verifying message signatures starts with a step of | Both signing and verifying message signatures starts with a step of | |||
computing a cryptographic hash of the message. Signers will choose | computing two cryptographic hash over the message. Signers will | |||
the parameters of the signature as described in Signer Actions | choose the parameters of the signature as described in Signer Actions | |||
(Section 5); verifiers will use the parameters specified in the | (Section 5); verifiers will use the parameters specified in the | |||
"DKIM-Signature" header field being verified. In the following | "DKIM-Signature" header field being verified. In the following | |||
discussion, the names of the tags in the "DKIM-Signature" header | discussion, the names of the tags in the "DKIM-Signature" header | |||
field which either exists (when verifying) or will be created (when | field which either exists (when verifying) or will be created (when | |||
signing) are used. | signing) are used. Note that canonicalization (Section 3.4) is only | |||
used to prepare the email for signing or verifying; it does not | ||||
The signer or verifier MUST pass the following to the hash algorithm | ||||
in the indicated order. Note that canonicalization (Section 3.4) is | ||||
only used to prepare the email for signing or verifying; it does not | ||||
affect the transmitted email in any way. | affect the transmitted email in any way. | |||
1. The header fields specified by the "h=" tag, in the order | The signer or verifier must compute two hashes, one over the body of | |||
specified in that tag, and canonicalized using the header | the message and one over the header of the message. Signers MUST | |||
canonicalization algorithm specified in the "c=" tag. | compute them in the order shown. Verifiers MAY compute them in any | |||
order convenient to the verifier, provided that the result is | ||||
semantically identical to the semantics that would be the case had | ||||
they been computed in this order. | ||||
2. A single CRLF. | In hash step 1, the signer or verifier MUST hash the message body, | |||
canonicalized using the header canonicalization algorithm specified | ||||
in the "c=" tag and truncated to the length specified in the "l=" | ||||
tag. That hash value is then converted to base64 form and inserted | ||||
into the "XXX=" tag of the DKIM-Signature: header field. | ||||
3. The message body, canonicalized using the body canonicalization | In hash step 2, the signer or verifier MUST pass the following to the | |||
algorithm specified in the "c=" tag, and truncated to the length | hash algorithm in the indicated order. | |||
specified in the "l=" tag. | ||||
4. A single CRLF. | 1. The header fields specified by the "h=" tag, in the order | |||
specified in that tag, and canonicalized using the header | ||||
canonicalization algorithm specified in the "c=" tag. Each | ||||
header field must be terminated with a single CRLF. | ||||
5. The "DKIM-Signature" header field that exists (verifying) or will | 2. The "DKIM-Signature" header field that exists (verifying) or will | |||
be inserted (signing) in the message, with the content of the | be inserted (signing) in the message, with the value of the "b=" | |||
"b=" tag deleted (i.e., treated as the empty string), | tag deleted (i.e., treated as the empty string), canonicalized | |||
canonicalized using the header canonicalization algorithm | using the header canonicalization algorithm specified in the "c=" | |||
specified in the "c=" tag, and without a trailing CRLF. | tag, and without a trailing CRLF. | |||
After the body is processed, a single CRLF followed by the "DKIM- | After the body is processed, a single CRLF followed by the "DKIM- | |||
Signature" header field being created or verified is presented to the | Signature" header field being created or verified is presented to the | |||
algorithm. The value portion of the "b=" tag (that is, the portion | algorithm. The value portion of the "b=" tag (that is, the portion | |||
after the "=" sign) must be treated as though it were empty, and the | after the "=" sign) must be treated as though it were empty, and the | |||
header field must be canonicalized according to the algorithm that is | header field must be canonicalized according to the algorithm that is | |||
specified in the "c=" tag. Any final CRLF on the "DKIM-Signature" | specified in the "c=" tag. Any final CRLF on the "DKIM-Signature" | |||
header field MUST NOT be included in the signature computation. | header field MUST NOT be included in the signature computation. | |||
All tags and their values in the DKIM-Signature header field are | All tags and their values in the DKIM-Signature header field are | |||
included in the cryptographic hash with the sole exception of the | included in the cryptographic hash with the sole exception of the | |||
value portion of the "b=" (signature) tag, which MUST be treated as | value portion of the "b=" (signature) tag, which MUST be treated as | |||
the null string. All tags MUST be included even if they might not be | the null string. All tags MUST be included even if they might not be | |||
understood by the verifier. The header field MUST be presented to | understood by the verifier. The header field MUST be presented to | |||
the hash algorithm after the body of the message rather than with the | the hash algorithm after the body of the message rather than with the | |||
rest of the header fields and MUST be canonicalized as specified in | rest of the headder fields and MUST be canonicalized as specified in | |||
the "c=" (canonicalization) tag. The DKIM-Signature header field | the "c=" (canonicalization) tag. The DKIM-Signature header field | |||
MUST NOT be included in its own h= tag. | MUST NOT be included in its own h= tag. | |||
When calculating the hash on messages that will be transmitted using | When calculating the hash on messages that will be transmitted using | |||
base64 or quoted-printable encoding, signers MUST compute the hash | base64 or quoted-printable encoding, signers MUST compute the hash | |||
after the encoding. Likewise, the verifier MUST incorporate the | after the encoding. Likewise, the verifier MUST incorporate the | |||
values into the hash before decoding the base64 or quoted-printable | values into the hash before decoding the base64 or quoted-printable | |||
text. However, the hash MUST be computed before transport level | text. However, the hash MUST be computed before transport level | |||
encodings such as SMTP "dot-stuffing." | encodings such as SMTP "dot-stuffing." | |||
With the exception of the canonicalization procedure described in | With the exception of the canonicalization procedure described in | |||
Section 3.4, the DKIM signing process treats the body of messages as | Section 3.4, the DKIM signing process treats the body of messages as | |||
simply a string of characters. DKIM messages MAY be either in plain- | simply a string of characters. DKIM messages MAY be either in plain- | |||
text or in MIME format; no special treatment is afforded to MIME | text or in MIME format; no special treatment is afforded to MIME | |||
content. Message attachments in MIME format MUST be included in the | content. Message attachments in MIME format MUST be included in the | |||
content which is signed. | content which is signed. | |||
4. Semantics of Multiple Signatures | More formally, the algorithm for the signature is: | |||
body-hash = hash-alg(canon_body) | ||||
Considerable energy has been spent discussing the desirability and | header-hash = crypt-alg(hash-alg(canon_header || DKIM-SIG), key) | |||
semantics of multiple DKIM signatures in a single message, | ||||
particularly in a "re-sending" scenario such as a mailing list. On | ||||
the one hand, discarding existing signature header fields loses | ||||
information which could prove to be valuable in the future. On the | ||||
other hand, since header fields are known to be re-ordered in transit | ||||
by at least some MTAs, determining the most interesting signature | ||||
header field is non-trivial. | ||||
Further confusion could occur with multiple signatures added at the | where crypt-alg is the encryption algorithm specified by the "a=" | |||
same logical "depth". For example, a signer could choose to sign | tag, hash-alg is the hash algorithm specified by the "a=" tag, | |||
using multiple signing or canonicalization algorithms. There is no a | canon_header and canon_body are the canonicalized message header and | |||
priori way to determine that two signatures are alternatives versus | body (respectively) as defined in Section 3.4 (excluding the DKIM- | |||
nested in a re-sending scenario. | Signature header field), and DKIM-SIG is the canonicalized DKIM- | |||
Signature header field sans the signature value itself, but with | ||||
body-hash included as the "bh=" tag. | ||||
[[DOCUMENTATION NOTE: ISSUE: downgrade attacks by removal of sig | 4. Semantics of Multiple Signatures | |||
headers that use stronger algorithms.]] | ||||
Also, many agents are expected to break existing signatures (e.g., a | A signer that is adding a signature to a message merely creates a new | |||
mailing list that modifies Subject header fields or adds unsubscribe | DKIM-Signature header, using the usual semantics of the h= option. A | |||
information to the end of the message). Retaining signature | signer MAY sign previously existing DKIM-Signature headers using the | |||
information that is known to be bad could create more problems than | method described in section NN to sign trace headers. Signers should | |||
it solves. | be cognizant that signing DKIM-Signature headers may result in | |||
signature failures with intermediaries that do not recognize that | ||||
DKIM-Signature's are trace headers and unwittingly reorder them. | ||||
For these reasons, multiple signatures are not prohibited but are | When evaluating a message with multiple signatures, a receiver should | |||
left undefined. | evaluate signatures independently and on their own merits. For | |||
example, a receiver that by policy chooses not to accept signatures | ||||
with deprecated crypto algorithms should consider such signatures | ||||
invalid. As with messages with a single signature, receievers are at | ||||
liberty to use the presence of valid signatures as an input to local | ||||
policy; likewise, the interpretation of multiple valid signatures in | ||||
combination is a local policy decision of the receiver. | ||||
INFORMATIVE IMPLEMENTATION GUIDANCE: Agents that forward mail | Signers SHOULD NOT remove any DKIM-Signature headers from messages | |||
without modification could decide whether to add another signature | they are signing, even if they know that the headers cannot be | |||
or simply retain an existing signatures. Agents that are known to | verified. | |||
break existing signatures may leave the existing signature or | ||||
delete it. Agents that re-sign messages that are already signed | ||||
should verify the previous signature and should probably refuse to | ||||
sign any critical information that failed a signature | ||||
verification. | ||||
5. Signer Actions | 5. Signer Actions | |||
The following steps are performed in order by signers. | The following steps are performed in order by signers. | |||
5.1 Determine if the Email Should be Signed and by Whom | 5.1 Determine if the Email Should be Signed and by Whom | |||
A signer can obviously only sign email for domains for which it has a | A signer can obviously only sign email for domains for which it has a | |||
private-key and the necessary knowledge of the corresponding public | private-key and the necessary knowledge of the corresponding public | |||
key and selector information. However there are a number of other | key and selector information. However there are a number of other | |||
skipping to change at page 29, line 37 | skipping to change at page 30, line 43 | |||
If an email cannot be signed for some reason, it is a local policy | If an email cannot be signed for some reason, it is a local policy | |||
decision as to what to do with that email. | decision as to what to do with that email. | |||
5.2 Select a private-key and corresponding selector information | 5.2 Select a private-key and corresponding selector information | |||
This specification does not define the basis by which a signer should | This specification does not define the basis by which a signer should | |||
choose which private-key and selector information to use. Currently, | choose which private-key and selector information to use. Currently, | |||
all selectors are equal as far as this specification is concerned, so | all selectors are equal as far as this specification is concerned, so | |||
the decision should largely be a matter of administrative | the decision should largely be a matter of administrative | |||
convenience. | convenience. Distribution and management of private-keys is also | |||
outside the scope of this document. | ||||
A signer SHOULD NOT sign with a key that is expected to expire within | A signer SHOULD NOT sign with a key that is expected to expire within | |||
seven days; that is, when rotating to a new key, signing should | seven days; that is, when rotating to a new key, signing should | |||
immediately commence with the new key and the old key SHOULD be | immediately commence with the new key and the old key SHOULD be | |||
retained for at least seven days before being removed from the key | retained for at least seven days before being removed from the key | |||
server. | server. | |||
5.3 Normalize the Message to Prevent Transport Conversions | 5.3 Normalize the Message to Prevent Transport Conversions | |||
Some messages, particularly those using 8-bit characters, are subject | Some messages, particularly those using 8-bit characters, are subject | |||
to modification during transit, notably conversion to 7-bit form. | to modification during transitt, notably conversion to 7-bit form. | |||
Such conversions will break DKIM signatures. In order to minimize | Such conversions will break DKIM signatures. In order to minimize | |||
the chances of such breakage, signers SHOULD convert the message to a | the chances of such breakage, signers SHOULD convert the message to a | |||
suitable MIME content transfer encoding such as quoted-printable or | suitable MIME content transfer encoding such as quoted-printable or | |||
base64 as described in MIME Part One [RFC2045] before signing. Such | base64 as described in MIME Part One [RFC2045] before signing. Such | |||
conversion is outside the scope of DKIM; the actual message SHOULD be | conversion is outside the scope of DKIM; the actual message SHOULD be | |||
converted to 7-bit MIME by an MUA or MSA prior to presentation to the | converted to 7-bit MIME by an MUA or MSA prior to presentation to the | |||
DKIM algorithm. | DKIM algorithm. | |||
Should the message be submitted to the signer with any local encoding | Should the message be submitted to the signer with any local encoding | |||
that will be modified before transmission, such conversion to | that will be modified before transmission, such conversion to | |||
skipping to change at page 30, line 40 | skipping to change at page 31, line 49 | |||
[RFC2821] explicitly permits modification or removal of the "Return- | [RFC2821] explicitly permits modification or removal of the "Return- | |||
Path" header field in transit. Signers MAY include any other header | Path" header field in transit. Signers MAY include any other header | |||
fields present at the time of signing at the discretion of the | fields present at the time of signing at the discretion of the | |||
signer. It is RECOMMENDED that all other existing, non-repeatable | signer. It is RECOMMENDED that all other existing, non-repeatable | |||
header fields be signed. | header fields be signed. | |||
The DKIM-Signature header field is always implicitly signed and MUST | The DKIM-Signature header field is always implicitly signed and MUST | |||
NOT be included in the h= tag except to indicate that other | NOT be included in the h= tag except to indicate that other | |||
preexisting signatures are also signed. | preexisting signatures are also signed. | |||
Signers MUST sign any header fields that the signers wish to have the | Signers MUST sign any header fields that the signers wish to assert | |||
verifiers treat as trusted. Put another way, verifiers MAY treat | were present at the time of signing. Put another way, verifiers MAY | |||
unsigned header fields with extreme skepticism, up to and including | treat unsigned header fields with extreme skepticism, up to and | |||
refusing to display them to the end user. | including refusing to display them to the end user. | |||
Signers MAY claim to have signed header fields that do not exist | Signers MAY claim to have signed header fields that do not exist | |||
(that is, signers MAY include the header field name in the h= tag | (that is, signers MAY include the header field name in the h=D tag | |||
even if that header field does not exist in the message). When | even if that header field does not exist in the message). When | |||
computing the signature, the non-existing header field MUST be | computing the signature, the non-existing header field MUST be | |||
treated as the null string (including the header field name, header | treated as the null string (including the header field name, header | |||
field value, all punctuation, and the trailing CRLF). | field value, all punctuation, and the trailing CRLF). | |||
INFORMATIVE RATIONALE: This allows signers to explicitly assert | INFORMATIVE RATIONALE: This allows signers to explicitly assert | |||
the absence of a header field; if that header field is added later | the absence of a header field; if that header field is added later | |||
the signature will fail. | the signature will fail. | |||
Signers choosing to sign an existing replicated header field (such as | Signers choosing to sign an existing replicated header field (such as | |||
skipping to change at page 32, line 10 | skipping to change at page 33, line 17 | |||
the original order. | the original order. | |||
INFORMATIVE RATIONALE: Received: is allowed because these header | INFORMATIVE RATIONALE: Received: is allowed because these header | |||
fields, as well as Resent-* header fields, are already order- | fields, as well as Resent-* header fields, are already order- | |||
sensitive. | sensitive. | |||
INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits | INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits | |||
header field blocks to be reordered (with the exception of | header field blocks to be reordered (with the exception of | |||
Received header fields), reordering of signed replicated header | Received header fields), reordering of signed replicated header | |||
fields by intermediate MTAs will cause DKIM signatures to be | fields by intermediate MTAs will cause DKIM signatures to be | |||
broken; such anti-social behavior should be avoided. | broken; such anti-social behavior shoulld be avoided. | |||
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | |||
specification, all end-user visible header fields should be signed | specification, all end-user visible header fields should be signed | |||
to avoid possible "indirect spamming." For example, if the | to avoid possible "indirect spamming." For example, if the | |||
"Subject" header field is not signed, a spammer can resend a | "Subject" header field is not signed, a spammer can resend a | |||
previously signed mail, replacing the legitimate subject with a | previously signed mail, replacing the legitimate subject with a | |||
one-line spam. | one-line spam. | |||
INFORMATIVE NOTE: There has been some discussion that a Sender | INFORMATIVE NOTE: There has been some discussion that a Sender | |||
Signing Policy include the list of header fields that the signer | Signing Policy include the list of header fields that the signer | |||
always signs. N.B. In theory this is unnecessary, since as long | always signs. N.B. In theory this is unnecessary, since as long | |||
as the signer really always signs the indicated header fields | as the signer really always signs the indicated header fields | |||
there is no possibility of an attacker replaying an existing | there is no possibility of an attacker replaying an existing | |||
message that has such an unsigned header field. | message that has such an unsigned header field. | |||
5.5 Compute the Message Hash | 5.5 Compute the Message Hash and Signature | |||
The signer MUST compute the message hash as described in Section 3.7 | The signer MUST compute the message hash as described in Section 3.7 | |||
and then sign it using the selected public-key algorithm. | and then sign it using the selected public-key algorithm. This will | |||
result in a DKIM-Signature header field which will include the body | ||||
hash and a signature of the header hash, where that header includes | ||||
the DKIM-Signature header field itself. | ||||
To avoid possible ambiguity, a signer SHOULD either sign or remove | To avoid possible ambiguity, a signer SHOULD either sign or remove | |||
any preexisting header fields which convey the results of previous | any preexisting header fields which convey the results of previous | |||
verifications of the message signature prior to preparation for | verifications of the message signature prior to preparation for | |||
signing and transmission. Such header fields MUST NOT be signed if | signing and transmission. Such header fields MUST NOT be signed if | |||
the signer is uncertain of the authenticity of the preexisting header | the signer is uncertain of the authenticity of the preexisting header | |||
field, for example, if it is not locally generated or signed by a | field, for example, if it is not locally generated or signed by a | |||
previous DKIM-Signature line that the current signer has verified. | previous DKIM-Signature line that the current signer has verified. | |||
Entities such as mailing list managers that implement DKIM and which | Entities such as mailing list managers that implement DKIM and which | |||
modify the message or the header field (for example, inserting | modify the message or a header field (for example, inserting | |||
unsubscribe information) before retransmitting the message SHOULD | unsubscribe information) before retransmitting the message SHOULD | |||
check any existing signature on input and MUST make such | check any existing signature on input and MUST make such | |||
modifications before re-signing the message; such signing SHOULD | modifications before re-signing the message; such signing SHOULD | |||
include any prior verification status, if any, that was inserted upon | include any prior verification status, if any, that was inserted upon | |||
message receipt. | message receipt. | |||
The signer MAY elect to limit the number of bytes of the body that | ||||
will be included in the hash and hence signed. The length actually | ||||
hashed should be inserted in the "l=" tag of the "DKIM-Signature" | ||||
header field. | ||||
INFORMATIVE NOTE: A possible value to include in the "l=" tag | ||||
would include the entire length of the message being signed, | ||||
thereby allowing intermediate agents to append further information | ||||
to the message without breaking the signature (e.g., a mailing | ||||
list manager might add unsubscribe innformation to the body). A | ||||
signer wishing to permit such intermediate agents to add another | ||||
MIME body part to a "multipart/mixed" message should use a length | ||||
that covers the entire presented message except for the trailing | ||||
"--CRLF" characters; this is known as the "N-4" approach. Note | ||||
that more than four characters may need to be stripped, since | ||||
there could be postlude information that needs to be ignored. | ||||
5.6 Insert the DKIM-Signature header field | 5.6 Insert the DKIM-Signature header field | |||
Finally, the signer MUST insert the "DKIM-Signature:" header field | Finally, the signer MUST insert the "DKIM-Signature:" header field | |||
prior to transmitting the email. The "DKIM-Signature" header field | created in the previous step prior to transmitting the email. The | |||
MUST be the same as used to compute the hash as described above, | "DKIM-Signature" header field MUST be the same as used to compute the | |||
except that the value of the "b=" tag MUST be the appropriately | hash as described above, except that the value of the "b=" tag MUST | |||
signed hash computed in the previous step, signed using the algorithm | be the appropriately signed hash computed in the previous step, | |||
specified in the "a=" tag of the "DKIM-Signature" header field and | signed using the algorithm specified in the "a=" tag of the "DKIM- | |||
using the private key corresponding to the selector given in the "s=" | Signature" header field and using the private key corresponding to | |||
tag of the "DKIM-Signature" header field, as chosen above in | the selector given in the "s=" tag of the "DKIM-Signature" header | |||
Section 5.2 | field, as chosen above in Section 5.2 | |||
The "DKIM-Signature" SHOULD be inserted before any header fields that | The "DKIM-Signature" SHOULD be inserted before any header fields that | |||
it signs in the header block. | it signs in the header block. | |||
INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this | INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this | |||
is to insert the "DKIM-Signature" header field at the beginning of | is to insert the "DKIM-Signature" header field at the beginning of | |||
the header block. This is consistent with treating "DKIM- | the header block. In particular, it may be placed before any | |||
Signature" as a trace header. | existing Received header fields. This is consistent with treating | |||
"DKIM-Signature" as a trace header. | ||||
6. Verifier Actions | 6. Verifier Actions | |||
Since a signer MAY expire a public key at any time, it is recommended | Since a signer MAY expire a public key at any time, it is recommended | |||
that verification occur in a timely manner with the most timely place | that verification occur in a timely manner with the most timely place | |||
being during acceptance by the border MTA. | being during acceptance by the border MTA. | |||
A border or intermediate MTA MAY verify the message signatures and | A border or intermediate MTA MAY verify the message signatures and | |||
add a verification header field to incoming messages. This | add a verification header field to incoming messages. This | |||
considerably simplifies things for the user, who can now use an | considerably simplifies things for the user, who can now use an | |||
existing mail user agent. Most MUAs have the ability to filter | existing mail user agent. Most MUAs have the ability to filter | |||
messages based on message header fields or content; these filters | messages based on message header fields or content; these filters | |||
would be used to implement whatever policy the user wishes with | would be used to implement whatever policy the user wishes with | |||
respect to unsigned mail. | respect to unsigned mail. | |||
A verifying MTA MAY implement a policy with respect to unverifiable | A verifying MTA MAY implement a policy with respect to unverifiable | |||
mail, regardless of whether or not it applies the verification header | mail, regardless of whether or not it applies the verification header | |||
field to signed messages. | field to signed messages. | |||
Verifiers apply the following steps in the order listed. | Verifiers MUST apply the following steps in the order listed. In | |||
many cases these steps say that a "DKIM-Signature" header field must | ||||
be ignored, e.g., because it is malformed or because the signature | ||||
verification failed. In such cases verifiers SSHOULD proceed to the | ||||
next signature, and treat the message as verified if any signature | ||||
succeeded, ignoring the bad signatures. The order in which | ||||
signatures are tried is a matter of local policy for the verifier and | ||||
is not defined here. A verifier MAY treat a message that has one or | ||||
more bad signatures and no good signatures differently from a message | ||||
with no signature at all; again, this is local policy and is beyond | ||||
the scope of this document. | ||||
6.1 Extract the Signature from the Message | 6.1 Extract the Signature from the Message | |||
The signature and associated signing identity is included in the | The signature and associated signing identity is included in the | |||
value of the DKIM-Signature header field. | value of the DKIM-Signature header field. | |||
Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag. | Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag. | |||
Existence of such a tag indicates a new, incompatible version of the | Existence of such a tag indicates a new, incompatible version of the | |||
DKIM-Signature header field. | DKIM-Signature header field. | |||
If the "DKIM-Signature" header field does not contain the "i=" tag, | If the "DKIM-Signature" header field does not contain the "i=" tag, | |||
the verifier MUST behave as though the value of that tag were "@d", | the verifier MUST behave as though the value of that tag were "@d", | |||
where "d" is the value from the "d=" tag (which MUST exist). | where "d" is the value from the "d=" tag (which MUST exist). | |||
Verifiers MUST confirm that the domain specified in the "d=" tag is | Verifiers MUST confirm that the domain specified in the "d=" tag is | |||
the same as or a superdomain of the domain part of the "i=" tag. If | the same as or a superdomain of the domain part of the "i=" tag. If | |||
not, the DKIM-Signature header field MUST be ignored. | not, the DKIM-Signature header field MUST be ignored. | |||
Implementers MUST meticulously validate the format and values in the | Implementers MUST meticulously validate the format and values in the | |||
"DKIM-Signature:" header field; any inconsistency or unexpected | "DKIM-Signature:" header field; any inconsistency or unexpected | |||
values MUST result in an unverified email. Being "liberal in what | values MUST cause the header field to be completely ignored. Being | |||
you accept" is definitely a bad strategy in this security context. | "liberal in what you accept" is definitely a bad strategy in this | |||
Note however that this does not include the existence of unknown tags | security context. Note however that this does not include the | |||
in a "DKIM-Signature" header field, which are explicitly permitted. | existence of unknown tags in a "DKIM-Signature" header field, which | |||
are explicitly permitted. | ||||
Verifiers MUST NOT attribute ultimate meaning to the order of | Verifiers MUST NOT attribute ultimate meaning to the order of | |||
multiple DKIM-Signature header fields. In particular, there is | multiple DKIM-Signature header fields. In particular, there is | |||
reason to believe that some relays will reorder the header field in | reason to believe that some relays will reorder the header field in | |||
potentially arbitrary ways. | potentially arbitrary ways. | |||
INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as | INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as | |||
a clue to signing order in the absence of any other information. | a clue to signing order in the absence of any other information. | |||
However, other clues as to the semantics of multiple signatures | However, other clues as to the semantics of multiple signatures | |||
must be considered before using ordering. | must be considered before using ordering. | |||
Since there can be multiple signatures in a message, a verifier | Since there can be multiple signatures in a message, a verifier | |||
SHOULD ignore an invalid signature (regardless if caused by a | SHOULD ignore an invalid signature (regardless if caused by a | |||
syntactic or semantic problem) and try other signatures. A verifier | syntactic or semantic problem) and try other signatures. A verifier | |||
MAY choose to treat a message with one or more invalid signatures and | MAY choose to treat a message with one or more invalid signatures and | |||
no valid signatures with more suspicion than a message with no | no valid signatures with more suspicion than a message with no | |||
signature at all. | signature at all. | |||
6.2 Get the Public Key | 6.2 Get the Public Key | |||
The public key is needed to complete the verification process. The | The public key is needed to complete the verificatiion process. The | |||
process of retrieving the public key depends on the query type as | process of retrieving the public key depends on the query type as | |||
defined by the "q=" tag in the "DKIM-Signature:" header field line. | defined by the "q=" tag in the "DKIM-Signature:" header field line. | |||
Obviously, a public key should only be retrieved if the process of | Obviously, a public key should only be retrieved if the process of | |||
extracting the signature information is completely successful. | extracting the signature information is completely successful. | |||
Details of key management and representation are described in | Details of key management and representation are described in | |||
Section 3.6. The verifier MUST validate the key record and MUST | Section 3.6. The verifier MUST validate the key record and MUST | |||
ignore any public key records that are malformed. | ignore any public key records that are malformed. | |||
When validating a message, a verifier MUST: | When validating a message, a verifier MUST perform the following | |||
steps in a manner that is semantically the same as performing them in | ||||
the order indicated (in some cases the implementation may parallelize | ||||
or reorder these steps, as long as the semantics remain unchanged): | ||||
1. Retrieve the public key as described in (Section 3.6) using the | 1. Retrieve the public key as described in (Section 3.6) using the | |||
domain from the "d=" tag and the selector from the "s=" tag. | domain from the "d=" tag and the selector from the "s=" tag. | |||
2. If the query for the public key fails to respond, the verifier | 2. If the query for the public key fails to respond, the verifier | |||
SHOULD defer acceptance of this email (normally this will be | SHOULD defer acceptance of this email (normally this will be | |||
achieved with a 451/4.7.5 SMTP reply code). | achieved with a 451/4.7.5 SMTP reply code). | |||
3. If the query for the public key fails because the corresponding | 3. If the query for the public key fails because the corresponding | |||
RR does not exist, the verifier MUST ignore the signature. | RR does not exist, the verifier MUST ignore the signature. | |||
skipping to change at page 35, line 46 | skipping to change at page 37, line 45 | |||
field, the verifier MUST ignore the signature. | field, the verifier MUST ignore the signature. | |||
If the signature is to be ignored, verifiers SHOULD search for | If the signature is to be ignored, verifiers SHOULD search for | |||
another signature in the message. | another signature in the message. | |||
6.3 Compute the Verification | 6.3 Compute the Verification | |||
Given a signer and a public key, verifying a signature consists of | Given a signer and a public key, verifying a signature consists of | |||
the following steps. | the following steps. | |||
o Based on the algorithm defined in the "c=" tag, the body length | 1. Based on the algorithm defined in the "c=" tag, the body length | |||
specified in the "l=" tag, and the header field names in the "h=" | specified in the "l=" tag, and the header field names in the "h=" | |||
tag, create a canonicalized copy of the email as is described in | tag, create a canonicalized copy of the email as is described in | |||
Section 3.7. When matching header field names in the "h=" tag | Section 3.7. When matching header field names in the "h=" tag | |||
against the actual message header field, comparisons MUST be case- | against the actual message header field, comparisons MUST be | |||
insensitive. | case-insensitive. | |||
o Based on the algorithm indicated in the "a=" tag, | 2. Based on the algorithm indicated in the "a=" tag, | |||
* Compute the message hash from the canonical copy as described | * Compute the message hashes from the canonical copy as | |||
in Section 3.7. | described in Section 3.7. | |||
* Decrypt the signature using the signer's public key. | * Decrypt the signature using the signer's public key. | |||
o Compare the decrypted signature to the message hash. If they are | 3. Compare the decrypted signature to the message hash. If they are | |||
identical, the hash computed by the signer must be the same as the | identical, the hash computed by the signer must be the same as | |||
hash computed by the verifier, and hence the signature verifies; | the hash computed by the verifier, and hence the signature | |||
otherwise, the signature fails. | verifies; otherwise, the signature fails. | |||
INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to | INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to | |||
initiate the public-key query in parallel with calculating the | initiate the public-key query in parallel with calculating the | |||
hash as the public key is not needed until the final decryption is | hash as the public key is not needed until the final decryption is | |||
calculated. | calculated. Implementations may also verify the signature on the | |||
message header before validating that the message hash listed in | ||||
the "bh=" tag in the DKIM-Signature header field matches that of | ||||
the actual message body; however, if the body hash does match, the | ||||
entire signature must be considered to have failed. | ||||
Verifiers MUST ignore any DKIM-Signature header fields where the | Verifiers SHOULD ignore any DKIM-Signature header fields where the | |||
signature does not validate. Verifiers that are prepared to validate | signature does not validate. Verifiers that are prepared to validate | |||
multiple signature header fields SHOULD proceed to the next signature | multiple signature header fields SHOULD proceed to the next signature | |||
header field, should it exist. However, verifiers MAY make note of | header field, should it exist. However, verifiers MAY make note of | |||
the fact that an invalid signature was present for consideration at a | the fact that an invalid signature was present for consideration at a | |||
later step. | later step. | |||
INFORMATIVE NOTE: The rationale of this requirement is to permit | INFORMATIVE NOTE: The rationale of this requirement is to permit | |||
messages that have invalid signatures but also a valid signature | messages that have invalid signatures but also a valid signature | |||
to work. For example, a mailing list exploder might opt to leave | to work. For example, a mailing list exploder might opt to leave | |||
the original submitter signature in place even though the exploder | the original submitter signature in place even though the exploder | |||
knows that it is modifying the message in some way that will break | knows that it is modifying the message in some way that will break | |||
that signature, and the exploder inserts its own signature. In | that signature, and the exploder inserts its own signature. In | |||
this case the message should succeed even in the presence of the | this case the message should succeed eveen in the presence of the | |||
known-broken signature. | known-broken signature. | |||
If a body length is specified in the "l=" tag of the signature, | If a body length is specified in the "l=" tag of the signature, | |||
verifiers MUST only verify the number of bytes indicated in the body | verifiers MUST only verify the number of bytes indicated in the body | |||
length. Verifiers MAY decide to treat a message containing bytes | length. Verifiers MAY decide to treat a message containing bytes | |||
beyond the indicated body length with suspicion. Verifiers MAY | beyond the indicated body length with suspicion. Verifiers MAY | |||
truncate the message at the indicated body length or reject the | truncate the message at the indicated body length or reject the | |||
signature outright. | signature outright. | |||
6.4 Insert the Authentication-Results Header Field | INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body | |||
at the indicated body length might pass on a malformed MIME | ||||
message if the signer used the "N-4" trick described in the | ||||
informative note inSection 5.5. Such verifiers may wish to check | ||||
for this case and include a trailing "--CRLF" to avoid breaking | ||||
the MIME structure. A simple way to achieve this might be to | ||||
append "--CRLF" to any "multipart" message with a body length; if | ||||
the MIME structure is already correctly formed, this will appear | ||||
in the postlude and will not be displayed to the end user. | ||||
Verifiers wishing to communicate the results of verification via an | 6.4 Communicate Verification Results | |||
email header field SHOULD use the Authentication-Results header field | ||||
[ID-AUTH-RES]. The Authentication-Results header field SHOULD be | Verifiers wishing to communicate the results of verification to other | |||
inserted before any existing DKIM-Signature or Authentication-Results | parts of the mail system may do so in whatever manner they see fit. | |||
header fields in the header field block. | For example, implementations might choose to add an email header | |||
field to the message before passing it on. An example proposal for a | ||||
header field is the Authentication-Results header field [ID-AUTH- | ||||
RES]. Any such header field SHOULD be inserted before any existing | ||||
DKIM-Signature or Authentication-Results header fields in the header | ||||
field block. | ||||
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | |||
search for Authentication-Results header fields to visibly mark | search for results header fields to visibly mark authenticated | |||
authenticated mail for end users should verify that the | mail for end users should verify that such header field was added | |||
Authentication-Results header field was added by the appropriate | by the appropriate verifying domain and that the verified identity | |||
verifying domain and that the verified identity matches the sender | matches the sender identity that will be displayed by the MUA. In | |||
identity that will be displayed by the MUA. In particular, MUA | particular, MUA patterns should not be influenced by bogus results | |||
patterns should not be influenced by bogus Authentication-Results | ||||
header fields added by attackers. | header fields added by attackers. | |||
6.5 Interpret Results/Apply Local Policy | 6.5 Interpret Results/Apply Local Policy | |||
It is beyond the scope of this specification to describe what actions | It is beyond the scope of this specification to describe what actions | |||
a verifier system should make, but an authenticated email presents an | a verifier system should make, but an authenticated email presents an | |||
opportunity to a receiving system that unauthenticated email cannot. | opportunity to a receiving system that unauthenticated email cannot. | |||
Specifically, an authenticated email creates a predictable identifier | Specifically, an authenticated email creates a predictable identifier | |||
by which other decisions can reliably be managed, such as trust and | by which other decisions can reliably be managed, such as trust and | |||
reputation. Conversely, unauthenticated email lacks a reliable | reputation. Conversely, unauthenticated email lacks a reliable | |||
skipping to change at page 37, line 34 | skipping to change at page 40, line 4 | |||
having no positive reputation. | having no positive reputation. | |||
If the verifying MTA is capable of verifying the public key of the | If the verifying MTA is capable of verifying the public key of the | |||
signer and check the signature on the message synchronously with the | signer and check the signature on the message synchronously with the | |||
SMTP session and such signature is missing or does not verify the MTA | SMTP session and such signature is missing or does not verify the MTA | |||
MAY reject the message with an error such as: | MAY reject the message with an error such as: | |||
550 5.7.1 Unsigned messages not accepted | 550 5.7.1 Unsigned messages not accepted | |||
550 5.7.5 Message signature incorrect | 550 5.7.5 Message signature incorrect | |||
If it is not possible to fetch the public key, perhaps because the | If it is not possible to fetch the public key, perhaps because the | |||
key server is not available, a temporary failure message MAY be | key server is not available, a temporary failure message MAY be | |||
generated, such as: | generated, such as: | |||
451 4.7.5 Unable to verify signature - key server unavailable | 451 4.7.5 Unable to verify signature - key server unavailable | |||
Once the signature has been verified, that information MUST be | Once the signature has been verified, that information MUST be | |||
conveyed to higher level systems (such as explicit allow/white lists | conveyed to higher level systems (such as explicit allow/white lists | |||
and reputation systems) and/or to the end user. If the | and reputation systems) and/or to the end user. If the message is | |||
authentication status is to be stored in the message header field, | signed on behalf of any address other than that in the From: header | |||
the Authentication-Results header field [ID-AUTH-RES] SHOULD be used | field, the mail system SHOULD take pains to ensure that the actual | |||
to convey this information. If the message is signed on behalf of | signing identity is clear to the reader. | |||
any address other than that in the From: header field, the mail | ||||
system SHOULD take pains to ensure that the actual signing identity | INFORMATIVE NOTE: If the authentication status is to be stored in | |||
is clear to the reader. | the message header field, the Authentication-Results header field | |||
[ID-AUTH-RES] may be used to convey this information. | ||||
The verifier MAY treat unsigned header fields with extreme | The verifier MAY treat unsigned header fields with extreme | |||
skepticism, including marking them as untrusted or even deleting them | skepticism, including marking them as untrusted or even deleting them | |||
before display to the end user. | before display to the end user. | |||
While the symptoms of a failed verification are obvious -- the | While the symptoms of a failed verification are obvious -- the | |||
signature doesn't verify -- establishing the exact cause can be more | signature doesn't verify -- establishing the exact cause can be more | |||
difficult. If a selector cannot be found, is that because the | difficult. If a selector cannot be found, is that because the | |||
selector has been removed or was the value changed somehow in | selector has been removed or was the value changed somehow in | |||
transit? If the signature line is missing is that because it was | transit? If the signature line is missing is that because it was | |||
skipping to change at page 39, line 9 | skipping to change at page 41, line 25 | |||
might be otherwise used to mislead the verifier, for example if a | might be otherwise used to mislead the verifier, for example if a | |||
message supposedly from administration@your-bank.com had a Sender | message supposedly from administration@your-bank.com had a Sender | |||
address of fraud@badguy.com. | address of fraud@badguy.com. | |||
Under no circumstances should an unsigned header field be displayed | Under no circumstances should an unsigned header field be displayed | |||
in any context that might be construed by the end user as having been | in any context that might be construed by the end user as having been | |||
signed. Notably, unsigned header fields SHOULD be hidden from the | signed. Notably, unsigned header fields SHOULD be hidden from the | |||
end user to the extent possible. | end user to the extent possible. | |||
The MUA MAY hide or mark portions of the message body that are not | The MUA MAY hide or mark portions of the message body that are not | |||
signed when using the "l=" tag. | signed wh€en using the "l=" tag. | |||
7. IANA Considerations | 7. IANA Considerations | |||
Use of the _domainkey prefix in DNS records will require registration | Use of the _domainkey prefix in DNS records will require registration | |||
by IANA. | by IANA. | |||
To avoid conflicts, tag names for the DKIM-Signature header and key | To avoid conflicts, tag names for the DKIM-Signature header and key | |||
records should be registered with IANA. | records should be registered with IANA. | |||
Tag values for the "a=", "c=", and "q=" tags in the DKIM-Signature | Tag values for the "a=", "c=", and "q=" tags in the DKIM-Signature | |||
skipping to change at page 40, line 18 | skipping to change at page 42, line 39 | |||
properly closed message will in many MUAs result in inappropriate | properly closed message will in many MUAs result in inappropriate | |||
data being rendered on top of existing, correct data: | data being rendered on top of existing, correct data: | |||
<div style="position: relative; bottom: 350px; z-index: 2;"> | <div style="position: relative; bottom: 350px; z-index: 2;"> | |||
<img src="http://www.ietf.org/images/ietflogo2e.gif" | <img src="http://www.ietf.org/images/ietflogo2e.gif" | |||
width=578 height=370> | width=578 height=370> | |||
</div> | </div> | |||
8.2 Misappropriated Private Key | 8.2 Misappropriated Private Key | |||
If the private key for a user is resident on their computer and is | If the private key for a user is resident on their computer and is | |||
not protected by an appropriately secure passphrase, it is possible | not protected by an appropriately secure mechanism, it is possible | |||
for malware to send mail as that user and any other user sharing the | for malware to send mail as that user and any other user sharing the | |||
same private key. The malware would, however, not be able to | same private key. The malware would, however, not be able to | |||
generate signed spoofs of other signers' addresses, which would aid | generate signed spoofs of other signers' addresses, which would aid | |||
in identification of the infected user and would limit the | in identification of the infected user and would limit the | |||
possibilities for certain types of attacks involving socially- | possibilities for certain types of attacks involving socially- | |||
engineered messages. | engineered messages. | |||
A larger problem occurs if malware on many users' computers obtains | A larger problem occurs if malware on many users' computers obtains | |||
the private keys for those users and transmits them via a covert | the private keys for those users and transmits them via a covert | |||
channel to a site where they can be shared. The compromised users | channel to a site where they can be shared. The compromised users | |||
skipping to change at page 41, line 50 | skipping to change at page 44, line 22 | |||
respond, however the cost/benefit of conducting prolonged DNS attacks | respond, however the cost/benefit of conducting prolonged DNS attacks | |||
of this nature is expected to be uneconomical. | of this nature is expected to be uneconomical. | |||
Finally, DKIM is only intended as a "sufficient" method of proving | Finally, DKIM is only intended as a "sufficient" method of proving | |||
authenticity. It is not intended to provide strong cryptographic | authenticity. It is not intended to provide strong cryptographic | |||
proof about authorship or contents. Other technologies such as | proof about authorship or contents. Other technologies such as | |||
OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. | OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. | |||
A second security issue related to the DNS revolves around the | A second security issue related to the DNS revolves around the | |||
increased DNS traffic as a consequence of fetching Selector-based | increased DNS traffic as a consequence of fetching Selector-based | |||
data as well as fetching signing domain policy. Widespread | data as well as fetching siggning domain policy. Widespread | |||
deployment of DKIM will result in a significant increase in DNS | deployment of DKIM will result in a significant increase in DNS | |||
queries to the claimed signing domain. In the case of forgeries on a | queries to the claimed signing domain. In the case of forgeries on a | |||
large scale, DNS servers could see a substantial increase in queries. | large scale, DNS servers could see a substantial increase in queries. | |||
8.5 Replay Attacks | 8.5 Replay Attacks | |||
In this attack, a spammer sends a message to be spammed to an | In this attack, a spammer sends a message to be spammed to an | |||
accomplice, which results in the message being signed by the | accomplice, which results in the message being signed by the | |||
originating MTA. The accomplice resends the message, including the | originating MTA. The accomplice resends the message, including the | |||
original signature, to a large number of recipients, possibly by | original signature, to a large number of recipients, possibly by | |||
skipping to change at page 42, line 51 | skipping to change at page 45, line 22 | |||
8.7 Intentionally malformed Key Records | 8.7 Intentionally malformed Key Records | |||
It is possible for an attacker to publish key records in DNS which | It is possible for an attacker to publish key records in DNS which | |||
are intentionally malformed, with the intent of causing a denial-of- | are intentionally malformed, with the intent of causing a denial-of- | |||
service attack on a non-robust verifier implementation. The attacker | service attack on a non-robust verifier implementation. The attacker | |||
could then cause a verifier to read the malformed key record by | could then cause a verifier to read the malformed key record by | |||
sending a message to one of its users referencing the malformed | sending a message to one of its users referencing the malformed | |||
record in a (not necessarily valid) signature. Verifiers MUST | record in a (not necessarily valid) signature. Verifiers MUST | |||
thoroughly verify all key records retrieved from DNS and be robust | thoroughly verify all key records retrieved from DNS and be robust | |||
against intentionally as well as unintentionally malformed key | against intentionally as well as unintentiionally malformed key | |||
records. | records. | |||
8.8 Intentionally Malformed DKIM-Signature header fields | 8.8 Intentionally Malformed DKIM-Signature header fields | |||
Verifiers MUST be prepared to receive messages with malformed DKIM- | Verifiers MUST be prepared to receive messages with malformed DKIM- | |||
Signature header fields, and thoroughly verify the header field | Signature header fields, and thoroughly verify the header field | |||
before depending on any of its contents. | before depending on any of its contents. | |||
8.9 Information Leakage | ||||
An attacker could determine when a particular signature was verified | ||||
by using a per-message selector and then monitoring their DNS traffic | ||||
for the key lookup. This would act as the equivalent of a "web bug" | ||||
for verification time rather than when the message was read. | ||||
9. References | 9. References | |||
9.1 Normative References | 9.1 Normative References | |||
[ID-AUTH-RES] | ||||
Kucherawy, M., "Message header field for Indicating Sender | ||||
Authentication Status", | ||||
draft-kucherawy-sender-auth-header-02 (work in progress), | ||||
May 2005. | ||||
[ID-DKIM-RR] | [ID-DKIM-RR] | |||
"DKIM Key Resource Records (To be written)", | "DKIM Key Resource Records (To be written)", | |||
draft-dkim-dkk-rr-xx (work in progress), 2005. | draft-dkim-dkk-rr-xx (work in progress), 2005. | |||
[ID-SHA] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms | [ID-SHA] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms | |||
(SHA and HMAC-SHA)", draft-eastlake-sha2-02 (work in | (SHA and HMAC-SHA)", draft-eastlake-sha2-02 (work in | |||
progress), January 2006. | progress), January 2006. | |||
[OPENSSL] Team, C&D., "OpenSSL Documents", | [OPENSSL] Team, C&D., "OpenSSL Documents", | |||
http://www.openssl.org/docs/, | http://www.openssl.org/docs/, | |||
skipping to change at page 44, line 21 | skipping to change at page 46, line 40 | |||
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep | [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep | |||
Profile for Internationalized Domain Names (IDN)", | Profile for Internationalized Domain Names (IDN)", | |||
RFC 3491, March 2003. | RFC 3491, March 2003. | |||
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", RFC 4234, October 2005. | Specifications: ABNF", RFC 4234, October 2005. | |||
9.2 Informative References | 9.2 Informative References | |||
[ID-AUTH-RES] | ||||
Kucherawy, M., "Message header field for Indicating Sender | ||||
Authentication Status", | ||||
draft-kucherawy-sender-auth-header-02 (work in progress), | ||||
May 2005. | ||||
[ID-DKIM-THREATS] | [ID-DKIM-THREATS] | |||
Fenton, J., "Analysis of Threats Motivating DomainKeys | Fenton, J., "Analysis of Threats Motivating DomainKeys | |||
Identified Mail (DKIM)", draft-fenton-dkim-threats-02 | Identified Mail (DKIM)", draft-fenton-dkim-threats-02 | |||
(work in progress), December 2005. | (work in progress), December 2005. | |||
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | |||
"Security Multiparts for MIME: Multipart/Signed and | "Security Multiparts for MIME: Multipart/Signed and | |||
Multipart/Encrypted", RFC 1847, October 1995. | Multipart/Encrypted", RFC 1847, October 1995. | |||
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | |||
"OpenPGP Message Format", RFC 2440, November 1998. | "OpenPGP Message Format", RFC 2440, November 1998. | |||
[RFC3766] "", 2005. | ||||
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | |||
Name System (DNS)", RFC 3833, August 2004. | Name System (DNS)", RFC 3833, August 2004. | |||
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", | [RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", | |||
RFC 3851, June 1999. | RFC 3851, June 1999. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
RFC 4033, March 2005. | RFC 4033, March 2005. | |||
skipping to change at page 46, line 33 | skipping to change at page 49, line 7 | |||
Email: mat@cisco.com | Email: mat@cisco.com | |||
Appendix A. Example of Use (INFORMATIVE) | Appendix A. Example of Use (INFORMATIVE) | |||
This section shows the complete flow of an email from submission to | This section shows the complete flow of an email from submission to | |||
final delivery, demonstrating how the various components fit | final delivery, demonstrating how the various components fit | |||
together. | together. | |||
A.1 The user composes an email | A.1 The user composes an email | |||
From: Joe SixPack <joe@football.example.com> | From: Joe SixPack <joe@foootball.example.com> | |||
To: Suzie Q <suzie@shopping.example.net> | To: Suzie Q <suzie@shopping.example.net> | |||
Subject: Is dinner ready? | Subject: Is dinner ready? | |||
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | |||
Message-ID: <20030712040037.46341.5F8J@football.example.com> | Message-ID: <20030712040037.46341.5F8J@football.example.com> | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
skipping to change at page 47, line 27 | skipping to change at page 50, line 4 | |||
Message-ID: <20030712040037.46341.5F8J@football.example.com> | Message-ID: <20030712040037.46341.5F8J@football.example.com> | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
The signing email server requires access to the private-key | The signing email server requires access to the private-key | |||
associated with the "brisbane" selector to generate this signature. | associated with the "brisbane" selector to generate this signature. | |||
Distribution and management of private-keys is outside the scope of | ||||
this document. | ||||
A.3 The email signature is verified | A.3 The email signature is verified | |||
The signature is normally verified by an inbound SMTP server or | The signature is normally verified by an inbound SMTP server or | |||
possibly the final delivery agent. However, intervening MTAs can | possibly the final delivery agent. However, intervening MTAs can | |||
also perform this verification if they choose to do so. The | also perform this verification if they choose to do so. The | |||
verification process uses the domain "example.com" extracted from the | verification process uses the domain "example.com" extracted from the | |||
"d=" tag and the selector "brisbane" from the "s=" tag in the "DKIM- | "d=" tag and the selector "brisbane" from the "s=" tag in the "DKIM- | |||
Signature" header field to form the DNS DKIM query for: | Signature" header field to form the DNS DKIM query for: | |||
skipping to change at page 50, line 23 | skipping to change at page 52, line 44 | |||
B.5 Affinity Addresses | B.5 Affinity Addresses | |||
"Affinity addresses" are email addresses that users employ to have an | "Affinity addresses" are email addresses that users employ to have an | |||
email address that is independent of any changes in email service | email address that is independent of any changes in email service | |||
provider they may choose to make. They are typically associated with | provider they may choose to make. They are typically associated with | |||
college alumni associations, professional organizations, and | college alumni associations, professional organizations, and | |||
recreational organizations with which they expect to have a long-term | recreational organizations with which they expect to have a long-term | |||
relationship. These domains usually provide forwarding of incoming | relationship. These domains usually provide forwarding of incoming | |||
email, but (currently) usually depend on the user to send outgoing | email, but (currently) usually depend on the user to send outgoing | |||
messages through their own service provider's MTA. They usually have | messages through their own service provider's MTA. They usually have | |||
an associated Web application which authenticates the user and allows | an aassociated Web application which authenticates the user and allows | |||
the forwarding address to be changed. | the forwarding address to be changed. | |||
With DKIM, affinity domains could use the Web application to allow | With DKIM, affinity domains could use the Web application to allow | |||
users to register their own public keys to be used to sign messages | users to register their own public keys to be used to sign messages | |||
on behalf of their affinity address. This is another application | on behalf of their affinity address. This is another application | |||
that takes advantage of user-level keying, and domains used for | that takes advantage of user-level keying, and domains used for | |||
affinity addresses would typically have a very large number of user- | affinity addresses would typically have a very large number of user- | |||
level keys. Alternatively, the affinity domain could handle outgoing | level keys. Alternatively, the affinity domain could handle outgoing | |||
mail, operating a mail submission agent that authenticates users | mail, operating a mail submission agent that authenticates users | |||
before accepting and signing messages for them. This is of course | before accepting and signing messages for them. This is of course | |||
skipping to change at page 51, line 8 | skipping to change at page 53, line 28 | |||
One way this can be handled is to continue to put the reader's email | One way this can be handled is to continue to put the reader's email | |||
address in the From field of the message, but put an address owned by | address in the From field of the message, but put an address owned by | |||
the site into the Sender field, and sign the message on behalf of the | the site into the Sender field, and sign the message on behalf of the | |||
Sender. A verifying MTA should accept this and rewrite the From | Sender. A verifying MTA should accept this and rewrite the From | |||
field to indicate the address that was verified, i.e., From: John | field to indicate the address that was verified, i.e., From: John | |||
Doe via news@news-site.com <jdoe@example.com>. | Doe via news@news-site.com <jdoe@example.com>. | |||
Appendix C. Creating a public key (INFORMATIVE) | Appendix C. Creating a public key (INFORMATIVE) | |||
XXX Update to 1024 bit key and SHA-256 and adjust examples | ||||
accordingly. XXX | ||||
The default signature is an RSA signed SHA1 digest of the complete | The default signature is an RSA signed SHA1 digest of the complete | |||
email. For ease of explanation, the openssl command is used to | email. For ease of explanation, the openssl command is used to | |||
describe the mechanism by which keys and signatures are managed. One | describe the mechanism by which keys and signatures are managed. One | |||
way to generate a 768 bit private-key suitable for DKIM, is to use | way to generate a 768 bit private-key suitable for DKIM, is to use | |||
openssl like this: | openssl like this: | |||
$ openssl genrsa -out rsa.private 768 | $ openssl genrsa -out rsa.private 768 | |||
This results in the file rsa.private containing the key information | This results in the file rsa.private containing the key information | |||
similar to this: | similar to this: | |||
-----BEGIN RSA PRIVATE KEY----- | -----BEGIN RSA PRIVATE KEY----- | |||
MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 | MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 | |||
ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo | ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo | |||
AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH | AUsFUq+J6+OpprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH | |||
+Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn | +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn | |||
Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ | Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ | |||
3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew | 3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew | |||
ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs | ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs | |||
FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb | FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb | |||
weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG | weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG | |||
6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= | 6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= | |||
-----END RSA PRIVATE KEY----- | -----END RSA PRIVATE KEY----- | |||
To extract the public-key component from the private-key, use openssl | To extract the public-key component from the private-key, use openssl | |||
skipping to change at page 52, line 30 | skipping to change at page 55, line 17 | |||
How this signature is added to the email is discussed elsewhere in | How this signature is added to the email is discussed elsewhere in | |||
this document. | this document. | |||
Appendix D. Acknowledgements | Appendix D. Acknowledgements | |||
The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, | The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, | |||
Steve Atkins, Fred Baker, Mark Baugher, Nathaniel Borenstein, Dave | Steve Atkins, Fred Baker, Mark Baugher, Nathaniel Borenstein, Dave | |||
Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Patrik | Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Patrik | |||
Faltstrom, Duncan Findlay, Elliot Gillum, Phillip Hallam-Baker, Tony | Faltstrom, Duncan Findlay, Elliot Gillum, Phillip Hallam-Baker, Tony | |||
Hansen, Arvel Hathcock, Amir Herzberg, Don Johnsen, Harry Katz, | Hansen, Arvel Hathcock, Amir Herzberg, Craig Hughes, Don Johnsen, | |||
Murray S. Kucherawy, Barry Leiba, John Levine, Simon Longsdale, David | Harry Katz, Murray S. Kucherawy, Barry Leiba, John Levine, Simon | |||
Margrave, Justin Mason, David Mayne, Steve Murphy, Russell Nelson, | Longsdale, David Margrave, Justin Mason, David Mayne, Steve Murphy, | |||
Dave Oran, Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake | Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer | |||
Ramsdell, Christian Renaud, Scott Renfro, Dave Rossetti, the | Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, | |||
Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, and | Dave Rossetti, Hector Santos, the Spamhaus..org team, Malte S. Stretz, | |||
Dan Wing for their valuable suggestions and constructive criticism. | Robert Sanders, Rand Wacker, and Dan Wing for their valuable | |||
suggestions and constructive criticism. | ||||
The DomainKeys specification was a primary source from which this | The DomainKeys specification was a primary source from which this | |||
specification has been derived. Further information about DomainKeys | specification has been derived. Further information about DomainKeys | |||
is at | is at | |||
<http://domainkeys.sourceforge.net/license/patentlicense1-1.html>. | <http://domainkeys.sourceforge.net/license/patentlicense1-1.html>. | |||
Appendix E. Edit History | Appendix E. Edit History | |||
E.1 Changes since -allman-01 version | [[This section to be removed before publication.]] | |||
E.1 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. | ||||
o Added rsa-sha256 signing algorithm. | ||||
o Expanded several examples. | ||||
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. | ||||
E.2 Changes since -allman-01 version | ||||
The following changes were made between draft-allman-dkim-base-01 and | The following changes were made between draft-allman-dkim-base-01 and | |||
draft-ietf-dkim-base-00: | draft-ietf-dkim-base-00: | |||
o Remove references to Sender Signing Policy document. Such | o Remove references to Sender Signing Policy document. Such | |||
consideration is implicitly included in Section 6.5. | consideration is implicitly included in Section 6.5. | |||
o Added ABNF for all tags. | o Added ABNF for all tags. | |||
o Updated references (still includes some references to expired | o Updated references (still includes some references to expired | |||
drafts, notably [ID-AUTH-RES]. | drafts, notably [ID-AUTH-RES]. | |||
o Significant wordsmithing. | o Significant wordsmithing. | |||
E.2 Changes since -allman-00 version | E.3 Changes since -allman-00 version | |||
The following changes were made between draft-allman-dkim-base-00 and | The following changes were made between draft-allman-dkim-base-00 and | |||
draft-allman-dkim-base-01: | draft-allman-dkim-base-01: | |||
o Changed "c=" tag to separate out header from body | o Changed "c=" tag to separate out header from body | |||
canonicalization. | canonicalization. | |||
o Eliminated "nowsp" canonicalization in favor of "relaxed", which | o Eliminated "nowsp" canonicalization in favor of "relaxed", which | |||
is somewhat less relaxed (but more secure) than "nowsp". | is somewhat less relaxed (but more secure) than "nowsp". | |||
skipping to change at page 54, line 11 | skipping to change at page 57, line 11 | |||
o Added several IANA Considerations. | o Added several IANA Considerations. | |||
o Fixed a number of grammar and formatting errors. | o Fixed a number of grammar and formatting errors. | |||
Intellectual Property Statement | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might oor might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
End of changes. 126 change blocks. | ||||
333 lines changed or deleted | 477 lines changed or added | |||
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |