Skip to content

Changes for #152 and #143 #155

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
nightwatchcyber merged 4 commits into from
Jun 4, 2019
Merged

Changes for #152 and #143 #155

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
aeeb84d
Changes for #152 and #143
nightwatchcyber May 27, 2019
a15035b
fixes
nightwatchcyber May 30, 2019
c64c135
updated redirect language
nightwatchcyber May 30, 2019
d30839d
fixes
nightwatchcyber Jun 4, 2019
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
179 changes: 92 additions & 87 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 @@ -333,12 +334,12 @@
<link href="#rfc.authors" rel="Chapter">


<meta name="generator" content="xml2rfc version 2.22.3 - 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-06" />
<meta name="dct.issued" scheme="ISO8601" content="2019-04-19" />
<meta name="dct.issued" scheme="ISO8601" content="2019-06-04" />
<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 @@ -362,12 +363,12 @@
<td class="right">Y. Shafranovich</td>
</tr>
<tr>
<td class="left">Expires: October 21, 2019</td>
<td class="left">Expires: December 6, 2019</td>
<td class="right">Nightwatch Cybersecurity</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">April 19, 2019</td>
<td class="right">June 04, 2019</td>
</tr>


Expand All @@ -383,7 +384,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 October 21, 2019.</p>
<p>This Internet-Draft will expire on December 6, 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 @@ -698,7 +699,7 @@ <h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#weblocation" id="weblocation">Web-based services</a>
</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.2">If retrieval of a &#8220;security.txt&#8221; file from the top-level path results in a redirect (as per section 6.4 of <a href="#RFC7231" class="xref">[RFC7231]</a>), the implementors MUST NOT follow that redirect if it leads to another domain or subdomain but SHOULD follow that redirect within the same domain name (but not different subdomain on the same domain).</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>
Expand Down Expand Up @@ -735,8 +736,8 @@ <h1 id="rfc.section.5">

sign-footer = &lt;OpenPGP signature from section 7 of [RFC4880]&gt;

unsigned = *line [canonical-field eol *line] [lang-field eol] *line
unsigned =/ *line [lang-field eol *line] [canonical-field eol] *line
unsigned = *line [can-field eol] *line (contact-field eol) *line [lang-field eol] *line
; the order of elements is not important

line = (field / comment) eol

Expand All @@ -755,7 +756,7 @@ <h1 id="rfc.section.5">

ack-field = "Acknowledgments" fs SP uri

canonical-field = "Canonical" fs SP uri
can-field = "Canonical" fs SP uri

contact-field = "Contact" fs SP uri

Expand Down Expand Up @@ -789,7 +790,7 @@ <h1 id="rfc.section.6.1">
<p id="rfc.section.6.1.p.1">An attacker that has compromised a website is able to compromise the &#8220;security.txt&#8221; file as well or setup a redirect to their own site. This can result in security reports not being received by the organization or sent to the attacker.</p>
<p id="rfc.section.6.1.p.2">To protect against this, organizations SHOULD digitally sign their &#8220;security.txt&#8221; files (as per <a href="#signature" class="xref">Section 3.4</a>), use the canonical directive to sign the location of the file (as per <a href="#canonical" class="xref">Section 3.5.2</a>), and regularly monitor the file and the referenced resources to detect tampering.</p>
<p id="rfc.section.6.1.p.3">Security researchers SHOULD check the &#8220;security.txt&#8221; file including verifying the digital signature and checking any available historical records before using the information contained in the file. If &#8220;security.txt&#8221; file looks suspicious or compromised, it SHOULD NOT be used.</p>
<p id="rfc.section.6.1.p.4">To avoid redirect attacks, redirects for these files MUST NOT be followed if they lead to a different domain (as per <a href="#weblocation" class="xref">Section 4.1</a>).</p>
<p id="rfc.section.6.1.p.4">To avoid redirect attacks, redirects for these files MUST NOT be followed when the file is placed in the top level path if they lead to a different domain (as per <a href="#weblocation" class="xref">Section 4.1</a>).</p>
<h1 id="rfc.section.6.2">
<a href="#rfc.section.6.2">6.2.</a> <a href="#incorrect-or-stale-information" id="incorrect-or-stale-information">Incorrect or Stale Information</a>
</h1>
Expand Down Expand Up @@ -1150,7 +1151,11 @@ <h1 id="rfc.appendix.B.7">
</h1>
<p></p>

<ul><li>Fixed ABNF grammar for non-chainable directives (#150)</li></ul>
<ul>
<li>Fixed ABNF grammar for non-chainable directives (#150)</li>
<li>Clarified ABNF grammar (#152)</li>
<li>Clarified redirect logic (#143)</li>
</ul>
<p id="rfc.section.B.7.p.2">Full list of changes can be viewed via the IETF document tracker: https://tools.ietf.org/html/draft-foudil-securitytxt</p>
<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
<div class="avoidbreak">
Expand Down
19 changes: 11 additions & 8 deletions draft-foudil-securitytxt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -366,10 +366,10 @@ Web-based services SHOULD place the security.txt file under the /.well-known/ pa
as per {{!RFC5785}}. A security.txt file located under the top-level path SHOULD either redirect (as per section 6.4 of {{!RFC7231}})
to the security.txt file under the /.well-known/ path or be used as a fallback if the ".well-known" path cannot be used.

If retrieval of a "security.txt" file results in a redirect (as per
section 6.4 of {{!RFC7231}}), the implementors MUST NOT follow
redirects that lead to another domain or subdomain
but SHOULD follow redirects within the same domain name
If retrieval of a "security.txt" file from the top-level path results in a redirect (as per
section 6.4 of {{!RFC7231}}), the implementors MUST NOT follow that
redirect if it leads to another domain or subdomain
but SHOULD follow that redirect within the same domain name
(but not different subdomain on the same domain).

The guidance regarding redirects SHOULD NOT apply to the resource locations that appear within the file.
Expand Down Expand Up @@ -421,8 +421,8 @@ sign-header = <headers and line from section 7 of [RFC4880]>

sign-footer = <OpenPGP signature from section 7 of [RFC4880]>

unsigned = *line [canonical-field eol *line] [lang-field eol] *line
unsigned =/ *line [lang-field eol *line] [canonical-field eol] *line
unsigned = *line [can-field eol] *line (contact-field eol) *line [lang-field eol] *line
; the order of elements is not important

line = (field / comment) eol

Expand All @@ -441,7 +441,7 @@ comment = "#" *(WSP / VCHAR / %x80-FFFFF)

ack-field = "Acknowledgments" fs SP uri

canonical-field = "Canonical" fs SP uri
can-field = "Canonical" fs SP uri

contact-field = "Contact" fs SP uri

Expand Down Expand Up @@ -488,7 +488,8 @@ contained in the file. If "security.txt" file looks suspicious or compromised,
it SHOULD NOT be used.

To avoid redirect attacks, redirects for these files MUST NOT be followed
if they lead to a different domain (as per {{weblocation}}).
when the file is placed in the top level path if they lead to a different
domain (as per {{weblocation}}).

## Incorrect or Stale Information

Expand Down Expand Up @@ -743,6 +744,8 @@ of DNS-stored encryption keys (#28 and #94)

## Since draft-foudil-securitytxt-06
- Fixed ABNF grammar for non-chainable directives (#150)
- Clarified ABNF grammar (#152)
- Clarified redirect logic (#143)

Full list of changes can be viewed via the IETF document tracker:
https://tools.ietf.org/html/draft-foudil-securitytxt
Loading