draft-ietf-dmarc-eaiauth-04.txt		draft-ietf-dmarc-eaiauth-05.txt
	Network Working Group J. Levine		Network Working Group J. Levine
	Internet-Draft Taughannock Networks		Internet-Draft Taughannock Networks
	Updates: 6376, 7208, 7489 (if approved) March 25, 2019		Updates: 6376, 7208, 7489 (if approved) April 5, 2019
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 26, 2019		Expires: October 7, 2019
	E-mail Authentication for Internationalized Mail		E-mail Authentication for Internationalized Mail
	draft-ietf-dmarc-eaiauth-04		draft-ietf-dmarc-eaiauth-05
	Abstract		Abstract
	SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain		SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain
	owner to publish e-mail authentication and policy information in the		owner to publish e-mail authentication and policy information in the
	DNS. In internationalized e-mail, domain names can occur both as		DNS. In internationalized e-mail, domain names can occur both as
	U-labels and A-labels. This specification updates the SPF, DKIM, and		U-labels and A-labels. This specification updates the SPF, DKIM, and
	DMARC specifications to clarify which form of internationalized		DMARC specifications to clarify which form of internationalized
	domain names to use in those specifications.		domain names to use in those specifications.
	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 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 26, 2019.		This Internet-Draft will expire on October 7, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 39 ¶		skipping to change at page 2, line 39 ¶
	the From: header of e-mail messages.		the From: header of e-mail messages.
	In conventional e-mail, all domain names are ASCII in all contexts so		In conventional e-mail, all domain names are ASCII in all contexts so
	there is no question about the representation of the domain names.		there is no question about the representation of the domain names.
	All internationalized domain names are represented as A-labels		All internationalized domain names are represented as A-labels
	[RFC5890] in message headers, in SMTP sessions, and in the DNS.		[RFC5890] in message headers, in SMTP sessions, and in the DNS.
	Internationalized mail [RFC6530] allows U-labels in SMTP sessions		Internationalized mail [RFC6530] allows U-labels in SMTP sessions
	[RFC6531] and in message headers [RFC6532].		[RFC6531] and in message headers [RFC6532].
	Every U-label is equivalent to an A-label, so in principle the choice		Every U-label is equivalent to an A-label, so in principle the choice
	of label format should not cause any ambiguities. But in practice,		of label format will not cause ambiguities. But in practice,
	consistent use of label formats will make it more likely that mail		consistent use of label formats will make it more likely that mail
	senders' and receivers' code interoperates.		senders' and receivers' code interoperates.
	Internationalized mail also allows UTF-8 encoded Unicode characters		Internationalized mail also allows UTF-8 encoded Unicode characters
	in the local parts of mailbox names, which were historically only		in the local parts of mailbox names, which were historically only
	ASCII.		ASCII.
	2. Definitions		2. Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] and [RFC8174]. when they appear in all capitals, as		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	shown here.		capitals, as shown here.
	The term IDN, for Internationalized Domain Name, refers to a domain		The term IDN, for Internationalized Domain Name, refers to a domain
	name containing either U-labels or A-labels.		name containing either U-labels or A-labels.
	Since DMARC is not currently a standards track protocol, this		Since DMARC is not currently a standards track protocol, this
	specification offers advice rather than requirements for DMARC.		specification offers advice rather than requirements for DMARC.
	3. General principles		3. General principles
	In headers in EAI mail messages, domain names that were restricted to		In headers in EAI mail messages, domain names that were restricted to
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 30 ¶
	UTF8-2 = <Defined in Section 4 of RFC 3629>		UTF8-2 = <Defined in Section 4 of RFC 3629>
	UTF8-3 = <Defined in Section 4 of RFC 3629>		UTF8-3 = <Defined in Section 4 of RFC 3629>
	UTF8-4 = <Defined in Section 4 of RFC 3629>		UTF8-4 = <Defined in Section 4 of RFC 3629>
	Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags		Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags
	of a DKIM-Signature header MUST be encoded as A-labels. This rule is		of a DKIM-Signature header MUST be encoded as A-labels. This rule is
	relaxed only for internationalized messages headers [RFC6532] so IDNs		relaxed only for internationalized messages headers [RFC6532] so IDNs
	SHOULD be represented as U-labels but MAY be A-labels. This provides		SHOULD be represented as U-labels. This provides improved
	improved consistency with other headers. The set of allowable		consistency with other headers. (A-labels remain valid to allow a
	characters in the local-part of an i= tag is extended as described in		transition from older software.) The set of allowable characters in
	[RFC6532]. When computing or verifying the hash in a DKIM signature		the local-part of an i= tag is extended in the same fashion as local
	as described in section 3.7, the hash MUST use the domain name in the		parts of e-mail addresses as described in section 3.2 of [RFC6532].
	format it occurs in the header.		When computing or verifying the hash in a DKIM signature as described
			in section 3.7, the hash MUST use the domain name in the format it
			occurs in the header.
	Section 3.4.2 of [RFC6376] describes relaxed header canonicalization.		Section 3.4.2 of [RFC6376] describes relaxed header canonicalization.
	Its first step converts all header field names from upper case to		Its first step converts all header field names from upper case to
	lower case. Field names are restricted to printable ASCII (see		lower case. Field names are restricted to printable ASCII (see
	[RFC5322] section 3.6.8) so this case conversion remains the usual		[RFC5322] section 3.6.8) so this case conversion remains ASCII case
	ASCII conversion.		conversion.
	DKIM key records, described in section 3.6.1, do not contain domain		DKIM key records, described in section 3.6.1, do not contain domain
	names, so there is no change to their specification.		names, so there is no change to their specification.
	6. DMARC and internationalized mail		6. DMARC and internationalized mail
	DMARC [RFC7489] defines a policy language that domain owners can		DMARC [RFC7489] defines a policy language that domain owners can
	specify for the domain of the address in a RFC5322.From header.		specify for the domain of the address in a RFC5322.From header.
	Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the		Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the
	RFC5322.From address domain are to be handled. That section is		RFC5322.From address domain are to be handled. That section is
	updated to say that all U-labels in the domain are converted to		updated to say that all U-labels in the domain are converted to
	A-labels before further processing. Sections 6.7 and 7.1 are		A-labels before further processing. Section 7.1 is similarly updated
	similarly updated to say that all U-labels in domains being handled		to say that all U-labels in domains being handled are converted to
	are converted to A-labels before further processing.		A-labels before further processing.
	DMARC policy records, described in sections 6.3 and 7.1, can contain		DMARC policy records, described in sections 6.3 and 7.1, can contain
	e-mail addresses in the rua and ruf tags. Since a policy record can		e-mail addresses in the rua and ruf tags. Since a policy record can
	be used for both internationalized and conventional mail, those		be used for both internationalized and conventional mail, those
	addresses still have to be conventional addresses, not		addresses still have to be conventional addresses, not
	internationalized addresses.		internationalized addresses.
	7. IANA Considerations		7. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 43 ¶
	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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	Appendix A. Change history		Appendix A. Change history
			04 to 05 editorial nits
	03 to 04 remove dangling A-R reference, add more i18nish and		03 to 04 remove dangling A-R reference, add more i18nish and
	security goodness		security goodness
	02 to 03 minor edits per Alexey		02 to 03 minor edits per Alexey
	01 to 02 update references		01 to 02 update references
	00 to 01 Relaxed canon, Typos		00 to 01 Relaxed canon, Typos
	00 First WG version		00 First WG version
	Author's Address		Author's Address
	John Levine		John Levine
	Taughannock Networks		Taughannock Networks
	PO Box 727		PO Box 727
	Trumansburg, NY 14886		Trumansburg, NY 14886
	Email: standards@taugh.com		Email: standards@taugh.com
End of changes. 11 change blocks.
	19 lines changed or deleted		22 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/