RE: Matter of DN and what's possible

I believe you, and I dont need to get into it. I trust you on this, to get it all right. You prove it by doing it, which is what matters. just wanted to ensure you do know that there is a field, for pick up one of the "alternates" of the certs representation - much like my openid points at several alternates of my website (rss fees, atom feeds, page browsing). If you can describe a cert generically and simply leverage the SAN URI field, and tha description (having crawled, or inferred) notes where one place exists to pick up from the web one particular bit format, that nirvana. but, I think it goes beyond that. playing with your wonderful toys: http://uriburner.com/about/html/http://uriburner.com/about/id/entity/https/idweb.cloudapp.net/Home/About#me its a bug bear that every validator has an inconsistent set of SSL trust roots (so https URIs ae not viable as names). Until, one uses your proxy URI (http://uriburner.com/about/id/entity/https/idweb.cloudapp.net/Home/About#me) in which its no longer the validating agent server (with its funky linux cert store, with who knows what values) trying to talk directly to the endpoint. But it talks to the proxy for said (https) resource., either as a source of triples or as a remote sparql query agent. What we will need is for the validating agent at the enforcement point, when talking to said sparql protocol endpoint to be only doing so, over webid-powered SSL, of course. In this way, the query occurs in the context of that UAs particular set of trust points, in X.509 space, that it has marked as "reliable" (for its and only its purposes). These need be nothing more that cert:key statements in a bag, derived from the X.509 bit packets of CA certs (and existing roots). If there is one thing this years effort failed to do, it was tell the big story. This is well worth continuing, but it has to refocus into infrasrtucture (rather than web app design, and webAPI design, and browser modification, and plugins, and session control, and....). It JUST needs to do what thesemantic web is obviously perfectly capable of doing: representing a billion trust graphs (about server certs of other's folks endpoints, if nothing else). > Date: Sun, 8 Jan 2012 16:34:06 -0500
> From: kidehen@openlinksw.com
> To: public-xg-webid@w3.org
> Subject: Re: Matter of DN and what's possible
> 
> On 1/8/12 3:13 PM, Peter Williams wrote:
> > 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).
> Peter,
> 
> What's critical here is our ability to be clear about use of Identifiers 
> in a cert. such that the Name and Address roles are distinct. Doing this 
> via DN (valid) but remains controversial here. Doing it via SAN valid, 
> but some still don't grasp that these valid *magical* properties of URIs 
> are rife with confusion since the URI abstraction itself remains 
> partially understood by the majority.
> 
> What we need to get people to understand somehow is the fact that you 
> can have a URL (a Locator) and a generic URI (Name) in a cert such that 
> publishers can make descriptor resources for cert. subjects -- using 
> URIs as subject names --  and then publish to network resources 
> addresses identified using URLs.  Doing this reduces publisher tedium 
> inevitably introduced by  Linked Data nuances re., de-referencable URI 
> based names.
> 
> Irrespective of what happens to WebID, we are going to keep and ensure 
> this fidelity in our verifiers.
> 
> BTW -- what I am describing is how you end up with a SPARQL URL 
> (shortened using a shortener of your choice) in an x.509 and WebID 
> verification sings along in the most unobtrusive manner imaginable. The 
> only time a SPARQL URL (and optional use of a shortener) creates 
> problems is when the mandate is that the SAN can only have 
> de-referencable URI based names. The URI abstraction always implies 
> scheme and role agnosticism albeit not always visible and comprehensible 
> to all URI users.
> 
> seeAlso from http://www.ietf.org/rfc/rfc3280.txt re. the implicit 
> possibilities for Names and Addresses in a SAN with  values that 
> constitute a composite key:
> 
> RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
> 
> 
>     GeneralName ::= CHOICE {
>          otherName                       [0]     OtherName,
>          rfc822Name                      [1]     IA5String,
>          dNSName                         [2]     IA5String,
>          x400Address                     [3]     ORAddress,
>          directoryName                   [4]     Name,
>          ediPartyName                    [5]     EDIPartyName,
>          uniformResourceIdentifier       [6]     IA5String,
>          iPAddress                       [7]     OCTET STRING,
>          registeredID                    [8]     OBJECT IDENTIFIER }
> 
>     OtherName ::= SEQUENCE {
>          type-id    OBJECT IDENTIFIER,
>          value      [0] EXPLICIT ANY DEFINED BY type-id }
> 
>     EDIPartyName ::= SEQUENCE {
>          nameAssigner            [0]     DirectoryString OPTIONAL,
>          partyName               [1]     DirectoryString }
> 
> 4.2.1.8  Issuer Alternative Names
> 
>     As with 4.2.1.7, this extension is used to associate Internet style
>     identities with the certificate issuer.  Issuer alternative names
>     MUST be encoded as in 4.2.1.7.
> 
>     Where present, this extension SHOULD NOT be marked critical.
> 
>     id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
> 
>     IssuerAltName ::= GeneralNames
> 
> -- 
> 
> 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
> 
> 
> 
> 
> 
>