Re: CfC: Transition CSP2 to CR.

* Brian Smith wrote:
>Basically, in CSP, anywhere a URI or URI reference is accepted, I want
>CSP to accept IRIs to the same extent that HTML supports IRIs. This
>seems very straightforward for <meta> CSP, and possible but
>problematic for CSP in HTTP header fields.

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.

>As you know, there are a lot of reasons why it is better to keep HTTP
>header field values as pure ASCII, so there needs to be a way to
>specify any IRI in an ASCII encoding--i.e. IRIs that have been
>converted to URIs in the CSP policy need to match the same things that
>the native unicode IRI encoding would match. Note that

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

>Although hostnames in URIs can use UTF-8+%xx-encoding, the punycode
>encoding of hostnames must also be accepted.

That is pretty clear, yes.

>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.
Björn Höhrmann · ·
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 ·
 Available for hire in Berlin (early 2015)  · 

Received on Wednesday, 11 February 2015 11:32:54 UTC