idnits 2.17.1 draft-west-webappsec-csp-reg-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 143: '...xperts), the IESG SHOULD draw from the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2015) is 3073 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. West 3 Internet-Draft Google, Inc 4 Intended status: Informational November 20, 2015 5 Expires: May 23, 2016 7 Initial Assignment for a Content Security Policy Directive Registry 8 draft-west-webappsec-csp-reg-04 10 Abstract 12 This document establishes an Internet Assigned Number Authority 13 (IANA) registry for Content Security Policy directives, and populates 14 that registry with the directives defined in the Content Security 15 Policy Level 2 specification. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 23, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Use of the Registry . . . . . . . . . . . . . . . . . . . . . 2 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 54 3.1. Content Security Policy directives Registry . . . . . . . 3 55 3.2. Registration Policy for Content Security Policy 56 directives . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 5.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 The Content Security Policy specification [CSP] defines a mechanism 67 by which web developers can control the resources which a particular 68 page can fetch or execute, as well as a number of security-relevant 69 policy decisions. 71 The policy language specified in that document consists of an 72 extensible set of "directives", each of which controls a specific 73 resource type or policy decision. This specification establishes a 74 registry to ensure that extensions to CSP are listed and 75 standardized. 77 2. Use of the Registry 79 Content Security Policy directives must be documented in a readily 80 available public specification in order to be registered by IANA. 81 This documentation must fully explain the syntax, intended usage, and 82 semantics of the directive. The intent of this requirement is to 83 assure interoperable independent implementations, and to prevent 84 accidental namespace collisions between implementations of dissimilar 85 features. 87 Documents defining new Content Security Policy directives must 88 register them with IANA, as described in Section 3. The IANA 89 registration policy for such parameters is "Specification Required" 90 [RFC5226], and is further discussed in Section 3.2. 92 3. IANA Considerations 94 This specification creates a new top-level IANA registry named 95 "Content Security Policy directives". 97 3.1. Content Security Policy directives Registry 99 New Content Security Policy directives, and updates to existing 100 directives, must be registered with IANA. 102 When registering a new Content Security Policy directive, the 103 following information must be provided: 105 o The directive's name, an ASCII string conforming to the 106 "directive-name" rule specified in Section 4.1 of [CSP]. The ABNF 107 [RFC5234] is as follows: 109 directive-name = 1*( ALPHA / DIGIT / "-" ) 111 o A reference to the readily available public specification defining 112 the new directive's syntax, usage, and semantics. 114 The following table contains the initial values for this registry: 116 +-----------------+-----------+ 117 | Directive Name | Reference | 118 +-----------------+-----------+ 119 | base-uri | [CSP] | 120 | child-src | [CSP] | 121 | connect-src | [CSP] | 122 | default-src | [CSP] | 123 | font-src | [CSP] | 124 | form-action | [CSP] | 125 | frame-ancestors | [CSP] | 126 | frame-src | [CSP] | 127 | img-src | [CSP] | 128 | media-src | [CSP] | 129 | object-src | [CSP] | 130 | plugin-types | [CSP] | 131 | report-uri | [CSP] | 132 | sandbox | [CSP] | 133 | script-src | [CSP] | 134 | style-src | [CSP] | 135 +-----------------+-----------+ 137 3.2. Registration Policy for Content Security Policy directives 139 The registration policy for Content Security Policy directives is 140 "Specification Required" [RFC5226], which uses a designated expert to 141 review the specification. 143 When appointing an Expert (or Experts), the IESG SHOULD draw from the 144 W3C's security community, coordinating through the liaison. 146 The designated expert, when deliberating on whether to include a new 147 directive in the registry, should consider the following criteria. 148 This is not an exhaustive list, but representative of the issues to 149 consider when rendering a decision: 151 o Content Security Policy is a restrictive feature, which allows web 152 developers to deny themselves access to resources and APIs which 153 would otherwise be available. Deploying Content Security Policy 154 is, therefore, a strict reduction in risk. The expert should 155 carefully consider whether proposed directives would violate this 156 property. 158 o Granular directives are valuable, but the expert should strive to 159 strike a reasonable balance between providing developers with all 160 the knobs and switches possible, and providing only those with 161 known security implications. 163 4. Security Considerations 165 The registry in this document does not in itself have security 166 implications. The directives specified, however, certainly do. The 167 documents referenced when registering new directives must contain 168 detailed security and privacy considerations sections, and should 169 contain usage information which informs web developers as to the 170 directive's expected implementation. 172 5. References 174 5.1. Normative References 176 [CSP] West, M., Barth, A., and D. Veditz, "Content Security 177 Policy Level 2", n.d., . 179 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 180 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 181 DOI 10.17487/RFC5226, May 2008, 182 . 184 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 185 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 186 RFC5234, January 2008, 187 . 189 5.2. Informative References 191 [RFC5341] Jennings, C. and V. Gurbani, "The Internet Assigned Number 192 Authority (IANA) tel Uniform Resource Identifier (URI) 193 Parameter Registry", RFC 5341, DOI 10.17487/RFC5341, 194 September 2008, . 196 Appendix A. Acknowledgements 198 Much of this document's structure comes from [RFC5341]. Thank you to 199 Cullen Jennings and Vijay K. Gurbani for giving me a reasonable 200 template to work within, and to Barry Leiba for his helpful 201 commentary and suggestions. 203 Author's Address 205 Mike West 206 Google, Inc 208 Email: mkwst@google.com 209 URI: https://mikewest.org/