draft-ietf-uta-smtp-tlsrpt-04.txt		draft-ietf-uta-smtp-tlsrpt-05.txt
	Using TLS in Applications D. Margolis		Using TLS in Applications D. Margolis
	Internet-Draft Google, Inc		Internet-Draft Google, Inc
	Intended status: Standards Track A. Brotman		Intended status: Standards Track A. Brotman
	Expires: October 5, 2017 Comcast, Inc		Expires: November 4, 2017 Comcast, Inc
	B. Ramakrishnan		B. Ramakrishnan
	Yahoo!, Inc		Yahoo!, Inc
	J. Jones		J. Jones
	Microsoft, Inc		Microsoft, Inc
	M. Risher		M. Risher
	Google, Inc		Google, Inc
	April 3, 2017		May 3, 2017
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-04		draft-ietf-uta-smtp-tlsrpt-05
	Abstract		Abstract
	A number of protocols exist for establishing encrypted channels		A number of protocols exist for establishing encrypted channels
	between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE		between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE
	[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due		[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due
	to misconfiguration or active attack, leading to undelivered messages		to misconfiguration or active attack, leading to undelivered messages
	or delivery over unencrypted or unauthenticated channels. This		or delivery over unencrypted or unauthenticated channels. This
	document describes a reporting mechanism and format by which sending		document describes a reporting mechanism and format by which sending
	systems can share statistics and specific information about potential		systems can share statistics and specific information about potential
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 October 5, 2017.		This Internet-Draft will expire on November 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 28 ¶		skipping to change at page 2, line 28 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4		2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4
	3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4		3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5		3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5
	3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5		3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5
	3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5		3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6
	4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 5		4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 6		4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7
	4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 6		4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7
	4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 6		4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7
	4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7		4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7
	4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7		4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7
	4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7		4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7
	4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 7		4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8
	4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8		4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8
	4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 8		4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 8
	5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 8		5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 8		5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9		5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9
	5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 9		5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 10
	5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 10		5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 10
	5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 10		5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 11		8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 12
	8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 11		8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 12
	8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 12		8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 12
	9. Appendix 2: JSON Report Schema . . . . . . . . . . . . . . . 12		9. Appendix 2: JSON Report Schema . . . . . . . . . . . . . . . 12
	10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 14		10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 15
	11. Normative References . . . . . . . . . . . . . . . . . . . . 16		11. Normative References . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and		The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
	hosts to establish secure SMTP sessions over TLS. The protocol		hosts to establish secure SMTP sessions over TLS. The protocol
	design is based on "Opportunistic Security" (OS) [RFC7435], which		design is based on "Opportunistic Security" (OS) [RFC7435], which
	maintains interoperability with clients that do not support STARTTLS		maintains interoperability with clients that do not support STARTTLS
	but means that any attacker who can delete parts of the SMTP session		but means that any attacker who can delete parts of the SMTP session
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 22 ¶
	o Policy Domain: The domain against which an MTA-STS or DANE Policy		o Policy Domain: The domain against which an MTA-STS or DANE Policy
	is defined.		is defined.
	o Sending MTA: The MTA initiating the delivery of an email message.		o Sending MTA: The MTA initiating the delivery of an email message.
	2. Related Technologies		2. Related Technologies
	o This document is intended as a companion to the specification for		o This document is intended as a companion to the specification for
	SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).		SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).
	o The Public Key Pinning Extension for HTTP [RFC7469] contains a		o SMTP-TLSRPT defines a mechanism for sending domains that are
	JSON-based definition for reporting individual pin validation		compatible with MTA-STS or DANE to share success and failure
	failures.		statistics with recipient domains. DANE is defined in [RFC6698]
			and MTA-STS is defined in [TODO]
	o The Domain-based Message Authentication, Reporting, and
	Conformance (DMARC) [RFC7489] contains an XML-based reporting
	format for aggregate and detailed email delivery errors.
	3. Reporting Policy		3. Reporting Policy
	A domain publishes a record to its DNS indicating that it wishes to		A domain publishes a record to its DNS indicating that it wishes to
	receive reports. These SMTP TLSRPT policies are distributed via DNS		receive reports. These SMTP TLSRPT policies are distributed via DNS
	from the Policy Domain's zone, as TXT records (similar to DMARC		from the Policy Domain's zone, as TXT records (similar to DMARC
	policies) under the name "_smtp-tlsrpt". For example, for the Policy		policies) under the name "_smtp-tlsrpt". For example, for the Policy
	Domain "example.com", the recipient's TLSRPT policy can be retrieved		Domain "example.com", the recipient's TLSRPT policy can be retrieved
	from "_smtp-tlsrpt.example.com".		from "_smtp-tlsrpt.example.com".
	Policies consist of the following directives:		Policies consist of the following directives:
	o "v": This value MUST be equal to "TLSRPTv1".		o "v": This value MUST be equal to "TLSRPTv1".
	o "rua": A URI specifying the endpoint to which aggregate		o "rua": A URI specifying the endpoint to which aggregate
	information about policy failures should be sent (see the section		information about policy failures should be sent (see Section 4,
	_Reporting_ _Schema_ for more information). Two URI schemes are		"Reporting Schema", for more information). Two URI schemes are
	supported: "mailto" and "https".		supported: "mailto" and "https".
	* In the case of "https", reports should be submitted via POST		o In the case of "https", reports should be submitted via POST
	([RFC2818]) to the specified URI.		([RFC2818]) to the specified URI.
	* In the case of "mailto", reports should be submitted to the		o In the case of "mailto", reports should be submitted to the
	specified email address. When sending failure reports via		specified email address ([RFC6068]). When sending failure reports
	SMTP, sending MTAs MUST deliver reports despite any TLS-related		via SMTP, sending MTAs MUST deliver reports despite any TLS-
	failures. This may mean that the reports are delivered in the		related failures. This may mean that the reports are delivered in
	clear.		the clear.
	The formal definition of the "_smtp-tlsrpt" TXT record, defined using		The formal definition of the "_smtp-tlsrpt" TXT record, defined using
	[RFC5234], is as follows:		[RFC5234], is as follows:
	tlsrpt-record = tlsrpt-version *WSP %x3B tlsrpt-rua		tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua
			[field-delim [tlsrpt-extensions]]
	tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53		field-delim = %x3B ; ";"
	%x52 %x50 %x54 %x76 %x31
	tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri		tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52
			%x50 %x54 %x76 %x31 ; "v=TSRPTv1"
	tlsrpt-uri = URI		tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..."
	; "URI" is imported from [@!RFC3986]; commas (ASCII
	; 0x2C) and exclamation points (ASCII 0x21)		tlsrpt-uri = URI
	; MUST be encoded; the numeric portion MUST fit		; "URI" is imported from [@!RFC3986]; commas (ASCII
	; within an unsigned 64-bit integer		; 0x2C) and exclamation points (ASCII 0x21)
			; MUST be encoded; the numeric portion MUST fit
			; within an unsigned 64-bit integer
			tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension)
			[field-delim]
			; extension fields
			tlsrpt-extension = tlsrpt-ext-name *WSP "=" *WSP tlsrpt-ext-value
			tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".")
			tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding
			; "=", ";", SP, and
			; control chars
	If multiple TXT records for "_smtp-tlsrpt" are returned by the		If multiple TXT records for "_smtp-tlsrpt" are returned by the
	resolver, records which do not begin with "v=TLSRPTv1;" are		resolver, records which do not begin with "v=TLSRPTv1;" are
	discarded. If the number of resulting records is not one, senders		discarded. If the number of resulting records is not one, senders
	MUST assume the recipient domain does not implement TLSRPT.		MUST assume the recipient domain does not implement TLSRPT. Parsers
			MUST accept TXT records which are syntactically valid (i.e. valid
			key-value pairs seprated by semi-colons) and implementing a superset
			of this specification, in which case unknown fields SHALL be ignored.
	3.1. Example Reporting Policy		3.1. Example Reporting Policy
	3.1.1. Report using MAILTO		3.1.1. Report using MAILTO
	_smtp-tlsrpt.example.com. IN TXT \		_smtp-tlsrpt.example.com. IN TXT \
	"v=TLSRPTv1;rua=mailto:reports@example.com"		"v=TLSRPTv1;rua=mailto:reports@example.com"
	3.1.2. Report using HTTPS		3.1.2. Report using HTTPS
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 25 ¶
	successfully negotiate a policy-compliant TLS connection, and		successfully negotiate a policy-compliant TLS connection, and
	serves to provide a "heartbeat" to receiving domains that		serves to provide a "heartbeat" to receiving domains that
	reporting is functional and tabulating correctly. This field		reporting is functional and tabulating correctly. This field
	contains an aggregate count of successful connections for the		contains an aggregate count of successful connections for the
	reporting system.		reporting system.
	4.2.2. Failure Count		4.2.2. Failure Count
	o "failure-count": This indicates that the sending MTA was unable to		o "failure-count": This indicates that the sending MTA was unable to
	successfully establish a connection with the receiving platform.		successfully establish a connection with the receiving platform.
	The "Result Types" section will elaborate on the failed		Section 4.3, "Result Types", will elaborate on the failed
	negotiation attempts. This field contains an aggregate count of		negotiation attempts. This field contains an aggregate count of
	failed connections.		failed connections.
	4.3. Result Types		4.3. Result Types
	The list of result types will start with the minimal set below, and		The list of result types will start with the minimal set below, and
	is expected to grow over time based on real-world experience. The		is expected to grow over time based on real-world experience. The
	initial set is:		initial set is:
	4.3.1. Negotiation Failures		4.3.1. Negotiation Failures
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 13 ¶
	chances of acceptance of the report at some compute cost.		chances of acceptance of the report at some compute cost.
	5.3. Email Transport		5.3. Email Transport
	The report MAY be delivered by email. No specific MIME message		The report MAY be delivered by email. No specific MIME message
	structure is required. It is presumed that the aggregate reporting		structure is required. It is presumed that the aggregate reporting
	address will be equipped to extract MIME parts with the prescribed		address will be equipped to extract MIME parts with the prescribed
	media type and filename and ignore the rest.		media type and filename and ignore the rest.
	If compressed, the report should use the media type "application/		If compressed, the report should use the media type "application/
	gzip" if compressed (see [RFC6713]), and "text/json" otherwise.		gzip" if compressed (see [RFC6713]), and "application/json"
			otherwise.
	The [RFC5322].Subject field for individual report submissions SHOULD		The [RFC5322].Subject field for individual report submissions SHOULD
	conform to the following ABNF:		conform to the following ABNF:
	tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"		tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"
	%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"		%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"
	domain-name 1*FWS ; from RFC 6376		domain-name 1*FWS ; from RFC 6376
	%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"		%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
	1*FWS domain-name 1*FWS		1*FWS domain-name 1*FWS
	%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"		%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
	skipping to change at page 10, line 42 ¶		skipping to change at page 10, line 50 ¶
	Submitter: mail.sender.example.com		Submitter: mail.sender.example.com
	Report-ID: <735ff.e317+bf22029@mailexample.net>		Report-ID: <735ff.e317+bf22029@mailexample.net>
	Note that, when sending failure reports via SMTP, sending MTAs MUST		Note that, when sending failure reports via SMTP, sending MTAs MUST
	NOT honor MTA-STS or DANE TLSA failures.		NOT honor MTA-STS or DANE TLSA failures.
	5.4. HTTPS Transport		5.4. HTTPS Transport
	The report MAY be delivered by POST to HTTPS. If compressed, the		The report MAY be delivered by POST to HTTPS. If compressed, the
	report should use the media type "application/gzip" (see [RFC6713]),		report should use the media type "application/gzip" (see [RFC6713]),
	and "text/json" otherwise.		and "application/json" otherwise.
	5.5. Delivery Retry		5.5. Delivery Retry
	In the event of a delivery failure, regardless of the delivery		In the event of a delivery failure, regardless of the delivery
	method, a sender SHOULD attempt redelivery for up to 24hrs after the		method, a sender SHOULD attempt redelivery for up to 24hrs after the
	initial attempt. As previously stated the reports are optional, so		initial attempt. As previously stated the reports are optional, so
	while it is ideal to attempt redelivery, it is not required. If		while it is ideal to attempt redelivery, it is not required. If
	multiple retries are attempted, they should be on a logarithmic		multiple retries are attempted, they should be on a logarithmic
	scale.		scale.
	skipping to change at page 13, line 23 ¶		skipping to change at page 14, line 10 ¶
	o "report-id": A unique identifier for the report. Report authors		o "report-id": A unique identifier for the report. Report authors
	may use whatever scheme they prefer to generate a unique		may use whatever scheme they prefer to generate a unique
	identifier. It is provided as a string.		identifier. It is provided as a string.
	o "policy-type": The type of policy that was applied by the sending		o "policy-type": The type of policy that was applied by the sending
	domain. Presently, the only three valid choices are "tlsa",		domain. Presently, the only three valid choices are "tlsa",
	"sts", and the literal string "no-policy-found". It is provided		"sts", and the literal string "no-policy-found". It is provided
	as a string.		as a string.
	o "policy-string": The string serialization of the policy, whether		o "policy-string": The JSON string serialization ([RFC7159] section
	TLSA record or MTA-STS policy. Any linefeeds from the original		7) of the policy, whether TLSA record ([RFC6698] section 2.3) or
	policy MUST be replaced with [SP]. TODO: Help with specifics.		MTA-STS policy.
	o "domain": The Policy Domain upon which the policy was applied.		o "domain": The Policy Domain is the domain against which the MTA-
	For messages sent to "user@example.com" this field would contain		STS or DANE policy is defined.
	"example.com". It is provided as a string.
	o "mx-host-pattern": The pattern of MX hostnames from the applied		o "mx-host-pattern": The pattern of MX hostnames from the applied
	policy. It is provided as a string, and is interpreted in the		policy. It is provided as a string, and is interpreted in the
	same manner as the "Checking of Wildcard Certificates" rules in		same manner as the "Checking of Wildcard Certificates" rules in
	Section 6.4.3 of [RFC6125].		Section 6.4.3 of [RFC6125].
	o "result-type": A value from the _Result Types_ section above.		o "result-type": A value from Section 4.3, "Result Types", above.
	o "ip-address": The IP address of the sending MTA that attempted the		o "ip-address": The IP address of the sending MTA that attempted the
	STARTTLS connection. It is provided as a string representation of		STARTTLS connection. It is provided as a string representation of
	an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal		an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal
	notation.		notation.
	o "receiving-mx-hostname": The hostname of the receiving MTA MX		o "receiving-mx-hostname": The hostname of the receiving MTA MX
	record with which the sending MTA attempted to negotiate a		record with which the sending MTA attempted to negotiate a
	STARTTLS connection.		STARTTLS connection.
	o "receiving-mx-helo": (optional) The HELO or EHLO string from the		o "receiving-mx-helo": (optional) The HELO or EHLO string from the
	banner announced during the reported session.		banner announced during the reported session.
	o "success-aggregate": The aggregate number (integer) of		o "success-aggregate": The aggregate number (integer) of
	successfully negotiated SSL-enabled connections to the receiving		successfully negotiated TLS-enabled connections to the receiving
	site.		site.
	o "failure-aggregate": The aggregate number (integer) of failures to		o "failure-aggregate": The aggregate number (integer) of failures to
	negotiate an SSL-enabled connection to the receiving site.		negotiate an TLS-enabled connection to the receiving site.
	o "session-count": The number of (attempted) sessions that match the		o "session-count": The number of (attempted) sessions that match the
	relevant "result-type" for this section.		relevant "result-type" for this section.
	o "additional-info-uri": An optional URI pointing to additional		o "additional-info-uri": An optional URI pointing to additional
	information around the relevant "result-type". For example, this		information around the relevant "result-type". For example, this
	URI might host the complete certificate chain presented during an		URI might host the complete certificate chain presented during an
	attempted STARTTLS session.		attempted STARTTLS session.
	o "failure-reason-code": A text field to include an SSL-related		o "failure-reason-code": A text field to include an TLS-related
	error code or error message.		error code or error message.
	10. Appendix 3: Example JSON Report		10. Appendix 3: Example JSON Report
	{		{
	"organization-name": "Company-X",		"organization-name": "Company-X",
	"date-range": {		"date-range": {
	"start-datetime": "2016-04-01T00:00:00Z",		"start-datetime": "2016-04-01T00:00:00Z",
	"end-datetime": "2016-04-01T23:59:59Z"		"end-datetime": "2016-04-01T23:59:59Z"
	},		},
	"contact-info": "sts-reporting@company-x.com",		"contact-info": "sts-reporting@company-x.com",
	"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",		"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
	"policy": {		"policy": {
	"policy-type": "sts",		"policy-type": "sts",
	skipping to change at page 16, line 33 ¶		skipping to change at page 16, line 33 ¶
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/		Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
	RFC5234, January 2008,		RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<http://www.rfc-editor.org/info/rfc5234>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
	10.17487/RFC5322, October 2008,		10.17487/RFC5322, October 2008,
	<http://www.rfc-editor.org/info/rfc5322>.		<http://www.rfc-editor.org/info/rfc5322>.
			[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
			URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
			<http://www.rfc-editor.org/info/rfc6068>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March		Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
	2011, <http://www.rfc-editor.org/info/rfc6125>.		2011, <http://www.rfc-editor.org/info/rfc6125>.
	[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication		[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
	of Named Entities (DANE) Transport Layer Security (TLS)		of Named Entities (DANE) Transport Layer Security (TLS)
	Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August		Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
End of changes. 31 change blocks.
	56 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/