Skip to content

Minor language fixes #148

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
EdOverflow merged 1 commit into from
Apr 8, 2019
Merged

Minor language fixes #148

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
181 changes: 91 additions & 90 deletions draft-foudil-securitytxt.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,32 +9,82 @@


<style type="text/css">/*<![CDATA[*/
@viewport {
zoom: 1.0;
width: extend-to-zoom;
}
@-ms-viewport {
width: extend-to-zoom;
zoom: 1.0;
}

@media screen and (min-width: 1024px) {
body>ul.toc, body>#rfc\.toc {
position: fixed;
bottom: 0;
right: 0;
right: calc(50vw - 550px);
width: 300px;
z-index: 1;
}
#rfc\.toc {
top: 55px;
overflow: auto;
overscroll-behavior: contain;
}
ul.toc, #rfc\.toc {
overflow: auto;
overscroll-behavior: contain;
}
body>ul.toc {
top: 140px;
}

body {
padding-right: 350px;
}
}

body {
font: 16px "Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif;
font: 16px "Helvetica Neue",Helvetica,Arial,sans-serif;
color: #333;
font-size-adjust: 0.5;
line-height: 24px;
margin: 75px auto;
max-width: 624px;
padding: 0 5px;
max-width: 724px;
}

.title, .filename, h1, h2, h3, h4, h5 {
font: 16px "Roboto Condensed","Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif;
.title, .filename, h1, h2, h3, h4 {
font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
font-size-adjust: 0.5;
font-weight: bold;
font-weight: 500;
color: #333;
line-height: 100%;
margin: 1.2em 0 0.3em;
margin: 0.8em 0 0.3em;
}
.title, #rfc\.title h1 { font-size: 32px; }
h1, section h1, h2, section h2, section h3, nav h2 { font-size: 20px; }
h3, section h4, h4, section h5 { font-size: 16px; }
.title { font-size: 36px; }
h1 { font-size: 36px; }
h2 { font-size: 24px; }
h3, h4 { font-size: 18px; }
h1 a[href], h2 a[href], h3 a[href], h4 a[href] {
color: #333;
}

ul.toc li {
list-style: none;
text-indent: -2.5em;
padding-left: 2.5em;
padding-bottom: 5px;
margin: 0;
}
ul.toc ul {
margin: 0;
}
/* xml2rfc nests ul directly inside ul which messes with the style badly */
ul.toc, ul.toc>ul, ul.toc ul>ul {
margin: 0 0 0 1.5em;
}

table {
margin-left: 0em;
border-collapse: collapse;
Expand All @@ -61,30 +111,28 @@
}


table.header, table#rfc\.headerblock {
table.header {
width: 100%;
}
table.header td, table#rfc\.headerblock td {
table.header td {
border: none;
background-color: transparent;
color: black;
padding: 0;
}
.filename {
display: block;
color: rgb(119, 119, 119);
font-size: 20px;
font-size: 23px;
font-weight: normal;
height: auto;
line-height: 100%;
margin: 10px 0 32px;
}
#rfc\.abstract+p, #rfc\.abstract p {
font-size: 20px;
line-height: 28px;
font-size: 18px;
line-height: 27px%;
}

samp, tt, code, pre, span.tt {
font: 13.5px Consolas, monospace;
samp, tt, code, pre {
font: 11pt consolas, monospace;
font-size-adjust: none;
}
pre {
Expand All @@ -94,24 +142,22 @@
padding: 5px;
margin: 5px;
}
.figure, caption {
.figure {
font-style: italic;
margin: 0 1.5em;
text-align: left;
}

address {
margin: 16px 2px;
line-height: 20px;
margin: 10px 0 0;
}
.vcard {
font-style: normal;
}
.vcardline {
display: block;
}
.vcardline .fn, address b {
font-weight: normal;
.vcardline .fn {
font-weight: bold;
}
.vcardline .hidden {
display: none;
Expand Down Expand Up @@ -165,61 +211,17 @@
background-color: #eee;
}

p, ol, ul, li {
ol, ul, li, p {
padding: 0;
margin: 0.5em 0 0.5em 2em;
}
p {
margin: 0.5em 0;
}
ol, ul {
margin: 0.2em 0 0.2em 2em;
}
li {
margin: 0.2em 0;
li, p {
margin-left: 0;
}
address {
font-style: normal;
}

ul.toc ul {
margin: 0 0 0 2em;
}
ul.toc li {
list-style: none;
margin: 0;
}

@media screen and (min-width: 924px) {
body {
padding-right: 350px;
}
body>ul.toc, body>#rfc\.toc {
position: fixed;
bottom: 0;
right: 0;
right: calc(50vw - 500px);
width: 300px;
z-index: 1;
overflow: auto;
overscroll-behavior: contain;
}
body>#rfc\.toc {
top: 55px;
}
body>ul.toc {
top: 100px;
}

ul.toc {
margin: 0 0 0 4px;
font-size: 12px;
line-height: 20px;
}
ul.toc ul {
margin-left: 1.2em;
}
}

.github-fork-ribbon-wrapper {
display: none;
}
Expand Down Expand Up @@ -276,8 +278,7 @@
.github-fork-ribbon-wrapper {
position: fixed;
}
/*]]>*/</style>
<meta name="viewport" content="initial-scale=1.0">
/*]]>*/</style>


<link href="#rfc.toc" rel="Contents">
Expand Down Expand Up @@ -332,12 +333,12 @@
<link href="#rfc.authors" rel="Chapter">


<meta name="generator" content="xml2rfc version 2.22.0 - https://tools.ietf.org/tools/xml2rfc" />
<meta name="generator" content="xml2rfc version 2.16.0 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />

<meta name="dct.creator" content="Foudil, E. and Y. Shafranovich" />
<meta name="dct.identifier" content="urn:ietf:id:draft-foudil-securitytxt-05" />
<meta name="dct.issued" scheme="ISO8601" content="2019-03-24" />
<meta name="dct.issued" scheme="ISO8601" content="2019-04-07" />
<meta name="dct.abstract" content="When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe the process for security researchers to follow in order to report security vulnerabilities." />
<meta name="description" content="When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe the process for security researchers to follow in order to report security vulnerabilities." />

Expand All @@ -361,12 +362,12 @@
<td class="right">Y. Shafranovich</td>
</tr>
<tr>
<td class="left">Expires: September 25, 2019</td>
<td class="left">Expires: October 9, 2019</td>
<td class="right">Nightwatch Cybersecurity</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">March 24, 2019</td>
<td class="right">April 07, 2019</td>
</tr>


Expand All @@ -382,7 +383,7 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on September 25, 2019.</p>
<p>This Internet-Draft will expire on October 9, 2019.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
Expand Down Expand Up @@ -520,10 +521,10 @@ <h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#the-specification" id="the-specification">The Specification</a>
</h1>
<p id="rfc.section.3.p.1">This document defines a text file to be placed in a known location that provides information for security researchers to assist in disclosing security vulnerabilities.</p>
<p id="rfc.section.3.p.2">The file is named &#8220;security.txt&#8221;, and this file SHOULD be placed under the /.well-known/ path (&#8220;/.well-known/security.txt&#8221;) <a href="#RFC5785" class="xref">[RFC5785]</a> of a domain name or IP address for web properties. If it is not possible to place the security.txt file in the /.well-known/ path or setup a redirect, web-based services MAY place the file in the top-level path of a given web domain or IP address (&#8220;/security.txt&#8221;) as a fallback option (see section <a href="#weblocation" class="xref">Section 4.1</a>).</p>
<p id="rfc.section.3.p.3">For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol <a href="#RFC1945" class="xref">[RFC1945]</a> as a resource of Internet Media Type &#8220;text/plain&#8221; with the default charset parameter set to &#8220;utf-8&#8221; per section 4.1.3 of <a href="#RFC2046" class="xref">[RFC2046]</a>, and it MUST be served with &#8220;https&#8221; (as per section 2.7.2 of <a href="#RFC7230" class="xref">[RFC7230]</a>). For file systems and version control repositories a &#8220;security.txt&#8221; file SHOULD be placed in the root directory of a particular file system or source code project.</p>
<p id="rfc.section.3.p.2">The file is named &#8220;security.txt&#8221;, and this file SHOULD be placed under the /.well-known/ path (&#8220;/.well-known/security.txt&#8221;) <a href="#RFC5785" class="xref">[RFC5785]</a> of a domain name or IP address for web properties. If it is not possible to place the security.txt file in the /.well-known/ path or setup a redirect, web-based services MAY place the file in the top-level path of a given web domain or IP address (&#8220;/security.txt&#8221;) as a fallback option (see <a href="#weblocation" class="xref">Section 4.1</a>).</p>
<p id="rfc.section.3.p.3">For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol (HTTP) <a href="#RFC1945" class="xref">[RFC1945]</a> as a resource of Internet Media Type &#8220;text/plain&#8221; with the default charset parameter set to &#8220;utf-8&#8221; per section 4.1.3 of <a href="#RFC2046" class="xref">[RFC2046]</a>, and it MUST be served with &#8220;https&#8221; (as per section 2.7.2 of <a href="#RFC7230" class="xref">[RFC7230]</a>). For file systems and version control repositories a &#8220;security.txt&#8221; file SHOULD be placed in the root directory of a particular file system or source code project.</p>
<p id="rfc.section.3.p.4">This text file contains multiple directives with different values. The &#8220;directive&#8221; is the first part of a field all the way up to the colon (&#8220;Contact:&#8221;) and follows the syntax defined for &#8220;field-name&#8221; in section 3.6.8 of <a href="#RFC5322" class="xref">[RFC5322]</a>. Directives MUST be case-insensitive (as per section 2.3 of <a href="#RFC5234" class="xref">[RFC5234]</a>). The &#8220;value&#8221; comes after the directive (&#8220;https://example.com/security&#8221;) and follows the syntax defined for &#8220;unstructured&#8221; in section 3.2.5 of <a href="#RFC5322" class="xref">[RFC5322]</a>.</p>
<p id="rfc.section.3.p.5">A &#8220;field&#8221; MUST always consist of a directive and a value (&#8220;Contact: https://example.com/security&#8221;). A security.txt file can have an unlimited number of fields. It is important to note that you MUST have a separate line for every field. One MUST NOT chain multiple values for a single directive and everything MUST be in a separate field. Unless otherwise indicated in a definition of a particular field, any directive MAY appear multiple times.</p>
<p id="rfc.section.3.p.5">A &#8220;field&#8221; MUST always consist of a directive and a value (&#8220;Contact: https://example.com/security&#8221;). A security.txt file can have an unlimited number of fields. It is important to note that you MUST have a separate line for every field. One MUST NOT chain multiple values for a single directive unless it is explicitly defined by that particular field. Unless otherwise indicated in a definition of a particular field, any directive MAY appear multiple times.</p>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#scope" id="scope">Scope</a>
</h1>
Expand All @@ -542,7 +543,7 @@ <h1 id="rfc.section.3.1">
# This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
https://[2001:db8:8:4::2]/.well-known/security.txt

# This security.txt file applies to the /example/folder1 directory.
# This security.txt file applies to the /example/folder1 directory and subfolders.
/example/folder1/security.txt
</pre>
<h1 id="rfc.section.3.2">
Expand All @@ -557,11 +558,11 @@ <h1 id="rfc.section.3.2">
<h1 id="rfc.section.3.3">
<a href="#rfc.section.3.3">3.3.</a> <a href="#separate-fields" id="separate-fields">Separate Fields</a>
</h1>
<p id="rfc.section.3.3.p.1">A separate line is REQUIRED for every new value and field. You MUST NOT chain everything into a single field. Every line MUST end either with a carriage return and line feed characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).</p>
<p id="rfc.section.3.3.p.1">A separate line is REQUIRED for every new value and field. You MUST NOT chain everything into a single field unless defined by that field. Every line MUST end either with a carriage return and line feed characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).</p>
<h1 id="rfc.section.3.4">
<a href="#rfc.section.3.4">3.4.</a> <a href="#signature" id="signature">Digital signature</a>
</h1>
<p id="rfc.section.3.4.p.1">It is RECOMMENDED that a security.txt file be digitally signed using an OpenPGP cleartext signature as described in section 7 of <a href="#RFC4880" class="xref">[RFC4880]</a>. When digital signatures are used, it is also RECOMMENDED that implementors use the &#8220;Canonical&#8221; directive as per <a href="#canonical" class="xref">Section 3.5.2</a>, thus allowing the digital signature to authenticate the location of the file.</p>
<p id="rfc.section.3.4.p.1">It is RECOMMENDED that a security.txt file be digitally signed using an OpenPGP cleartext signature as described in section 7 of <a href="#RFC4880" class="xref">[RFC4880]</a>. When digital signatures are used, it is also RECOMMENDED that implementors use the &#8220;Canonical&#8221; directive (as per <a href="#canonical" class="xref">Section 3.5.2</a>), thus allowing the digital signature to authenticate the location of the file.</p>
<p id="rfc.section.3.4.p.2">When it comes to verifying the key used to generate the signature, it is always the security researcher&#8217;s responsibility to make sure the key being used is indeed one they trust.</p>
<h1 id="rfc.section.3.5">
<a href="#rfc.section.3.5">3.5.</a> <a href="#field-definitions" id="field-definitions">Field Definitions</a>
Expand All @@ -587,7 +588,7 @@ <h1 id="rfc.section.3.5.1">
<h1 id="rfc.section.3.5.2">
<a href="#rfc.section.3.5.2">3.5.2.</a> <a href="#canonical" id="canonical">Canonical</a>
</h1>
<p id="rfc.section.3.5.2.p.1">This directive indicates the canonical URI where the security.txt file is located, which is usually something like &#8220;https://example.com/.well-known/security.txt&#8221;. If this directive indicates a web URL, then it MUST begin with &#8220;https://&#8221; (as per section 2.7.2 of <a href="#RFC7230" class="xref">[RFC7230]</a>).</p>
<p id="rfc.section.3.5.2.p.1">This directive indicates the canonical URI where the security.txt file is located, which is usually something like &#8220;https://example.com/.well-known/security.txt&#8221;. If this directive indicates a web URL, then it MUST begin with &#8220;https://&#8221; (as per section 2.7.2 of <a href="#RFC7230" class="xref">[RFC7230]</a>). The purpose of this directive is to allow a digital signature to be applied to the location of the &#8220;security.txt&#8221; file.</p>
<p id="rfc.section.3.5.2.p.2">This directive MUST NOT appear more than once.</p>
<pre>
Canonical: https://example.com/.well-known/security.txt
Expand Down Expand Up @@ -641,7 +642,7 @@ <h1 id="rfc.section.3.5.7">
<p id="rfc.section.3.5.7.p.1">This directive can be used to indicate a set of natural languages that are preferred when submitting security reports. This set MAY list multiple values, separated by commas. If this directive is included then at least one value MUST be listed. The values within this set are language tags (as defined in <a href="#RFC5646" class="xref">[RFC5646]</a>). If this directive is absent, security researchers MAY assume that English is the default language to be used (as per section 4.5 of <a href="#RFC2277" class="xref">[RFC2277]</a>).</p>
<p id="rfc.section.3.5.7.p.2">The order in which they appear MUST NOT be interpreted as an indication of priority - rather these MUST BE interpreted as all being of equal priority.</p>
<p id="rfc.section.3.5.7.p.3">This directive MUST NOT appear more than once.</p>
<p id="rfc.section.3.5.7.p.4">Example:</p>
<p id="rfc.section.3.5.7.p.4">Example (English, Spanish and French):</p>
<pre>
Preferred-Languages: en, es, fr
</pre>
Expand Down Expand Up @@ -696,7 +697,7 @@ <h1 id="rfc.section.4.1">
</h1>
<p id="rfc.section.4.1.p.1">Web-based services SHOULD place the security.txt file under the /.well-known/ path; e.g. https://example.com/.well-known/security.txt as per <a href="#RFC5785" class="xref">[RFC5785]</a>. A security.txt file located under the top-level path SHOULD either redirect (as per section 6.4 of <a href="#RFC7231" class="xref">[RFC7231]</a>) to the security.txt file under the /.well-known/ path or be used as a fallback if the &#8220;.well-known&#8221; path cannot be used.</p>
<p id="rfc.section.4.1.p.2">If retrieval of a &#8220;security.txt&#8221; file results in a redirect (as per section 6.4 of <a href="#RFC7231" class="xref">[RFC7231]</a>), the implementors MUST NOT follow redirects that lead to another domain or subdomain but SHOULD follow redirects within the same domain name (but not different subdomain on the same domain).</p>
<p id="rfc.section.4.1.p.3">This does not apply to resource locations that appear within the file.</p>
<p id="rfc.section.4.1.p.3">The guidance regarding redirects SHOULD NOT apply to the resource locations that appear within the file.</p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#filesystems" id="filesystems">Filesystems</a>
</h1>
Expand Down
Loading