Re: [pkix] [apps-discuss] character repertoire for fragment identifiers

[Sam Ruby <[e-mail]>]

On 01/11/2015 05:10 PM, Sean Leonard wrote:
>
> 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 & 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.

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=
https://www.ietf.org/#related

Are both valid GeneralNames?  If not, why not?

- Sam Ruby