RE: Matter of DN and what's possible

First, the API you are refernecing only gives access to the first URI. And yes, by ISO smenatics, its a name. Its one of a number of alternative names. In the issuer policy referencedin the certPolicy extensions, where the policy on the end of the referring URI MAY BE METADATA that instructs a "cert using system:, it can say whether as authority it intends for "alternativeness" of a SAN collection to means one of the owl:sameAs meanings. It can say whether URIs in the URI bag are equivalent, whether all names of all names forms, are equivalent.  Second, the v3 cert already has an extension address locator, for the "endpoint" at which one shoud expect a MIME typed stream to be returned. Tt avoid the rat trap, is uses the notion of access method: http://www.ietf.org/rfc/rfc3280.txt 4.2.2.2  Subject Information Access   note PKIX does not defined "information services/ endpoints" for end user certs (only certs that are marked CA). In this community (where we do not distingush between CAs and EE - since everyone is a potential self-signer and thus a CA), it is quite acceptble to use the provided locator tag. Simply mark one's cert with the basicConstraints isa CA. Then include the access locator (with the file locator oid given in the spec).  Alternative, we get a MIB from IANA, and define our own OID, say it has the very same semantics as PKIX defined for CAs... except it servers for non-CA certs (formally).> Date: Sun, 8 Jan 2012 14:20:25 -0500
> From: kidehen@openlinksw.com
> To: public-xg-webid@w3.org
> Subject: Matter of DN and what's possible
> 
> All,
> 
> Please look at: 
> http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509nametype(v=vs.85).aspx 
> .
> 
> Again, I believe we can reduce Linked Data publishing complexity re. 
> WebID by separating the identifiers that serve the role of Name from 
> identifiers that serve the role of Address. In doing so, a publish (via 
> an x.509) cert can assert:
> 
> 1. Here is a Subject's Name  (which could be an Identifier in composite 
> or compound form, important thing is that its a key)
> 2. Here is the Address of a Resource that describes an x.509 cert 
> Subject via a directed graph (negotiable representation) via existence 
> of a "mirrored claim" (in this case relation connecting Subject Name to 
> Public Key components).
> 
> I see two routes:
> 
> 1. be more flexible and imaginative about contents of DN
> 2. delineate between UrlName (URL) and UriName  (generic URI) when 
> dealing with a composite SAN i.e., one with many URIs.
> 
> Of course, there is a 3rd route, but utterly heretic. Just adopt the 
> same approach as Microsoft! It won't lock you into Windows.
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> Founder&  CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 
>