互联网工程任务组 (IETF) M. Nottingham 征求意见稿：8615 2019 年 5 月 废止：5785 更新：7230、7595 类别：标准轨道 ISSN: 2070-1721 知名统一资源标识符（URI） 摘要 本备忘录为所选统一资源标识符（URI）方案中的“知名位置” 定义了路径前缀 "/.well-known/"。 这样做废止了 RFC 5785，并更新了 RFC 7230 中定义的 URI 方案， 以保留该空间。它还更新了 RFC 7595，以便在注册表中跟踪支持 知名 URI 的 URI 方案。 本备忘录的状态 这是一份互联网标准轨道文档。 本文档是互联网工程任务组（IETF）的产物。它代表了 IETF 社群的共识。它已经过公开审查，并由互联网工程指导组 （IESG）批准发布。有关互联网标准的更多信息可见 RFC 7841 第 2 节。 有关本文档当前状态、任何勘误以及如何提供反馈的信息， 可从 https://www.rfc-editor.org/info/rfc8615 获得。 版权声明 版权所有 (c) 2019 IETF Trust 以及标识为本文档作者的人员。 保留所有权利。 本文档受 BCP 78 以及本文档发布日期生效的 IETF Trust 与 IETF 文档相关的法律条款 （https://trustee.ietf.org/license-info）约束。 请仔细阅读这些文档，因为它们描述了你关于本文档的权利和限制。 从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节所述的简化 BSD 许可证文本，并按简化 BSD 许可证 所述不提供担保。 Nottingham 标准轨道 [第 1 页]
RFC 8615 知名 URI 2019 年 5 月 目录 1. 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 记号约定 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 知名 URI . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. 注册知名 URI . . . . . . . . . . . . . . . . . . . . . 4 4. 安全考虑事项 . . . . . . . . . . . . . . . . . . . . . . 5 4.1. 保护知名资源 . . . . . . . . . . . . . . . . . . . . . 6 4.2. 与 Web 浏览的交互 . . . . . . . . . . . . . . . . . . 6 4.3. 限定应用的作用域 . . . . . . . . . . . . . . . . . . 7 4.4. 隐藏能力 . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA 考虑事项 . . . . . . . . . . . . . . . . . . . . . . 8 5.1. 知名 URI 注册表 . . . . . . . . . . . . . . . . . . . 8 5.2. 统一资源标识符（URI）方案注册表 . . . . . . . . . 9 6. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. 规范性参考文献 . . . . . . . . . . . . . . . . . . . 9 6.2. 资料性参考文献 . . . . . . . . . . . . . . . . . . . 10 附录 A. 常见问题 . . . . . . . . . . . . . . . . . . . . . 12 附录 B. 相对于 RFC 5785 的变更 . . . . . . . . . . . . . . 12 作者地址 . . . . . . . . . . . . . . . . . . . . . . . . . 12 1. 引言 Web 上的某些应用在发出请求之前，需要发现有关某个源 [RFC6454] 的信息（有时称为“站点范围元数据”）。例如， Robots Exclusion Protocol （http://www.robotstxt.org）规定了一种方式，使自动化进程能够 获取访问资源的许可；同样，Platform for Privacy Preferences [P3P] 告诉用户代理如何在与源服务器交互之前发现隐私 政策。 虽然有若干方式可以访问每个资源的元数据（例如 HTTP 首部字段、 Web Distributed Authoring and Versioning (WebDAV) [RFC4918] 中的 PROPFIND），但与这些方式相关的感知开销（无论是客户端 感知的延迟，还是部署困难，或二者兼有）往往妨碍了它们在这些 场景中的使用。 与此同时，将 HTTP 用作非 Web 协议底层承载的做法已经变得 更加流行。有时，此类协议需要一种方式来定位给定主机上的一个 或多个资源。 当发生这种情况时，一种解决方案是为与整个源相关的数据或服务 指定一个“知名位置”，以便能够轻松定位它。然而，这种做法存在 缺点：它既可能与其他此类指定的“知名位置”发生冲突，也可能与 该源已经创建（或希望创建）的资源发生冲突。此外，定义知名位置 会篡夺该源对其自身 URI 空间的控制 [RFC7320]。 Nottingham 标准轨道 [第 2 页]
RFC 8615 知名 URI 2019 年 5 月 为了解决这些用例，本备忘录在 HTTP、HTTPS、WebSocket (WS) 和 Secure WebSocket (WSS) URI 中为这些“知名位置”保留了一个 路径前缀 "/.well-known/"。未来需要为此类元数据定义资源的 规范可以注册其用途，以避免冲突，并尽量减少对源 URI 空间的 影响。 知名 URI 也可以与其他 URI 方案一起使用，但仅当这些方案的定义 明确允许这样做时才可以。 2. 记号约定 本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、 "SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、 "NOT RECOMMENDED"、"MAY" 和 "OPTIONAL"，当且仅当它们如本文所示 以全大写形式出现时，应按 BCP 14 [RFC2119] [RFC8174] 中的说明解释。 3. 知名 URI 知名 URI 是一种 URI [RFC3986]，其路径组件以字符 "/.well-known/" 开头，前提是该方案被明确规定支持知名 URI。 例如，如果某个应用注册了名称 'example'，那么在 'http://www.example.com/' 上对应的知名 URI 将是 'http://www.example.com/.well-known/example'。 本规范更新了 "http" [RFC7230] 和 "https" [RFC7230] 方案，以支持知名 URI。其他现有方案可以使用适当流程来更新其 定义；例如，[RFC8307] 就为 "ws" 和 "wss" 方案这样做。 "Uniform Resource Identifier (URI) Schemes" 注册表跟踪哪些方案 支持知名 URI；见第 5.2 节。 希望铸造新的知名 URI 的应用必须注册它们，并遵循 第 5.1 节中的流程，同时满足以下要求。 注册名称必须符合 [RFC3986] 中的 "segment-nz" 产生式。 这意味着它们不能包含 "/" 字符。 特定应用的注册名称应该相应地精确；不鼓励“占用”通用术语。 例如，如果 Example 应用需要一个用于元数据的知名位置， 合适的注册名称可以是 "example-metadata"，甚至是 "example.com-metadata"，而不是 "metadata"。 Nottingham 标准轨道 [第 3 页]
RFC 8615 知名 URI 2019 年 5 月 注册至少会引用一个规范，该规范定义通过解引用知名 URI 所获得的 格式和相关媒体类型，以及可与该知名 URI 一起使用的 URI 方案。 如果没有明确指定 URI 方案，则假定为 "http" 和 "https"。 通常，应用会使用给定方案的默认端口；如果使用了替代端口， 则有关应用必须明确指定它。 注册也可以包含附加信息，例如要追加到知名 URI 的附加路径组件、 查询字符串和/或片段标识符的语法，或者特定于协议的细节 （例如 HTTP [RFC7231] 方法处理）。 请注意，本规范既不定义如何确定用于为特定应用查找知名 URI 的 主机名，也不定义通过解引用该知名 URI 所发现元数据的作用域； 二者都应由应用本身定义。 此外，本规范没有为位于 "/.well-known/" 的资源定义格式或媒体 类型，客户端不应期望该位置存在资源。 知名 URI 根植于路径层次结构的顶部；按定义，它们在路径的其他 部分并不是知名的。例如，"/.well-known/example" 是知名 URI， 而 "/foo/.well-known/example" 不是。 另请参见第 4 节，了解关于知名位置的安全考虑事项。 3.1. 注册知名 URI "Well-Known URIs" 注册表位于 <https://www.iana.org/assignments/well-known-uris/>。注册请求 可以按照该处的说明提交，也可以通过向 <wellknown-uri-review@ietf.org> 邮件列表发送电子邮件来提交。 注册请求至少包括以下信息： URI suffix: 相对于 "/.well-known/" 所请求的知名 URI 名称； 例如 "example"。 Nottingham 标准轨道 [第 4 页]
RFC 8615 知名 URI 2019 年 5 月 Change controller: 对于标准轨道 RFC，写明 "IETF"。对于其他项， 给出负责方的名称。也可以包含其他细节（例如电子邮件地址、 主页 URI）。 Specification document(s): 指向规定该字段的文档的引用，最好 包括可用于获取该文档副本的 URI。也可以包含相关章节的指示， 但这不是必需的。 Status: "permanent" 或 "provisional" 之一。见下文指导。 Related information: 可选地，引用包含进一步相关信息的附加文档。 已注册值的一般要求在第 3 节中描述。 由标准轨道 RFC 和其他开放标准（在 [RFC2026] 第 7.1.1 节 意义上）定义的值，其状态为 "permanent"。如果专家在与社群 协商后发现其他值正在使用，也可以将其注册为 permanent。 其他值应注册为 "provisional"。 如果专家在与社群协商后发现 provisional 条目未被使用，专家可以 移除这些条目。专家可以将 provisional 条目的状态更改为 permanent；这样做时，专家应考虑该值被使用的广泛程度，并事先 咨询社群。 请注意，上文中的“咨询社群”指的是负责所涉及 URI 方案的人群。 通常，这会在相应工作组（可能已经结束）的邮件列表上进行， 如果不存在这样的列表，则在 <art@ietf.org> 上进行。 如果专家确定某个未注册的知名 URI 已被广泛部署，并且不太可能 以其他方式及时注册，则知名 URI 可以由第三方（包括专家）注册。 此类注册仍须满足所定义的要求，包括需要引用规范。 4. 安全考虑事项 铸造新知名 URI 的应用以及部署它们的管理员，需要考虑若干与 安全相关的问题，包括但不限于敏感数据暴露、拒绝服务攻击 （除了普通负载问题之外）、服务器 Nottingham 标准轨道 [第 5 页]
RFC 8615 知名 URI 2019 年 5 月 和客户端认证、易受 DNS 重新绑定攻击的影响，以及有限的服务器 访问权限却能影响知名 URI 服务方式的攻击。 [RFC3552] 包含一些可能与应用协议以及部署它们的管理员相关的 潜在安全考虑事项示例。 4.1. 保护知名资源 由于知名位置实际上代表整个源，服务器操作员应适当地控制对这些 位置的写入能力。当多个实体共处于同一源上时，这一点尤其重要。 即使对于由单个实体控制并代表单个实体的源，也应谨慎确保不会 无意授予对知名位置的写入访问权限，无论是通过服务器配置从外部 授予，还是通过实现权限（例如在文件系统上）在本地授予。 4.2. 与 Web 浏览的交互 对 "http" 或 "https" URL 使用知名 URI 的应用需要意识到， 知名资源将可被 Web 浏览器访问，因此能够被从该源其他部分获得的 内容操纵。如果攻击者能够注入内容（例如通过跨站脚本漏洞）， 他们就能够向知名资源发起可能任意的请求。 HTTP 和 HTTPS 还将源用作许多其他机制的安全边界，包括但不限于 cookie [RFC6265]、Web Storage [WEBSTORAGE] 以及各种能力。 定义知名位置的应用不应假定它对这些机制具有独占访问权，或假定 它是使用该源的唯一应用。根据应用的性质，缓解措施可以包括： o 加密敏感信息 o 允许灵活使用标识符（例如 cookie 名称），以避免与其他应用 发生冲突 o 在 cookie 上使用 'HttpOnly' 标志，以确保 cookie 不会暴露给 浏览器脚本语言 [RFC6265] o 在 cookie 上使用 'Path' 参数，以确保它们不会对源的其他部分 可用 [RFC6265] Nottingham 标准轨道 [第 6 页]
RFC 8615 知名 URI 2019 年 5 月 o 使用 X-Content-Type-Options: nosniff [FETCH]，以确保攻击者 控制下的内容不会被诱导成由 Web 浏览器解释为主动内容的形式 其他良好实践包括： o 在 Content-Type 首部字段中使用特定于应用的媒体类型，并要求 客户端在未使用它时失败 o 使用 Content-Security-Policy [CSP] 约束主动内容 （例如 HTML [HTML5]）的能力，从而缓解跨站脚本攻击 o 使用 Referrer-Policy [REFERRER-POLICY]，防止 URL 中的敏感数据 在 Referer 请求首部字段中泄漏 o 避免对任何敏感信息（例如认证令牌、密码）使用压缩，因为 Web 浏览器提供的脚本环境允许攻击者反复探测压缩空间； 如果攻击者能够访问通信路径，他们就可以利用这种能力恢复 该信息。 4.3. 限定应用的作用域 本备忘录不指定从知名 URI 获得的信息的适用作用域，也不指定如何 为特定应用发现知名 URI。 使用此机制的各个应用必须定义这两个方面；如果未指定这一点， 实现偏差以及对应用之间边界的混淆可能会导致安全问题。 将在知名 URI 中发现的元数据应用于并非共处同一源上的资源， 会带来管理和安全方面的风险。例如，允许 "https://example.com/.well-known/example" 将策略应用到 "https://department.example.com"、"https://www.example.com"，甚至 "https://www.example.com:8000"，会假定主机之间存在某种关系， 而实际上可能并不存在，从而把控制权交给潜在攻击者。 同样，规定在特定主机名上的知名 URI 用于引导某个协议，可能会 导致大量不需要的请求。例如，如果使用知名 HTTPS URI 来查找关于 电子邮件等单独服务的策略，即使 Web 服务器未实现该知名 URI， 也可能导致请求洪水 Nottingham 标准轨道 [第 7 页]
RFC 8615 知名 URI 2019 年 5 月 涌向 Web 服务器。此类不需要的请求可能类似于拒绝服务攻击。 4.4. 隐藏能力 使用知名位置的应用应考虑到，一些服务器管理员可能不知道它们的 存在（尤其是在会隐藏名称以 "." 开头的目录的操作系统上）。 这意味着，如果攻击者拥有对 .well-known 目录的写入权限， 他们就能够控制其内容，而管理员可能并未意识到这一点。 5. IANA 考虑事项 5.1. 知名 URI 注册表 本规范更新了最初在 [RFC5785] 中定义的 "Well- Known URI" 注册表的注册流程；见第 3.1 节。 知名 URI 根据一名或多名专家的建议进行注册，并要求提供规范 （使用 [RFC8126] 中的术语）。 专家在评估注册请求时的主要考虑事项是： o 符合第 3 节中的要求 o 规范文档的可获得性和稳定性 o 第 4 节中概述的考虑事项 IANA 将把任何收到的注册请求发送者引导至本文档，并在已定义的 情况下，引导至专家制定的流程；通常，这意味着将他们引向注册表 网页。 根据本文档，IANA 已经： o 将注册流程更新为需要规范。 o 向注册表添加了 "Status" 列，并将所有现有注册标记为 "permanent"。 Nottingham 标准轨道 [第 8 页]
RFC 8615 知名 URI 2019 年 5 月 5.2. 统一资源标识符（URI）方案注册表 本规范向 "Uniform Resource Identifier (URI) Schemes" 注册表的 注册模板添加了一个字段，名称为 "Well-Known URI Support"， 默认值为 "-"。 如果某个 URI 方案已被明确规定按第 3 节使用知名 URI， 该值会更改为对该规范的引用。表 1 给出了不等于 "-" 的初始值。 +------------+------------------------+ | URI 方案 | 知名 URI 支持 | +------------+------------------------+ | coap | [RFC7252] | | coap+tcp | [RFC8323] | | coap+ws | [RFC8323] | | coaps | [RFC7252] | | coaps+tcp | [RFC8323] | | coaps+ws | [RFC8323] | | http | [RFC8615] | | https | [RFC8615] | | ws | [RFC8307] | | wss | [RFC8307] | +------------+------------------------+ 表 1：URI 方案注册表中新增列非空的行 6. 参考文献 6.1. 规范性参考文献 [RFC2119] Bradner, S., "用于在 RFC 中指示要求级别的关键词", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997 年 3 月, <https://www.rfc-editor.org/info/rfc2119>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "统一 资源标识符（URI）：通用语法", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005 年 1 月, <https://www.rfc-editor.org/info/rfc3986>. [RFC6454] Barth, A., "Web 源概念", RFC 6454, DOI 10.17487/RFC6454, 2011 年 12 月, <https://www.rfc-editor.org/info/rfc6454>. Nottingham 标准轨道 [第 9 页]
RFC 8615 知名 URI 2019 年 5 月 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "超文本传输 协议（HTTP/1.1）：消息语法和路由", RFC 7230, DOI 10.17487/RFC7230, 2014 年 6 月, <https://www.rfc-editor.org/info/rfc7230>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "编写 IANA 考虑事项章节的指南", BCP 26, RFC 8126, DOI 10.17487/RFC8126, 2017 年 6 月, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "RFC 2119 关键词中大写与小写的歧义", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017 年 5 月, <https://www.rfc-editor.org/info/rfc8174>. 6.2. 资料性参考文献 [CSP] West, M., "Content Security Policy Level 3", World Wide Web Consortium WD WD-CSP3-20160913, 2016 年 9 月, <https://www.w3.org/TR/2016/WD-CSP3-20160913>. [FETCH] WHATWG, "Fetch - 现行标准", <https://fetch.spec.whatwg.org>. [HTML5] WHATWG, "HTML - 现行标准", <https://html.spec.whatwg.org>. [P3P] Marchiori, M., "Platform for Privacy Preferences 1.0 (P3P1.0) 规范", World Wide Web Consortium Recommendation REC-P3P-20020416, 2002 年 4 月, <http://www.w3.org/TR/2002/REC-P3P-20020416>. [REFERRER-POLICY] Eisinger, J. and E. Stark, "Referrer Policy", World Wide Web Consortium CR CR-referrer-policy-20170126, 2017 年 1 月, <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>. [RFC2026] Bradner, S., "互联网标准流程 -- 修订版 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, 1996 年 10 月, <https://www.rfc-editor.org/info/rfc2026>. [RFC3552] Rescorla, E. and B. Korver, "编写 RFC 文本中安全考虑 事项的指南", BCP 72, RFC 3552, DOI 10.17487/RFC3552, 2003 年 7 月, <https://www.rfc-editor.org/info/rfc3552>. Nottingham 标准轨道 [第 10 页]
RFC 8615 知名 URI 2019 年 5 月 [RFC4918] Dusseault, L., Ed., "用于 Web 分布式创作与版本控制 （WebDAV）的 HTTP 扩展", RFC 4918, DOI 10.17487/RFC4918, 2007 年 6 月, <https://www.rfc-editor.org/info/rfc4918>. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "定义知名统一资源 标识符（URI）", RFC 5785, DOI 10.17487/RFC5785, 2010 年 4 月, <https://www.rfc-editor.org/info/rfc5785>. [RFC6265] Barth, A., "HTTP 状态管理机制", RFC 6265, DOI 10.17487/RFC6265, 2011 年 4 月, <https://www.rfc-editor.org/info/rfc6265>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "超文本传输 协议（HTTP/1.1）：语义与内容", RFC 7231, DOI 10.17487/RFC7231, 2014 年 6 月, <https://www.rfc-editor.org/info/rfc7231>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "受限应用协议 （CoAP）", RFC 7252, DOI 10.17487/RFC7252, 2014 年 6 月, <https://www.rfc-editor.org/info/rfc7252>. [RFC7320] Nottingham, M., "URI 设计与所有权", BCP 190, RFC 7320, DOI 10.17487/RFC7320, 2014 年 7 月, <https://www.rfc-editor.org/info/rfc7320>. [RFC8307] Bormann, C., "WebSocket 协议的知名 URI", RFC 8307, DOI 10.17487/RFC8307, 2018 年 1 月, <https://www.rfc-editor.org/info/rfc8307>. [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "基于 TCP、TLS 和 WebSocket 的 CoAP（受限应用协议）", RFC 8323, DOI 10.17487/RFC8323, 2018 年 2 月, <https://www.rfc-editor.org/info/rfc8323>. [WEBSTORAGE] Hickson, I., "Web Storage（第二版）", World Wide Web Consortium Recommendation REC-webstorage-20160419, 2016 年 4 月, <http://www.w3.org/TR/2016/REC-webstorage-20160419>. Nottingham 标准轨道 [第 11 页]
RFC 8615 知名 URI 2019 年 5 月 附录 A. 常见问题 知名位置对 Web 来说不是坏事吗？ 是的，但由于各种原因——既有技术原因，也有社会原因—— 它们有时是必要的。本备忘录为它们定义了一个“沙箱”， 以降低冲突风险，并尽量减少对站点上既有 URI 的影响。 为什么是 "/.well-known?" 它很短、具有描述性，并且根据搜索索引显示，并未被广泛使用。 这对现有机制（例如 P3P 和 robots.txt）有什么影响？ 没有影响，除非它们选择使用此机制。 为什么不定义每个目录的知名位置？ 允许每个 URI 路径段都有一个知名位置（例如 "/images/.well-known/"）会增加与站点上既有 URI 发生冲突的 风险，而且通常发现这些解决方案扩展性不好，因为它们过于 “话多”。 附录 B. 相对于 RFC 5785 的变更 o 允许非 Web 知名位置 o 调整了 IANA 说明 o 更新了参考文献 o 作出了各种其他澄清 o 在 "Uniform Resource Identifier (URI) Schemes" 注册表中跟踪 支持方案 作者地址 Mark Nottingham Email: mnot@mnot.net URI: https://www.mnot.net/ Nottingham 标准轨道 [第 12 页]