rfc9116.original.xml		rfc9116.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.24 -->		<!DOCTYPE rfc [
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">		<!ENTITY nbsp "&#160;">
	<?rfc sortrefs="yes"?>		<!ENTITY zwsp "&#8203;">
	<?rfc strict="yes"?>		<!ENTITY nbhy "&#8209;">
	<?rfc symrefs="yes"?>		<!ENTITY wj "&#8288;">
	<?rfc toc="yes"?>		]>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-foudil-securitytxt-13" category="info" obsoletes="" updates="" submissionType="		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	IETF" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3"		-foudil-securitytxt-12" number="9116" obsoletes="" updates="" submissionType="IE
	>		TF" category="info" consensus="true" xml:lang="en" sortRefs="true" symRefs="true
	<!-- xml2rfc v2v3 conversion 3.5.0 -->		" tocInclude="true"
			version="3">
	<front>		<front>
	<title abbrev="security.txt">A File Format to Aid in Security Vulnerability Disclosure</title>		<title abbrev="security.txt">A File Format to Aid in Security Vulnerability Disclosure</title>
	<seriesInfo name="Internet-Draft" value="draft-foudil-securitytxt-13"/>		<seriesInfo name="RFC" value="9116"/>
	<author initials="E." surname="Foudil" fullname="Edwin Foudil">		<author initials="E." surname="Foudil" fullname="Edwin Foudil">
	<organization/>		<organization/>
	<address>		<address>
	<email>contact@edoverflow.com</email>		<email>contact@edoverflow.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="Y." surname="Shafranovich" fullname="Yakov Shafranovich">		<author initials="Y." surname="Shafranovich" fullname="Yakov Shafranovich">
	<organization>Nightwatch Cybersecurity</organization>		<organization>Nightwatch Cybersecurity</organization>
	<address>		<address>
	<email>yakov+ietf@nightwatchcybersecurity.com</email>		<email>yakov+ietf@nightwatchcybersecurity.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2021" month="July" day="11"/>		<date year="2022" month="April"/>
	<abstract>		<abstract>
	<t>When security vulnerabilities are discovered by		<t>When security vulnerabilities are discovered by
	researchers, proper reporting channels are often lacking. As a result,		researchers, proper reporting channels are often lacking. As a result,
	vulnerabilities may be left unreported. This document defines a machine-parsable format		vulnerabilities may be left unreported. This document defines a machine-parsable format
	("security.txt") to help organizations describe their vulnerability disclosure p ractices		("security.txt") to help organizations describe their vulnerability disclosure p ractices
	to make it easier for researchers to report vulnerabilities.</t>		to make it easier for researchers to report vulnerabilities.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="default">		<section anchor="introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<section anchor="motivation" numbered="true" toc="default">		<section anchor="motivation" numbered="true" toc="default">
	<name>Motivation, Prior Work and Scope</name>		<name>Motivation, Prior Work, and Scope</name>
	<t>Many security researchers encounter situations where they are unable		<t>Many security researchers encounter situations where they are unable
	to report security vulnerabilities to organizations because there are		to report security vulnerabilities to organizations because there are
	no reporting channels to contact the owner of a particular		no reporting channels to contact the owner of a particular
	resource and no information available about the vulnerability disclosure practic es		resource, and no information is available about the vulnerability disclosure pra ctices
	of such owner.</t>		of such owner.</t>
	<t>As per section 4 of <xref target="RFC2142" format="default"/>, there is an existing convention		<t>As per <xref target="RFC2142" section="4" sectionFormat="of"/>, there is an existing convention
	of using the &lt;SECURITY@domain&gt; email address for communications regarding		of using the &lt;SECURITY@domain&gt; email address for communications regarding
	security issues. That convention provides only a single, email-based		security issues. That convention provides only a single, email-based
	channel of communication per domain, and does not provide		channel of communication per domain and does not provide
	a way for domain owners to publish information about their security disclosure		a way for domain owners to publish information about their security disclosure
	practices.</t>		practices.</t>
	<t>There are also contact conventions prescribed for Internet Service Pr oviders (ISPs)		<t>There are also contact conventions prescribed for Internet Service Pr oviders (ISPs)
	in section 2 of <xref target="RFC3013" format="default"/>, for Computer Security		in <xref target="RFC3013" section="2" sectionFormat="of"/>, for Computer Securit
	Incident Response Teams (CSIRTs)		y Incident Response Teams (CSIRTs)
	in section 3.2 of <xref target="RFC2350" format="default"/> and for site operato		in <xref target="RFC2350" section="3.2" sectionFormat="of"/>, and for site opera
	rs in section 5.2 of		tors in <xref target="RFC2196" section="5.2" sectionFormat="of"/>. As per <xref
	<xref target="RFC2196" format="default"/>. As per <xref target="RFC7485" format=		target="RFC7485" format="default"/>, there is also contact information provided
	"default"/>, there is also contact information provided by		by
	Regional Internet Registries (RIRs) and domain registries for owners of IP		Regional Internet Registries (RIRs) and domain registries for owners of IP
	addresses, autonomous system numbers (ASNs), and domain names. However, none of		addresses, Autonomous System Numbers (ASNs), and domain names. However, none of
	these tackle the issue of how security researchers can locate contact informatio n		these tackle the issue of how security researchers can locate contact informatio n
	and vulnerability disclosure practices for organizations in order to report		and vulnerability disclosure practices for organizations in order to report
	vulnerabilities.</t>		vulnerabilities.</t>
	<t>In this document, we define a richer, machine-parsable and more exten sible way		<t>In this document, we define a richer, machine-parsable, and more exte nsible way
	for organizations to communicate information about their security disclosure		for organizations to communicate information about their security disclosure
	practices and ways to contact them. Other details of vulnerability disclosure		practices and ways to contact them. Other details of vulnerability disclosure
	are outside the scope of this document. Readers are encouraged to consult other		are outside the scope of this document. Readers are encouraged to consult other
	documents such as <xref target="ISO.29147.2018" format="default"/> or <xref targ et="CERT.CVD" format="default"/>.</t>		documents such as <xref target="ISO.29147.2018" format="default"/> or <xref targ et="CERT.CVD" format="default"/>.</t>
	<t>As per <xref target="CERT.CVD" format="default"/>, "vulnerability res		<t>As per <xref target="CERT.CVD" format="default"/>, "vulnerability res
	ponse" refers to reports of product vulnerabilities		ponse" refers to reports of product vulnerabilities,
	which is related but distinct from reports of network intrusions and compromised		which is related to but distinct from reports of network intrusions and compromi
			sed
	websites ("incident response"). The mechanism defined in this document is intend ed		websites ("incident response"). The mechanism defined in this document is intend ed
	to be used for the former ("vulnerability response"). If implementors want		to be used for the former ("vulnerability response"). If implementors want
	to utilize this mechanism for incident response, they should be aware of additio nal		to utilize this mechanism for incident response, they should be aware of additio nal
	security considerations discussed in <xref target="compromise" format="default"/ >.</t>		security considerations discussed in <xref target="compromise" format="default"/ >.</t>
	<t>The "security.txt" file is intended to be complementary and not as a substitute		<t>The "security.txt" file is intended to be complementary and not a sub stitute
	or replacement for other public resources maintained by organizations regarding		or replacement for other public resources maintained by organizations regarding
	their security disclosure practices.</t>		their security disclosure practices.</t>
	</section>		</section>
	<section anchor="terminology" numbered="true" toc="default">		<section anchor="terminology" numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14
	BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="		>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
	default"/> when, and only when, they appear in all		"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
	capitals, as shown here.</t>		BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="
			default"/> when, and only when, they appear in all capitals, as shown here.</t>
	<t>The term "researcher" corresponds		<t>The term "researcher" corresponds
	to the terms "finder" and "reporter" in <xref target="ISO.29147.2018" format="de fault"/> and <xref target="CERT.CVD" format="default"/>.		to the terms "finder" and "reporter" in <xref target="ISO.29147.2018" format="de fault"/> and <xref target="CERT.CVD" format="default"/>.
	The term "organization" corresponds to the term "vendor"		The term "organization" corresponds to the term "vendor"
	in <xref target="ISO.29147.2018" format="default"/> and <xref target="CERT.CVD" format="default"/>.</t>		in <xref target="ISO.29147.2018" format="default"/> and <xref target="CERT.CVD" format="default"/>.</t>
	<t>The term "implementors" includes all parties involved in		<t>The term "implementors" includes all parties involved in
	the vulnerability disclosure process.</t>		the vulnerability disclosure process.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="note-to-readers" numbered="true" toc="default">
	<name>Note to Readers</name>
	<ul empty="true" spacing="normal">
	<li>
	<strong>Note to the RFC Editor:</strong> Please remove this section p
	rior
	to publication.</li>
	</ul>
	<t>Development of this draft takes place on Github at: https://github.com/
	securitytxt/security-txt</t>
	</section>
	<section anchor="the-specification" numbered="true" toc="default">		<section anchor="the-specification" numbered="true" toc="default">
	<name>The Specification</name>		<name>The Specification</name>
	<t>This document defines a text file to be placed in a known location		<t>This document defines a text file to be placed in a known location
	that provides information about vulnerability disclosure practices of a particul ar organization.		that provides information about vulnerability disclosure practices of a particul ar organization.
	The format of this file is machine-parsable and MUST follow the ABNF grammar def ined in		The format of this file is machine parsable and <bcp14>MUST</bcp14> follow the A BNF grammar defined in
	<xref target="abnf" format="default"/>. This file is intended to help security r esearchers when		<xref target="abnf" format="default"/>. This file is intended to help security r esearchers when
	disclosing security vulnerabilities.</t>		disclosing security vulnerabilities.</t>
	<t>By convention, the file is named "security.txt". Location and scope are described		<t>By convention, the file is named "security.txt". The location and scope are described
	in <xref target="location" format="default"/>.</t>		in <xref target="location" format="default"/>.</t>
	<t>This text file contains multiple fields with different values. A field		<t>This text file contains multiple fields with different values. A field
	contains a "name" which is the first part of a field all the way up		contains a "name", which is the first part of a field all the way up
	to the colon (for example: "Contact:") and follows the syntax defined for "field		to the colon (for example: "Contact:") and follows the syntax defined for "field
	-name" in section 3.6.8		-name" in <xref target="RFC5322" section="3.6.8" sectionFormat="of"/>. Field nam
	of <xref target="RFC5322" format="default"/>. Field names are case-insensitive (		es are case insensitive (as per <xref target="RFC5234" section="2.3" sectionForm
	as per section 2.3 of <xref target="RFC5234" format="default"/>).		at="of"/>).
	The "value" comes after the field name (for example: "mailto:security@example.co m") and follows the syntax		The "value" comes after the field name (for example: "mailto:security@example.co m") and follows the syntax
	defined for "unstructured" in section 3.2.5 of <xref target="RFC5322" format="de		defined for "unstructured" in <xref target="RFC5322" section="3.2.5" sectionForm
	fault"/>. The file MAY also contain blank lines.</t>		at="of"/>. The file <bcp14>MAY</bcp14> also contain blank lines.</t>
	<t>A field MUST always consist of a name and a value		<t>A field <bcp14>MUST</bcp14> always consist of a name and a value
	(for example: "Contact: mailto:security@example.com"). A "security.txt" file		(for example: "Contact: mailto:security@example.com"). A "security.txt" file
	can have an unlimited number of fields. Each field MUST appear on		can have an unlimited number of fields. Each field <bcp14>MUST</bcp14> appear on
	its own line. Unless specified otherwise by the field definition,		its own line. Unless otherwise specified by the field definition,
	multiple values MUST NOT be chained together for a single field.		multiple values <bcp14>MUST NOT</bcp14> be chained together for a single field.
	Unless otherwise indicated in a definition of a particular field, a field MAY ap		Unless otherwise indicated in a definition of a particular field, a field <bcp14
	pear		>MAY</bcp14> appear
	multiple times.</t>		multiple times.</t>
	<t>Implementors should be aware that some of the fields may		<t>Implementors should be aware that some of the fields may
	contain URIs using percent-encoding (as per section 2.1 of <xref target="RFC3986 " format="default"/>).</t>		contain URIs using percent-encoding (as per <xref target="RFC3986" section="2.1" sectionFormat="of"/>).</t>
	<section anchor="comments" numbered="true" toc="default">		<section anchor="comments" numbered="true" toc="default">
	<name>Comments</name>		<name>Comments</name>
	<t>Any line beginning with the "#" (%x23) symbol MUST be interpreted as		<t>Any line beginning with the "#" (%x23) symbol <bcp14>MUST</bcp14> be
	a comment.		interpreted as a comment. The content of the comment may contain any ASCII or Un
	The content of the comment may contain any ASCII or Unicode characters in the		icode characters in the
	%x21-7E and %x80-FFFFF ranges plus the tab (%x09) and space (%x20) characters.</		%x21-7E and %x80-FFFFF ranges plus the tab (%x09) and space (%x20) charac
	t>		ters.</t>
	<t>Example:</t>		<t>Example:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	# This is a comment.		# This is a comment.
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="line-separator" numbered="true" toc="default">		<section anchor="line-separator" numbered="true" toc="default">
	<name>Line Separator</name>		<name>Line Separator</name>
	<t>Every line MUST end either with a carriage return and line feed		<t>Every line <bcp14>MUST</bcp14> end with either a carriage return and line feed
	characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).</t>		characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).</t>
	</section>		</section>
	<section anchor="signature" numbered="true" toc="default">		<section anchor="signature" numbered="true" toc="default">
	<name>Digital signature</name>		<name>Digital Signature</name>
	<t>It is RECOMMENDED that a "security.txt" file be digitally signed		<t>It is <bcp14>RECOMMENDED</bcp14> that a "security.txt" file be digita
	using an OpenPGP cleartext signature as described in		lly signed
	section 7 of <xref target="RFC4880" format="default"/>. When digital signatures		using an OpenPGP cleartext signature as described in <xref target="RFC4880" sect
	are used, it is also		ion="7" sectionFormat="of"/>. When digital signatures are used, it is also
	RECOMMENDED that organizations use the "Canonical" field (as per <xref target="c		<bcp14>RECOMMENDED</bcp14> that organizations use the "Canonical" field (as per
	anonical" format="default"/>),		<xref target="canonical" format="default"/>),
	thus allowing the digital signature to authenticate the location of the file.</t >		thus allowing the digital signature to authenticate the location of the file.</t >
	<t>When it comes to verifying the key used to generate the signature, it is always		<t>When it comes to verifying the key used to generate the signature, it is always
	the security researcher's responsibility to make sure the key being		the security researcher's responsibility to make sure the key being
	used is indeed one they trust.</t>		used is indeed one they trust.</t>
	</section>		</section>
	<section anchor="extensibility" numbered="true" toc="default">		<section anchor="extensibility" numbered="true" toc="default">
	<name>Extensibility</name>		<name>Extensibility</name>
	<t>Like many other formats and protocols, this format may need to be ext ended		<t>Like many other formats and protocols, this format may need to be cha nged
	over time to fit the ever-changing landscape of the Internet. Therefore,		over time to fit the ever-changing landscape of the Internet. Therefore,
	extensibility is provided via an IANA registry for fields as defined		extensibility is provided via an IANA registry for fields as defined
	in <xref target="registry" format="default"/>. Any fields registered via that pr ocess MUST be		in <xref target="registry" format="default"/>. Any fields registered via that pr ocess <bcp14>MUST</bcp14> be
	considered optional. To encourage extensibility and interoperability,		considered optional. To encourage extensibility and interoperability,
	researchers MUST ignore any fields they do not explicitly support.</t>		researchers <bcp14>MUST</bcp14> ignore any fields they do not explicitly support .</t>
	<t>In general, implementors should "be conservative in what you do,		<t>In general, implementors should "be conservative in what you do,
	be liberal in what you accept from others" (as per <xref target="RFC0793" format ="default"/>).</t>		be liberal in what you accept from others" (as per <xref target="RFC0793" format ="default"/>).</t>
	</section>		</section>
	<section anchor="field-definitions" numbered="true" toc="default">		<section anchor="field-definitions" numbered="true" toc="default">
	<name>Field Definitions</name>		<name>Field Definitions</name>
	<t>Unless otherwise stated, all fields MUST be considered optional.</t>		<t>Unless otherwise stated, all fields <bcp14>MUST</bcp14> be considered optional.</t>
	<section anchor="acknowledgments" numbered="true" toc="default">		<section anchor="acknowledgments" numbered="true" toc="default">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>This field indicates a link to a page where security
			<t>The "Acknowledgments" field indicates a link to a page where securi
			ty
	researchers are recognized for their reports. The page being referenced		researchers are recognized for their reports. The page being referenced
	should list security researchers that reported security vulnerabilities		should list security researchers that reported security vulnerabilities
	and collaborated to remediate them. Organizations should be careful		and collaborated to remediate them. Organizations should be careful
	to limit the vulnerability information being published in order		to limit the vulnerability information being published in order
	to prevent future attacks.</t>		to prevent future attacks.</t>
	<t>If this field indicates a web URI, then it MUST begin with "https:/		<t>If this field indicates a web URI, then it <bcp14>MUST</bcp14> begi
	/"		n with "https://"
	(as per section 2.7.2 of <xref target="RFC7230" format="default"/>).</t>		(as per <xref target="RFC7230" section="2.7.2" sectionFormat="of"/>).</t>
	<t>Example:</t>		<t>Example:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Acknowledgments: https://example.com/hall-of-fame.html		Acknowledgments: https://example.com/hall-of-fame.html
	]]></artwork>		]]></artwork>
	<t>Example security acknowledgments page:</t>		<t>Example security acknowledgments page:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	We would like to thank the following researchers:		We would like to thank the following researchers:
	(2017-04-15) Frank Denis - Reflected cross-site scripting		(2017-04-15) Frank Denis - Reflected cross-site scripting
	(2017-01-02) Alice Quinn - SQL injection		(2017-01-02) Alice Quinn - SQL injection
	(2016-12-24) John Buchner - Stored cross-site scripting		(2016-12-24) John Buchner - Stored cross-site scripting
	(2016-06-10) Anna Richmond - A server configuration issue		(2016-06-10) Anna Richmond - A server configuration issue
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="canonical" numbered="true" toc="default">		<section anchor="canonical" numbered="true" toc="default">
	<name>Canonical</name>		<name>Canonical</name>
	<t>This field indicates the canonical URIs where the "security.txt" fi le is located,		<t>The "Canonical" field indicates the canonical URIs where the "secur ity.txt" file is located,
	which is usually something like "https://example.com/.well-known/security.txt".		which is usually something like "https://example.com/.well-known/security.txt".
	If this field indicates a web URI, then it MUST begin with "https://"		If this field indicates a web URI, then it <bcp14>MUST</bcp14> begin with "https
	(as per section 2.7.2 of <xref target="RFC7230" format="default"/>).</t>		://"
			(as per <xref target="RFC7230" section="2.7.2" sectionFormat="of"/>).</t>
	<t>While this field indicates that a "security.txt" retrieved from a g iven URI		<t>While this field indicates that a "security.txt" retrieved from a g iven URI
	is intended to apply to that URI, it MUST NOT be interpreted to apply to		is intended to apply to that URI, it <bcp14>MUST NOT</bcp14> be interpreted to a
	all canonical URIs listed within the file. Researchers SHOULD use an additional		pply to
			all canonical URIs listed within the file. Researchers <bcp14>SHOULD</bcp14> use
			an additional
	trust mechanism such as a digital signature (as per <xref target="signature" for mat="default"/>) to make the		trust mechanism such as a digital signature (as per <xref target="signature" for mat="default"/>) to make the
	determination that a particular canonical URI is applicable.</t>		determination that a particular canonical URI is applicable.</t>
	<t>If this field appears within a "security.txt" file, and the URI use d to		<t>If this field appears within a "security.txt" file and the URI used to
	retrieve that file is not listed within any canonical fields,		retrieve that file is not listed within any canonical fields,
	then the contents of the file SHOULD NOT be trusted.</t>		then the contents of the file <bcp14>SHOULD NOT</bcp14> be trusted.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Canonical: https://www.example.com/.well-known/security.txt		Canonical: https://www.example.com/.well-known/security.txt
	Canonical: https://someserver.example.com/.well-known/security.txt		Canonical: https://someserver.example.com/.well-known/security.txt
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="contact" numbered="true" toc="default">		<section anchor="contact" numbered="true" toc="default">
	<name>Contact</name>		<name>Contact</name>
	<t>This field indicates an address that researchers		<t>The "Contact" field indicates a method that researchers
	should use for reporting security		should use for reporting security
	vulnerabilities such as an email address, a phone number and/or a		vulnerabilities such as an email address, a phone number, and/or a
	web page with contact information. The "Contact" field MUST		web page with contact information. This field <bcp14>MUST</bcp14>
	always be present in a "security.txt" file. If this field indicates a web URI,		always be present in a "security.txt" file. If this field indicates a web URI,
	then it MUST begin with "https://" (as per section 2.7.2 of <xref target="RFC723		then it <bcp14>MUST</bcp14> begin with "https://" (as per <xref target="RFC7230"
	0" format="default"/>).		section="2.7.2" sectionFormat="of"/>).
	Security email addresses should use the conventions defined in section		Security email addresses should use the conventions defined in <xref target="RFC
	4 of <xref target="RFC2142" format="default"/>.</t>		2142" section="4" sectionFormat="of"/>.</t>
	<t>The value MUST follow the URI syntax described in section 3 of <xre		<t>The value <bcp14>MUST</bcp14> follow the URI syntax described in <x
	f target="RFC3986" format="default"/>.		ref target="RFC3986" section="3" sectionFormat="of"/>.
	This means that "mailto" and "tel" URI schemes must be used		This means that "mailto" and "tel" URI schemes must be used
	when specifying email addresses and telephone numbers, as defined in <xref targe t="RFC6068" format="default"/>		when specifying email addresses and telephone numbers, as defined in <xref targe t="RFC6068" format="default"/>
	and <xref target="RFC3966" format="default"/>. When the value of this field is a n email address,		and <xref target="RFC3966" format="default"/>. When the value of this field is a n email address,
	it is RECOMMENDED that encryption be used (as per <xref target="encryption" form		it is <bcp14>RECOMMENDED</bcp14> that encryption be used (as per <xref
	at="default"/>).</t>		target="encryption" format="default"/>).</t>
	<t>The precedence SHOULD be in listed order. The first occurrence is t
	he preferred		<t>These <bcp14>SHOULD</bcp14> be listed in order of preference, with
	method of contact. In the example below, the first email address		the first occurrence being the preferred
			method of contact, the second occurrence being the second most preferred method
			of contact, etc. In the example below, the first email address
	("security@example.com") is the preferred method of contact.</t>		("security@example.com") is the preferred method of contact.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Contact: mailto:security@example.com		Contact: mailto:security@example.com
	Contact: mailto:security%2Buri%2Bencoded@example.com		Contact: mailto:security%2Buri%2Bencoded@example.com
	Contact: tel:+1-201-555-0123		Contact: tel:+1-201-555-0123
	Contact: https://example.com/security-contact.html		Contact: https://example.com/security-contact.html
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="encryption" numbered="true" toc="default">		<section anchor="encryption" numbered="true" toc="default">
	<name>Encryption</name>		<name>Encryption</name>
	<t>This field indicates an encryption key that		<t>The "Encryption" field indicates an encryption key that
	security researchers should use for encrypted communication. Keys MUST NOT		security researchers should use for encrypted communication. Keys <bcp14>MUST NO
	appear in this field - instead the value of this field		T</bcp14>
	MUST be a URI pointing to a location where the key can be retrieved.		appear in this field. Instead, the value of this field
	If this field indicates a web URI, then it MUST begin with "https://"		<bcp14>MUST</bcp14> be a URI pointing to a location where the key can be retriev
	(as per section 2.7.2 of <xref target="RFC7230" format="default"/>).</t>		ed.
			If this field indicates a web URI, then it <bcp14>MUST</bcp14> begin with "https
			://"
			(as per <xref target="RFC7230" section="2.7.2" sectionFormat="of"/>).</t>
	<t>When it comes to verifying the authenticity of the key, it is alway s the security		<t>When it comes to verifying the authenticity of the key, it is alway s the security
	researcher's responsibility to make sure the key being specified is indeed one		researcher's responsibility to make sure the key being specified is indeed one
	they trust. Researchers must not assume that this key is		they trust. Researchers must not assume that this key is
	used to generate the digital signature referenced in <xref target="signature" fo rmat="default"/>.</t>		used to generate the digital signature referenced in <xref target="signature" fo rmat="default"/>.</t>
	<t>Example of an OpenPGP key available from a web server:</t>		<t>Example of an OpenPGP key available from a web server:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Encryption: https://example.com/pgp-key.txt		Encryption: https://example.com/pgp-key.txt
	]]></artwork>		]]></artwork>
	<t>Example of an OpenPGP key available from an OPENPGPKEY DNS record:< /t>		<t>Example of an OpenPGP key available from an OPENPGPKEY DNS record:< /t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY		Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY
	]]></artwork>		]]></artwork>
	<t>Example of an OpenPGP key being referenced by its fingerprint:</t>		<t>Example of an OpenPGP key being referenced by its fingerprint:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f		Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="expires" numbered="true" toc="default">		<section anchor="expires" numbered="true" toc="default">
	<name>Expires</name>		<name>Expires</name>
	<t>This field indicates the date and time after which the data contain ed in the "security.txt"		<t>The "Expires" field indicates the date and time after which the dat a contained in the "security.txt"
	file is considered stale and should not be used (as per <xref target="stale" for mat="default"/>). The value of this field is formatted		file is considered stale and should not be used (as per <xref target="stale" for mat="default"/>). The value of this field is formatted
	according to the Internet profile of <xref target="ISO.8601" format="default"/> as defined in <xref target="RFC3339" format="default"/>. It is RECOMMENDED that the value		according to the Internet profiles of <xref target="ISO.8601-1" format="default" /> and <xref target="ISO.8601-2" format="default"/> as defined in <xref target=" RFC3339" format="default"/>. It is <bcp14>RECOMMENDED</bcp14> that the value
	of this field be less than a year into the future to avoid staleness.</t>		of this field be less than a year into the future to avoid staleness.</t>
	<t>This field MUST always be present and MUST NOT appear more than onc e.</t>		<t>This field <bcp14>MUST</bcp14> always be present and <bcp14>MUST NO T</bcp14> appear more than once.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Expires: 2021-12-31T18:37:07z		Expires: 2021-12-31T18:37:07z
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="hiring" numbered="true" toc="default">		<section anchor="hiring" numbered="true" toc="default">
	<name>Hiring</name>		<name>Hiring</name>
	<t>The "Hiring" field is used for linking to the vendor's security-rel ated job positions.		<t>The "Hiring" field is used for linking to the vendor's security-rel ated job positions.
	If this field indicates a web URI, then it MUST begin with "https://"		If this field indicates a web URI, then it <bcp14>MUST</bcp14> begin with "https
	(as per section 2.7.2 of <xref target="RFC7230" format="default"/>).</t>		://"
			(as per <xref target="RFC7230" section="2.7.2" sectionFormat="of"/>).</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Hiring: https://example.com/jobs.html		Hiring: https://example.com/jobs.html
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="policy" numbered="true" toc="default">		<section anchor="policy" numbered="true" toc="default">
	<name>Policy</name>		<name>Policy</name>
	<t>This field indicates a link to where the vulnerability disclosure p olicy is located.		<t>The "Policy" field indicates a link to where the vulnerability disc losure policy is located.
	This can help security researchers understand		This can help security researchers understand
	the organization's vulnerability reporting practices.		the organization's vulnerability reporting practices.
	If this field indicates a web URI, then it MUST begin with "https://"		If this field indicates a web URI, then it <bcp14>MUST</bcp14> begin with "https
	(as per section 2.7.2 of <xref target="RFC7230" format="default"/>).</t>		://"
			(as per <xref target="RFC7230" section="2.7.2" sectionFormat="of"/>).</t>
	<t>Example:</t>		<t>Example:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Policy: https://example.com/disclosure-policy.html		Policy: https://example.com/disclosure-policy.html
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="preflang" numbered="true" toc="default">		<section anchor="preflang" numbered="true" toc="default">
	<name>Preferred-Languages</name>		<name>Preferred-Languages</name>
	<t>This field can be used to indicate a set of natural languages that		<t>The "Preferred-Languages" field can be used to indicate a set of na
	are preferred when submitting security reports. This set MAY list multiple		tural languages that
	values, separated by commas. If this field is included then at least		are preferred when submitting security reports. This set <bcp14>MAY</bcp14> list
	one value MUST be listed. The values within this set are language tags		multiple
			values, separated by commas. If this field is included, then at least
			one value <bcp14>MUST</bcp14> be listed. The values within this set are language
			tags
	(as defined in <xref target="RFC5646" format="default"/>). If this field is abse nt, security researchers		(as defined in <xref target="RFC5646" format="default"/>). If this field is abse nt, security researchers
	may assume that English is the language to be used (as per section 4.5		may assume that English is the language to be used (as per <xref target="RFC2277
	of <xref target="RFC2277" format="default"/>).</t>		" section="4.5" sectionFormat="of"/>).</t>
	<t>The order in which they appear is not an indication of priority;		<t>The order in which they appear is not an indication of priority;
	the listed languages are intended to have equal priority.</t>		the listed languages are intended to have equal priority.</t>
	<t>This field MUST NOT appear more than once.</t>		<t>This field <bcp14>MUST NOT</bcp14> appear more than once.</t>
	<t>Example (English, Spanish and French):</t>		<t>Example (English, Spanish and French):</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Preferred-Languages: en, es, fr		Preferred-Languages: en, es, fr
	]]></artwork>		]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="example-of-an-unsigned-securitytxt-file" numbered="true" toc="default">		<section anchor="example-of-an-unsigned-securitytxt-file" numbered="true" toc="default">
	<name>Example of an unsigned "security.txt" file</name>		<name>Example of an Unsigned "security.txt" File</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	# Our security address		# Our security address
	Contact: mailto:security@example.com		Contact: mailto:security@example.com
	# Our OpenPGP key		# Our OpenPGP key
	Encryption: https://example.com/pgp-key.txt		Encryption: https://example.com/pgp-key.txt
	# Our security policy		# Our security policy
	Policy: https://example.com/security-policy.html		Policy: https://example.com/security-policy.html
	# Our security acknowledgments page		# Our security acknowledgments page
	Acknowledgments: https://example.com/hall-of-fame.html		Acknowledgments: https://example.com/hall-of-fame.html
	Expires: 2021-12-31T18:37:07z		Expires: 2021-12-31T18:37:07z
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="example-of-a-signed-securitytxt-file" numbered="true" toc ="default">		<section anchor="example-of-a-signed-securitytxt-file" numbered="true" toc ="default">
	<name>Example of a signed "security.txt" file</name>		<name>Example of a Signed "security.txt" File</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	-----BEGIN PGP SIGNED MESSAGE-----		-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA256		Hash: SHA256
	# Canonical URI		# Canonical URI
	Canonical: https://example.com/.well-known/security.txt		Canonical: https://example.com/.well-known/security.txt
	# Our security address		# Our security address
	Contact: mailto:security@example.com		Contact: mailto:security@example.com
	skipping to change at line 354 ¶		skipping to change at line 345 ¶
	Expires: 2021-12-31T18:37:07z		Expires: 2021-12-31T18:37:07z
	-----BEGIN PGP SIGNATURE-----		-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v2.2		Version: GnuPG v2.2
	[signature]		[signature]
	-----END PGP SIGNATURE-----		-----END PGP SIGNATURE-----
	]]></artwork>		]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="location" numbered="true" toc="default">		<section anchor="location" numbered="true" toc="default">
	<name>Location of the security.txt file</name>		<name>Location of the security.txt File</name>
	<t>For web-based services, organizations MUST place the "security.txt" fil		<t>For web-based services, organizations <bcp14>MUST</bcp14> place the "se
	e under the "/.well-known/" path; e.g. https://example.com/.well-known/security.		curity.txt" file under the "/.well-known/" path, e.g., https://example.com/.well
	txt		-known/security.txt
	as per <xref target="RFC8615" format="default"/> of a domain name or IP address.		as per <xref target="RFC8615" format="default"/> of a domain name or IP address.
	For legacy compatibility, a security.txt file might be placed at the top-level		For legacy compatibility, a "security.txt" file might be placed at the top-leve
	path		l path
	or redirect (as per section 6.4 of <xref target="RFC7231" format="default"/>) to		or redirect (as per <xref target="RFC7231" section="6.4" sectionFormat="of"/>) t
	the "security.txt" file under the "/.well-known/" path. If a "security.txt" fil		o the "security.txt" file under the "/.well-known/" path. If a "security.txt" fi
	e		le
	is present in both locations, the one in the "/.well-known/" path MUST be used.<		is present in both locations, the one in the "/.well-known/" path <bcp14>MUST</b
	/t>		cp14> be used.</t>
	<t>The file MUST be accessed via HTTP 1.0 or a higher version		<t>The file <bcp14>MUST</bcp14> be accessed via HTTP 1.0 or a higher versi
	and the file access MUST use "https" scheme (as per section 2.7.2 of <xref targe		on,
	t="RFC7230" format="default"/>).		and the file access <bcp14>MUST</bcp14> use the "https" scheme (as per <xref tar
	It MUST have a Content-Type of "text/plain"		get="RFC7230" section="2.7.2" sectionFormat="of"/>).
	with the default charset parameter set to "utf-8" (as per section 4.1.3 of <xref		It <bcp14>MUST</bcp14> have a Content-Type of "text/plain"
	target="RFC2046" format="default"/>).</t>		with the default charset parameter set to "utf-8" (as per <xref target="RFC2046"
	<t>Retrieval of "security.txt" files and resources indicated within such f		section="4.1.3" sectionFormat="of"/>).</t>
	iles may result in a redirect (as per		<t>Retrieval of "security.txt" files and resources indicated within such f
	section 6.4 of <xref target="RFC7231" format="default"/>). Researchers should pe		iles may result in a redirect (as per <xref target="RFC7231" section="6.4" secti
	rform additional analysis (as per <xref target="redirects" format="default"/>) t		onFormat="of"/>). Researchers should perform additional analysis (as per <xref t
	o make sure these redirects		arget="redirects" format="default"/>) to make sure these redirects
	are not malicious or pointing to resources controlled by an attacker.</t>		are not malicious or pointing to resources controlled by an attacker.</t>
	<section anchor="scope-of-the-file" numbered="true" toc="default">		<section anchor="scope-of-the-file" numbered="true" toc="default">
	<name>Scope of the File</name>		<name>Scope of the File</name>
	<t>A "security.txt" file MUST only apply to the domain		<t>A "security.txt" file <bcp14>MUST</bcp14> only apply to the domain
	or IP address in the URI used to retrieve it, not to any of its subdomains or pa rent domains.		or IP address in the URI used to retrieve it, not to any of its subdomains or pa rent domains.
	A "security.txt" file MAY also apply to products and services provided by the or		A "security.txt" file <bcp14>MAY</bcp14> also apply to products and services pro
	ganization publishing the file.</t>		vided by the organization publishing the file.</t>
	<t>As per <xref target="motivation" format="default"/>, this specificati		<t>As per <xref target="motivation" format="default"/>, this specificati
	on is intended for vulnerability response.		on is intended for a vulnerability response.
	If implementors want to use this for incident response, they should be aware of		If implementors want to use this for an incident response, they should be aware
	additional security considerations discussed in <xref target="compromise" format		of additional security considerations discussed in <xref target="compromise" for
	="default"/>.</t>		mat="default"/>.</t>
	<t>Organizations SHOULD use the policy directive (as per <xref target="p		<t>Organizations <bcp14>SHOULD</bcp14> use the policy directive (as per
	olicy" format="default"/>)		<xref target="policy" format="default"/>)
	to provide additional details regarding scope and details of their vulnerability		to provide additional details regarding the scope and details of their vulnerabi
	disclosure process.</t>		lity disclosure process.</t>
	<t>Some examples appear below:</t>		<t>Some examples appear below:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	# The following only applies to example.com.		# The following only applies to example.com.
	https://example.com/.well-known/security.txt		https://example.com/.well-known/security.txt
	# This only applies to subdomain.example.com.		# This only applies to subdomain.example.com.
	https://subdomain.example.com/.well-known/security.txt		https://subdomain.example.com/.well-known/security.txt
	# This security.txt file applies to IPv4 address of 192.0.2.0.		# This security.txt file applies to IPv4 address of 192.0.2.0.
	https://192.0.2.0/.well-known/security.txt		https://192.0.2.0/.well-known/security.txt
	# This security.txt file applies to IPv6 address of 2001:db8:8:4::2.		# This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
	https://[2001:db8:8:4::2]/.well-known/security.txt		https://[2001:db8:8:4::2]/.well-known/security.txt
	]]></artwork>		]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="abnf" numbered="true" toc="default">		<section anchor="abnf" numbered="true" toc="default">
	<name>File Format Description and ABNF Grammar</name>		<name>File Format Description and ABNF Grammar</name>
	<t>The file format of the "security.txt" file MUST be plain text (MIME typ		<t>The file format of the "security.txt" file <bcp14>MUST</bcp14> be plain
	e "text/plain") as defined		text (MIME type "text/plain") as defined
	in section 4.1.3 of <xref target="RFC2046" format="default"/> and MUST be encode		in <xref target="RFC2046" section="4.1.3" sectionFormat="of"/> and <bcp14>
	d using UTF-8 <xref target="RFC3629" format="default"/> in Net-Unicode form <xre		MUST</bcp14> be encoded using UTF-8 <xref target="RFC3629" format="default"/> in
	f target="RFC5198" format="default"/>.</t>		Net-Unicode form <xref target="RFC5198" format="default"/>.</t>
	<t>The format of this file MUST follow the ABNF definition below (using		<t keepWithPrevious="true">The format of this file <bcp14>MUST</bcp14> fol
	the conventions defined in <xref target="RFC5234" format="default"/>).</t>		low the ABNF definition below (which incorporates the core ABNF rules from
	<artwork name="" type="" align="left" alt=""><![CDATA[		<xref target="RFC5234" format="default"/> and uses the case-sensitive stri
			ng support from <xref target="RFC7405" format="default"/>).</t>
			<sourcecode type="abnf"><![CDATA[
	body = signed / unsigned		body = signed / unsigned
	signed = sign-header unsigned sign-footer		unsigned = *line (contact-field eol) ; one or more required
			*line (expires-field eol) ; exactly one required
			*line [lang-field eol] *line ; exactly one optional
			; order of fields within the file is not important
			; except that if contact-field appears more
			; than once, the order of those indicates
			; priority (see Section 3.5.3)
	sign-header = < headers and line from section 7 of [RFC4880] >		; signed is the production that should match the OpenPGP clearsigned
			; document
			signed = cleartext-header
			1*(hash-header)
			CRLF
			cleartext
			signature
	sign-footer = < OpenPGP signature from section 7 of [RFC4880] >		cleartext-header = %s"-----BEGIN PGP SIGNED MESSAGE-----" CRLF
	unsigned = *line (contact-field eol) ; one or more required		hash-header = %s"Hash: " hash-alg *("," hash-alg) CRLF
	*line (expires-field eol) ; exactly one required
	*line [lang-field eol] *line ; exactly one optional		hash-alg = token
	; order of fields within the file is not important		; imported from RFC 2045; see RFC 4880 Section
	; except that if contact-field appears more		; 10.3.3 for a pointer to the registry of
	; than once the order of those indicates		; valid values
	; priority (see Section 3.5.3)
			;cleartext = 1*( UTF8-octets [CR] LF)
			; dash-escaped per RFC 4880 Section 7.1
			cleartext = *((line-dash / line-from / line-nodash) [CR] LF)
			line-dash = ("- ") "-" *UTF8-char-not-cr
			; MUST include initial "- "
			line-from = ["- "] "From " *UTF8-char-not-cr
			; SHOULD include initial "- "
			line-nodash = ["- "] *UTF8-char-not-cr
			; MAY include initial "- "
			UTF8-char-not-dash = UTF8-1-not-dash / UTF8-2 / UTF8-3 / UTF8-4
			UTF8-1-not-dash = %x00-2C / %x2E-7F
			UTF8-char-not-cr = UTF8-1-not-cr / UTF8-2 / UTF8-3 / UTF8-4
			UTF8-1-not-cr = %x00-0C / %x0E-7F
			; UTF8 rules from RFC 3629
			UTF8-octets = *( UTF8-char )
			UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
			UTF8-1 = %x00-7F
			UTF8-2 = %xC2-DF UTF8-tail
			UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
			%xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
			UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
			%xF1-F3 3( UTF8-tail ) /
			%xF4 %x80-8F 2( UTF8-tail )
			UTF8-tail = %x80-BF
			signature = armor-header
			armor-keys
			CRLF
			signature-data
			armor-tail
			armor-header = %s"-----BEGIN PGP SIGNATURE-----" CRLF
			armor-keys = *(token ": " *( VCHAR / WSP ) CRLF)
			; Armor Header Keys from RFC 4880
			armor-tail = %s"-----END PGP SIGNATURE-----" CRLF
			signature-data = 1*(1*(ALPHA / DIGIT / "=" / "+" / "/") CRLF)
			; base64; see RFC 4648
			; includes RFC 4880 checksum
	line = [ (field / comment) ] eol		line = [ (field / comment) ] eol
	eol = *WSP [CR] LF		eol = *WSP [CR] LF
	field = ; optional fields		field = ; optional fields
	ack-field /		ack-field /
	can-field /		can-field /
	contact-field / ; optional repeated instances		contact-field / ; optional repeated instances
	encryption-field /		encryption-field /
	skipping to change at line 447 ¶		skipping to change at line 497 ¶
	expires-field = "Expires" fs SP date-time		expires-field = "Expires" fs SP date-time
	encryption-field = "Encryption" fs SP uri		encryption-field = "Encryption" fs SP uri
	hiring-field = "Hiring" fs SP uri		hiring-field = "Hiring" fs SP uri
	lang-field = "Preferred-Languages" fs SP lang-values		lang-field = "Preferred-Languages" fs SP lang-values
	policy-field = "Policy" fs SP uri		policy-field = "Policy" fs SP uri
	date-time = < imported from section 5.6 of [RFC3339] >		date-time = < imported from Section 5.6 of [RFC3339] >
	lang-tag = < Language-Tag from section 2.1 of [RFC5646] >		lang-tag = < Language-Tag from Section 2.1 of [RFC5646] >
	lang-values = lang-tag *(*WSP "," *WSP lang-tag)		lang-values = lang-tag *(*WSP "," *WSP lang-tag)
	uri = < URI as per section 3 of [RFC3986] >		uri = < URI as per Section 3 of [RFC3986] >
	ext-field = field-name fs SP unstructured		ext-field = field-name fs SP unstructured
	field-name = < imported from section 3.6.8 of [RFC5322] >		field-name = < imported from Section 3.6.8 of [RFC5322] >
	unstructured = < imported from section 3.2.5 of [RFC5322] >		unstructured = < imported from Section 3.2.5 of [RFC5322] >
	]]></artwork>
	<t>"ext-field" refers to extension fields, which are discussed in <xref ta		token = < imported from Section 5.1 of [RFC2045] >
	rget="extensibility" format="default"/></t>
			ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
			BIT = "0" / "1"
			CHAR = %x01-7F
			; any 7-bit US-ASCII character,
			; excluding NUL
			CR = %x0D
			; carriage return
			CRLF = CR LF
			; Internet standard newline
			CTL = %x00-1F / %x7F
			; controls
			DIGIT = %x30-39
			; 0-9
			DQUOTE = %x22
			; " (Double Quote)
			HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
			HTAB = %x09
			; horizontal tab
			LF = %x0A
			; linefeed
			LWSP = *(WSP / CRLF WSP)
			; Use of this linear-white-space rule
			; permits lines containing only white
			; space that are no longer legal in
			; mail headers and have caused
			; interoperability problems in other
			; contexts.
			; Do not use when defining mail
			; headers and use with caution in
			; other contexts.
			OCTET = %x00-FF
			; 8 bits of data
			SP = %x20
			VCHAR = %x21-7E
			; visible (printing) characters
			WSP = SP / HTAB
			; white space
			]]></sourcecode>
			<t>"ext-field" refers to extension fields, which are discussed in <xref ta
			rget="extensibility" format="default"/>.</t>
	</section>		</section>
	<section anchor="security-considerations" numbered="true" toc="default">		<section anchor="security-considerations" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>Because of the use of URIs and well-known resources, security considera tions of		<t>Because of the use of URIs and well-known resources, security considera tions of
	<xref target="RFC3986" format="default"/> and <xref target="RFC8615" format="def ault"/> apply here, in addition to the		<xref target="RFC3986" format="default"/> and <xref target="RFC8615" format="def ault"/> apply here, in addition to the
	considerations outlined below.</t>		considerations outlined below.</t>
	<section anchor="compromise" numbered="true" toc="default">		<section anchor="compromise" numbered="true" toc="default">
	<name>Compromised Files and Incident Response</name>		<name>Compromised Files and Incident Response</name>
	<t>An attacker that has compromised a website is able to compromise		<t>An attacker that has compromised a website is able to compromise
	the "security.txt" file as well or setup a redirect to their own site.		the "security.txt" file as well or set up a redirect to their own site.
	This can result in security reports not being received by the organization		This can result in security reports not being received by the organization
	or sent to the attacker.</t>		or being sent to the attacker.</t>
	<t>To protect against this, organizations should use the "Canonical" fie ld to indicate the locations		<t>To protect against this, organizations should use the "Canonical" fie ld to indicate the locations
	of the file (as per <xref target="canonical" format="default"/>), digitally sign their "security.txt"		of the file (as per <xref target="canonical" format="default"/>), digitally sign their "security.txt"
	files (as per <xref target="signature" format="default"/>), and regularly monito r the file and		files (as per <xref target="signature" format="default"/>), and regularly monito r the file and
	the referenced resources to detect tampering.</t>		the referenced resources to detect tampering.</t>
	<t>Security researchers should validate the "security.txt" file includin
	g verifying		<t>Security researchers should validate the "security.txt" file, including verif
			ying
	the digital signature and checking any available historical records before using the information		the digital signature and checking any available historical records before using the information
	contained in the file. If the "security.txt" file looks suspicious or compromise d,		contained in the file. If the "security.txt" file looks suspicious or compromise d,
	it should not be used.</t>		it should not be used.</t>
	<t>While it is not recommended, implementors may choose to use the infor mation published		<t>While it is not recommended, implementors may choose to use the infor mation published
	within a "security.txt" file for incident response. In such cases, extreme cauti on		within a "security.txt" file for an incident response. In such cases, extreme ca ution
	should be taken before trusting such information, since		should be taken before trusting such information, since
	it may have been compromised by an attacker. Researchers should use additional m ethods		it may have been compromised by an attacker. Researchers should use additional m ethods
	to verify such data including out of band verification of the PGP signature, DNS SEC-based approaches, etc.</t>		to verify such data including out-of-band verification of the Pretty Good Privac y (PGP) signature, DNSSEC-based approaches, etc.</t>
	</section>		</section>
	<section anchor="redirects" numbered="true" toc="default">		<section anchor="redirects" numbered="true" toc="default">
	<name>Redirects</name>		<name>Redirects</name>
	<t>When retrieving the file and any resources referenced in the file, re searchers should record		<t>When retrieving the file and any resources referenced in the file, re searchers should record
	any redirects since they can lead to a different domain or IP address controlled by an attacker. Further		any redirects since they can lead to a different domain or IP address controlled by an attacker. Further
	inspections of such redirects is recommended before using the information contai ned within the file.</t>		inspection of such redirects is recommended before using the information contain ed within the file.</t>
	</section>		</section>
	<section anchor="stale" numbered="true" toc="default">		<section anchor="stale" numbered="true" toc="default">
	<name>Incorrect or Stale Information</name>		<name>Incorrect or Stale Information</name>
	<t>If information and resources referenced in a "security.txt" file are incorrect		<t>If information and resources referenced in a "security.txt" file are incorrect
	or not kept up to date, this can result in security reports not being received		or not kept up to date, this can result in security reports not being received
	by the organization or sent to incorrect contacts, thus exposing possible		by the organization or sent to incorrect contacts, thus exposing possible
	security issues to third parties. Not having a "security.txt" file may be prefer able		security issues to third parties. Not having a "security.txt" file may be prefer able
	to having stale information in this file. Organizations must use		to having stale information in this file. Organizations must use
	the "Expires" field (see <xref target="expires" format="default"/>) to indicate to researchers when		the "Expires" field (see <xref target="expires" format="default"/>) to indicate to researchers when
	the data in the file is no longer valid.</t>		the data in the file is no longer valid.</t>
	<t>Organizations should ensure that information in this file and any ref erenced		<t>Organizations should ensure that information in this file and any ref erenced
	resources such as web pages, email addresses, and telephone numbers		resources such as web pages, email addresses, and telephone numbers
	are kept current, are accessible, controlled by the organization,		are kept current, are accessible, are controlled by the organization,
	and are kept secure.</t>		and are kept secure.</t>
	</section>		</section>
	<section anchor="intentionally-malformed-files-resources-and-reports" numb ered="true" toc="default">		<section anchor="intentionally-malformed-files-resources-and-reports" numb ered="true" toc="default">
	<name>Intentionally Malformed Files, Resources and Reports</name>		<name>Intentionally Malformed Files, Resources, and Reports</name>
	<t>It is possible for compromised or malicious sites to create files tha t are extraordinarily		<t>It is possible for compromised or malicious sites to create files tha t are extraordinarily
	large or otherwise malformed in an attempt to discover or exploit weaknesses		large or otherwise malformed in an attempt to discover or exploit weaknesses
	in parsing code. Researchers should make sure that any such code		in the parsing code.
	is robust against large or malformed files and fields, and may choose not to par
	se		Researchers should make sure that any such code
	files larger than 32 KBs, having fields longer than 2,048 characters or		is robust against large or malformed files and fields, and they may choose to ha
	containing more than 1,000 lines. The ABNF grammar (as defined in		ve the code not parse files larger than 32 KBs, those with fields longer than 2,
			048 characters, or those containing more than 1,000 lines. The ABNF grammar (as
			defined in
	<xref target="abnf" format="default"/>) can also be used as a way to verify thes e files.</t>		<xref target="abnf" format="default"/>) can also be used as a way to verify thes e files.</t>
	<t>The same concerns apply to any other resources referenced within "sec urity.txt"		<t>The same concerns apply to any other resources referenced within "sec urity.txt"
	files, as well as any security reports received as a result of publishing		files, as well as any security reports received as a result of publishing
	this file. Such resources and reports may be hostile, malformed or malicious.</t >		this file. Such resources and reports may be hostile, malformed, or malicious.</ t>
	</section>		</section>
	<section anchor="no-implied-permission-for-testing" numbered="true" toc="d efault">		<section anchor="no-implied-permission-for-testing" numbered="true" toc="d efault">
	<name>No Implied Permission for Testing</name>		<name>No Implied Permission for Testing</name>
	<t>The presence of a "security.txt" file might be interpreted by researc hers		<t>The presence of a "security.txt" file might be interpreted by researc hers
	as providing permission to do security testing against the domain or IP address		as providing permission to do security testing against the domain or IP address
	where it is published, or products and services provided by the organization pub lishing		where it is published or against products and services provided by the organizat ion publishing
	the file.		the file.
	This might result in increased testing against an organization by researchers. O n the other hand, a decision not		This might result in increased testing against an organization by researchers. O n the other hand, a decision not
	to publish a "security.txt" file might be interpreted by the		to publish a "security.txt" file might be interpreted by the
	organization operating that website to be a way to signal to researchers		organization operating that website to be a way to signal to researchers
	that permission to test that particular site or project is denied. This might re sult in pushback against		that permission to test that particular site or project is denied. This might re sult in pushback against
	researchers reporting security issues to that organization.</t>		researchers reporting security issues to that organization.</t>
	<t>Therefore, researchers shouldn't assume that presence or absence of		<t>Therefore, researchers shouldn't assume that the presence or absence of
	a "security.txt" file grants or denies permission for security testing.		a "security.txt" file grants or denies permission for security testing.
	Any such permission may be indicated in the company's vulnerability disclosure p olicy		Any such permission may be indicated in the company's vulnerability disclosure p olicy
	(as per <xref target="policy" format="default"/>) or a new field (as per <xref t arget="extensibility" format="default"/>).</t>		(as per <xref target="policy" format="default"/>) or a new field (as per <xref t arget="extensibility" format="default"/>).</t>
	</section>		</section>
	<section anchor="multi-user-environments" numbered="true" toc="default">		<section anchor="multi-user-environments" numbered="true" toc="default">
	<name>Multi-user Environments</name>		<name>Multi-User Environments</name>
	<t>In multi-user / multi-tenant environments, it may possible for a user		<t>In multi-user / multi-tenant environments, it may be possible for a u
	to take		ser to take
	over the location of the "security.txt" file. Organizations should reserve		over the location of the "security.txt" file. Organizations should reserve
	the "security.txt" namespace at the root to ensure no third-party can create a p age with		the "security.txt" namespace at the root to ensure no third party can create a p age with
	the "security.txt" AND "/.well-known/security.txt" names.</t>		the "security.txt" AND "/.well-known/security.txt" names.</t>
	</section>		</section>
	<section anchor="protecting-data-in-transit" numbered="true" toc="default" >		<section anchor="protecting-data-in-transit" numbered="true" toc="default" >
	<name>Protecting Data in Transit</name>		<name>Protecting Data in Transit</name>
	<t>To protect a "security.txt" file from being tampered with in transit,		<t>To protect a "security.txt" file from being tampered with in transit,
	implementors MUST use		implementors <bcp14>MUST</bcp14> use
	HTTPS (as per section 2.7.2 of <xref target="RFC7230" format="default"/>) when s		HTTPS (as per <xref target="RFC7230" section="2.7.2" sectionFormat="of"/>) when
	erving the file itself and for retrieval of any web URIs		serving the file itself and for retrieval of any web URIs
	referenced in it (except when otherwise noted in this specification). As part of the TLS		referenced in it (except when otherwise noted in this specification). As part of the TLS
	handshake, researchers should validate the provided X.509 certificate		handshake, researchers should validate the provided X.509 certificate
	in accordance with <xref target="RFC6125" format="default"/> and the following c onsiderations:</t>		in accordance with <xref target="RFC6125" format="default"/> and the following c onsiderations:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Matching is performed only against the DNS-ID identifiers.</li>		<li>Matching is performed only against the DNS-ID identifiers.</li>
	<li>DNS domain names in server certificates MAY contain the wildcard		<li>DNS domain names in server certificates <bcp14>MAY</bcp14> contain
	character '*' as the complete left-most label within the identifier.</li>		the wildcard
			character '*' as the complete leftmost label within the identifier.</li>
	</ul>		</ul>
	<t>The certificate may also be checked for revocation via the Online Cer tificate Status		<t>The certificate may also be checked for revocation via the Online Cer tificate Status
	Protocol (OCSP) <xref target="RFC6960" format="default"/>, certificate revocatio n lists (CRLs), or similar mechanisms.</t>		Protocol (OCSP) <xref target="RFC6960" format="default"/>, certificate revocatio n lists (CRLs), or similar mechanisms.</t>
	<t>In cases where the "security.txt" file cannot be served via HTTPS (su ch as localhost) or is		<t>In cases where the "security.txt" file cannot be served via HTTPS (su ch as localhost) or is
	being served with an invalid certificate, additional human validation is recomme nded since		being served with an invalid certificate, additional human validation is recomme nded since
	the contents may have been modified while in transit.</t>		the contents may have been modified while in transit.</t>
	<t>As an additional layer of protection, it is also recommended that		<t>As an additional layer of protection, it is also recommended that
	organizations digitally sign their "security.txt" file with OpenPGP (as per <xre f target="signature" format="default"/>).		organizations digitally sign their "security.txt" file with OpenPGP (as per <xre f target="signature" format="default"/>).
	Also, to protect security reports from being tampered with or observed while in transit,		Also, to protect security reports from being tampered with or observed while in transit,
	organizations should specify encryption keys (as per <xref target="encryption" f ormat="default"/>) unless		organizations should specify encryption keys (as per <xref target="encryption" f ormat="default"/>) unless
	HTTPS is being used for report submission.</t>		HTTPS is being used for report submission.</t>
	<t>However, the determination of validity of such keys is out of scope		<t>However, the determination of validity of such keys is out of scope
	for this specification. Security researchers need to establish other secure mean s to		for this specification. Security researchers need to establish other secure mean s to
	verify them.</t>		verify them.</t>
	</section>		</section>
	<section anchor="spam-and-spurious-reports" numbered="true" toc="default">		<section anchor="spam-and-spurious-reports" numbered="true" toc="default">
	<name>Spam and Spurious Reports</name>		<name>Spam and Spurious Reports</name>
	<t>Similar to concerns in <xref target="RFC2142" format="default"/>, den ial of service attacks via spam reports		<t>Similar to concerns in <xref target="RFC2142" format="default"/>, den ial-of-service attacks via spam reports
	would become easier once a "security.txt" file is published by		would become easier once a "security.txt" file is published by
	an organization. In addition, there is an increased likelihood of reports		an organization. In addition, there is an increased likelihood of reports
	being sent in an automated fashion and/or as result of automated scans without		being sent in an automated fashion and/or as a result of automated scans without
	human analysis. Attackers can also use this file as a way to spam unrelated		human analysis. Attackers can also use this file as a way to spam unrelated
	third parties by listing their resources and/or contact information.</t>		third parties by listing their resources and/or contact information.</t>
	<t>Organizations need to weigh the advantages of publishing this file ve rsus		<t>Organizations need to weigh the advantages of publishing this file ve rsus
	the possible disadvantages and increased resources required to analyze		the possible disadvantages and increased resources required to analyze
	security reports.</t>		security reports.</t>
	<t>Security researchers should review all information within the "securi ty.txt"		<t>Security researchers should review all information within the "securi ty.txt"
	file before submitting reports in an automated fashion or as resulting from auto mated scans.</t>		file before submitting reports in an automated fashion or reports resulting from automated scans.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>Implementors should be aware that any resources referenced within		<t>Implementors should be aware that any resources referenced within
	a "security.txt" file MUST NOT point to the Well-Known URIs namespace unless		a "security.txt" file <bcp14>MUST NOT</bcp14> point to the Well-Known URIs names pace unless
	they are registered with IANA (as per <xref target="RFC8615" format="default"/>) .</t>		they are registered with IANA (as per <xref target="RFC8615" format="default"/>) .</t>
	<section anchor="well-known-uris-registry" numbered="true" toc="default">		<section anchor="well-known-uris-registry" numbered="true" toc="default">
	<name>Well-Known URIs registry</name>		<name>Well-Known URIs Registry</name>
	<t>The "Well-Known URIs" registry should be updated with the following a		<t>IANA has updated the "Well-Known URIs" registry with the following ad
	dditional		ditional
	values (using the template from <xref target="RFC8615" format="default"/>):</t>		values (using the template from <xref target="RFC8615" format="default"/>
	<t>URI suffix: security.txt</t>		):</t>
	<t>Change controller: IETF</t>		<dl spacing="compact">
	<t>Specification document(s): this document</t>		<dt>URI suffix:</dt><dd>security.txt</dd>
	<t>Status: permanent</t>		<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Specification document(s):</dt><dd>RFC 9116</dd>
			<dt>Status:</dt><dd>permanent</dd>
			</dl>
	</section>		</section>
	<section anchor="registry" numbered="true" toc="default">		<section anchor="registry" numbered="true" toc="default">
	<name>Registry for security.txt Fields</name>		<name>Registry for security.txt Fields</name>
	<t>IANA is requested to create the "security.txt Fields" registry in		<t>IANA has created the "security.txt Fields" registry in
	accordance with <xref target="RFC8126" format="default"/>. This registry will co		accordance with <xref target="RFC8126" format="default"/>. This registry contain
	ntain fields for		s fields for
	use in "security.txt" files, defined by this specification.</t>		use in "security.txt" files, defined by this specification.</t>
	<t>New registrations or updates MUST be published in accordance with the		<t>New registrations or updates <bcp14>MUST</bcp14> be published in acco
	"Expert Review" guidelines as described in sections 4.5 and 5 of		rdance with the
	<xref target="RFC8126" format="default"/>. Any new field thus registered is cons		"Expert Review" guidelines as described in Sections
	idered optional		<xref target="RFC8126" section="4.5" sectionFormat="bare"/> and <xref target="RF
			C8126" section="5" sectionFormat="bare"/> of <xref target="RFC8126" format="defa
			ult"/>. Any new field thus registered is considered optional
	by this specification unless a new version of this specification is published.</ t>		by this specification unless a new version of this specification is published.</ t>
	<t>Designated Experts are expected to check whether a proposed registrat		<t>Designated experts should determine whether a proposed registration o
	ion or update		r update
	makes sense in the context of industry accepted vulnerability disclosure process		provides value to organizations and researchers using this format and makes sens
	es		e in the context of industry-accepted vulnerability disclosure processes
	such as <xref target="ISO.29147.2018" format="default"/> and <xref target="CERT.		such as <xref target="ISO.29147.2018" format="default"/> and <xref target="CERT.
	CVD" format="default"/>, and provides value to organizations		CVD" format="default"/>.</t>
	and researchers using this format.</t>
	<t>New registrations and updates MUST contain the following information:		<t>New registrations and updates <bcp14>MUST</bcp14> contain the followi
	</t>		ng information:</t>
	<ol spacing="normal" type="1"><li>Name of the field being registered or
	updated</li>		<ol spacing="normal" type="1">
			<li>Name of the field being registered or updated</li>
	<li>Short description of the field</li>		<li>Short description of the field</li>
	<li>Whether the field can appear more than once</li>		<li>Whether the field can appear more than once</li>
	<li>The document in which the specification of the field is published (if available)</li>
	<li>		<li>
	<t>New or updated status, which MUST be one of:		<t> New or updated status, which <bcp14>MUST</bcp14> be one of the f
	</t>		ollowing:</t>
	<ul spacing="normal">
	<li>current: The field is in current use</li>		<dl spacing="compact">
	<li>deprecated: The field has been in use, but new usage is discou
	raged</li>		<dt>current:</dt><dd>The field is in current use.</dd>
	<li>historic: The field is no longer in current use</li>		<dt>deprecated:</dt><dd>The field has been in use, but new usage i
	</ul>		s discouraged.</dd>
			<dt>historic:</dt><dd>The field is no longer in current use.</dd>
			</dl>
	</li>		</li>
	<li>Change controller</li>		<li>Change controller</li>
			<li>The document in which the specification of the field is published (i f available)</li>
	</ol>		</ol>
	<t>An update may make a notation on an existing registration indicating
	that a registered field is historical or deprecated if appropriate.</t>
	<t>The initial registry contains these values:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	Field Name: Acknowledgments
	Description: link to page where security researchers are recognized
	Multiple Appearances: Yes
	Published in: this document
	Status: current
	Change controller: IETF
	Field Name: Canonical		<t>Existing registrations may be marked historic or deprecated, as appro
	Description: canonical URI for this file		priate, by a future update to this document.</t>
	Multiple Appearances: Yes
	Published in: this document
	Status: current
	Change controller: IETF
	Field Name: Contact		<t>The initial registry contains these values:</t>
	Description: contact information to use for reporting vulnerabilities
	Multiple Appearances: Yes
	Published in: this document
	Status: current
	Change controller: IETF
	Field Name: Expires		<dl spacing="compact">
	Description: date and time after which this file is considered stale		<dt>Field Name:</dt><dd>Acknowledgments</dd>
	Multiple Appearances: No		<dt>Description:</dt><dd>link to page where security researchers are recogniz
	Published in: this document		ed</dd>
	Status: current		<dt>Multiple Appearances:</dt><dd>yes</dd>
	Change controller: IETF		<dt>Status:</dt><dd>current</dd>
			<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Reference:</dt><dd>RFC 9116</dd>
			</dl>
	Field Name: Encryption		<dl spacing="compact">
	Description: link to a key to be used for encrypted communication		<dt>Field Name:</dt><dd>Canonical</dd>
	Multiple Appearances: Yes		<dt>Description:</dt><dd>canonical URI for this file</dd>
	Published in: this document		<dt>Multiple Appearances:</dt><dd>yes</dd>
	Status: current		<dt>Status:</dt><dd>current</dd>
	Change controller: IETF		<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Reference:</dt><dd>RFC 9116</dd>
			</dl>
	Field Name: Hiring		<dl spacing="compact">
	Description: link to the vendor's security-related job positions		<dt>Field Name:</dt><dd>Contact</dd>
	Multiple Appearances: Yes		<dt>Description:</dt><dd>contact information to use for reporting vulnerabili
	Published in: this document		ties</dd>
	Status: current		<dt>Multiple Appearances:</dt><dd>yes</dd>
	Change controller: IETF		<dt>Status:</dt><dd>current</dd>
			<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Reference:</dt><dd>RFC 9116</dd>
			</dl>
	Field Name: Policy		<dl spacing="compact">
	Description: link to security policy page		<dt>Field Name:</dt><dd>Expires</dd>
	Multiple Appearances: Yes		<dt>Description:</dt><dd>date and time after which this file is considered st
	Published in: this document		ale</dd>
	Status: current		<dt>Multiple Appearances:</dt><dd>no</dd>
	Change controller: IETF		<dt>Status:</dt><dd>current</dd>
			<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Reference:</dt><dd>RFC 9116</dd>
			</dl>
	Field Name: Preferred-Languages		<dl spacing="compact">
	Description: list of preferred languages for security reports		<dt>Field Name:</dt><dd>Encryption</dd>
	Multiple Appearances: No		<dt>Description:</dt><dd>link to a key to be used for encrypted communication
	Published in: this document		</dd>
	Status: current		<dt>Multiple Appearances:</dt><dd>yes</dd>
	Change controller: IETF		<dt>Status:</dt><dd>current</dd>
	]]></artwork>		<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Reference:</dt><dd>RFC 9116</dd>
			</dl>
			<dl spacing="compact">
			<dt>Field Name:</dt><dd>Hiring</dd>
			<dt>Description:</dt><dd>link to the vendor's security-related job positions<
			/dd>
			<dt>Multiple Appearances:</dt><dd>yes</dd>
			<dt>Status:</dt><dd>current</dd>
			<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Reference:</dt><dd>RFC 9116</dd>
			</dl>
			<dl spacing="compact">
			<dt>Field Name:</dt><dd>Policy</dd>
			<dt>Description:</dt><dd>link to security policy page</dd>
			<dt>Multiple Appearances:</dt><dd>yes</dd>
			<dt>Status:</dt><dd>current</dd>
			<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Reference:</dt><dd>RFC 9116</dd>
			</dl>
			<dl spacing="compact">
			<dt>Field Name:</dt><dd>Preferred-Languages</dd>
			<dt>Description:</dt><dd>list of preferred languages for security reports</dd
			>
			<dt>Multiple Appearances:</dt><dd>no</dd>
			<dt>Status:</dt><dd>current</dd>
			<dt>Change controller:</dt><dd>IETF</dd>
			<dt>Reference:</dt><dd>RFC 9116</dd>
			</dl>
	</section>		</section>
	</section>		</section>
	<section anchor="contributors" numbered="true" toc="default">
	<name>Contributors</name>
	<t>The authors would like to acknowledge the help provided during the
	development of this document by Tom Hudson, Jobert Abma,
	Gerben Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, Eduardo V
	ela, and Krzysztof Kotowicz.</t>
	<t>The authors would also like to acknowledge the feedback provided by mul
	tiple members of IETF's
	LAST CALL, SAAG, and SECDISPATCH lists.</t>
	<t>Yakov would like to also thank L.T.S. (for everything).</t>
	</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC2142" target="https://www.rfc-editor.org/info/rfc2
	142" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2142.
	42.xml">		xml"/>
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
	<title>Mailbox Names for Common Services, Roles and Functions</title		xml"/>
	>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
	<author initials="D." surname="Crocker" fullname="D. Crocker">		xml"/>
	<organization/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.
	</author>		xml"/>
	<date year="1997" month="May"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.
	<abstract>		xml"/>
	<t>This specification enumerates and describes Internet mail addre		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.
	sses (mailbox name @ host reference) to be used when contacting personnel at an		xml"/>
	organization. [STANDARDS-TRACK]</t>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4880.
	</abstract>		xml"/>
	</front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.
	<seriesInfo name="RFC" value="2142"/>		xml"/>
	<seriesInfo name="DOI" value="10.17487/RFC2142"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6068.
	</reference>		xml"/>
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3966.
	119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21		xml"/>
	19.xml">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3339.
	<front>		xml"/>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5646.
	le>		xml"/>
	<author initials="S." surname="Bradner" fullname="S. Bradner">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2277.
	<organization/>		xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8615.
	<date year="1997" month="March"/>		xml"/>
	<abstract>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.
	<t>In many standards track documents several words are used to sig		xml"/>
	nify the requirements in the specification. These words are often capitalized.		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.
	This document defines these words as they should be interpreted in IETF document		xml"/>
	s. This document specifies an Internet Best Current Practices for the Internet		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.
	Community, and requests discussion and suggestions for improvements.</t>		xml"/>
	</abstract>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5198.
	</front>		xml"/>
	<seriesInfo name="BCP" value="14"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.
	<seriesInfo name="RFC" value="2119"/>		xml"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6960.
	</reference>		xml"/>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405.
	174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81		xml"/>
	74.xml">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>
	<date year="2017" month="May"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC5322" target="https://www.rfc-editor.org/info/rfc5
	322" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.53
	22.xml">
	<front>
	<title>Internet Message Format</title>
	<author initials="P." surname="Resnick" fullname="P. Resnick" role="
	editor">
	<organization/>
	</author>
	<date year="2008" month="October"/>
	<abstract>
	<t>This document specifies the Internet Message Format (IMF), a sy
	ntax for text messages that are sent between computer users, within the framewor
	k of "electronic mail" messages. This specification is a revision of Request Fo
	r Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "
	Standard for the Format of ARPA Internet Text Messages", updating it to reflect
	current practice and incorporating incremental changes that were specified in ot
	her RFCs. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5322"/>
	<seriesInfo name="DOI" value="10.17487/RFC5322"/>
	</reference>
	<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
	234" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.52
	34.xml">
	<front>
	<title>Augmented BNF for Syntax Specifications: ABNF</title>
	<author initials="D." surname="Crocker" fullname="D. Crocker" role="
	editor">
	<organization/>
	</author>
	<author initials="P." surname="Overell" fullname="P. Overell">
	<organization/>
	</author>
	<date year="2008" month="January"/>
	<abstract>
	<t>Internet technical specifications often need to define a formal
	syntax. Over the years, a modified version of Backus-Naur Form (BNF), called A
	ugmented BNF (ABNF), has been popular among many Internet specifications. The c
	urrent specification documents ABNF. It balances compactness and simplicity with
	reasonable representational power. The differences between standard BNF and AB
	NF involve naming rules, repetition, alternatives, order-independence, and value
	ranges. This specification also supplies additional rule definitions and encod
	ing for a core lexical analyzer of the type common to several Internet specifica
	tions. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="68"/>
	<seriesInfo name="RFC" value="5234"/>
	<seriesInfo name="DOI" value="10.17487/RFC5234"/>
	</reference>
	<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3
	986" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.39
	86.xml">
	<front>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>
	<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee
	">
	<organization/>
	</author>
	<author initials="R." surname="Fielding" fullname="R. Fielding">
	<organization/>
	</author>
	<author initials="L." surname="Masinter" fullname="L. Masinter">
	<organization/>
	</author>
	<date year="2005" month="January"/>
	<abstract>
	<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
	aracters that identifies an abstract or physical resource. This specification d
	efines the generic URI syntax and a process for resolving URI references that mi
	ght be in relative form, along with guidelines and security considerations for t
	he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
	rset of all valid URIs, allowing an implementation to parse the common component
	s of a URI reference without knowing the scheme-specific requirements of every p
	ossible identifier. This specification does not define a generative grammar for
	URIs; that task is performed by the individual specifications of each URI schem
	e. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
	</reference>
	<reference anchor="RFC4880" target="https://www.rfc-editor.org/info/rfc4
	880" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.48
	80.xml">
	<front>
	<title>OpenPGP Message Format</title>
	<author initials="J." surname="Callas" fullname="J. Callas">
	<organization/>
	</author>
	<author initials="L." surname="Donnerhacke" fullname="L. Donnerhacke
	">
	<organization/>
	</author>
	<author initials="H." surname="Finney" fullname="H. Finney">
	<organization/>
	</author>
	<author initials="D." surname="Shaw" fullname="D. Shaw">
	<organization/>
	</author>
	<author initials="R." surname="Thayer" fullname="R. Thayer">
	<organization/>
	</author>
	<date year="2007" month="November"/>
	<abstract>
	<t>This document is maintained in order to publish all necessary i
	nformation needed to develop interoperable applications based on the OpenPGP for
	mat. It is not a step-by-step cookbook for writing an application. It describe
	s only the format and methods needed to read, check, generate, and write conform
	ing packets crossing any network. It does not deal with storage and implementat
	ion questions. It does, however, discuss implementation issues necessary to avoi
	d security flaws.</t>
	<t>OpenPGP software uses a combination of strong public-key and sy
	mmetric cryptography to provide security services for electronic communications
	and data storage. These services include confidentiality, key management, authe
	ntication, and digital signatures. This document specifies the message formats
	used in OpenPGP. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4880"/>
	<seriesInfo name="DOI" value="10.17487/RFC4880"/>
	</reference>
	<reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7
	230" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
	30.xml">
	<front>
	<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Ro
	uting</title>
	<author initials="R." surname="Fielding" fullname="R. Fielding" role
	="editor">
	<organization/>
	</author>
	<author initials="J." surname="Reschke" fullname="J. Reschke" role="
	editor">
	<organization/>
	</author>
	<date year="2014" month="June"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
	on-level protocol for distributed, collaborative, hypertext information systems.
	This document provides an overview of HTTP architecture and its associated ter
	minology, defines the "http" and "https" Uniform Resource Identifier (URI) schem
	es, defines the HTTP/1.1 message syntax and parsing requirements, and describes
	related security concerns for implementations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7230"/>
	<seriesInfo name="DOI" value="10.17487/RFC7230"/>
	</reference>
	<reference anchor="RFC6068" target="https://www.rfc-editor.org/info/rfc6
	068" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.60
	68.xml">
	<front>
	<title>The 'mailto' URI Scheme</title>
	<author initials="M." surname="Duerst" fullname="M. Duerst">
	<organization/>
	</author>
	<author initials="L." surname="Masinter" fullname="L. Masinter">
	<organization/>
	</author>
	<author initials="J." surname="Zawinski" fullname="J. Zawinski">
	<organization/>
	</author>
	<date year="2010" month="October"/>
	<abstract>
	<t>This document defines the format of Uniform Resource Identifier
	s (URIs) to identify resources that are reached using Internet mail. It adds bet
	ter internationalization and compatibility with Internationalized Resource Ident
	ifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [ST
	ANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6068"/>
	<seriesInfo name="DOI" value="10.17487/RFC6068"/>
	</reference>
	<reference anchor="RFC3966" target="https://www.rfc-editor.org/info/rfc3
	966" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.39
	66.xml">
	<front>
	<title>The tel URI for Telephone Numbers</title>
	<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
	">
	<organization/>
	</author>
	<date year="2004" month="December"/>
	<abstract>
	<t>This document specifies the URI (Uniform Resource Identifier) s
	cheme "tel". The "tel" URI describes resources identified by telephone numbers.
	This document obsoletes RFC 2806. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3966"/>
	<seriesInfo name="DOI" value="10.17487/RFC3966"/>
	</reference>
	<reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3
	339" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.33
	39.xml">
	<front>
	<title>Date and Time on the Internet: Timestamps</title>
	<author initials="G." surname="Klyne" fullname="G. Klyne">
	<organization/>
	</author>
	<author initials="C." surname="Newman" fullname="C. Newman">
	<organization/>
	</author>
	<date year="2002" month="July"/>
	<abstract>
	<t>This document defines a date and time format for use in Interne
	t protocols that is a profile of the ISO 8601 standard for representation of dat
	es and times using the Gregorian calendar.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3339"/>
	<seriesInfo name="DOI" value="10.17487/RFC3339"/>
	</reference>
	<reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5
	646" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.56
	46.xml">
	<front>
	<title>Tags for Identifying Languages</title>
	<author initials="A." surname="Phillips" fullname="A. Phillips" role
	="editor">
	<organization/>
	</author>
	<author initials="M." surname="Davis" fullname="M. Davis" role="edit
	or">
	<organization/>
	</author>
	<date year="2009" month="September"/>
	<abstract>
	<t>This document describes the structure, content, construction, a
	nd semantics of language tags for use in cases where it is desirable to indicate
	the language used in an information object. It also describes how to register
	values for use in language tags and the creation of user-defined extensions for
	private interchange. This document specifies an Internet Best Current Practice
	s for the Internet Community, and requests discussion and suggestions for improv
	ements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="47"/>
	<seriesInfo name="RFC" value="5646"/>
	<seriesInfo name="DOI" value="10.17487/RFC5646"/>
	</reference>
	<reference anchor="RFC2277" target="https://www.rfc-editor.org/info/rfc2
	277" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.22
	77.xml">
	<front>
	<title>IETF Policy on Character Sets and Languages</title>
	<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
	<organization/>
	</author>
	<date year="1998" month="January"/>
	<abstract>
	<t>This document is the current policies being applied by the Inte
	rnet Engineering Steering Group (IESG) towards the standardization efforts in th
	e Internet Engineering Task Force (IETF) in order to help Internet protocols ful
	fill these requirements. This document specifies an Internet Best Current Pract
	ices for the Internet Community, and requests discussion and suggestions for imp
	rovements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="18"/>
	<seriesInfo name="RFC" value="2277"/>
	<seriesInfo name="DOI" value="10.17487/RFC2277"/>
	</reference>
	<reference anchor="RFC8615" target="https://www.rfc-editor.org/info/rfc8
	615" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.86
	15.xml">
	<front>
	<title>Well-Known Uniform Resource Identifiers (URIs)</title>
	<author initials="M." surname="Nottingham" fullname="M. Nottingham">
	<organization/>
	</author>
	<date year="2019" month="May"/>
	<abstract>
	<t>This memo defines a path prefix for "well-known locations", "/.
	well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
	<t>In doing so, it obsoletes RFC 5785 and updates the URI schemes
	defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track UR
	I schemes that support well-known URIs in their registry.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8615"/>
	<seriesInfo name="DOI" value="10.17487/RFC8615"/>
	</reference>
	<reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7
	231" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
	31.xml">
	<front>
	<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
	</title>
	<author initials="R." surname="Fielding" fullname="R. Fielding" role
	="editor">
	<organization/>
	</author>
	<author initials="J." surname="Reschke" fullname="J. Reschke" role="
	editor">
	<organization/>
	</author>
	<date year="2014" month="June"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless \%applica
	tion- level protocol for distributed, collaborative, hypertext information syste
	ms. This document defines the semantics of HTTP/1.1 messages, as expressed by r
	equest methods, request header fields, response status codes, and response heade
	r fields, along with the payload of messages (metadata and body content) and mec
	hanisms for content negotiation.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7231"/>
	<seriesInfo name="DOI" value="10.17487/RFC7231"/>
	</reference>
	<reference anchor="RFC2046" target="https://www.rfc-editor.org/info/rfc2
	046" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.20
	46.xml">
	<front>
	<title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media
	Types</title>
	<author initials="N." surname="Freed" fullname="N. Freed">
	<organization/>
	</author>
	<author initials="N." surname="Borenstein" fullname="N. Borenstein">
	<organization/>
	</author>
	<date year="1996" month="November"/>
	<abstract>
	<t>This second document defines the general structure of the MIME
	media typing system and defines an initial set of media types. [STANDARDS-TRACK
	]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="2046"/>
	<seriesInfo name="DOI" value="10.17487/RFC2046"/>
	</reference>
	<reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3
	629" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.36
	29.xml">
	<front>
	<title>UTF-8, a transformation format of ISO 10646</title>
	<author initials="F." surname="Yergeau" fullname="F. Yergeau">
	<organization/>
	</author>
	<date year="2003" month="November"/>
	<abstract>
	<t>ISO/IEC 10646-1 defines a large character set called the Univer
	sal Character Set (UCS) which encompasses most of the world's writing systems.
	The originally proposed encodings of the UCS, however, were not compatible with
	many current applications and protocols, and this has led to the development of
	UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the
	full US-ASCII range, providing compatibility with file systems, parsers and othe
	r software that rely on US-ASCII values but are transparent to other values. Th
	is memo obsoletes and replaces RFC 2279.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="63"/>
	<seriesInfo name="RFC" value="3629"/>
	<seriesInfo name="DOI" value="10.17487/RFC3629"/>
	</reference>
	<reference anchor="RFC5198" target="https://www.rfc-editor.org/info/rfc5
	198" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.51
	98.xml">
	<front>
	<title>Unicode Format for Network Interchange</title>
	<author initials="J." surname="Klensin" fullname="J. Klensin">
	<organization/>
	</author>
	<author initials="M." surname="Padlipsky" fullname="M. Padlipsky">
	<organization/>
	</author>
	<date year="2008" month="March"/>
	<abstract>
	<t>The Internet today is in need of a standardized form for the tr
	ansmission of internationalized "text" information, paralleling the specificatio
	ns for the use of ASCII that date from the early days of the ARPANET. This docu
	ment specifies that format, using UTF-8 with normalization and specific line-end
	ing sequences. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5198"/>
	<seriesInfo name="DOI" value="10.17487/RFC5198"/>
	</reference>
	<reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6
	125" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.61
	25.xml">
	<front>
	<title>Representation and Verification of Domain-Based Application S
	ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
	tificates in the Context of Transport Layer Security (TLS)</title>
	<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
	">
	<organization/>
	</author>
	<author initials="J." surname="Hodges" fullname="J. Hodges">
	<organization/>
	</author>
	<date year="2011" month="March"/>
	<abstract>
	<t>Many application technologies enable secure communication betwe
	en two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX
	) certificates in the context of Transport Layer Security (TLS). This document s
	pecifies procedures for representing and verifying the identity of application s
	ervices in such interactions. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6125"/>
	<seriesInfo name="DOI" value="10.17487/RFC6125"/>
	</reference>
	<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6
	960" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.69
	60.xml">
	<front>
	<title>X.509 Internet Public Key Infrastructure Online Certificate S
	tatus Protocol - OCSP</title>
	<author initials="S." surname="Santesson" fullname="S. Santesson">
	<organization/>
	</author>
	<author initials="M." surname="Myers" fullname="M. Myers">
	<organization/>
	</author>
	<author initials="R." surname="Ankney" fullname="R. Ankney">
	<organization/>
	</author>
	<author initials="A." surname="Malpani" fullname="A. Malpani">
	<organization/>
	</author>
	<author initials="S." surname="Galperin" fullname="S. Galperin">
	<organization/>
	</author>
	<author initials="C." surname="Adams" fullname="C. Adams">
	<organization/>
	</author>
	<date year="2013" month="June"/>
	<abstract>
	<t>This document specifies a protocol useful in determining the cu
	rrent status of a digital certificate without requiring Certificate Revocation L
	ists (CRLs). Additional mechanisms addressing PKIX operational requirements are
	specified in separate documents. This document obsoletes RFCs 2560 and 6277. I
	t also updates RFC 5912.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6960"/>
	<seriesInfo name="DOI" value="10.17487/RFC6960"/>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="ISO.8601">		<reference anchor="ISO.8601-1">
	<front>		<front>
	<title>ISO/IEC 8601, Date and time - Representations for information interchange - Parts 1 and 2</title>		<title>Date and time - Representations for information interchange - Part 1: Basic rules</title>
	<author>		<author>
	<organization>International Organization for Standardization (ISO) </organization>		<organization>ISO</organization>
	</author>		</author>
	<date year="2019"/>		<date month="February" year="2019"/>
	</front>		</front>
			<seriesInfo name="ISO" value="8601-1:2019"/>
	</reference>		</reference>
	<reference anchor="ISO.29147.2018">
			<reference anchor="ISO.8601-2">
	<front>		<front>
	<title>ISO/IEC 29147:2018, Information technology - Security techniq ues - Vulnerability disclosure</title>		<title>Date and time - Representations for information interchange - Part 2: Extensions</title>
	<author>		<author>
	<organization>International Organization for Standardization (ISO) </organization>		<organization>ISO</organization>
	</author>		</author>
	<date year="2018"/>		<date month="February" year="2019"/>
	</front>		</front>
			<seriesInfo name="ISO" value="8601-2:2019"/>
	</reference>		</reference>
	<reference anchor="CERT.CVD">
			<reference anchor="ISO.29147.2018">
	<front>		<front>
	<title>The CERT Guide to Coordinated Vulnerability Disclosure (CMU/S EI-2017-SR-022)</title>		<title>Information technology - Security techniques - Vulnerability disclosure</title>
	<author>		<author>
	<organization>Software Engineering Institute, Carnegie Mellon Univ		<organization>ISO</organization>
	ersity</organization>
	</author>
	<date year="2017"/>
	</front>
	</reference>
	<reference anchor="RFC3013" target="https://www.rfc-editor.org/info/rfc3
	013" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.30
	13.xml">
	<front>
	<title>Recommended Internet Service Provider Security Services and P
	rocedures</title>
	<author initials="T." surname="Killalea" fullname="T. Killalea">
	<organization/>
	</author>
	<date year="2000" month="November"/>
	<abstract>
	<t>The purpose of this document is to express what the engineering
	community as represented by the IETF expects of Internet Service Providers (ISP
	s) with respect to security. This document specifies an Internet Best Current P
	ractices for the Internet Community, and requests discussion and suggestions for
	improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="46"/>
	<seriesInfo name="RFC" value="3013"/>
	<seriesInfo name="DOI" value="10.17487/RFC3013"/>
	</reference>
	<reference anchor="RFC2350" target="https://www.rfc-editor.org/info/rfc2
	350" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.23
	50.xml">
	<front>
	<title>Expectations for Computer Security Incident Response</title>
	<author initials="N." surname="Brownlee" fullname="N. Brownlee">
	<organization/>
	</author>
	<author initials="E." surname="Guttman" fullname="E. Guttman">
	<organization/>
	</author>
	<date year="1998" month="June"/>
	</front>
	<seriesInfo name="BCP" value="21"/>
	<seriesInfo name="RFC" value="2350"/>
	<seriesInfo name="DOI" value="10.17487/RFC2350"/>
	</reference>
	<reference anchor="RFC2196" target="https://www.rfc-editor.org/info/rfc2
	196" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21
	96.xml">
	<front>
	<title>Site Security Handbook</title>
	<author initials="B." surname="Fraser" fullname="B. Fraser">
	<organization/>
	</author>
	<date year="1997" month="September"/>
	<abstract>
	<t>This handbook is a guide to developing computer security polici
	es and procedures for sites that have systems on the Internet. The purpose of t
	his handbook is to provide practical guidance to administrators trying to secure
	their information and services. The subjects covered include policy content an
	d formation, a broad range of technical system and network security topics, and
	security incident response. This memo provides information for the Internet com
	munity. It does not specify an Internet standard of any kind.</t>
	</abstract>
	</front>
	<seriesInfo name="FYI" value="8"/>
	<seriesInfo name="RFC" value="2196"/>
	<seriesInfo name="DOI" value="10.17487/RFC2196"/>
	</reference>
	<reference anchor="RFC7485" target="https://www.rfc-editor.org/info/rfc7
	485" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.74
	85.xml">
	<front>
	<title>Inventory and Analysis of WHOIS Registration Objects</title>
	<author initials="L." surname="Zhou" fullname="L. Zhou">
	<organization/>
	</author>
	<author initials="N." surname="Kong" fullname="N. Kong">
	<organization/>
	</author>
	<author initials="S." surname="Shen" fullname="S. Shen">
	<organization/>
	</author>
	<author initials="S." surname="Sheng" fullname="S. Sheng">
	<organization/>
	</author>
	<author initials="A." surname="Servin" fullname="A. Servin">
	<organization/>
	</author>
	<date year="2015" month="March"/>
	<abstract>
	<t>WHOIS output objects from registries, including both Regional I
	nternet Registries (RIRs) and Domain Name Registries (DNRs), were collected and
	analyzed. This document describes the process and results of the statistical an
	alysis of existing WHOIS information. The purpose of this document is to build a
	n object inventory to facilitate discussions of data objects included in Registr
	ation Data Access Protocol (RDAP) responses.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7485"/>
	<seriesInfo name="DOI" value="10.17487/RFC7485"/>
	</reference>
	<reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc7
	93" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.079
	3.xml">
	<front>
	<title>Transmission Control Protocol</title>
	<author initials="J." surname="Postel" fullname="J. Postel">
	<organization/>
	</author>		</author>
	<date year="1981" month="September"/>		<date year="2018" month="October"/>
	</front>		</front>
	<seriesInfo name="STD" value="7"/>		<seriesInfo name="ISO/IEC" value="29147:2018"/>
	<seriesInfo name="RFC" value="793"/>		</reference>
	<seriesInfo name="DOI" value="10.17487/RFC0793"/>
	</reference>		<reference anchor="CERT.CVD">
	<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
	126" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
	26.xml">
	<front>		<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs		<title>The CERT Guide to Coordinated Vulnerability Disclosure</title
	</title>		>
	<author initials="M." surname="Cotton" fullname="M. Cotton">		<author>
	<organization/>		<organization>Software Engineering Institute</organization>
	</author>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>
	<author initials="T." surname="Narten" fullname="T. Narten">
	<organization/>
	</author>		</author>
	<date year="2017" month="June"/>		<date year="2017" month="August"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in th
	ese fields do not have conflicting uses and to promote interoperability, their a
	llocations are often coordinated by a central record keeper. For IETF protocols
	, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This documen
	t defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Considerati
	ons is clear and addresses the various issues that are likely in the operation o
	f a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>		</front>
	<seriesInfo name="BCP" value="26"/>		<refcontent>Carnegie Mellon University, CMU/SEI-2017-SR-022</refcontent>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	</reference>		</reference>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3013.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2350.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2196.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7485.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.
			xml"/>
	</references>		</references>
	</references>		</references>
	<section anchor="note-to-readers-1" numbered="true" toc="default">
	<name>Note to Readers</name>		<section anchor="contributors" numbered="false" toc="default">
	<ul empty="true" spacing="normal">		<name>Acknowledgments</name>
	<li>		<t>The authors would like to acknowledge the help provided during the
	<strong>Note to the RFC Editor:</strong> Please remove this section p		development of this document by <contact fullname="Tom Hudson"/>, <contact fulln
	rior		ame="Jobert Abma"/>,
	to publication.</li>		<contact fullname="Gerben Janssen van Doorn"/>, <contact fullname="Austin Heap"/
	</ul>		>, <contact fullname="Stephane Bortzmeyer"/>, <contact fullname="Max Smith"/>, <
	<t>Development of this draft takes place on Github at https://github.com/s		contact fullname="Eduardo Vela"/>, and <contact fullname="Krzysztof Kotowicz"/>.
	ecuritytxt/security-txt</t>		</t>
	</section>		<t>The authors would also like to acknowledge the feedback provided by mul
	<section anchor="document-history" numbered="true" toc="default">		tiple members of the IETF's
	<name>Document History</name>		LAST CALL, SAAG, and SECDISPATCH lists.</t>
	<ul empty="true" spacing="normal">		<t><contact fullname="Yakov Shafranovich"/> would like to also thank L.T.S. (for
	<li>		everything).</t>
	<strong>Note to the RFC Editor:</strong> Please remove this section p
	rior
	to publication.</li>
	</ul>
	<section anchor="since-draft-foudil-securitytxt-00" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-00</name>
	<ul spacing="normal">
	<li>Moved to use IETF's markdown tools for draft updates</li>
	<li>Added table of contents and a fuller list of references</li>
	<li>Moved file to .well-known URI and added IANA registration (#3)</li
	>
	<li>Added extensibility with an IANA registry for fields (#34)</li>
	<li>Added text explaining relationship to RFC 2142 / security@ email a
	ddress (#25)</li>
	<li>Scope expanded to include internal hosts, domains, IP addresses an
	d file systems</li>
	<li>Support for digital signatures added (#19)</li>
	</ul>
	<t>The full list of changes can be viewed via the IETF document tracker:
	https://tools.ietf.org/html/draft-foudil-securitytxt-01</t>
	</section>
	<section anchor="since-draft-foudil-securitytxt-01" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-01</name>
	<ul spacing="normal">
	<li>Added appendix with pointer to Github and document history</li>
	<li>Added external signature file to the well known URI registry (#59)
	</li>
	<li>Added policy field (#53)</li>
	<li>Added diagram explaining the location of the file on public vs. in
	ternal systems</li>
	<li>Added recommendation that external signature files should use HTTP
	S (#55)</li>
	<li>Added recommendation that organizations should monitor their secur
	ity.txt files (#14)</li>
	</ul>
	<t>The full list of changes can be viewed via the IETF document tracker:
	https://tools.ietf.org/html/draft-foudil-securitytxt-02</t>
	</section>
	<section anchor="since-draft-foudil-securitytxt-02" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-02</name>
	<ul spacing="normal">
	<li>Use "mailto" and "tel" (#62)</li>
	<li>Fix typo in the "Example" section (#64)</li>
	<li>Clarified that the root directory is a fallback option (#72)</li>
	<li>Defined content-type for the response (#68)</li>
	<li>Clarify the scope of the security.txt file (#69)</li>
	<li>Cleaning up text based on the NITS tools suggestions (#82)</li>
	<li>Added clarification for newline values</li>
	<li>Clarified the encryption field language, added examples
	of DNS-stored encryption keys (#28 and #94)</li>
	<li>Added "Hiring" field</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-03" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-03</name>
	<ul spacing="normal">
	<li>Added "Hiring" field to the registry section</li>
	<li>Added an encryption example using a PGP fingerprint (#107)</li>
	<li>Added reference to the mailing list (#111)</li>
	<li>Added a section referencing related work (#113)</li>
	<li>Fixes for idnits (#82)</li>
	<li>Changing some references to informative instead of normative</li>
	<li>Adding "Permission" field (#30)</li>
	<li>Fixing remaining ABNF issues (#83)</li>
	<li>Additional editorial changes and edits</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-04" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-04</name>
	<ul spacing="normal">
	<li>Addressing IETF feedback (#118)</li>
	<li>Case sensitivity clarification (#127)</li>
	<li>Syntax fixes (#133, #135 and #136)</li>
	<li>Removed permission field (#30)</li>
	<li>Removed signature field and switched to inline signatures (#93 and
	#128)</li>
	<li>Adding canonical field (#100)</li>
	<li>Text and ABNF grammar improvements plus ABNF changes for comments
	(#123)</li>
	<li>Changed ".security.txt" to "security.txt" to be consistent</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-05" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-05</name>
	<ul spacing="normal">
	<li>Changing HTTPS to MUST (#55)</li>
	<li>Adding language recommending encryption for email reports (#134)</
	li>
	<li>Added language handling redirects (#143)</li>
	<li>Expanded security considerations section and fixed typos (#30, #73
	, #103, #112)</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-06" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-06</name>
	<ul spacing="normal">
	<li>Fixed ABNF grammar for non-chainable fields (#150)</li>
	<li>Clarified ABNF grammar (#152)</li>
	<li>Clarified redirect logic (#143)</li>
	<li>Clarified comments (#158)</li>
	<li>Updated references and template for well-known URI to RFC 8615</li
	>
	<li>Fixed nits from the IETF validator</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-07" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-07</name>
	<ul spacing="normal">
	<li>Addressing AD feedback (#165)</li>
	<li>Fix for ABNF grammar in lang-values (#164)</li>
	<li>Fixing idnits warnings</li>
	<li>Adding guidance for designated experts</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-08" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-08</name>
	<ul spacing="normal">
	<li>Added language and example regarding URI encoding (#176)</li>
	<li>Add "Expires" field (#181)</li>
	<li>Changed language from "directive" to "field" (#182)</li>
	<li>Addressing last call feedback (#179, #180 and #183)</li>
	<li>Clarifying order of fields (#174)</li>
	<li>Revert comment/field association (#158)</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-09" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-09</name>
	<ul spacing="normal">
	<li>Adjust ABNF to allow blank lines between directives (#191)</li>
	<li>Make "Expires" field required (#190)</li>
	<li>Adding a warning about the well-known URI namespace (#188)</li>
	<li>Adding scope language around products/services (#185)</li>
	<li>Addressing last call feedback (#189)</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-10" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-10</name>
	<ul spacing="normal">
	<li>Changes addressing IESG feedback</li>
	<li>Removed language regarding file systems (#201)</li>
	<li>Adding language to explain alignment with the CERT CVD guide (#202
	)</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-11" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-11</name>
	<ul spacing="normal">
	<li>Changed date format from RFC 5322 to RFC 3339 / ISO 8601 (#208)</l
	i>
	<li>Added clarification in "canonical" field regarding the URI used to
	retrieve the file</li>
	<li>Added language about machine-parsability</li>
	<li>Added quotes around "security.txt" for consistency</li>
	</ul>
	</section>
	<section anchor="since-draft-foudil-securitytxt-12" numbered="true" toc="d
	efault">
	<name>Since draft-foudil-securitytxt-12</name>
	<ul spacing="normal">
	<li>TBD</li>
	</ul>
	<t>Full list of changes can be viewed via the IETF document tracker:
	https://tools.ietf.org/html/draft-foudil-securitytxt</t>
	</section>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAKgq62AAA+19aXPbVrLod/yK86iaiuRLUiS1K3PnRpZkWxNb1ohy8lK5
	qVcgcUhiDAIcLJIVl99vf72dBSAoK5m6M/nwVBVHwnKW7j69d6PX6wVlXCb6
	VJ2pV3Gi1assX4alKjN1FkcqTtVYT6s8Lh/VD1WS6jycxAn+dREX0yQrqlwH
	4WSS6/tTVciT/fJTGUTZNA2XMG6Uh7OyN8uqKE565hF4ojfcC+JVfqrKvCrK
	0WBwMhgF07A8hUlnWbCKTwOliiwvcz0rTtU3j7r4Bq+UeTwtvb8fl/UHymxq
	/gircpHlp0EPhoQnLvuwO1wGPMVru4weYIf2ol6GcXKqpllahtPyOx1l9zqf
	JdlDf5otzSg/9dV4Ec7yMM3u4+nCjvVT+DG7b97K8nmYxr+GZZylp+o6ni/K
	h7CcLtT540TnBhpu6kcc5D9iXc6+S+3DU/9ZWkqAIEI8xfcawaTU1fh9//hw
	MOS/AAqMVLi8e3V5rvBWV12EpVZhGsHdpVY9datXuS407BbXVygYU9mRsxR+
	L3U+XYTpHJ++CfOyUEMaYCTTGAgr+wM7hmnxxZQGCRP13gMCzTEuYYwwj8y1
	bVjmjowRwRpP1WgwPLH7Gp0M94/6cOl4w+7ogVN8oAtTu/WXerpIsySbP8Ly
	LR3T1fgflS7gap2oI0fU/+P7O6YL55e3d/3zHy4aO7tbaLqlXldxpPE0nmcZ
	DAhz6mjjSVTb5+8+7I4vr3ow/lFvfNsbjEY7T29lnM2AyuDdy3Qep1rncTqH
	/RWwkKrUXXUe5qmex1q900kCe/mQAs3lBVNtbUNHQRD0ej0VTuCMwvkJflzo
	1DIFde8tOgbY45wIbzxjsKfJY4C0GAK9wfBdtcqzlc5VrlfAAnBNSIepTvhF
	WDSMnYTTj3Crr87gKjxaVEnZDZoTLcNHNdEq0bNSVSkPqKM+wDguFLCpagkn
	QEV6BtvHcZbhdAG/9lZhXoQTYIlMUMF2x2dwnR3EykInq9ohhxF1Mc1jmLBc
	6DivbdsnMNggwCie6iKAcZbhR63iUumwiGHXSEQeNHAmXncTin0G+TKOokQH
	wRZSZp5F1RTXAn9vqXcZMAlaWlfd5DEM/GOWf6RDPJ4CiNXnraV95EsQvAvT
	R4c0fxE6nWYVEr4C7Fey2we4RVt9JLxUKUIscOvdiH54pA63iZ6GVUFjwUAw
	WJBmbeiHF4VB46Mqe4BhgR4AcYAwAGiVhDmSUlblU+Z2MI7P1cJ7YLWE2HCS
	VTzKM7AEUxQVcG6aEOAONIcEChukUfdxDZ8//9ftq/PRcH/05UtXdgJEFqZK
	f4oL3keW3gO9IXrgharAa7iC//7z+PL8w+3V3U/fRRkIg/S//8JCQYVRBNth
	7gzMf1ml8VRglus5spl0Hlg4x0UBnA2pG6S4mwzP0z2wkkJlaQK4UjhxAueb
	5uhNwkJHgcAYd1KbiDbKq+oSRKMMBkqz0owahOoBThmukB9jKBGyVtUkiYtF
	HQUG8HHuKMRjvhbqAOc7Qw8qTAqHe7c1wEMuZy6iJTB31iWw/BzksAa6p1XC
	eoAT3xQ7ID4t3kYOb3uD4R7iDcc4z5arCmndio2rdApjAKe41cUKZtXqTodL
	GPJ8fHV7Vx90r+8NO9o7GHz5QnDDkeHwANUCRMMygxV5bx3QW4EhopPDL1+I
	tSH0+eLR/vFBnbJ8kPgQFsQQX70F/k2CygIGr6AiBVjcvr26LXYEq4S63N3E
	9QomYTtXN4HQogYGDfIkS7NlVhWggxWlXqq0Wk4IyGfj62Kn64+JKhIQ5Zvs
	QQO77wLtpMjEA9gIHnng4wmdfCZfnGyRPbSzoSmcpiSboirTsvEAJ/36aead
	1fgPEm0OROKYbVOSADFegVLhi42uetAiOlACxbjE7roEwUUtM1iA/gRyq4jx
	GhyYYH0VxN3M0dO/79DQdDB8k1cu++o9Ug4suIRDTzjdBKqApGxVFqR+AGIK
	EhbwRm3/fSClkE4WPk8SIg/nQHY8MwpkleGcgXmjYC4aFkDSdeUOzkiGhG5U
	IqB+y2X9q13Vqa86lwPZgd9mNXFJW1yxQGxKoOBhAejCQ5TrhNSqCYA3IjYN
	T8/ybOmPAsfmAQUn6MRgrxCuEMyALBh/GSP7fNATPNxwADqxYRZ2bTt9UuqW
	GplsXCyFasjEqoEUV4SKdwqnFwUpaBIgFpl3ICKQIAAi25uAABNdzVS8XCUa
	h0Me8xCmJQ5VlfDsr5rncythtb+x4C4L9WKRVUmEiwgfWPFCeRSz5uukDuIa
	OazRgYCOqqLg3X3+7IBEOEU41HUpNUPT09u44o3ji7yNMH8UWV4i7YD8qiai
	owakLK1AGaQn+WgTnZPomSqjDKAqCBOEBPbJY+PkOVm68YgpXy6BbnWn82XM
	Bgbv6iNADKgkKlTn3YfxXafL/1fX7+n328u/fbi6vbzA38dvzt6+tb/wEwH8
	8f7DW7mPv7k3z9+/e3d5fcEvw1XVuPTu7KcOsdyg8/7m7ur99dnbzjptIQoZ
	tGTbgeBEwg+d1ooYC16e36jhPiDuf5EgGp7A0eQ/jodH+/AHaH2iCZA2wX+y
	ErhaAafGicMkAXN+FZcgo7o4BZDSQ6pQcgkNwAKWquN4ewfwnTP9RaQVl/IQ
	gBPOSoRP4Jwd0eHzDpPXGhvBh+p8xE3nI702ofImBA4DZJjlneC5E3gz+EcP
	VzhNKtS7AB6soWok8/ssuWdgf0X9zIDaiNzUdVYS8oTjBsFf1IsX5iKOAvhR
	l3A2wcp78UKpmwSsCQ10vQQTi+nAaBorNATgfaOesZoHs1yAeE6yFdGK5fXo
	wAEZ/REWTqcMkK5ex+Wimih01yzKclWc7u7O6RL6J3Y9N4/9vYdeIdgGAmq8
	0tN4JtMi7NotsRLEJbMGplmanXhKqD6mSE2kCOAYJaq7VsddF5vPUAkaNkSN
	PTAF8aAWMIZptYp7OvezDGzmB0LO2cvrV2qeh8tlmHu8H7S9cJLOUNO788f0
	GSEZma26EB68QDaDhsQmawsw+/LRU5m7LElkLlTOogZH7qu3AlraDUt/MtkN
	o+CjYRAgZwBGc0gj1SMG1roENSBeoSUd6wRO2gNQCuBgBsIaEX4fJmSynPF9
	916oOri2jrKimpedFyUhilHGL+Hxwrtoh1Qrwz2mGfostlEk6E8hHsxT1Tln
	lei0syNKOSKJxy4e4dYnix98r0Pj93ghNR3/sH8ckJaPnPFgbzRCLL6i1ZC+
	S/CawhnswWZQ7UN3ndoO64bjqL+n3CijPeCvO0xuHQIMMikabIbmCAPATNHc
	GdpyZXZqMPmd3MEzuXGzQW2zVQqqP2hLcDSixnZH/QO1tt07Q0cgfzxrBF6c
	JGH6USV4lFGPk1XTsQgT0k5JaSgEi7QdXGHI9BBsQJp6co9IRC2qRYBGwyK8
	xxlUlSbxMka5xwYLzs+E2VeXcJRrK2VxBgwmRjUQOQ5sqK8+pAma5AXzMRiK
	FI4H0HBQsXBIItiSttQN7ClgeldGMyBFZ8FaSZnNNakuuHljpPNY/UAmdVOB
	TCQzQViim2yNl9EIXXtYCFm0Nbcq9AmTieNrjk31j9hsAfTITNCe6CUYMwbx
	H26vCnFsAJ1PYaQeGgaoWrUQ/9DR1N7J8SERP+pWYICTuQCkkz4S1GEV8zhN
	cRhiIDh9Z6ujtv/0abS3g4GASZYwVNf1m5DMKrRY6GjhWq2M0+YeuQrNNtAP
	djY+v7pCq+QD2GNZRHhCeaHZcIdXA5h82Du6JNL906fjQe8V/qgcneYoLys+
	a2U4wYUOTvgYFiuUo7jywY43KGz9Uig+CP6v/SGpiUKhtg/vPgLsLYJorAHp
	6FiAgcDQFsARTECcKB0TcRH4YKQwz2Ow1kCkwHlnRk/PzzQ7g8xWt89v375S
	u7C/wQX+c7aDMPl7BWc3dG+4faht8/iZYPMinqMiCAQ9T0NkLurzlv39CxAd
	mT2eSsuUFrbaCRN0HNN4oHviKLBapjc43e9XOr15faOmoP3kJIvcnE0911Dh
	kaPB/ePjAfI18l1HzVUzS0dzrIveWnHABGvrrlsW4tUEHhamGRr2SUfOoTkO
	YCKZW3AAuqDNVKQwZg/GPbi2FFQM0KWPAp1cBfiUkcbudCaobNNm4lIECbwI
	pBHPHs3YaLWQiQl35hr1BhnOTuZ2i4ybVNYWfeSbwliPsehZxrNNmpaZaqLR
	yKIJSdGJkHbQH0QGBEUDmWguxVnCY33e0v7fQDRvYxh6iec0MzwT1DO2y0EV
	LDOQ/kVXdDVW3fCAp9ralzQi2tkYhOCoGNyYxewURldVj8JfCCkQZ1EBBo1l
	fcabRkIw1zCD7ga1NeL+rCPuPg6RPq/Ors+Mi409psJCiThJErNmZZ4hJyDs
	UR7jyxQywRGN3otWguF9gbHGEa4rNtVhkZnzz6j6MhFgxC/JLckXu344hkcG
	akAfVugWQxiLMrLK9acVGBJxiWeyWqGBxv4ypqikW3dJiGDpkJEP2lF+T8FM
	5KoPuKXHrIKBuwEGbuC4wgC1W+F0qlfipCHkg6XlDhO6SgdHJ3tWmLBSdmHl
	I0iVNWFalChJu6RIyvaMLGmDJ467pc6maIckOpqzb+vzVli/8kW0Yj7vRmAX
	zDc/0iEGOQ0Y4UCKjQj7wEeek+tpNgeW4hxBsQmOFayF0Sh0ttgNBsgGUhI4
	J6hntZoQREAmKLbRgAjY15UkYE3lpHGQjw3shliYBToXa1zPqQ4gZ/SsSlAn
	J82rJeLiG2y8BwkbsG5Djll8HwT6Pfl4KmboJbqOSWuxNlkTzg96gioJmTzE
	BQWrc6QnFIQdY8B2gnX15Mh48lE4HI32BkxTrVK6QQzOMvZU1N0F0Fcvm/Vm
	oO/2F+UyqclxGdfhoUFOhOX6rD8C7QiOP4orABVvdhUaEeJhHN7epvDwYL83
	PNhRr3J8/EKncUEpAbMENo/SPM+KokfRChSZK4xemTeHvcFoR50lGFz5WwVK
	mcIA+9/eAuD/zqCjJw97w1FvtL+j/potUvWymi4wVgdPAgt4aobD3gBeBc3o
	LE1DdQu23zID+uuBco+cQmMcLJ3F8yqXPAUMGjT0IdAgjUiFU+nE64bzSFqg
	fYFUWBva3OSs5ChE1HWe5KqoWCkBQQvkiFIDkdJpI4T+gwZKIDfGbt30/lcT
	848LcrG0g6VNCwN9MY81+q+IAYdqDqybFP+g4boAIyN5FKIseeVm0WL5+Hq6
	90KAbLiBEGRi8BTuk5Vv1m8wIGfZmbhNUeUCYeu5qkmv8JzeJgoRtqhWTpI4
	HfXLjtVmUO2PdEnOX0k0YTB5Bldt6aQ6rVA8ontojVuxJVaYjbUqvextxT3j
	eKKtBQYRvADrzwFpXIcVimy3IpZuqGXqVMwfsoYKX21UzgGNaCLwaTBC/WNm
	T5hjdQ8PD/3nUHnbu3hq+Hw/b4i1Ay+hLjju/NtG4ZvaoLqIP0tARmAiAXEW
	hklAsKK5mclgKSmtB+zR3F4tULEVPwNgcBfNegwUidDHI9sSxWSJbnweHc8j
	EYjvBL2hnLulNpEMxYG+wkeCr/ORFpu9nY/YSHkNCtpqAsYM8iP3XhBMhg/2
	3dCcSCHOdfKarLlV8TRYp50z7Zzbqule6DNJLHWYCvbFayaxhVKDdUajAj2g
	ubREviFBuOCBUprI60PmU3OrdEh1on28c/TD2ykv53BwePzlS8ChBF7f4aE1
	PUu746yOxBY6C+J26xk0wPxxJToV8wzH2dxNFgKkQoKWqSNUHM3pJwZtmAlp
	Ycblhz7YbAoYJ0XT+GZXpHqCcA9QAGYRp5IQFQM58rbkbMPYgETjicbharvy
	0q0abszmVGp9qjqXeobncONDfxq9hP/Dv+TC0lH7S4Dy0/8YYtZd7+DgAPSj
	0Z672Sb8bVDErHhNE0SGdukQCNavQ9hmtuahHE1tJIOgVe1vsDl5T0f1xJ++
	+l4/Ok9l4KJ7HklSXmypw2gT0QbGjgrpYK0ykPnke0Djx7osnLqFK0eH7UQ7
	TePfoBQ96TOxrhcErIhNWHfdUaJ8R0nw+xwlno+55i0JPG9JTQMifsVh8qJa
	impAkMMx4yJodfWsK0HOiGSe5alCzgAiR7NzuuEMLr1OlENED4v1uuHiqLv9
	jKzmqx4MuCbqnz813L25vIa731/+pC6ux2RF59HmZURpcXoQjaK9o3BydBjt
	H0V7h/3/k8EUsBhci7e+/yofV/o/3QTPXGPTQsd4AcYWQDrMURGGs7F5fbKS
	/dkqPz2YjSJ9cDAaTg/3wuPBMJwcnEynk8PBXrR/Eun9/cnoZDgYzNa5yqdV
	jK5MdKjRb0/ZRFEtZZxjUGzuyN3QOMxNKkvTXAqMWup5UQogNR5W+BDS67qM
	osfwOKq7zeKQlSZgXUE4nVKO9NwExG2+2yrPaBV0zk2qPMbxW+Ty3t7eCYrh
	DS5py+OC+koow5gVStTHHplPykLEXYEM7z6LZf8pB/Y90PvBMU/Bs+Fk1MWF
	BVM2Gc2VARXVBZ4gGJOyR0M0wfeGd8Pj072j08HRr2vk8CamlO/PWwv65Yvk
	5/DljoOzTUJCx5UHZM6U+KawjK5n8qn+noGamxXscfuXM3Bvn7yXdi4Diyza
	pe9NBgYb+p1X9MvXPXlOgm3ONuAxnfNA1FGKT24M81eY+1JgUQG53v3oAsC9
	mQdmDBYvWemP4B1jcLYjwUGoxxDagBGj8vXehum8CufExVARTEKhXLtJUSCM
	sDN7xqCqprgfCTOQeIkdirSlMPdVS9b3q8kyLmtGoO96pbyakmKq5GY1EdWA
	47xduEtBOeb1qF+FxZptVphEoYgxAZwG03fKAO0Iz/Qhf3gh9Qs2lGxdIrIW
	3ITZlyrDeUG4W2N1B4f7FHBdX0w4KSi7tY0cAwyi+MrFZTrnDG8WGW7ibI2n
	22z5/oFLnRiNjo6cEcJJuOTsFzHjssrYtxGmBp0S6qJ0Jljlt3Q8xFpxeEVo
	1PJpMBFA/6MC5Js3W/jwU8zWiPdt2XpXjVfoVloQr36Fkn2x0yD/ddo9VZg2
	hxQyy5vR3LoCUaUc5mzNbagHit9XXuqisaWeZQLJy56y8ptUtObcfJCfPPZW
	YviHfm0PLR7w3+tq/02isYYD9UwE9PDn5eXrq2uFQBxfvb4GzeHd5Xh89vqS
	bgZvwmJxCgb22ejgEHd77rsK2/xiz3KG/X/U/1Oob8Hb2d2HW0HZD1jxhpB4
	nVY3r9X9qD8Kgp+tRfQLvw5aYtvLNapyaXViNPpIZMfr5y2bVBcEr0DhAhnN
	BTpkRqFE7zYyDIhhcW7mpngF6RB8t0ZEHYBqufhW6f68/9sozqrplBh8ODzA
	BH48Kl7NB+aJXN0YYsT6W9Af9TyckiCEmcUA7pJcbkJiiSWwXuKnqN9ltuol
	mKhKS+f07whwOy3X5Mxhf7+moAzFj//7oESCstXXGsSF74+dZKA5GSwW7ONC
	QW4MpJaxrXhHeSmikBPrjPNkijF+Cfu/ubu7UcP+QFGa2ALgBMu+ZyoNTKSA
	XufXeBT09rA+1xH35rOdu1eiGXISHbnaMbHr7pHzITqYabMLaIrTTmCzs0Dh
	CLECBBODUC1BNWipqYJQU4l5pypnveN1F/N+f+hnRY4G+5IYdsv+oJBq1Frw
	wB5Yl/DvMuRERSJnPT+JagzXjLILvUlEwVNEVPe5iBULL6E16oWdYDlh8lgA
	dTir1sxT+DEl4/ihhG25T7ooKjzLEDMrsNIK0O27z9xG0QjPsyRhJRNNUAqN
	U6UiiLKxq97RVOePGZltB4CQzCWCLnSn5UgHtdNsqNkLSFl/HVgSXVo6mrwp
	echiKv2Z8Ei8k5DSf+VKf9OKTGKpXZAU9DCuDUv0K95U00oy2QTGeyd5Uba4
	yKuA/SIJQ4Wfol7LyEYbuL32hgyttcobXDLHPuLi99faOKn4m2pt6jkZXnSU
	XOhsjTK5+bnJnz+Lzftlh7MuCLT+akwJma2aMSniWPPnysvKr9VAm/KGMeaU
	itgpjN5NEYL1TEg/scGSqtQUe5KrH/xWBYpMgOaIlmb7rWO33v76LOvCzpvy
	6uZ+354ygOLwZNQf9PE/O6299M9PdehPNRoMhqfR5Pj0+HT/9HTkJvy5ceeX
	58Vlg61aW5ELLZkeUldAVRGvpSri8xaVQniyzy+4aBfYRjqS6OHag+13V+8u
	FXpna2Jpp5Fh96SscT63CZc14sHnHNMPd696x8ZXeDjC2igY7VqXPZMkTDJA
	LOzhybGNYLaVj7SWiXiJ3HQE1DZNHTwRPW2UD/g4mGTRo/J//lMZa2bXWpZB
	IJfWHustqN7I2aB0cZZlIMf5LfOEeevPamGKQm1GMfrja+m2P0uy7S/qLzIK
	D+mNYswRF5P4yjB2id4WXtD82xJn67GBr7NkR31LKlkm5n2u/1HFGLhULT8y
	iPjL64PAsZ9i0iMO9oxBfka/hBvhF7lcH8dkGbaO8624SGzZQjMjxvhJQBJl
	eYm1n+3D6E+UREk+nNgGT3v1pBQEzob3rUdE5K0sqlxkXm1CseFl43lR24XG
	vHVTZXLQ39sJAoKJ/wOY/Flt89J2TQ78jvoFYRgE8I9qPv7ix/GN+vn89hf1
	9lUQ8Jv1J761cBZAti4VtCgByW7r/WmYPn2/BtZdf9ZcA4y5fAO9u9MNwHJB
	XTvIpp/W99mx/+QiWdw/+QhwUr4PwCwa9wCYndNOEJg6itqNrY56sY3I2FU/
	nL85u6XKAFMoAbh2APZealj5wO1Be7lRwP6DwEHce8HPrfcerQHfPGrTatyD
	9aMtD4rLwDyIsbAexsHg8SZK6HF7sTZ0DfxmaBtecc95jMFtq8VtaF6i59kB
	HAQ1BNqX6WJtErsHD3Z/Fk5h8vlcP4pDw2IxKEYsliYtw7mqvW/W1ruDO7Ux
	pMDnZ/E2uzHEc23GsOO+2KaD2+l2+ASbG0AosIE1svszmR8N83HPLvvkmKe0
	xOu96ur6DIC82jfhGHz7q5CiWkC7z73RyIgjO97XR5DyOn8EX5Hq2C34bQ4k
	jx/7TnFSn3jNTXMlzzCoV098Qc3MZmyd10yKIHgpvXhE8ZJfKQmTektYxc9Z
	oN2NBgq1NHEJWMplPInTiA07DJ51yRIXK0Nsz6A5XFUmXMGPqpEtFjNdGEjd
	5GWud2zBzEBrHmFlmTWTWQouwsLv6MDxMUpQppgIFyK7B4JNWikMgzBC5aLQ
	ZbXyvQu8q5gaq1AzGC8E6NwRzUCTRMg5d2Cq4/t2QzegGVMzi+8FuCM7rsQl
	hHM0uDkrpOlKbCTrrdcs+cE0v+aoCPzs0Q2VTY3CLYFES8JAsSEJtysOnjlm
	2cIoSxi7NJ0xYk4qILR4GRbOSwJrx8RdxALYatTrDG3PJxKkgE3Fkdlqax44
	he0QLzZBKGhPqKESioWmlmXkFHHpKoAH2ATFADhFBeP/WFDkNYjym9yspVx4
	+Z7ty0yy7CP6X4qV8yR5lE45hOu5GDY5nLOa8A6uD4V8RDVwvq+DiicXGSp/
	1uNR72BjazqCp1Kd230klD5I3jusqAayBX6GBSjwZ0Uwcd4TbFWQGgBShhT5
	J/BdbzVdrK6datw4rpwcmxMNL/oMoOFLa3P6Uaq5c4xwMiK1r2CC4IkpU8bR
	CrYkgOMyoW5F+FhcjwrUzJ4u5i6NL88lCADsMs9CWAMCoZwyB7w1TkPgcc7B
	KGls4pXzvV9cap0+eoejnvBlHuy2nQom0oDfNxMTONmTRT2aKCMwowR7U+lv
	moPV3IibXZfqVZVjfRaY6+iOM+KEIeomphY+liqfPDleslKzjIDACCIDO4JM
	sYQT2zgmutZQ8vMWpyRRBn+tyUTN61yHZDuRc1BaZkO2jYfrI9pjIC6QT4Wl
	Flfkb5YMQZsL1JMMdl5jnFCIApgCaMHcSAL+R12qmn3lWK7EeWRamfSxLQke
	HmJqrTuV/oucVGHaA8obnAhW7znqvCPNkjJKbayM3HXaOdfSoh2Jag7ntLFv
	3UmqbL1xhs1gW7OdgV1iNh5z/zUvqhwC0KYqUxK/aQfeMbMleY5OTOWAqQco
	us2E8m57RjlFBohYOAG77HKDPIr1IN66jVPVpIYuBYnsKIQ1ewRK9i+RlH4X
	JtRwSvSqLnJAWT2OcMs0aAq4DdmYXoWWj6KXxQYxuEkWalI5mr8SjuEaGu6R
	lofc7DSPk0cwF/I5+WlcrebSroqKW5Bj6OWKaNu0FFXUPWKVZMDfH3T4MSV4
	ouMP27RwJ8ZIt3J0PyCDa0qFh+MLGOjLswmVvosWZdfnVuVCUUYtpw5wTkBK
	aASXokXfoWFydqrsjdT3L+EtOSXi5hGipCdG3cH+sd+OIMuNVoBvuIyVYXcw
	GEgbDvKd1xrR1NOCbDOaHeI5FHUxGTxUKoXNVZxg43AVrV48nAVaS1N0CeVp
	4QI2rkS7lUcKJ27TArtWlaYCm8d17me14dD1gKWcIBvxCTx+MmbJ4ZOwGUjY
	1CIDdQEPkMOmT7x8Rq4zhW0yMCn7BsvACjbB4ME7TdqGracoqDoi2xA2dhFu
	vwxuUk+3Ck1sSzpqmOmQ2DMHkJJn9pR73SpvA05TZI3OamRdCsj9M4G1wElS
	rrChrTm5BUIn16TANFeKXkR/zPr+QQgwe2YKApqmRiaRnsYEBjhKgddm9LfB
	Ge3LupSkxpysOYSlNf84lc0eAFLNkoZQkR5UNQThVnkkrzaQO4ASuLFaFvEA
	qm5sexI3IbeqisUENCIDsFpx+HqBWk1UN5pRmH6q1KygRbNLv6nXDTgKzjkn
	kIg5aAcyMBUqIsx5O4UPC+p82iDVPrV2IdbqPSnnsNbbhgMfyxVwgLWE17Xs
	2qAlisl5Eql+WGu80XCLSMOAd5jD2QPGl6vL9D7Os1Sa0YARsnT3duUPGAID
	vdp7lCpBcC81mRgqeg9RA0JG2k60NO5oLedr1UJyLplsc0VQEypqNCOJM3nG
	Ykc0l1R0OWxcVrLSLhI5dOWJbQOfXV80clhaJmZA3rDLAenzQlStOyATOAJ1
	j0S7IYgeMlZt2V4XYUEkwaM0bFCT5hJggsz4mdktkuWL/M63kOKy0MnM9u3N
	/dQTFEWSOl0EdXUf0L4tkRUa12ktwKm8fp+1BIMdbvQrPc1wCXdvxwHyumIB
	hNJqhNVcE5ZJ/+/+weBEgQAueXCNKg9XRmCEgeEnFYjD0YH448paUL3ucTsN
	gh7ogeWU0ifiwqS5aOn+6AscMFR7VxeKTHcsWqKWRj2qvfE7AbMdw5X8bqUF
	5XqY/ks43EOcRNMw95oRqW9efIOi3nCEBDg5tXbvLTPSxSY68U07txJRUbz5
	6HgaJYc8M9qg+t6cR+6xokEGUUjq3HsbzMOyKoIb6TSjtt+fj292DGxPDgeY
	S+JP5w2LOcrcVwkbJVNX6GWMssEWqEu3YXJ2fKUVARxc8dkQTF2GGBwAY2Ig
	g0lQtyFWGBeBFJfxC9wQCmU0EZW/6q7v3FhUS3hKCE/yYnzTmz0qpV9SXvet
	LLOIa9ke2K1kzzFn49RK9gGZjxxRFC5BThvXdqk2M+XuNxrxf93VyPCj3Ztg
	c7vbEUQVzNiV7CNiWWua6EZuhabLxEC6se9u0Op+lRLjRj1nsal+F3vaoWrH
	SI8LWYYt2THN+LGQgaQsgNv24uZMPb+dAfaFRhxLbSPREE0fF8ZzRdk+Abei
	aTKzvmr1qJq+SyD8Q9bVWKNj49NUZGeBsy6Wkry2Cpf8wYIVjIoWpDU7x3Js
	uN00mx02G8L04UdthNm26LSmbwwdlAJHFxwGD+JDnFI6En+MgSLc7QLK16Cx
	03pDkyWfpSHo+vcAnDaMHUKSGMxCqmA2CzHHU+r7U2q3viR9aBaCvs0+J2on
	UHhWj3uqmCI4kf4AYwEfXJOMCMJGXGyFM/RcippEMJy2ixDCL2dQWVdQ8/+g
	Ep3Ipw1KaUrkWVe75AdY72/QdKkY2njQoPty5CK6B5WK6jdq1py3Rsx3rbgb
	mVWyQBv03uTGVgbSvvHJeRpsnAJQftVB8zx/JTAAzDwGdRLblPjOH0/0tJVB
	im/Sqygy3GMTln0Mky+AKlvraKb2wNRYrBnI+3ozx40+YN7JBlXfVshQNqqJ
	Nv2ICuH3FBekWKFTQIU/leY7IV4XM2KRtPh6Ay8ODoo+3hzZNEeTYsXG7Y5r
	sOb2XK0imwjc0He8NjESlt523mP0LCXkpkLI19YGmhF1iqhms/hT4/tXwTl/
	N8n64fJTdXV59wqoqpZZatoebxc7p6rWrBueJA3jlKyjMKVL5Or3msfVkvte
	sZ8IIwDSOw4oACEbM8nrQrrsiJq/RqUyggc/pIA15ZFAMBwd2q7F9nFQ2BKr
	wYnbCpaJNedqzcWjxMVjHFBkj68JkyC4hnMmM5gYcC7odD3aav3CmktGMx/9
	xaDWAPjw4HbUHL+slHCn6aK1eUiBZWrEQw7cdznMvtF0dfYkec89oq6XO9t0
	rtYdyuEQ+1SS+G2W4Foest0otetmJQXm4N3Jdxg+rbiHF6Ia9VpUIEnWhvRd
	pYy5oYOoA2iwpD7f2K5YO8s7pcRKTOJOo4oQzQ349JPf2qDcXl0ET3zwodlI
	vWuaN3Ifby58bH4qKJBoi6uPLZxgIE7cSjT4Vo1qfEvDMQOPm8P5VkoN+0pd
	h42WtzbiYlFuQUjZfyN4abxApSvyUl79EfCpPXjqR0GNG5pEclvlIb6yD6/c
	kWvPfC7Cq5RsUEttwTVdZTueufAzfSHsAHcJMHPboI6IlU0pMQeNv9xivyPW
	MyGIU2kMY8tZzQ2yx+3TEX5zjhw7/guYeEEGArxWYUI8fosDj0NVoCMi5jR3
	+biIG8zEzRtzuwDO+ioO+2qNM1MmCO+a7BUKAIRorwsc09onnGonx1SikgOU
	uoB5NGFX5AX4yT1mYIB5lxTPXeXYSFFsVEr+pVwAYau2Izq73FlIMXXiD7e3
	vKbPEDYS58wjXuL1qS1Yb2k8WTtX9caTZqh3pmP0GdEo5S2eqp9c8uKNx4qb
	Mk0eMZJNkGMub5SZLRu1iSmtW6z3X7N2CtVq/cH2wepx+y5avuwkuRX15mTN
	dp1/rC1KpLZ1i081GPG+h9BsHvL0Dq+zf/EGrTH+5HkLuSlT/Zs+G1ov/cFQ
	yPmqT+6ufH4zkD/Y5jhP9snNNWqbuRT5D7aL9VThDVviby64LheuVUItTGN8
	Ef++o8Y9HUEvr9CAZeHI3zEtGk1vXak4mzXUTMU6xaMqF3MuiNq+cGN0KdDP
	78DIe1NFBTps/ppN0GI4myzDbvBa5xNQUP4K9jZoxyCDU3WRZTk8dkYZZuqN
	Dldd2KJewXa0egmw+3WpH9HF9i78pMZg8S+66jKqwjzK1A9wLljb/T7/9bH4
	tYTFfJ+VoINOf+237ZScNJu2i/33KUToB2vtpx2Wmj/Mh9/wA7h+UwRvz0CZ
	Oz97+xYWfHb2mhcyvjy/uBrfnN2dv2EHNayDv2rcgDWuhLsMv+3f9cd9+QwJ
	fnCAut7uyGdJcUV/2A8X/dbvFl0YInlDutzj/8g20NtJaXQbv5o9GGA0Jrtn
	6w41AUYpKK35xwg9IGWWJXySGQBi88BrZxG5yinlVLolko+eP7syq/DoWfZg
	XUGFndB8ismL/HH6Pb5PY/vd7eXbx1t7O3bqett5E3XY2BIf3t13L5MNiik9
	kuNCkgWlySKmjDkEP7p81a5lYd81PqG6vTU6wAG5HBrGCk1PGOm+w/kBFOrI
	CgziSnFy10ugsJk92KebvnyJEBpzz3uGe8t3I2gL21vDkx0pBgRoW1jzN7YL
	07QIHRQ6srEnRLDjUfht5Y/YS8/QL+G7j98M74OZvIvdLnY3k8/wWUQ2tFBH
	QxRMnE+MLXL3cQDbHCT6yKesbSFHw8c3QdMr4RMaovAeJvY4MrIksL11cOLw
	LhJXAvdbBx49RXGImUw+VbRF07n3W2q+B3hf9B2eHQZ5SBtU8jo7b9hGLQVY
	4m1bBwc7T47VGu7xstjjhk9PkuG3hvv/ZsIZPYtwRrD5D9hmYr2p7vbW4Qhh
	8wqIqXxcZbYbhvTZ6Vj2CE/SuT9PwpzDhbb1HqUwcOJvlj/yF3FmYZKQ8GM/
	G7x+RBNdiF9R+FyPSoLNZzRNXjlOduwm4xSnwm+XsF4/Da+c8Cs6JKLDlF3k
	TpygnfG+rq/uxsKMi2o+x5wXRPn21vHIkciUtzh1H49P9QOFmqWyqw4F7UcE
	+UQY5a0rPMYU0WM5BobjC262vxZJ3BodE3K2TjweW2/79yyM72142Rxy54qX
	Bs+Ws9Ta1ZquwPIhH8qA93pi4gkYHPlHS6STmQbpjRvuF/TwcOgeDi1lmdes
	/MCAAH7WFd/YE+oUPTiOUuxZYfB1bj4EQ5+/ctKRpYfY5/QFE26Giy3mzEVe
	Cb7ccfmCNnF5a28gM/OylsLKKFNTkrlgFYbvmfC4JlUD/USGCyA68WrxLMTt
	83Ao0nA2YhZWj0R48LFAHcZ8vY6qu2oUC8+NCC1jbsI9I/DB1b29roJ/2X8O
	vxziQ7ekC0W1xLAaDMwDPqOlamRMSAQJNF0YcU1nxBOw21snezLX6HjHAbzR
	9p7oiKa6wwNrexCYhNgYc5bvtfSbwq930W0DYfMNdrqNe9+zpIEHoF+Pb2CH
	m7Ur5nsyRWkCOl9D1IFPfSxnYBzyx3ryRr5RxK33rOShJuUey0A9nVQiE3dE
	VHkMwI6AuUcJ06Ops0AhRPu9NIrTppI/c9xYT/qEOAOGTwrdAMjiiGhjQP8O
	4XA9BwiHcjYb+CKOmaU9+oAet/41uuPwYFAXIvXMZ7g/qt+3JXpJNgc1wW7X
	PeGj/oCo7IP4yj1+wBn7JmhI/btq2rKoqhhDtHsiTkMBRiu3JcsGP+X2DPAc
	1Q/z2UXtKB8eGMGL66kTfOoXEtPD+x43Eib4EObIkgpHahg+owAbKbwuDqU5
	DvWsRR+vkx2xMBEFrrcMgs19Q3BreHQoFLteBbI1PB76Z9KOTNDt2F43fDql
	oBbfMkLZgDAJQZBM6WtQHiSPTpBojwfCao49AqHe4M3WDPjKPnO2e/QlCAXt
	ClsrimwaW06KJPUcuJ3QSun7e4RLssmxT4j3zU3gM+WDpo/YyY5pMScEnHcY
	4GiCziZF4GMDj6uEBv3uE/RNmnaRfgSlz39ZlXL4zbOKI3yUab5rs8zxvYNn
	oeD45FlQGg4sFRTGdGM5N35tx/NEjsc7Ddn5Jh4qTINhG6+lMmzuPwNHdk7p
	vy7LAGOb6vyHC4430yjP43jDoUfFkfAS7B9DhIwcBMvEDTfBAn0wfK/G7xX2
	tqZ5jh1brwttjMRPm3W9btvlpqZexpZqObZEGPUPIZORbx/9R5VRx2HGfzMR
	gNOEWChOH58FHrQ07l5eBMGrf4tBFPw/9sm8ITuNAAA=
	</rfc>		</rfc>
End of changes. 122 change blocks.
	1435 lines changed or deleted		577 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/