On Wednesday, February 07, 2018 09:11:48 PM Murray S. Kucherawy wrote: > On Wed, Feb 7, 2018 at 7:59 PM, <internet-dra...@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. ... > > Let me know if I missed anything.
On the DCRUP mailing list there has been discussion about adding header.a (algorithm) to authentication results. This is in addition to the discussion about adding header.s (selector) for ARC. The general view there was that since there is nothing experimental about those DKIM signature elements, it would be better not to have them included in an experimental document. 7601bis seems ideal both technically and timing wise. I'm attaching both a unified diff of the XML and an RFCdiff of my proposed text. Please review, comment, etc. I hope this can be included in 7601bis. Scott KTitle: Diff: draft-ietf-dmarc-rfc7601bis-00.txt - draft-ietf-dmarc-rfc7601bis-00dsk.txt
draft-ietf-dmarc-rfc7601bis-00.txt | draft-ietf-dmarc-rfc7601bis-00dsk.txt | |||
---|---|---|---|---|
DMARC Working Group M. Kucherawy | DMARC Working Group M. Kucherawy | |||
Internet-Draft | Internet-Draft | |||
Obsoletes: 7601 (if approved) February 15, 2018 | Obsoletes: 7601 (if approved) February 16, 2018 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: August 19, 2018 | Expires: August 20, 2018 | |||
Message Header Field for Indicating Message Authentication Status | Message Header Field for Indicating Message Authentication Status | |||
draft-ietf-dmarc-rfc7601bis-00 | draft-ietf-dmarc-rfc7601bis-00 | |||
Abstract | Abstract | |||
This document specifies a message header field called Authentication- | This document specifies a message header field called Authentication- | |||
Results for use with electronic mail messages to indicate the results | Results for use with electronic mail messages to indicate the results | |||
of message authentication efforts. Any receiver-side software, such | of message authentication efforts. Any receiver-side software, such | |||
as mail filters or Mail User Agents (MUAs), can use this header field | as mail filters or Mail User Agents (MUAs), can use this header field | |||
skipping to change at page 1, line 36 | skipping to change at page 1, line 36 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
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." | |||
This Internet-Draft will expire on August 19, 2018. | This Internet-Draft will expire on August 20, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 30 | skipping to change at page 2, line 30 | |||
2. Definition and Format of the Header Field . . . . . . . . . . 9 | 2. Definition and Format of the Header Field . . . . . . . . . . 9 | |||
2.1. General Description . . . . . . . . . . . . . . . . . . . 9 | 2.1. General Description . . . . . . . . . . . . . . . . . . . 9 | |||
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 | 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 | |||
2.3. Property Types (ptypes) and Properties . . . . . . . . . 12 | 2.3. Property Types (ptypes) and Properties . . . . . . . . . 12 | |||
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13 | 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13 | |||
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 | 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 | |||
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15 | 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15 | |||
2.7. Defined Methods and Result Values . . . . . . . . . . . . 15 | 2.7. Defined Methods and Result Values . . . . . . . . . . . . 15 | |||
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 15 | 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 15 | |||
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 | 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 | |||
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18 | 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 | 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20 | |||
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 20 | 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 21 | |||
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 20 | 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21 | |||
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 21 | 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 22 | |||
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 | 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 | |||
4. Adding the Header Field to a Message . . . . . . . . . . . . 23 | 4. Adding the Header Field to a Message . . . . . . . . . . . . 23 | |||
4.1. Header Field Position and Interpretation . . . . . . . . 24 | 4.1. Header Field Position and Interpretation . . . . . . . . 25 | |||
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 25 | 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 26 | |||
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 | 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
6.1. The Authentication-Results Header Field . . . . . . . . . 27 | 6.1. The Authentication-Results Header Field . . . . . . . . . 28 | |||
6.2. "Email Authentication Methods" Registry Description . . . 27 | 6.2. "Email Authentication Methods" Registry Description . . . 28 | |||
6.3. "Email Authentication Methods" Registry Update . . . . . 27 | 6.3. "Email Authentication Methods" Registry Update . . . . . 28 | |||
6.4. "Email Authentication Property Types" Registry . . . . . 27 | 6.4. "Email Authentication Property Types" Registry . . . . . 28 | |||
6.5. "Email Authentication Result Names" Description . . . . . 28 | 6.5. "Email Authentication Result Names" Description . . . . . 29 | |||
6.6. "Email Authentication Result Names" Update . . . . . . . 28 | 6.6. "Email Authentication Result Names" Update . . . . . . . 29 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | |||
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 28 | 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 29 | |||
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 30 | 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 31 | |||
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 30 | 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31 | |||
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 30 | 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 31 | |||
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 30 | 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 31 | |||
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 31 | 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 32 | |||
7.7. Attacks against Authentication Methods . . . . . . . . . 31 | 7.7. Attacks against Authentication Methods . . . . . . . . . 32 | |||
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 31 | 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32 | |||
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 31 | 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 32 | |||
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 31 | 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 32 | |||
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 32 | 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 32 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 33 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 33 | 8.2. Informative References . . . . . . . . . . . . . . . . . 34 | |||
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 36 | Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 37 | |||
Appendix B. Authentication-Results Examples . . . . . . . . . . 36 | Appendix B. Authentication-Results Examples . . . . . . . . . . 37 | |||
B.1. Trivial Case; Header Field Not Present . . . . . . . . . 36 | B.1. Trivial Case; Header Field Not Present . . . . . . . . . 37 | |||
B.2. Nearly Trivial Case; Service Provided, but No | B.2. Nearly Trivial Case; Service Provided, but No | |||
Authentication Done . . . . . . . . . . . . . . . . . . . 37 | Authentication Done . . . . . . . . . . . . . . . . . . . 38 | |||
B.3. Service Provided, Authentication Done . . . . . . . . . . 37 | B.3. Service Provided, Authentication Done . . . . . . . . . . 39 | |||
B.4. Service Provided, Several Authentications Done, Single | B.4. Service Provided, Several Authentications Done, Single | |||
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
B.5. Service Provided, Several Authentications Done, Different | B.5. Service Provided, Several Authentications Done, Different | |||
MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
B.6. Service Provided, Multi-tiered Authentication Done . . . 41 | B.6. Service Provided, Multi-tiered Authentication Done . . . 42 | |||
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 43 | B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 44 | |||
Appendix C. Operational Considerations about Message | Appendix C. Operational Considerations about Message | |||
Authentication . . . . . . . . . . . . . . . . . . . 44 | Authentication . . . . . . . . . . . . . . . . . . . 45 | |||
Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 45 | Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 46 | |||
Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 47 | Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 48 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
1. Introduction | 1. Introduction | |||
This document describes a header field called Authentication-Results | This document describes a header field called Authentication-Results | |||
for electronic mail messages that presents the results of a message | for electronic mail messages that presents the results of a message | |||
authentication effort in a machine-readable format. The intent of | authentication effort in a machine-readable format. The intent of | |||
the header field is to create a place to collect such data when | the header field is to create a place to collect such data when | |||
message authentication mechanisms are in use so that a Mail User | message authentication mechanisms are in use so that a Mail User | |||
Agent (MUA) and downstream filters can make filtering decisions and/ | Agent (MUA) and downstream filters can make filtering decisions and/ | |||
or provide a recommendation to the user as to the validity of the | or provide a recommendation to the user as to the validity of the | |||
skipping to change at page 16, line 49 | skipping to change at page 16, line 49 | |||
permerror: The message could not be verified due to some error that | permerror: The message could not be verified due to some error that | |||
is unrecoverable, such as a required header field being absent. A | is unrecoverable, such as a required header field being absent. A | |||
later attempt is unlikely to produce a final result. | later attempt is unlikely to produce a final result. | |||
DKIM results are reported using a ptype of "header". The property, | DKIM results are reported using a ptype of "header". The property, | |||
however, represents one of the tags found in the DKIM-Signature | however, represents one of the tags found in the DKIM-Signature | |||
header field rather than a distinct header field. For example, the | header field rather than a distinct header field. For example, the | |||
ptype-property combination "header.d" refers to the content of the | ptype-property combination "header.d" refers to the content of the | |||
"d" (signing domain) tag from within the signature header field, and | "d" (signing domain) tag from within the signature header field, and | |||
not a distinct header field called "d". | not a distinct header field called "d". In addition to previous | |||
registrations, this document adds DKIM properties for "a" | ||||
(cryptographic algorithm used to sign the message) and "s" | ||||
(selector). These new properties will be used to aid receiver post- | ||||
verification processing. As an example, [RFC8301] obsoleted use of | ||||
the rsa-sha1 algorithm in DKIM, so it is important to be able to | ||||
distinguish such signatures from rsa-sha256. See Table 1. | ||||
The ability to report different DKIM results for a message with | The ability to report different DKIM results for a message with | |||
multiple signatures is described in [RFC6008]. | multiple signatures is described in [RFC6008]. | |||
[DKIM] advises that if a message fails verification, it is to be | [DKIM] advises that if a message fails verification, it is to be | |||
treated as an unsigned message. A report of "fail" here permits the | treated as an unsigned message. A report of "fail" here permits the | |||
receiver of the report to decide how to handle the failure. A report | receiver of the report to decide how to handle the failure. A report | |||
of "neutral" or "none" preempts that choice, ensuring the message | of "neutral" or "none" preempts that choice, ensuring the message | |||
will be treated as if it had not been signed. | will be treated as if it had not been signed. | |||
skipping to change at page 27, line 40 | skipping to change at page 28, line 21 | |||
Header field name: Authentication-Results | Header field name: Authentication-Results | |||
Applicable protocol: mail ([MAIL]) | Applicable protocol: mail ([MAIL]) | |||
Status: Standard | Status: Standard | |||
Author/Change controller: IETF | Author/Change controller: IETF | |||
Specification document(s): [this document] | Specification document(s): [this document] | |||
Related information: none | Related information: none | |||
6.2. "Email Authentication Methods" Registry Description | 6.2. "Email Authentication Methods" Registry Description | |||
No changes are made to this registry. | IANA is requested to make the following additions to this registry. | |||
+--------+--------+--------+----------+-------------+--------+------+ | ||||
| METHOD | REF | PTYPE | PROPERTY | VALUE | STATUS | VERS | | ||||
+--------+--------+--------+----------+-------------+--------+------+ | ||||
| dkim | [DKIM] | header | a | DKIM | active | 1 | | ||||
| | | | | signing | | | | ||||
| | | | | algorithm | | | | ||||
| dkim | [DKIM] | header | s | DKIM | active | 1 | | ||||
| | | | | selector | | | | ||||
+--------+--------+--------+----------+-------------+--------+------+ | ||||
Table 1: DKIM Property Additions | ||||
6.3. "Email Authentication Methods" Registry Update | 6.3. "Email Authentication Methods" Registry Update | |||
No changes are made to this registry. | No changes are made to this registry. | |||
6.4. "Email Authentication Property Types" Registry | 6.4. "Email Authentication Property Types" Registry | |||
[RFC7410] created the "Email Authentication Property Types" registry. | [RFC7410] created the "Email Authentication Property Types" registry. | |||
No changes are made to this registry. However, it should be noted | No changes are made to this registry. However, it should be noted | |||
skipping to change at page 35, line 27 | skipping to change at page 36, line 27 | |||
[PRA] Lyon, J., "Purported Responsible Address in E-Mail | [PRA] Lyon, J., "Purported Responsible Address in E-Mail | |||
Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, | Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, | |||
<http://www.rfc-editor.org/info/rfc4407>. | <http://www.rfc-editor.org/info/rfc4407>. | |||
[RFC7410] Kucherawy, M., "A Property Types Registry for the | [RFC7410] Kucherawy, M., "A Property Types Registry for the | |||
Authentication-Results Header Field", RFC 7410, DOI 10 | Authentication-Results Header Field", RFC 7410, DOI 10 | |||
.17487/RFC7410, December 2014, | .17487/RFC7410, December 2014, | |||
<http://www.rfc-editor.org/info/rfc7410>. | <http://www.rfc-editor.org/info/rfc7410>. | |||
[RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage | ||||
Update to DomainKeys Identified Mail (DKIM)", RFC 8302, | ||||
DOI 10.17487/RFC8301, January 2018, | ||||
<http://www.rfc-editor.org/info/rfc8301>. | ||||
[RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- | [RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- | |||
Since Header Field and SMTP Service Extension", RFC 7293, | Since Header Field and SMTP Service Extension", RFC 7293, | |||
DOI 10.17487/RFC7293, July 2014, | DOI 10.17487/RFC7293, July 2014, | |||
<http://www.rfc-editor.org/info/rfc7293>. | <http://www.rfc-editor.org/info/rfc7293>. | |||
[SECURITY] | [SECURITY] | |||
Rescorla, E. and B. Korver, "Guidelines for Writing RFC | Rescorla, E. and B. Korver, "Guidelines for Writing RFC | |||
Text on Security Considerations", BCP 72, RFC 3552, DOI 10 | Text on Security Considerations", BCP 72, RFC 3552, DOI 10 | |||
.17487/RFC3552, July 2003, | .17487/RFC3552, July 2003, | |||
<http://www.rfc-editor.org/info/rfc3552>. | <http://www.rfc-editor.org/info/rfc3552>. | |||
skipping to change at page 46, line 44 | skipping to change at page 47, line 44 | |||
o RFC 7208 uses all-lowercase result strings now, so adjusted prose | o RFC 7208 uses all-lowercase result strings now, so adjusted prose | |||
accordingly. | accordingly. | |||
o Updated list of supported methods, and mentioned the registries | o Updated list of supported methods, and mentioned the registries | |||
immediately below. | immediately below. | |||
o Mentioned that when a local-part is removed, the "@" goes with it. | o Mentioned that when a local-part is removed, the "@" goes with it. | |||
o Referred to RFC 7328 in the "iprev" definition. | o Referred to RFC 7328 in the "iprev" definition. | |||
o Added IANA registration for DKIM "a" and "s" properties | ||||
o Corrected the "smime-part" prose. | o Corrected the "smime-part" prose. | |||
o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the | o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the | |||
Received fields. | Received fields. | |||
o Made minor editorial adjustments. | o Made minor editorial adjustments. | |||
Appendix E. Acknowledgments | Appendix E. Acknowledgments | |||
The author wishes to acknowledge the following individuals for their | The author wishes to acknowledge the following individuals for their | |||
End of changes. 14 change blocks. | ||||
46 lines changed or deleted | 71 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |
--- draft-ietf-dmarc-rfc7601bis-00.xml 2018-02-15 21:35:04.515992669 -0500 +++ draft-ietf-dmarc-rfc7601bis-00dsk.xml 2018-02-16 01:47:03.348119368 -0500 @@ -918,17 +918,27 @@ result. </t> </list> </t> - <t> DKIM results are reported using a ptype - of "header". The property, however, - represents one of the tags found in the - DKIM-Signature header field rather than - a distinct header field. For example, - the ptype-property combination "header.d" - refers to the content of the "d" - (signing domain) tag from within the - signature header field, and not a distinct - header field called "d". </t> - + <t> DKIM results are reported using a ptype + of "header". The property, however, + represents one of the tags found in the + DKIM-Signature header field rather than + a distinct header field. For example, + the ptype-property combination "header.d" + refers to the content of the "d" + (signing domain) tag from within the + signature header field, and not a distinct + header field called "d". In addition to + previous registrations, this document adds + DKIM properties for "a" (cryptographic + algorithm used to sign the message) and + "s" (selector). These new properties will + be used to aid receiver post-verification + processing. As an example, + <xref target="RFC8301"/> obsoleted use of + the rsa-sha1 algorithm in DKIM, so it is + important to be able to distinguish such + signatures from rsa-sha256. See <xref + target="dkimproperties"/>.</t> <t> The ability to report different DKIM results for a message with multiple signatures is described in <xref target="RFC6008"/>. </t> @@ -1666,7 +1676,35 @@ <section anchor="name_registry_1" title=""Email Authentication Methods" Registry Description"> - <t> No changes are made to this registry. </t> + <t> IANA is requested to make the following additions to + this registry. </t> + + <texttable anchor="dkimproperties" + title="DKIM Property Additions"> + <ttcol align="center">METHOD</ttcol> + <ttcol align="left">REF</ttcol> + <ttcol align="left">PTYPE</ttcol> + <ttcol align="center">PROPERTY</ttcol> + <ttcol align="left">VALUE</ttcol> + <ttcol align="left">STATUS</ttcol> + <ttcol align="center">VERS</ttcol> + + <c>dkim</c> + <c><xref target="DKIM"/></c> + <c>header</c> + <c>a</c> + <c>DKIM signing algorithm</c> + <c>active</c> + <c>1</c> + + <c>dkim</c> + <c><xref target="DKIM"/></c> + <c>header</c> + <c>s</c> + <c>DKIM selector</c> + <c>active</c> + <c>1</c> + </texttable> </section> <section anchor="name_registry_2" @@ -2346,6 +2384,16 @@ <seriesInfo name='RFC' value='5518'/> <seriesInfo name='DOI' value='10.17487/RFC5518'/> </reference> + <reference anchor="RFC8301" target='http://www.rfc-editor.org/info/rfc8301'> + <front> + <title>Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)</title> + <author initials='S.' surname='Kitterman' fullname='S. Kitterman'><organization /></author> + <date year='2018' month='January' /> + <abstract><t> The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms.</t></abstract> + </front> + <seriesInfo name='RFC' value='8302'/> + <seriesInfo name='DOI' value='10.17487/RFC8301'/> + </reference> </references> @@ -2924,6 +2972,9 @@ <t> Referred to RFC 7328 in the "iprev" definition. </t> + + <t> Added IANA registration for DKIM "a" and "s" + properties</t> <t> Corrected the "smime-part" prose. </t>
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc