RFC 9116: セキュリティ脆弱性の開示を支援するためのファイル形式

RFC 9116	security.txt	2022年4月
Foudil & Shafranovich	情報提供	[ページ]

概要

セキュリティ脆弱性が研究者によって発見されても、適切な報告経路が欠如していることがよくあります。その結果、脆弱性が報告されないままになる可能性があります。この文書は、機械可読な形式（"security.txt"）を定義し、組織が自らの脆弱性開示の実践を記述できるようにすることで、研究者が脆弱性を報告しやすくします。¶

1. はじめに

1.1. 動機、先行研究、および範囲

多くのセキュリティ研究者は、特定のリソースの所有者に連絡するための報告経路がなく、その所有者の脆弱性開示の実践に関する情報も入手できないため、組織にセキュリティ脆弱性を報告できない状況に遭遇します。¶

第4節 of [RFC2142]に従い、セキュリティ問題に関する連絡に <SECURITY@domain>メールアドレスを使用する既存の慣習があります。この慣習は、ドメインごとに単一のメールベースの連絡経路しか提供せず、ドメイン所有者が自らのセキュリティ開示の実践に関する情報を公開する方法を提供しません。¶

Internet Service Providers（ISP）向けには第2節 of [RFC3013]に、Computer Security Incident Response Teams（CSIRT）向けには第 3.2節 of [RFC2350]に、サイト運営者向けには第 5.2節 of [RFC2196]にも、連絡先の慣習が規定されています。[RFC7485]に従い、IPアドレス、 Autonomous System Numbers（ASN）、およびドメイン名の所有者については、 Regional Internet Registries（RIR）およびドメインレジストリによって提供される連絡先情報もあります。しかし、これらはいずれも、セキュリティ研究者が脆弱性を報告するために、組織の連絡先情報および脆弱性開示の実践をどのように見つけられるかという問題には対処していません。¶

この文書では、組織が自らのセキュリティ開示の実践および連絡方法に関する情報を伝達するための、より豊かで、機械可読で、より拡張可能な方法を定義します。脆弱性開示のその他の詳細は、この文書の範囲外です。読者には、 [ISO.29147.2018]や [CERT.CVD]などの他の文書を参照することを推奨します。¶

[CERT.CVD]に従い、「脆弱性対応」とは製品の脆弱性に関する報告を指し、これはネットワーク侵入や侵害されたWebサイトに関する報告（「インシデント対応」）と関連はありますが区別されます。この文書で定義される仕組みは、前者（「脆弱性対応」）に使用されることを意図しています。実装者がこの仕組みをインシデント対応に利用したい場合は、第5.1節で説明される追加のセキュリティ上の考慮事項を認識しておくべきです。¶

"security.txt"ファイルは、組織が自らのセキュリティ開示の実践について維持している他の公開リソースを補完することを意図しており、代替または置換ではありません。¶

1.2. 用語

この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174]に記述されているとおりに解釈されます。¶

「研究者」という用語は、 [ISO.29147.2018]および[CERT.CVD]における「finder」および「reporter」という用語に対応します。「組織」という用語は、 [ISO.29147.2018]および[CERT.CVD]における「vendor」という用語に対応します。¶

「実装者」という用語には、脆弱性開示プロセスに関与するすべての当事者が含まれます。¶

2. 仕様

この文書は、特定の組織の脆弱性開示の実践に関する情報を提供する、既知の場所に配置されるテキストファイルを定義します。このファイルの形式は機械可読であり、第4節で定義されるABNF文法に従わなければなりません（MUST）。このファイルは、セキュリティ研究者がセキュリティ脆弱性を開示する際に役立つことを意図しています。¶

慣例により、このファイルは"security.txt"と命名されます。場所と範囲は第3節で説明されています。¶

このテキストファイルには、異なる値を持つ複数のフィールドが含まれます。フィールドには「名前」が含まれます。これはフィールドの最初の部分からコロンまで（例: "Contact:"）であり、第3.6.8節 of [RFC5322]の"field-name"に定義された構文に従います。フィールド名は大文字小文字を区別しません（第2.3節 of [RFC5234]に従います）。「値」はフィールド名の後に続きます（例: "mailto:security@example.com"）。これは第3.2.5節 of [RFC5322]の "unstructured"に定義された構文に従います。このファイルには空行を含めることもできます（MAY）。¶

フィールドは常に名前と値で構成されなければなりません（MUST）（例: "Contact: mailto:security@example.com"）。"security.txt"ファイルは無制限の数のフィールドを持つことができます。各フィールドはそれぞれ独自の行に現れなければなりません（MUST）。フィールド定義で別途指定されない限り、複数の値を単一のフィールドに連結してはなりません（MUST NOT）。特定のフィールドの定義で別途示されない限り、フィールドは複数回現れてもかまいません（MAY）。¶

実装者は、一部のフィールドにパーセントエンコーディングを使用するURIが含まれる可能性があることを認識しておくべきです（第2.1節 of [RFC3986]に従います）。¶

2.1. コメント

"#"（%x23）記号で始まる任意の行は、コメントとして解釈されなければなりません（MUST）。コメントの内容には、 %x21-7Eおよび%x80-FFFFFの範囲の任意のASCIIまたはUnicode文字に加えて、タブ（%x09）および空白（%x20）文字を含めることができます。¶

例:¶

# This is a comment.

2.2. 行区切り

すべての行は、復帰と改行の文字（CRLF / %x0D %x0A）または改行文字のみ（LF / %x0A）のいずれかで終わらなければなりません（MUST）。¶

2.3. デジタル署名

"security.txt"ファイルは、第7節 of [RFC4880]に記述されているOpenPGPクリアテキスト署名を使用してデジタル署名されることが推奨されます（RECOMMENDED）。デジタル署名が使用される場合、組織は（第2.5.2節に従って）"Canonical"フィールドを使用することも推奨されます（RECOMMENDED）。これにより、デジタル署名がファイルの場所を認証できます。¶

署名の生成に使用された鍵を検証する際には、使用されている鍵が実際に信頼する鍵であることを確認する責任は、常にセキュリティ研究者にあります。¶

2.4. 拡張性

他の多くの形式やプロトコルと同様に、この形式も変化し続けるインターネットの状況に適合するため、時間の経過とともに変更が必要になる可能性があります。そのため、第6.2節で定義されるフィールド用のIANAレジストリを通じて拡張性が提供されます。そのプロセスを通じて登録されたすべてのフィールドは、任意と見なされなければなりません（MUST）。拡張性と相互運用性を促進するため、研究者は明示的にサポートしていないフィールドをすべて無視しなければなりません（MUST）。¶

一般に、実装者は「自分が行うことには保守的に、他者から受け入れるものには寛容に」すべきです（[RFC0793]に従います）。¶

2.5. フィールド定義

別途記載がない限り、すべてのフィールドは任意と見なされなければなりません（MUST）。¶

2.5.1. Acknowledgments

"Acknowledgments"フィールドは、セキュリティ研究者が報告について認められるページへのリンクを示します。参照されるページには、セキュリティ脆弱性を報告し、その修正に協力したセキュリティ研究者を記載するべきです。組織は、将来の攻撃を防ぐために、公開される脆弱性情報を制限するよう注意するべきです。¶

このフィールドがWeb URIを示す場合、それは "https://"で始まらなければなりません（MUST）（第2.7.2節 of [RFC7230]に従います）。¶

例:¶

Acknowledgments: https://example.com/hall-of-fame.html

セキュリティ謝辞ページの例:¶

We would like to thank the following researchers:

(2017-04-15) Frank Denis - Reflected cross-site scripting
(2017-01-02) Alice Quinn  - SQL injection
(2016-12-24) John Buchner - Stored cross-site scripting
(2016-06-10) Anna Richmond - A server configuration issue

2.5.2. Canonical

"Canonical"フィールドは、"security.txt"ファイルが配置されている正規URIを示します。通常は "https://example.com/.well-known/security.txt"のようなものです。このフィールドがWeb URIを示す場合、それは "https://"で始まらなければなりません（MUST）（第2.7.2節 of [RFC7230]に従います）。¶

このフィールドは、指定されたURIから取得された"security.txt"がそのURIに適用されることを意図していることを示しますが、ファイル内に列挙されたすべての正規URIに適用されるものとして解釈してはなりません（MUST NOT）。研究者は、特定の正規URIが適用可能であるかを判断するために、（第2.3節に従った）デジタル署名などの追加の信頼メカニズムを使用するべきです（SHOULD）。¶

このフィールドが"security.txt"ファイル内に現れ、そのファイルを取得するために使用されたURIがいずれのcanonicalフィールドにも記載されていない場合、そのファイルの内容は信頼するべきではありません（SHOULD NOT）。¶

Canonical: https://www.example.com/.well-known/security.txt
Canonical: https://someserver.example.com/.well-known/security.txt

2.5.3. Contact

"Contact"フィールドは、メールアドレス、電話番号、および/または連絡先情報を含むWebページなど、研究者がセキュリティ脆弱性を報告するために使用するべき方法を示します。このフィールドは "security.txt"ファイル内に常に存在しなければなりません（MUST）。このフィールドがWeb URIを示す場合、それは"https://"で始まらなければなりません（MUST）（第2.7.2節 of [RFC7230]に従います）。セキュリティ用メールアドレスは、第 4節 of [RFC2142]で定義される慣習を使用するべきです。¶

値は、第3節 of [RFC3986]に記述されるURI構文に従わなければなりません（MUST）。これは、メールアドレスおよび電話番号を指定するとき、 [RFC6068]および [RFC3966]で定義されているように、 "mailto"および"tel" URIスキームを使用しなければならないことを意味します。このフィールドの値がメールアドレスである場合、（第2.5.4節に従って）暗号化を使用することが推奨されます（RECOMMENDED）。¶

これらは優先順に列挙するべきであり（SHOULD）、最初の出現が優先される連絡方法、2番目の出現が2番目に優先される連絡方法、というようになります。下の例では、最初のメールアドレス（"security@example.com"）が優先される連絡方法です。¶

Contact: mailto:security@example.com
Contact: mailto:security%2Buri%2Bencoded@example.com
Contact: tel:+1-201-555-0123
Contact: https://example.com/security-contact.html

2.5.4. Encryption

"Encryption"フィールドは、セキュリティ研究者が暗号化された通信に使用するべき暗号鍵を示します。鍵はこのフィールド内に現れてはなりません（MUST NOT）。その代わり、このフィールドの値は、鍵を取得できる場所を指すURIでなければなりません（MUST）。このフィールドがWeb URIを示す場合、それは "https://"で始まらなければなりません（MUST）（第2.7.2節 of [RFC7230]に従います）。¶

鍵の真正性を検証する際には、指定された鍵が実際に信頼する鍵であることを確認する責任は、常にセキュリティ研究者にあります。研究者は、この鍵が第2.3節で参照されるデジタル署名の生成に使用されるものだと想定してはなりません。¶

Webサーバーから利用可能なOpenPGP鍵の例:¶

Encryption: https://example.com/pgp-key.txt

OPENPGPKEY DNSレコードから利用可能なOpenPGP鍵の例:¶

Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY

フィンガープリントによって参照されるOpenPGP鍵の例:¶

Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f

2.5.5. Expires

"Expires"フィールドは、"security.txt"ファイル内に含まれるデータがそれ以降古くなったものと見なされ、使用されるべきではない日付と時刻を示します（第5.3節に従います）。このフィールドの値は、 [RFC3339]で定義される [ISO.8601-1]および[ISO.8601-2]のインターネットプロファイルに従って形式化されます。このフィールドの値は、古くなることを避けるため、未来の1年未満にすることが推奨されます（RECOMMENDED）。¶

このフィールドは常に存在しなければならず（MUST）、 2回以上現れてはなりません（MUST NOT）。¶

Expires: 2021-12-31T18:37:07z

2.5.6. Hiring

"Hiring"フィールドは、ベンダーのセキュリティ関連の求人へのリンクに使用されます。このフィールドがWeb URIを示す場合、それは "https://"で始まらなければなりません（MUST）（第2.7.2節 of [RFC7230]に従います）。¶

Hiring: https://example.com/jobs.html

2.5.7. Policy

"Policy"フィールドは、脆弱性開示ポリシーが配置されている場所へのリンクを示します。これは、セキュリティ研究者が組織の脆弱性報告の実践を理解するのに役立ちます。このフィールドがWeb URIを示す場合、それは "https://"で始まらなければなりません（MUST）（第2.7.2節 of [RFC7230]に従います）。¶

例:¶

Policy: https://example.com/disclosure-policy.html

2.5.8. Preferred-Languages

"Preferred-Languages"フィールドは、セキュリティ報告を提出する際に優先される自然言語の集合を示すために使用できます。この集合には、コンマで区切られた複数の値を列挙できます（MAY）。このフィールドが含まれる場合、少なくとも 1つの値が列挙されなければなりません（MUST）。この集合内の値は、（[RFC5646]で定義される）言語タグです。このフィールドがない場合、セキュリティ研究者は英語が使用される言語であると想定してもかまいません（第 4.5節 of [RFC2277]に従います）。¶

それらが現れる順序は優先順位を示すものではなく、列挙された言語は同等の優先度を持つことを意図しています。¶

このフィールドは2回以上現れてはなりません（MUST NOT）。¶

例（英語、スペイン語、フランス語）:¶

Preferred-Languages: en, es, fr

2.6. 署名なし "security.txt" ファイルの例

# Our security address
Contact: mailto:security@example.com

# Our OpenPGP key
Encryption: https://example.com/pgp-key.txt

# Our security policy
Policy: https://example.com/security-policy.html

# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html

Expires: 2021-12-31T18:37:07z

2.7. 署名付き "security.txt" ファイルの例

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

# Canonical URI
Canonical: https://example.com/.well-known/security.txt

# Our security address
Contact: mailto:security@example.com

# Our OpenPGP key
Encryption: https://example.com/pgp-key.txt

# Our security policy
Policy: https://example.com/security-policy.html

# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html

Expires: 2021-12-31T18:37:07z
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2

[signature]
-----END PGP SIGNATURE-----

3. security.txtファイルの場所

Webベースのサービスでは、組織は [RFC8615]に従い、ドメイン名またはIPアドレスの "/.well-known/"パスの下、例としてhttps://example.com/.well-known/security.txtに "security.txt"ファイルを配置しなければなりません（MUST）。レガシー互換性のため、 "security.txt"ファイルはトップレベルパスに配置されることがあるほか、（第6.4節 of [RFC7231]に従って） "/.well-known/"パスの下の"security.txt"ファイルへリダイレクトされることがあります。 "security.txt"ファイルが両方の場所に存在する場合、"/.well-known/"パス内のものが使用されなければなりません（MUST）。¶

このファイルはHTTP 1.0またはそれ以上のバージョンでアクセスされなければならず、ファイルアクセスには"https"スキームを使用しなければなりません（MUST）（第2.7.2節 of [RFC7230]に従います）。これは、デフォルトのcharsetパラメータを"utf-8"に設定した "text/plain"のContent-Typeを持たなければなりません（MUST）（第4.1.3節 of [RFC2046]に従います）。¶

"security.txt"ファイルおよびそのようなファイル内で示されたリソースの取得は、（第6.4節 of [RFC7231]に従って）リダイレクトを引き起こす可能性があります。研究者は、これらのリダイレクトが悪意のあるものではなく、攻撃者によって制御されるリソースを指していないことを確認するため、（第 5.2節に従って）追加の分析を行うべきです。¶

3.1. ファイルの範囲

"security.txt"ファイルは、それを取得するために使用されたURI内のドメインまたはIPアドレスにのみ適用されなければならず（MUST）、そのサブドメインまたは親ドメインには適用されません。 "security.txt"ファイルは、そのファイルを公開している組織が提供する製品およびサービスにも適用されてもかまいません（MAY）。¶

第1.1節に従い、この仕様は脆弱性対応を意図しています。実装者がこれをインシデント対応に使用したい場合は、第5.1節で説明される追加のセキュリティ上の考慮事項を認識しておくべきです。¶

組織は、（第2.5.7節に従って） policyディレクティブを使用し、脆弱性開示プロセスの範囲および詳細に関する追加情報を提供するべきです（SHOULD）。¶

いくつかの例を以下に示します:¶

# The following only applies to example.com.
https://example.com/.well-known/security.txt

# This only applies to subdomain.example.com.
https://subdomain.example.com/.well-known/security.txt

# This security.txt file applies to IPv4 address of 192.0.2.0.
https://192.0.2.0/.well-known/security.txt

# This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
https://[2001:db8:8:4::2]/.well-known/security.txt

4. ファイル形式の説明とABNF文法

"security.txt"ファイルのファイル形式は、第4.1.3節 of [RFC2046]で定義されるプレーンテキスト（MIMEタイプ"text/plain"）でなければならず（MUST）、 Net-Unicode形式[RFC5198]の UTF-8 [RFC3629]を使用してエンコードされなければなりません（MUST）。¶

このファイルの形式は、以下のABNF定義（[RFC5234]のコアABNF規則を取り込み、 [RFC7405]の大文字小文字を区別する文字列サポートを使用する）に従わなければなりません（MUST）。¶

body             =  signed / unsigned

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)

; signed is the production that should match the OpenPGP clearsigned
; document
signed           =  cleartext-header
                    1*(hash-header)
                    CRLF
                    cleartext
                    signature

cleartext-header =  %s"-----BEGIN PGP SIGNED MESSAGE-----" CRLF

hash-header      =  %s"Hash: " hash-alg *("," hash-alg) CRLF

hash-alg         =  token
                      ; imported from RFC 2045; see RFC 4880 Section
                      ; 10.3.3 for a pointer to the registry of
                      ; valid values

;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

eol              =  *WSP [CR] LF

field            =  ; optional fields
                    ack-field /
                    can-field /
                    contact-field / ; optional repeated instances
                    encryption-field /
                    hiring-field /
                    policy-field /
                    ext-field

fs               =  ":"

comment          =  "#" *(WSP / VCHAR / %x80-FFFFF)

ack-field        =  "Acknowledgments" fs SP uri

can-field        =  "Canonical" fs SP uri

contact-field    =  "Contact" fs SP uri

expires-field    =  "Expires" fs SP date-time

encryption-field =  "Encryption" fs SP uri

hiring-field     =  "Hiring" fs SP uri

lang-field       =  "Preferred-Languages" fs SP lang-values

policy-field     =  "Policy" fs SP uri

date-time        =  < imported from Section 5.6 of [RFC3339] >

lang-tag         =  < Language-Tag from Section 2.1 of [RFC5646] >

lang-values      =  lang-tag *(*WSP "," *WSP lang-tag)

uri              =  < URI as per Section 3 of [RFC3986] >

ext-field        =  field-name fs SP unstructured

field-name       =  < imported from Section 3.6.8 of [RFC5322] >

unstructured     =  < imported from Section 3.2.5 of [RFC5322] >

token            =  < imported from Section 5.1 of [RFC2045] >

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

"ext-field"は拡張フィールドを指し、これは第2.4節で説明されています。¶

5. セキュリティに関する考慮事項

URIおよびwell-knownリソースの使用により、以下に概説する考慮事項に加えて、 [RFC3986]および[RFC8615]のセキュリティに関する考慮事項がここに適用されます。¶

5.1. 侵害されたファイルとインシデント対応

Webサイトを侵害した攻撃者は、 "security.txt"ファイルも侵害したり、自身のサイトへのリダイレクトを設定したりできます。これにより、セキュリティ報告が組織に届かなかったり、攻撃者に送信されたりする可能性があります。¶

これを防ぐため、組織は（第2.5.2節に従って）"Canonical"フィールドを使用してファイルの場所を示し、（第2.3節に従って） "security.txt"ファイルにデジタル署名し、改ざんを検出するためにファイルおよび参照されるリソースを定期的に監視するべきです。¶

セキュリティ研究者は、"security.txt"ファイルに含まれる情報を使用する前に、デジタル署名の検証や利用可能な履歴記録の確認を含めて、 "security.txt"ファイルを検証するべきです。"security.txt"ファイルが疑わしい、または侵害されているように見える場合、それは使用されるべきではありません。¶

推奨されませんが、実装者はインシデント対応のために "security.txt"ファイル内で公開された情報を使用することを選択できます。そのような場合、その情報は攻撃者によって侵害されている可能性があるため、そのような情報を信頼する前には極めて慎重であるべきです。研究者は、 Pretty Good Privacy（PGP）署名の帯域外検証、DNSSECベースの手法など、そのようなデータを検証するための追加の方法を使用するべきです。¶

5.2. リダイレクト

ファイルおよびファイル内で参照されるリソースを取得する際、研究者はあらゆるリダイレクトを記録するべきです。これは、それらが攻撃者によって制御される別のドメインまたはIPアドレスにつながる可能性があるためです。ファイル内に含まれる情報を使用する前に、そのようなリダイレクトのさらなる検査が推奨されます。¶

5.3. 不正確または古くなった情報

"security.txt"ファイル内で参照される情報およびリソースが不正確である、または最新に保たれていない場合、セキュリティ報告が組織に届かなかったり、誤った連絡先に送信されたりし、その結果、潜在的なセキュリティ問題が第三者に露出する可能性があります。古くなった情報をこのファイルに持つよりも、 "security.txt"ファイルを持たない方が望ましい場合があります。組織は "Expires"フィールド（第2.5.5節参照）を使用して、ファイル内のデータがいつ無効になるかを研究者に示さなければなりません。¶

組織は、このファイル内の情報およびWebページ、メールアドレス、電話番号などの参照されるリソースが最新に保たれ、アクセス可能であり、組織によって制御され、かつ安全に保たれていることを確実にするべきです。¶

5.4. 意図的に不正形式にされたファイル、リソース、および報告

侵害された、または悪意のあるサイトが、解析コードの弱点を発見または悪用しようとして、非常に大きい、またはその他の形で不正形式のファイルを作成する可能性があります。研究者は、そのようなコードが大きなファイルや不正形式のファイルおよびフィールドに対して堅牢であることを確認するべきであり、32 KBを超えるファイル、2,048文字を超えるフィールド、または1,000行を超えるファイルを解析しないように選択してもかまいません。ABNF文法（第4節で定義）は、これらのファイルを検証する方法としても使用できます。¶

同じ懸念は、"security.txt"ファイル内で参照されるその他の任意のリソース、およびこのファイルの公開の結果として受信される任意のセキュリティ報告にも適用されます。そのようなリソースや報告は、敵対的、不正形式、または悪意のあるものである可能性があります。¶

5.5. テストに対する暗黙の許可はない

"security.txt"ファイルの存在は、研究者によって、それが公開されているドメインまたはIPアドレス、あるいはそのファイルを公開している組織が提供する製品およびサービスに対してセキュリティテストを行う許可を与えるものとして解釈される可能性があります。これにより、研究者による組織へのテストが増加する可能性があります。一方で、 "security.txt"ファイルを公開しないという決定は、そのWebサイトを運営する組織によって、その特定のサイトまたはプロジェクトをテストする許可が拒否されていることを研究者に示す方法として解釈される可能性があります。これにより、その組織にセキュリティ問題を報告する研究者に対して反発が生じる可能性があります。¶

したがって、研究者は、"security.txt"ファイルの存在または不在が、セキュリティテストの許可または拒否を付与するものだと想定するべきではありません。そのような許可は、会社の脆弱性開示ポリシー（第2.5.7節に従う）または新しいフィールド（第2.4節に従う）で示される場合があります。¶

5.6. マルチユーザー環境

マルチユーザー/マルチテナント環境では、ユーザーが "security.txt"ファイルの場所を乗っ取ることが可能な場合があります。組織は、第三者が"security.txt"および"/.well-known/security.txt"という名前でページを作成できないように、ルートで"security.txt"名前空間を予約するべきです。¶

5.7. 転送中のデータの保護

"security.txt"ファイルが転送中に改ざんされることを防ぐため、実装者はファイル自体を提供する際、およびその中で参照される任意のWeb URIを取得する際、 HTTPS（第2.7.2節 of [RFC7230]に従う）を使用しなければなりません（MUST）（この仕様で別途記されている場合を除きます）。TLSハンドシェイクの一部として、研究者は、[RFC6125]および以下の考慮事項に従って、提供されたX.509証明書を検証するべきです:¶

照合はDNS-ID識別子に対してのみ行われます。¶
サーバー証明書内のDNSドメイン名は、識別子内の完全な左端ラベルとしてワイルドカード文字'*'を含んでもかまいません（MAY）。¶

証明書は、Online Certificate Status Protocol（OCSP）[RFC6960]、証明書失効リスト（CRL）、または同様の仕組みによって失効について確認されてもかまいません。¶

"security.txt"ファイルをHTTPS経由で提供できない場合（localhostなど）や、無効な証明書で提供されている場合には、内容が転送中に変更されている可能性があるため、追加の人間による検証が推奨されます。¶

追加の保護層として、組織は（第2.3節に従って）OpenPGPで"security.txt"ファイルにデジタル署名することも推奨されます。また、セキュリティ報告が転送中に改ざんまたは観察されることを防ぐため、組織は、報告提出にHTTPSが使用されていない限り、（第 2.5.4節に従って）暗号鍵を指定するべきです。¶

ただし、そのような鍵の有効性の判断はこの仕様の範囲外です。セキュリティ研究者は、それらを検証するための他の安全な手段を確立する必要があります。¶

5.8. スパムと根拠のない報告

[RFC2142]における懸念と同様に、 "security.txt"ファイルが組織によって公開されると、スパム報告によるサービス拒否攻撃が容易になります。さらに、人間による分析なしに、自動化された方法で、および/または自動スキャンの結果として報告が送信される可能性が高まります。攻撃者は、このファイルを、関係のない第三者のリソースや連絡先情報を列挙することによって、第三者にスパムを送る手段として使用することもできます。¶

組織は、このファイルを公開する利点と、セキュリティ報告を分析するために必要となる可能性のある不利な点および追加リソースを比較検討する必要があります。¶

セキュリティ研究者は、自動化された方法で報告を提出する前、または自動スキャンの結果として報告を提出する前に、"security.txt"ファイル内のすべての情報を確認するべきです。¶

6. IANAに関する考慮事項

実装者は、"security.txt"ファイル内で参照される任意のリソースが、 IANAに登録されていない限り（[RFC8615]に従う）、 Well-Known URIs名前空間を指してはならないことを認識しておくべきです（MUST NOT）。¶

6.1. Well-Known URIs レジストリ

IANAは、（[RFC8615]のテンプレートを使用して） "Well-Known URIs"レジストリを以下の追加値で更新しました:¶

URIサフィックス:: security.txt¶
変更管理者:: IETF¶
仕様文書:: RFC 9116¶
状態:: 永続¶

6.2. security.txt フィールドのレジストリ

IANAは、[RFC8126]に従って "security.txt Fields"レジストリを作成しました。このレジストリは、 "security.txt"ファイルで使用するための、この仕様によって定義されるフィールドを含みます。¶

新しい登録または更新は、 [RFC8126]の 4.5節および5節に記述されている "Expert Review"ガイドラインに従って公開されなければなりません（MUST）。そのように登録された新しいフィールドは、この仕様の新しいバージョンが公開されない限り、この仕様では任意と見なされます。¶

指定専門家は、提案された登録または更新が、この形式を使用する組織および研究者に価値を提供するか、また [ISO.29147.2018]や [CERT.CVD]などの業界で受け入れられている脆弱性開示プロセスの文脈で妥当であるかを判断するべきです。¶

新しい登録および更新は、以下の情報を含まなければなりません（MUST）:¶

登録または更新されるフィールドの名前¶
フィールドの短い説明¶
フィールドが複数回現れることができるかどうか¶
新規または更新後の状態。これは以下のいずれかでなければなりません（MUST）:¶

current:

このフィールドは現在使用中です。¶

deprecated:

このフィールドは使用されていましたが、新たな使用は推奨されません。¶

historic:

このフィールドはもはや現在使用されていません。¶
変更管理者¶
フィールドの仕様が公開されている文書（利用可能な場合）¶

既存の登録は、必要に応じて、この文書の将来の更新によって historicまたはdeprecatedとして示されることがあります。¶

初期レジストリには以下の値が含まれます:¶

フィールド名:: Acknowledgments¶
説明:: セキュリティ研究者が認められるページへのリンク¶
複数回の出現:: はい¶
状態:: current¶
変更管理者:: IETF¶
参照:: RFC 9116¶

フィールド名:: Canonical¶
説明:: このファイルの正規URI¶
複数回の出現:: はい¶
状態:: current¶
変更管理者:: IETF¶
参照:: RFC 9116¶

フィールド名:: Contact¶
説明:: 脆弱性の報告に使用する連絡先情報¶
複数回の出現:: はい¶
状態:: current¶
変更管理者:: IETF¶
参照:: RFC 9116¶

フィールド名:: Expires¶
説明:: このファイルが古くなったものと見なされる日付と時刻¶
複数回の出現:: いいえ¶
状態:: current¶
変更管理者:: IETF¶
参照:: RFC 9116¶

フィールド名:: Encryption¶
説明:: 暗号化された通信に使用する鍵へのリンク¶
複数回の出現:: はい¶
状態:: current¶
変更管理者:: IETF¶
参照:: RFC 9116¶

フィールド名:: Hiring¶
説明:: ベンダーのセキュリティ関連の求人へのリンク¶
複数回の出現:: はい¶
状態:: current¶
変更管理者:: IETF¶
参照:: RFC 9116¶

フィールド名:: Policy¶
説明:: セキュリティポリシーページへのリンク¶
複数回の出現:: はい¶
状態:: current¶
変更管理者:: IETF¶
参照:: RFC 9116¶

フィールド名:: Preferred-Languages¶
説明:: セキュリティ報告に優先される言語のリスト¶
複数回の出現:: いいえ¶
状態:: current¶
変更管理者:: IETF¶
参照:: RFC 9116¶

7. 参考文献

7.1. 規範参考文献

[RFC2046]: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, 1996年11月, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997年3月, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2142]: Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, DOI 10.17487/RFC2142, 1997年5月, <https://www.rfc-editor.org/info/rfc2142>.
[RFC2277]: Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 1998年1月, <https://www.rfc-editor.org/info/rfc2277>.
[RFC3339]: Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, 2002年7月, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3629]: Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003年11月, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3966]: Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, 2004年12月, <https://www.rfc-editor.org/info/rfc3966>.
[RFC3986]: Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005年1月, <https://www.rfc-editor.org/info/rfc3986>.
[RFC4880]: Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, 2007年11月, <https://www.rfc-editor.org/info/rfc4880>.
[RFC5198]: Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, 2008年3月, <https://www.rfc-editor.org/info/rfc5198>.
[RFC5234]: Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, 2008年1月, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5322]: Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, 2008年10月, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5646]: Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2009年9月, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6068]: Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, 2010年10月, <https://www.rfc-editor.org/info/rfc6068>.
[RFC6125]: Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, 2011年3月, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6960]: Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, 2013年6月, <https://www.rfc-editor.org/info/rfc6960>.
[RFC7230]: Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, 2014年6月, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231]: Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, 2014年6月, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7405]: Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, 2014年12月, <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017年5月, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8615]: Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, 2019年5月, <https://www.rfc-editor.org/info/rfc8615>.

7.2. 参考情報文献

[CERT.CVD]: Software Engineering Institute, "The CERT Guide to Coordinated Vulnerability Disclosure", Carnegie Mellon University, CMU/SEI-2017-SR-022, 2017年8月.
[ISO.29147.2018]: ISO, "Information technology - Security techniques - Vulnerability disclosure", ISO/IEC 29147:2018, 2018年10月.
[ISO.8601-1]: ISO, "Date and time - Representations for information interchange - Part 1: Basic rules", ISO 8601-1:2019, 2019年2月.
[ISO.8601-2]: ISO, "Date and time - Representations for information interchange - Part 2: Extensions", ISO 8601-2:2019, 2019年2月.
[RFC0793]: Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, 1981年9月, <https://www.rfc-editor.org/info/rfc793>.
[RFC2196]: Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, DOI 10.17487/RFC2196, 1997年9月, <https://www.rfc-editor.org/info/rfc2196>.
[RFC2350]: Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, DOI 10.17487/RFC2350, 1998年6月, <https://www.rfc-editor.org/info/rfc2350>.
[RFC3013]: Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, DOI 10.17487/RFC3013, 2000年11月, <https://www.rfc-editor.org/info/rfc3013>.
[RFC7485]: Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, "Inventory and Analysis of WHOIS Registration Objects", RFC 7485, DOI 10.17487/RFC7485, 2015年3月, <https://www.rfc-editor.org/info/rfc7485>.
[RFC8126]: Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, 2017年6月, <https://www.rfc-editor.org/info/rfc8126>.