Skip to content

Commit

Permalink
final fixes, reverting webkey reference
Browse files Browse the repository at this point in the history
  • Loading branch information
@nightwatchcyber
nightwatchcyber committed May 24, 2021
1 parent b6d2217 commit d2ecacd
Show file tree
Hide file tree
Showing 3 changed files with 117 additions and 123 deletions.
45 changes: 20 additions & 25 deletions draft-foudil-securitytxt.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -826,7 +826,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Foudil &amp; Shafranovich</td>
<td class="center">Expires 20 November 2021</td>
<td class="center">Expires 25 November 2021</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -839,12 +839,12 @@
<dd class="internet-draft">draft-foudil-securitytxt-12</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-05-19" class="published">19 May 2021</time>
<time datetime="2021-05-24" class="published">24 May 2021</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2021-11-20">20 November 2021</time></dd>
<dd class="expires"><time datetime="2021-11-25">25 November 2021</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -885,7 +885,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 20 November 2021.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 25 November 2021.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1183,7 +1183,7 @@ <h2 id="name-the-specification">
</h2>
<p id="section-3-1">This document defines a text file to be placed in a known location
that provides information about vulnerability disclosure practices of a particular organization.
The format of this file is machine-parsable following the ABNF grammar defined in
The format of this file is machine-parsable and MUST follow the ABNF grammar defined in
<a href="#abnf" class="xref">Section 5</a>. This file is intended to help security researchers when
disclosing security vulnerabilities.<a href="#section-3-1" class="pilcrow"></a></p>
<p id="section-3-2">By convention, the file is named "security.txt". Location and scope are described
Expand All @@ -1194,7 +1194,7 @@ <h2 id="name-the-specification">
The "value" comes after the field name (for example: "mailto:[email protected]") and follows the syntax
defined for "unstructured" in section 3.2.5 of <span>[<a href="#RFC5322" class="xref">RFC5322</a>]</span>. The file MAY also contain blank lines.<a href="#section-3-3" class="pilcrow"></a></p>
<p id="section-3-4">A field MUST always consist of a name and a value
(for example: "Contact: mailto:[email protected]"). A security.txt file
(for example: "Contact: mailto:[email protected]"). A "security.txt" file
can have an unlimited number of fields. Each field MUST appear on
its own line. Unless specified otherwise by the field definition,
multiple values MUST NOT be chained together for a single field.
Expand Down Expand Up @@ -1232,15 +1232,14 @@ <h3 id="name-line-separator">
<h3 id="name-digital-signature">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-digital-signature" class="section-name selfRef">Digital signature</a>
</h3>
<p id="section-3.3-1">It is RECOMMENDED that a security.txt file be digitally signed
<p id="section-3.3-1">It is RECOMMENDED that a "security.txt" file be digitally signed
using an OpenPGP cleartext signature as described in
section 7 of <span>[<a href="#RFC4880" class="xref">RFC4880</a>]</span>. When digital signatures are used, it is also
RECOMMENDED that organizations use the "Canonical" field (as per <a href="#canonical" class="xref">Section 3.5.2</a>),
thus allowing the digital signature to authenticate the location of the file.<a href="#section-3.3-1" class="pilcrow"></a></p>
<p id="section-3.3-2">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
used is indeed one they trust. Researchers should use other ways to obtain
and verify the key (such as <span>[<a href="#I-D.koch-openpgp-webkey-service" class="xref">I-D.koch-openpgp-webkey-service</a>]</span>).<a href="#section-3.3-2" class="pilcrow"></a></p>
used is indeed one they trust.<a href="#section-3.3-2" class="pilcrow"></a></p>
</section>
</div>
<div id="extensibility">
Expand Down Expand Up @@ -1301,7 +1300,7 @@ <h4 id="name-acknowledgments">
<h4 id="name-canonical">
<a href="#section-3.5.2" class="section-number selfRef">3.5.2. </a><a href="#name-canonical" class="section-name selfRef">Canonical</a>
</h4>
<p id="section-3.5.2-1">This field indicates the canonical URIs where the security.txt file is located,
<p id="section-3.5.2-1">This field indicates the canonical URIs where the "security.txt" file is located,
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://"
(as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).<a href="#section-3.5.2-1" class="pilcrow"></a></p>
Expand Down Expand Up @@ -1330,7 +1329,7 @@ <h4 id="name-contact">
should use for reporting security
vulnerabilities such as an email address, a phone number and/or a
web page with contact information. The "Contact" field MUST
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 <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).
Security email addresses should use the conventions defined in section
4 of <span>[<a href="#RFC2142" class="xref">RFC2142</a>]</span>.<a href="#section-3.5.3-1" class="pilcrow"></a></p>
Expand Down Expand Up @@ -1528,9 +1527,9 @@ <h3 id="name-example-of-a-signed-securit">
<h2 id="name-location-of-the-securitytxt">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-location-of-the-securitytxt" class="section-name selfRef">Location of the security.txt file</a>
</h2>
<p id="section-4-1">For web-based services, organizations MUST place the security.txt file under the "/.well-known/" path; e.g. https://example.com/.well-known/security.txt
<p id="section-4-1">For web-based services, organizations MUST place the "security.txt" file under the "/.well-known/" path; e.g. https://example.com/.well-known/security.txt
as per <span>[<a href="#RFC8615" class="xref">RFC8615</a>]</span> of a domain name or IP address. For legacy compatibility, a security.txt file might be placed at the top-level path
or redirect (as per section 6.4 of <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>) to the security.txt file under the "/.well-known/" path. If a "security.txt" file
or redirect (as per section 6.4 of <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>) to the "security.txt" file under the "/.well-known/" path. If a "security.txt" file
is present in both locations, the one in the "/.well-known/" path MUST be used.<a href="#section-4-1" class="pilcrow"></a></p>
<p id="section-4-2">The file MUST be accessed via HTTP 1.0 or a higher version
and the file access MUST use "https" scheme (as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).
Expand Down Expand Up @@ -1699,7 +1698,7 @@ <h3 id="name-incorrect-or-stale-informat">
<p id="section-6.3-1">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
by the organization or sent to incorrect contacts, thus exposing possible
security issues to third parties. Not having a security.txt file may be preferable
security issues to third parties. Not having a "security.txt" file may be preferable
to having stale information in this file. Organizations must use
the "Expires" field (see <a href="#expires" class="xref">Section 3.5.5</a>) to indicate to researchers when
the data in the file is no longer valid.<a href="#section-6.3-1" class="pilcrow"></a></p>
Expand All @@ -1721,7 +1720,7 @@ <h3 id="name-intentionally-malformed-fil">
files larger than 32 KBs, having fields longer than 2,048 characters or
containing more than 1,000 lines. The ABNF grammar (as defined in
<a href="#abnf" class="xref">Section 5</a>) can also be used as a way to verify these files.<a href="#section-6.4-1" class="pilcrow"></a></p>
<p id="section-6.4-2">The same concerns apply to any other resources referenced within security.txt
<p id="section-6.4-2">The same concerns apply to any other resources referenced within "security.txt"
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.<a href="#section-6.4-2" class="pilcrow"></a></p>
</section>
Expand All @@ -1731,12 +1730,12 @@ <h3 id="name-intentionally-malformed-fil">
<h3 id="name-no-implied-permission-for-t">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-no-implied-permission-for-t" class="section-name selfRef">No Implied Permission for Testing</a>
</h3>
<p id="section-6.5-1">The presence of a security.txt file might be interpreted by researchers
<p id="section-6.5-1">The presence of a "security.txt" file might be interpreted by researchers
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 publishing
the file.
This might result in increased testing against an organization by researchers. On 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
that permission to test that particular site or project is denied. This might result in pushback against
researchers reporting security issues to that organization.<a href="#section-6.5-1" class="pilcrow"></a></p>
Expand Down Expand Up @@ -1815,7 +1814,7 @@ <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-7-1">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 MUST NOT point to the Well-Known URIs namespace unless
they are registered with IANA (as per <span>[<a href="#RFC8615" class="xref">RFC8615</a>]</span>).<a href="#section-7-1" class="pilcrow"></a></p>
<div id="well-known-uris-registry">
<section id="section-7.1">
Expand All @@ -1837,7 +1836,7 @@ <h3 id="name-registry-for-securitytxt-fi">
</h3>
<p id="section-7.2-1">IANA is requested to create the "security.txt Fields" registry in
accordance with <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. This registry will contain fields for
use in security.txt files, defined by this specification.<a href="#section-7.2-1" class="pilcrow"></a></p>
use in "security.txt" files, defined by this specification.<a href="#section-7.2-1" class="pilcrow"></a></p>
<p id="section-7.2-2">New registrations or updates MUST be published in accordance with the
"Expert Review" guidelines as described in sections 4.5 and 5 of
<span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. Any new field thus registered is considered optional
Expand Down Expand Up @@ -2049,10 +2048,6 @@ <h3 id="name-informative-references">
<dd>
<span class="refAuthor">Software Engineering Institute, Carnegie Mellon University</span>, <span class="refTitle">"The CERT Guide to Coordinated Vulnerability Disclosure (CMU/SEI-2017-SR-022)"</span>, <time datetime="2017" class="refDate">2017</time>. </dd>
<dd class="break"></dd>
<dt id="I-D.koch-openpgp-webkey-service">[I-D.koch-openpgp-webkey-service]</dt>
<dd>
<span class="refAuthor">Koch, W.</span>, <span class="refTitle">"OpenPGP Web Key Directory"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-koch-openpgp-webkey-service-11</span>, <time datetime="2020-11-17" class="refDate">17 November 2020</time>, <span>&lt;<a href="https://www.ietf.org/archive/id/draft-koch-openpgp-webkey-service-11.txt">https://www.ietf.org/archive/id/draft-koch-openpgp-webkey-service-11.txt</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ISO.29147.2018">[ISO.29147.2018]</dt>
<dd>
<span class="refAuthor">International Organization for Standardization (ISO)</span>, <span class="refTitle">"ISO/IEC 29147:2018, Information technology - Security techniques - Vulnerability disclosure"</span>, <time datetime="2018" class="refDate">2018</time>. </dd>
Expand Down Expand Up @@ -2361,9 +2356,9 @@ <h2 id="name-since-draft-foudil-securitytxt-11">
</li>
<li class="normal" id="section-b.12-1.2">Added clarification in "canonical" field regarding the URI used to retrieve the file<a href="#section-b.12-1.2" class="pilcrow"></a>
</li>
<li class="normal" id="section-b.12-1.3">Added language about machine-<a href="#section-b.12-1.3" class="pilcrow"></a>
<li class="normal" id="section-b.12-1.3">Added language about machine-parsability<a href="#section-b.12-1.3" class="pilcrow"></a>
</li>
<li class="normal" id="section-b.12-1.4">Added a reference to the PGP webkey draft<a href="#section-b.12-1.4" class="pilcrow"></a>
<li class="normal" id="section-b.12-1.4">Added quotes around "security.txt" for consistency<a href="#section-b.12-1.4" class="pilcrow"></a>
</li>
</ul>
<p id="section-b.12-2">Full list of changes can be viewed via the IETF document tracker:
Expand Down
Loading

0 comments on commit d2ecacd

Please sign in to comment.