Subject: Re: [pkix] [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt

From: Sean Leonard <[email-masked]>
Date: Sun, 11 Jan 2015 14:10:11 -0800

[Adding pkix@]
On the two intertwined points:

On 1/11/2015 8:28 AM, Julian Reschke wrote:
> On 2015-01-11 17:19, Sam Ruby wrote:
>> ...
>>> Now suffering from information overflow.
>>>
>>> We were discussing RFC 3986. Which *ASCII* characters that are 
>>> currently
>>> forbidden in fragment identifiers do you want to allow?
>>
>> We seem to be in a loop.
>>
>> To you, RFC 3986 (including potential errata and/or bis work) implies
>> ASCII.
>>
>> I point out that that restriction does not seem to make sense for
>> fragments.
>
> Actually, you did not. Instead you pointed to lots of material 
> somewhere else that I didn't want to parse just to find out what 
> you're proposing.
>
>> You return back to asking about ASCII.
>
> Because that's what RFC 3986 is concerned with.
>
>> To help break this loop, permit me to turn this question around.
>> Restricting the scope of the conversation to fragments, why do you
>> believe it makes sense to limit such to ASCII only?  What problems do
>> non-ASCII characters in fragments cause?
>
> I fail to see how fragments are special here compared to, say, the path.
>
> I fully agree that work on what we used to call IRIs is something that 
> needs to be done. However right now I'm trying to figure out what's 
> wrong with RFC *3986*.
>
> I hear you saying that URIs should allow non-ASCII characters in 
> certain places. This may break code where these characters are put on 
> the wire (such as HTTP) or stored in places that do not allow 
> non-ASCII characters (say, a database column).
>
> The fact that it's hard to extend the URI character repertoire beyond 
> ASCII is why the IETF attempted to do it in a separate spec/construct. 
> I'm not convinced that the situation has changed sufficiently to 
> invalidate that approach.
On 1/11/2015 8:45 AM, Sam Ruby wrote:
> On 01/11/2015 11:29 AM, Julian Reschke wrote:
>> On 2015-01-11 17:25, Mark Nottingham wrote:
>>> I and others have brought that up. What’s interesting is that they say
>>> it’s reasonably interoperable with deployed implementations.
>>>
>>> Cheers,
>>> ...
>>
>> Let me guess: "deployed implementations" == "what current browsers do".
>
> Your sarcasm is not appreciated.
>
> I encourage you to actually look at test results:
>
> https://url.spec.whatwg.org/interop/test-results/7b83ef3682

***

I fully agree with Julian on the matter of US-ASCII for URIs. URIs (RFC 
3986) are only made of US-ASCII characters.

If someone wishes to extend URIs (as opposed to IRIs or whatever) to 
include non-US-ASCII characters, that's a problem for web browsers and 
all other Internet software alike. This goes exactly to my point about 
protocol slots.

Certificates, CRLs, and other security objects are just as fundamentally 
a part of the Web (and web browser) infrastructure as HTML. In 
X.509/PKIX security objects, the GeneralName uniformResourceIdentifier 
construct is US-ASCII only (IA5String). If you extend "URIs" to be 
beyond US-ASCII, RFC 5280 has to be updated...and all the security 
libraries that depend upon it. Just because HTML(5) can be served as 
UTF-8 or use &amp; encoding or whatever, doesn't make the problem go away.

Does the URL Interop test-results explicitly test for certificates? I 
suggest attempting to put some non-US-ASCII characters in a GeneralName 
protocol slot (say, for revocation) and see what happens.

HTML 4.01 is at least consistent in saying (for its time) that hrefs and 
other things are URIs. For interoperable behavior, use US-ASCII 
characters only and stick with % encoding.

The security angle brings up another problem: the interoperable 
transcription of URIs across systems. The ASCII range is a limited 
repertoire, so it is easy to write it out unambiguously on paper, 
display it on a TV screen, say it over the radio or a public service 
announcement, or memorize it on your smartphone, in order to type it 
into your web browser, the command-line, or any other system of choice.

If you allow the enormous (and ever-expanding) range of Unicode 
characters in "URIs", all of those use cases become fundamentally 
ambiguous, inviting homograph attacks. Which smiley face out of nearly a 
hundred smiley emoji do you mean when you say "http://foo.com/😋" ?? How 
about an URI containing "ῗ" (U+1FD7 GREEK SMALL LETTER IOTA WITH 
DIALYTIKA AND PERISPOMENI)--what composition or decomposition mode? What 
if the combining accent mark code points are in a different order?

***
I have empathy for what Sam/the W3C wants, since the HTML protocol slots 
basically beg to be filled with Unicode strings like <a 
href="http://zh.wikipedia.org/wiki/巴泰勒米·波岡達"> (instead of <a 
href="http://zh.wikipedia.org/wiki/%E5%B7%B4%E6%B3%B0%E5%8B%92%E7%B1%B3%C2%B7%E6%B3%A2%E5%B2%A1%E9%81%94">).

But maybe the more interoperable approach is to define a format and 
mechanism (e.g., IRIs, or something like IRIs v2) to map /from ///the 
Unicode-capable protocol slots, /to/ the well-standardized RFC 3986 URI 
format.

My 2¢.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Sun, 11 Jan 2015 14:44:30 -0800

On 1/11/2015 2:24 PM, Sam Ruby wrote:
> On 01/11/2015 05:10 PM, Sean Leonard wrote:
>>
> The topic is character repertoire for fragment identifiers, not 
> schemes.  I am not suggesting that we allow non-US-ASCII protocols.
>
> I am willing to accept that GeneralName's that are expressed in the 
> form of a URI must be ASCII-only.
>
> The next question is: are all possible URIs valid GeneralNames?
>
> Here are two examples:
>
> data:image/gif;base64,R0lGODlhyAAiALM...DfD0QAADs=

Yes. Use case: Certificate Image. RFC 6170 (previously RFC 3709).

> https://www.ietf.org/#related

Yes. Use case: Certification Practice Statement (CPS) Pointer 
(Certificate Policies, id-qt-cps). Section 4.2.1.4 of RFC 5280. I have 
seen fragments in there in the wild.

Both examples are valid.

Note: the examples I provide here are actually examples where the URIs 
are encoded directly in IA5Strings; there is no GeneralName CHOICE. But 
the premise still stands. Others with PKIX experience can point to 
systems/protocols where uniformResourceIdentifier is in use with the 
appropriate.

One offhand example that I was able to find, via a Google search, is the 
GS1 Certificate Profile Standard v2.0 
<http://www.gs1.org/gsmp/kc/epcglobal/cert/cert_2_0-standard-20100610.pdf>. 
That happens to use GeneralName. It's a bit elliptical, and refers to 
RFC 4043 (which I rarely see), but...it's there.

Sean

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jan 2015 17:24:06 -0500

> protocol slot (say, for revocation) and see what happens.

The topic is character repertoire for fragment identifiers, not schemes. 
  I am not suggesting that we allow non-US-ASCII protocols.

I am willing to accept that GeneralName's that are expressed in the form 
of a URI must be ASCII-only.

Here are two examples:

Are both valid GeneralNames?  If not, why not?

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jan 2015 21:23:57 -0500

> RFC 4043 (which I rarely see), but...it's there.

Thanks!  This input is helpful.  I don't see where it clearly states 
that fragments are allowed, but then again, I don't see where it says 
that they would be disallowed.  That coupled with your statement that 
you have seen them in practice (however rare) is valuable input.

- Sam Ruby

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 12 Jan 2015 18:29:46 +0900

> into your web browser, the command-line, or any other system of choice.

Many other writing systems are equally limited, and are easier to use 
for those using them natively. Some writing systems in East Asia aren't 
that limited, but have other mechanisms to just about allow the same 
things to happen.

> hundred smiley emoji do you mean when you say "http://foo.com/😋" ??

Homograph attacks can happen, but only at points where different actors 
can add to the same namespace. There are exceptions, but usually, the 
path part isn't such an exception.

Also, people using smileys in their IRIs and hoping that these get 
easily copied are just shooting themselves in the foot. Just because it 
turns out that using some Unicode characters in IRIs isn't necessarily a 
good idea doesn't mean that we should exclude them all.

> How

Very very much so. The former is readable (although there are better 
examples than foreign names such as Barthélemy Boganda) to a significant 
part of the world's population; the later is gibberish for everybody.

> Unicode-capable protocol slots, /to/ the well-standardized RFC 3986 URI

With IRIs, that's essentially what we have. (of course I don't want to 
imply that the IRI spec cannot be improved upon)

Regards,   Martin.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Jan 2015 12:15:37 -0600

On Mon, Jan 12, 2015 at 06:29:46PM +0900, "Martin J. Dürst" wrote:
> examples than foreign names such as Barthélemy Boganda) to a
> significant part of the world's population; the later is gibberish
> for everybody.

The href attribute in HTML is one thing.  "_All_ URI/IRI slots" is
another.

I don't object to versioning protocols and data formats to change
specific URI slots into IRI slots.

Thus I have no objection to -say- the href attribute in HTML being made
into an IRI slot (with or without versioning of HTML -- that being an
issue for W3C, though if it were the IETF we'd want to do something
better than a flag day).

I object to any proposal that implies that all existing URI slots must
now [magically] be able to carry Unicode non-ASCII character data.

> >Unicode-capable protocol slots, /to/ the well-standardized RFC 3986 URI

We already have this: RFC 3987.

> With IRIs, that's essentially what we have. (of course I don't want
> to imply that the IRI spec cannot be improved upon)

Exactly.

Terminology is a problem here.  In conversation and these e-mail
threads, I really want to refer to IRIs as "URIs".  But in the context
of RFCs 3986 and 3987 it is critical to be careful to say "URI" in
reference to "slots" accepting US-ASCII only, and "IRI" in reference to
slots that notionally[*] accept Unicode.

It would be very convenient if we only needed to be so careful when
pairing "URI" and "IRI" with the word "slot".

[*] I say notionally because related UI elements generally can only
    handle an equivalent subset when used in non-Unicode locales.

Nico
--

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 13 Jan 2015 17:59:48 +0900

> issue for W3C, though if it were the IETF we'd want to do something

There was no flag day for HTML. IRIs didn't exist (neither the spec nor 
the name) when HTML 4.0 became a Recommendation in 1997 
(http://www.w3.org/TR/REC-html40-971218/). But there's implementation 
advice in that spec at 
http://www.w3.org/TR/REC-html40-971218/appendix/notes.html#h-B.2.1 that 
amounts to essentially the same conversion as the one from IRIs to URIs 
defined later in RFC 3987. Browsers took up that hint sooner or later.

Regards,   Martin.

---

From: Graham Klyne <[email-masked]>
Date: Wed, 14 Jan 2015 23:09:57 +0000

On 11/01/2015 22:24, Sam Ruby wrote:
> The topic is character repertoire for fragment identifiers, not schemes.  I am
> not suggesting that we allow non-US-ASCII protocols.

*Some* protocols include URIs with fragments.  (The restriction on not sending 
the fragment when dereferencing a URI is a specific to the way resource 
retrieval is handled on the web.)

Even HTTP allows URIs with fragment identifiers in, say, Link: headers.

#g
--