W3C home > Mailing lists > Public > public-web-security@w3.org > March 2011

Re: Syntax presentation (was Re: Unofficial Draft of Content Security Policy)

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Tue, 08 Mar 2011 20:59:43 -0800
Message-ID: <4D77093F.1020104@KingsMountain.com>
To: W3C Web Security Interest Group <public-web-security@w3.org>
Adam Barth replied..
 > On Tue, Mar 8, 2011 at 3:20 PM, Brandon Sterne <bsterne@mozilla.com> wrote:
 >> On 03/08/2011 02:50 PM, Brandon Sterne wrote:
 >>> On 03/03/2011 01:33 PM, Adam Barth wrote:
 >>>> For
 >>>> example, here's a possible grammar for a CSP policy:
 >>>> policy          = directive-list
 >>>> directive-list  = directive *( ";" directive )
 >>>> directive       = *LWS directive-name [ LWS directive-value ]
 >>>> directive-name  = 1*<OCTET, except LWS and ";">
 >>>> directive-value = *<OCTET, except ";">
 >>>> (Of course, the above might not be correct---it's just an example.)
 >>> Hey Adam,
 >>> Your ABNF example defines directive names and values by sequences of
 >>> allowed characters, while the Mozilla grammar enumerates the list of
 >>> "good directives" and makes room for "future directives" using character
 >>> sequences.
 >> I neglected to quote the following sentence from your message, which is
 >> important:
 >>> This approach follows how, for example, HTTP header fields work.
 >>> There's a general grammar for HTTP header fields in general, and then
 >>> a more specific grammar for particular header fields.
 >> The "more specific grammar" for the individual directives is where the
 >> enumeration of known directives will presumably take place.  I withdraw
 >> my previous question and ask this one instead :-)
 >> How does one link directive-name in your grammar to, say, the grammar
 >> for the script-src directive?
 >> In the current revision, you can make the substitution <directive> -->
 >> <src-directive> --> "script-src".  How would this same transition be
 >> made between generic and specific directive syntaxes using ABNF?
 >> Hope my question is clear.
 > One approach is to do this the same way we do this in HTTP:
 > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.2
 > defines the general syntax for headers.
 > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.4
 > lists a bunch of headers that are defined in the spec itself.


 > HTTP also has a registry where folks can define new headers.  For
 > example, <http://tools.ietf.org/html/draft-ietf-httpstate-cookie-23#section-9>
 > adds "Cookie" to the list of headers:
 > http://www.iana.org/assignments/message-headers/perm-headers.html
 > That page lists all the officially registered headers with links to
 > the documents that define them.
 > I'm not sure we need to jump to having a registry right away.  Let's
 > just start with a list of directives in the spec itself.  If CSP
 > becomes a popular way of expressing policy, we might want to add a
 > registry in the future so we don't need to revise the core CSP spec
 > every time someone invents a new directive.

nominally agreed.

Defining a registry isn't "hard" and is something that isn't necessary to add 
to the spec right now, but might be necessary to get the spec to PS RFC (even 
if the presently-defined directives are hard-coded into the spec).

Received on Wednesday, 9 March 2011 05:00:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:18 UTC