Internet Engineering Task Force (IETF) M. West
Request for Comments: 7762 Google, Inc
Category: Informational January 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. West
Request for Comments: 7762 Google, Inc
Category: Informational January 2016
ISSN: 2070-1721
Initial Assignment for the Content Security Policy Directives Registry
内容安全策略指令注册表的初始分配
Abstract
摘要
This document establishes an Internet Assigned Number Authority (IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content Security Policy Level 2 specification.
本文档为内容安全策略指令建立Internet分配号码管理局（IANA）注册表，并使用内容安全策略级别2规范中定义的指令填充该注册表。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7762.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7762.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4.1. Content Security Policy Directives Registry . . . . . . . 3
4.2. Registration Policy for Content Security Policy
Directives . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4.1. Content Security Policy Directives Registry . . . . . . . 3
4.2. Registration Policy for Content Security Policy
Directives . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
The Content Security Policy (CSP) specification [CSP] defines a mechanism that web developers can use to control the resources that a particular page can fetch or execute, as well as a number of additional security-relevant policy decisions.
内容安全策略（CSP）规范[CSP]定义了一种机制，web开发人员可以使用该机制来控制特定页面可以获取或执行的资源，以及许多其他与安全相关的策略决策。
The policy language specified in that document consists of an extensible set of "directives", each of which controls a specific resource type or policy decision. This specification establishes a registry to ensure that extensions to CSP are listed and standardized.
该文档中指定的策略语言由一组可扩展的“指令”组成，每个指令控制特定的资源类型或策略决策。本规范建立了一个注册表，以确保CSP的扩展被列出并标准化。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Content Security Policy directives must be documented in a readily available public specification in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the directive. The intent of this requirement is to assure interoperable independent implementations, and to prevent accidental namespace collisions between implementations of dissimilar features.
内容安全策略指令必须记录在现成的公共规范中，以便由IANA注册。本文档必须充分解释指令的语法、预期用途和语义。此需求的目的是确保可互操作的独立实现，并防止不同功能的实现之间发生意外的命名空间冲突。
Documents defining new Content Security Policy directives MUST register them with IANA, as described in Section 3. The IANA
定义新内容安全策略指令的文档必须向IANA注册，如第3节所述。IANA
registration policy for such parameters is "Specification Required" [RFC5226] and is further discussed in Section 3.2.
此类参数的注册政策为“所需规范”[RFC5226]，并在第3.2节中进一步讨论。
This specification creates a new top-level IANA registry named "Content Security Policy Directives".
此规范创建了一个名为“内容安全策略指令”的新顶级IANA注册表。
New Content Security Policy directives, and updates to existing directives, MUST be registered with IANA.
新的内容安全策略指令以及对现有指令的更新必须向IANA注册。
When registering a new Content Security Policy directive, the following information MUST be provided:
注册新的内容安全策略指令时，必须提供以下信息：
o The directive's name, an ASCII string conforming to the "directive-name" rule specified in Section 4.1 of [CSP]. The ABNF [RFC5234] is as follows:
o 指令名称，符合[CSP]第4.1节规定的“指令名称”规则的ASCII字符串。ABNF[RFC5234]如下所示：
directive-name = 1*( ALPHA / DIGIT / "-" )
directive-name = 1*( ALPHA / DIGIT / "-" )
o A reference to the readily available public specification defining the new directive's syntax, usage, and semantics.
o 对定义新指令语法、用法和语义的现成公共规范的引用。
The following table contains the initial values for this registry:
下表包含此注册表的初始值：
+-----------------+-----------+
| Directive Name | Reference |
+-----------------+-----------+
| base-uri | [CSP] |
| child-src | [CSP] |
| connect-src | [CSP] |
| default-src | [CSP] |
| font-src | [CSP] |
| form-action | [CSP] |
| frame-ancestors | [CSP] |
| frame-src | [CSP] |
| img-src | [CSP] |
| media-src | [CSP] |
| object-src | [CSP] |
| plugin-types | [CSP] |
| report-uri | [CSP] |
| sandbox | [CSP] |
| script-src | [CSP] |
| style-src | [CSP] |
+-----------------+-----------+
+-----------------+-----------+
| Directive Name | Reference |
+-----------------+-----------+
| base-uri | [CSP] |
| child-src | [CSP] |
| connect-src | [CSP] |
| default-src | [CSP] |
| font-src | [CSP] |
| form-action | [CSP] |
| frame-ancestors | [CSP] |
| frame-src | [CSP] |
| img-src | [CSP] |
| media-src | [CSP] |
| object-src | [CSP] |
| plugin-types | [CSP] |
| report-uri | [CSP] |
| sandbox | [CSP] |
| script-src | [CSP] |
| style-src | [CSP] |
+-----------------+-----------+
The registration policy for Content Security Policy directives is "Specification Required" [RFC5226], which uses a designated expert to review the specification.
内容安全策略指令的注册策略是“需要规范”[RFC5226]，它使用指定的专家来审查规范。
When appointing an Expert (or Experts), the IESG SHOULD draw from the W3C's security community, coordinating through the liaison.
在任命专家时，IESG应从W3C的安全社区中抽调人员，通过联络进行协调。
The designated expert, when deliberating on whether to include a new directive in the registry, SHOULD consider the following criteria. This is not an exhaustive list, but representative of the issues to consider when rendering a decision:
指定专家在考虑是否在注册中心中包括新指令时，应考虑以下标准。这不是一个详尽的清单，而是代表在作出决定时要考虑的问题：
o Content Security Policy is a restrictive feature, which allows web developers to deny themselves access to resources and APIs that would otherwise be available. Deploying Content Security Policy is, therefore, a strict reduction in risk. The expert SHOULD carefully consider whether proposed directives would violate this property.
o 内容安全策略是一项限制性功能，它允许web开发人员拒绝自己访问原本可用的资源和API。因此，部署内容安全策略可以严格降低风险。专家应该仔细考虑建议的指令是否会违反这个属性。
o Granular directives are valuable, but the expert SHOULD strive to strike a reasonable balance between providing developers with all the knobs and switches possible and providing only those with known security implications.
o 粒度指令是有价值的，但是专家应该努力在为开发人员提供所有可能的旋钮和开关与只提供已知安全含义的旋钮和开关之间取得合理的平衡。
The registry in this document does not in itself have security implications. The directives specified, however, certainly do. The documents referenced when registering new directives MUST contain detailed security and privacy considerations sections, and SHOULD contain usage information that informs web developers as to the directive's expected implementation.
本文件中的注册表本身不涉及安全问题。然而，指定的指令确实如此。注册新指令时引用的文档必须包含详细的安全和隐私注意事项部分，并应包含通知web开发人员该指令预期实现的使用信息。
[CSP] West, M., Barth, A., and D. Veditz, "Content Security Policy Level 2", July 2015, <https://www.w3.org/TR/CSP2>.
[CSP]West，M.，Barth，A.，和D.Veditz，“内容安全策略级别2”，2015年7月<https://www.w3.org/TR/CSP2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5341] Jennings, C. and V. Gurbani, "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", RFC 5341, DOI 10.17487/RFC5341, September 2008, <http://www.rfc-editor.org/info/rfc5341>.
[RFC5341]Jennings，C.和V.Gurbani，“互联网分配号码管理局（IANA）电话统一资源标识符（URI）参数注册表”，RFC 5341，DOI 10.17487/RFC53412008年9月<http://www.rfc-editor.org/info/rfc5341>.
Acknowledgements
致谢
Much of this document's structure comes from [RFC5341]. Thank you to Cullen Jennings and Vijay K. Gurbani for giving me a reasonable template to work within and to Barry Leiba for his helpful commentary and suggestions.
本文档的大部分结构来自[RFC5341]。感谢Cullen Jennings和Vijay K.Gurbani为我提供了一个合理的模板，并感谢Barry Leiba提供了有益的评论和建议。
Author's Address
作者地址
Mike West Google, Inc
迈克·韦斯特谷歌公司
Email: mkwst@google.com
URI: https://mikewest.org/
Email: mkwst@google.com
URI: https://mikewest.org/