RE: Documenting implicit assumptions?

dont be afraid to use the OTHER_NAME macro, the notation of X.509 type name form extensions. In 2000, all type defintions for various URI concepts were given IA5String as value type (so we could be ultra-correct in definition, ensure the type system was minimal, and let serializers in security modules detect early non-compliance of a security critical datum).
 
One just defines URInext OTHER-NAME UniversalString... (say) and assigns a new object id (OID) for the new name-form. Decide of UniversalString is sufficient for IRIs. With that done, URIs in SANs have more powerful string types as containers for their bytes. Microsoft already properly used what ISO provided for them/us to use, when putting SPNs in certs (SPNs are a theory of service names that link domain-names to identity delegation theorems).
 
in the Windows tool chain for cert minting, anyone can actually practically issue certs with SANs using such custom-defined name form. 
 
Best to do this in collaboration with IETF PKIX WG to build some bridges. They have all the formal apparatus, not that its hard to create one's own since ISO intended anyone to be able to extend the standard. Names always evolve. Ideally, there would be a entire scheme of OTHER-NAME definitions, in which each "type" of URI used for identity would be defined and differentiated. But, perhaps, this is making X.509 type language compete with the value of RDF to do the same kind of thing. Here, culturally, perhaps its better to let semweb-style ontologies take the role in distributing typelibs.
 > From: tai@g5n.co.uk
> To: nathan@webr3.org
> CC: henry.story@bblfish.net; benjamin.heitmann@deri.org; public-xg-webid@w3.org; msporny@digitalbazaar.com; michael.hausenblas@deri.org; timbl@w3.org
> Date: Tue, 1 Feb 2011 10:57:41 +0000
> Subject: Re: Documenting implicit assumptions?
> 
> On Mon, 2011-01-31 at 19:59 +0000, Nathan wrote:
> > subjectAltName tightly binds WebID to x509v3 certificates, x509v3 
> > certificates with subjectAltName extensions are very hard to produce 
> > with common libraries (unless you have a custom setup - e.g.
> > openssl). 
> 
> Point and click certificate generation (on Linux and similar - requires
> OpenSSL and Gambas):
> 
> http://buzzword.org.uk/2008/foaf_ssl/MakeWebIDCert/
> 
> > is subjectAltName IRI compatible?
> 
> HTTP isn't IRI compatible. Very few protocols are. But luckily that
> doesn't matter because there is a mapping from IRIs to URIs - for every
> valid IRI you can calculate an equivalent URI. In fact the only official
> syntax definition for IRIs exclusively defines them in terms of a
> mapping to URIs. (To paraphrase, "if a Unicode string processed this way
> results in a valid URI, then what you started with was an IRI".)
>