draft-ietf-dmarc-arc-multi-01.txt   draft-ietf-dmarc-arc-multi-02.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Experimental S. Blank, Ed. Intended status: Experimental S. Blank, Ed.
Expires: September 20, 2018 ValiMail Expires: March 14, 2019 ValiMail
J. Levine, Ed. J. Levine, Ed.
Taughannock Networks Taughannock Networks
March 19, 2018 September 10, 2018
Using Multiple Signing Algorithms with the ARC (Authenticated Received Using Multiple Signing Algorithms with the ARC (Authenticated Received
Chain) Protocol Chain) Protocol
draft-ietf-dmarc-arc-multi-01 draft-ietf-dmarc-arc-multi-02
Abstract Abstract
The Authenticated Received Chain (ARC) protocol creates a mechanism The Authenticated Received Chain (ARC) protocol creates a mechanism
whereby a series of handlers of an email message can conduct whereby a series of handlers of an email message can conduct
authentication of the email message as it passes among them on the authentication of the email message as it passes among them on the
way to its destination. way to its destination.
Initial development of ARC has been done with a single allowed Initial development of ARC has been done with a single allowed
signing algorithm, but parallel work in the DCRUP working group signing algorithm, but RFC 8463 has expanded the supported
(https://datatracker.ietf.org/wg/dcrup/about/) is expanding the algorithms. This specification defines how to extend ARC for
supported algorithms. This specification defines how to extend ARC multiple signing algorithms.
for multiple signing algorithms.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 20, 2018. This Internet-Draft will expire on March 14, 2019.
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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 46 skipping to change at page 2, line 46
Appendix B. Comments and Feedback . . . . . . . . . . . . . . . 6 Appendix B. Comments and Feedback . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The Authenticated Received Chain (ARC) protocol adds a traceable The Authenticated Received Chain (ARC) protocol adds a traceable
chain of signatures that cover the handling of an email message chain of signatures that cover the handling of an email message
through a chain of intermediary handlers. through a chain of intermediary handlers.
Initial development of ARC has been done with a single allowed Initial development of ARC has been done with a single allowed
signing algorithm, but parallel work in the DCRUP working group signing algorithm, but RFC 8463 expanded the supported algorithms.
(https://datatracker.ietf.org/wg/dcrup/about/) is expanding the This specification defines how to extend ARC for multiple signing
supported algorithms. This specification defines how to extend ARC algorithms.
for multiple signing algorithms.
2. Overview 2. Overview
In order to phase in new signing algorithms, this specification In order to phase in new signing algorithms, this specification
identifies how signers and validators process ARC sets found in email identifies how signers and validators process ARC sets found in email
messages. messages.
3. Definitions and Terminology 3. Definitions and Terminology
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
[RFC2119]. [RFC2119].
Because many of the core concepts and definitions are found in Because many of the core concepts and definitions are found in
[RFC5598], readers should to be familiar with the contents of [RFC5598], readers should to be familiar with the contents of
[RFC5598], and in particular, the potential roles of intermediaries [RFC5598], and in particular, the potential roles of intermediaries
in the delivery of email and the problems [RFC7960] created by the in the delivery of email and the problems [RFC7960] created by the
initial DMARC [RFC7489] . initial DMARC [RFC7489] .
4. Supporting Alternate Signing Algorithms 4. Supporting Alternate Signing Algorithms
During a period where multiple algorithms are allowed, all of the To enable multiple algorithms, all of the statements in the ARC spec
statements in the ARC spec which refer to "exactly one set of ARC which refer to "exactly one set of ARC headers per instance" need to
headers per instance" need to be understood as "at least one set per be understood as "at least one set per instance and no more than one
instance and no more than one set per instance per algorithm". set per instance per algorithm".
5. General Approach 5. General Approach
5.1. Signers 5.1. Signers
There is a separate independent signing chain for each signing There is a separate independent signing chain for each signing
algorithm. Hence, when creating an ARC signature, a signer MUST algorithm. Hence, when creating an ARC signature, a signer MUST
include only other signatures that use the same algorithm as the include only other signatures that use the same algorithm as the
signature being created. signature being created.
skipping to change at page 4, line 48 skipping to change at page 4, line 48
6.4. Obsolescence Period 6.4. Obsolescence Period
ARC sets built with algorithms that are obsolete MUST NOT be ARC sets built with algorithms that are obsolete MUST NOT be
considered valid within an ARC chain. Intermediaries MUST NOT create considered valid within an ARC chain. Intermediaries MUST NOT create
any sets with any obsoleted algorithm. any sets with any obsoleted algorithm.
7. Privacy Considerations 7. Privacy Considerations
No unique privacy considerations are introduced by this specification 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 8. IANA Considerations
No new IANA considerations are introduced by this specification. No new IANA considerations are introduced by this specification.
9. Security Considerations 9. Security Considerations
No new security considerations are introduced by this specification 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. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>. <https://www.rfc-editor.org/info/rfc5598>.
10.2. Informative References 10.2. Informative References
[ARC-DRAFT-11] [ARC-DRAFT]
Andersen, K., Long, B., and S. Jones, "Authenticated 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.,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-11>. draft-ietf-dmarc-arc-protocol-16>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting, between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows", and Conformance (DMARC) and Indirect Email Flows",
 End of changes. 12 change blocks. 
21 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/