W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CfC: Transition CSP2 to CR.

From: Brian Smith <brian@briansmith.org>
Date: Wed, 11 Feb 2015 03:53:04 -0800
Message-ID: <CAFewVt7ZB6bg5m7aaS8hUSReW96udbPwLUbocFMAK=WRCNshJA@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>
Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> I think there is currently no adequate specification to reference for
> use in a security-sensitive environment. Much as I would agree that
> non-ASCII characters in URIs and parts of URIs or equivalent protocol
> elements should be permissable wherever ASCII is permissable, I think
> it would be better to do this at a later time for CSP.

These issues exist for Link and other header fields too. I think there
should be a general framework for solutions to this problem of IRIs in
HTTP header fields. I agree that CSP 2 shouldn't have to create that

> (You ended that paragraph in the middle of a sentence.)

Just ignore that.

>>You mentioned that urlencode(normalize(utf8encode(...))) is most
>>probably wrong. However, consider a document that is NOT in UTF-8
>>encoding, but instead in Shift-JIS. I believe that there does need to
>>be a first step of converting the text to Unicode and then UTF-8
>>encoding the Unicode text. However, I could very well be wrong here.
> You have to decode character encodings, sure, but that does not seem
> relevant here.

It is relevant for CSP policies that are defined in <meta>.

Received on Wednesday, 11 February 2015 11:53:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC