--- 1/draft-ietf-dmarc-arc-multi-01.txt 2018-09-10 10:13:14.382259342 -0700 +++ 2/draft-ietf-dmarc-arc-multi-02.txt 2018-09-10 10:13:14.398259730 -0700 @@ -1,52 +1,51 @@ DMARC Working Group K. Andersen Internet-Draft LinkedIn Intended status: Experimental S. Blank, Ed. -Expires: September 20, 2018 ValiMail +Expires: March 14, 2019 ValiMail J. Levine, Ed. Taughannock Networks - March 19, 2018 + September 10, 2018 Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol - draft-ietf-dmarc-arc-multi-01 + draft-ietf-dmarc-arc-multi-02 Abstract The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of an email message can conduct authentication of the email message as it passes among them on the way to its destination. Initial development of ARC has been done with a single allowed - signing algorithm, but parallel work in the DCRUP working group - (https://datatracker.ietf.org/wg/dcrup/about/) is expanding the - supported algorithms. This specification defines how to extend ARC - for multiple signing algorithms. + signing algorithm, but RFC 8463 has expanded the supported + algorithms. This specification defines how to extend ARC for + multiple signing algorithms. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 20, 2018. + This Internet-Draft will expire on March 14, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -80,24 +79,23 @@ Appendix B. Comments and Feedback . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The Authenticated Received Chain (ARC) protocol adds a traceable chain of signatures that cover the handling of an email message through a chain of intermediary handlers. Initial development of ARC has been done with a single allowed - signing algorithm, but parallel work in the DCRUP working group - (https://datatracker.ietf.org/wg/dcrup/about/) is expanding the - supported algorithms. This specification defines how to extend ARC - for multiple signing algorithms. + signing algorithm, but RFC 8463 expanded the supported algorithms. + This specification defines how to extend ARC for multiple signing + algorithms. 2. Overview In order to phase in new signing algorithms, this specification identifies how signers and validators process ARC sets found in email messages. 3. Definitions and Terminology This section defines terms used in the rest of the document. @@ -108,24 +106,24 @@ [RFC2119]. Because many of the core concepts and definitions are found in [RFC5598], readers should to be familiar with the contents of [RFC5598], and in particular, the potential roles of intermediaries in the delivery of email and the problems [RFC7960] created by the initial DMARC [RFC7489] . 4. Supporting Alternate Signing Algorithms - During a period where multiple algorithms are allowed, all of the - statements in the ARC spec which refer to "exactly one set of ARC - headers per instance" need to be understood as "at least one set per - instance and no more than one set per instance per algorithm". + To enable multiple algorithms, all of the statements in the ARC spec + which refer to "exactly one set of ARC headers per instance" need to + be understood as "at least one set per instance and no more than one + set per instance per algorithm". 5. General Approach 5.1. Signers There is a separate independent signing chain for each signing algorithm. Hence, when creating an ARC signature, a signer MUST include only other signatures that use the same algorithm as the signature being created. @@ -175,51 +173,51 @@ 6.4. Obsolescence Period ARC sets built with algorithms that are obsolete MUST NOT be considered valid within an ARC chain. Intermediaries MUST NOT create any sets with any obsoleted algorithm. 7. Privacy Considerations No unique privacy considerations are introduced by this specification - beyond those of the base [ARC-DRAFT-11] protocol. + beyond those of the base [ARC-DRAFT] protocol. 8. IANA Considerations No new IANA considerations are introduced by this specification. 9. Security Considerations No new security considerations are introduced by this specification - beyond those of the base [ARC-DRAFT-11] protocol. + beyond those of the base [ARC-DRAFT] protocol. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . 10.2. Informative References - [ARC-DRAFT-11] + [ARC-DRAFT] Andersen, K., Long, B., and S. Jones, "Authenticated - Received Chain (ARC) Protocol (I-D-11)", n.d., + Received Chain (ARC) Protocol (I-D-16)", n.d., . + draft-ietf-dmarc-arc-protocol-16>. [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, E., Ed., and K. Andersen, Ed., "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows",