- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 4 Jan 2012 01:43:03 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-xg-webid@w3.org
On 4 Jan 2012, at 01:33, Kingsley Idehen wrote: > On 1/3/12 6:17 PM, Henry Story wrote: >> On 3 Jan 2012, at 23:22, Kingsley Idehen wrote: >> >>> On 1/3/12 3:16 PM, Henry Story wrote: >>>> On 3 Jan 2012, at 18:32, Peter Williams wrote: >>>> >>>>> henry is not correct about CNs. >>>>> >>>>> >>>>> >>>>> CNs are unique in that their type is defined locally. Thats is definition. If one makes it a URI, its a URI. >>>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366101(v=vs.85).aspx >>>> >>>> They give the following examples >>>> >>>> DN: CN=Jeff Smith,OU=Sales,DC=Fabrikam,DC=COM >>>> >>>> Is Jeff Smith globally unique? Ah no it's locally unique inside the company Fabrikam . Oh but then its not a URI. >>>> >>>> What has this got to do with the discussion btw? Is there something magical you can do by putting your URI in the CN? Probably not. So why bother? >>> Here's what's utterly magical (if you need that moniker) re. URLs (Addresses) or URIs (> 1 level of indirection) in the CN: >>> >>> The ability to fix problems re. URI abstraction re. comprehension and exploitation. We still continue to trip of Name/Address ambiguity. We have URNs, URLs as subClassesOf URI. We have the ability to use URIs as Name e.g. HTTP scheme URIs which are powerful but unintuitive etc.. >> I never heard of this problem. >> >>> Magic is when you solve this mess in such a way that all parties are happy. Intuition reigns, everyone can read the URI syntax and comprehend the power of the abstraction. >>> >>> Imagine a WebID verification protocol that encouraged: >>> >>> 1. Putting an Address for a profile document in the CN (which is a compound key since all of its elements aren't necessarily individually unique) >>> 2. Put intuitive Names (so URNs that don't resolve are fine) in the SAN (Subject Alternative Name) slot > > Henry, >> Ah you want me to imagine doing the opposite of what the X509 spec says one should do? > > Of course not! > >> Put URIs in the DN and human readable names in the SAN??? > > Of course not! > > I am saying, and I was pretty darn clear about this: > Put Addresses in the DN. But that's not what they are for. In any case what practical value does this bring? > Put Names in the SAN. Instead of mandating de-referencable Names. Hence my reference to URN inclusion. Well the SAN is defined already in X509. We can but URI's there. That's what we are doing. And it all works fine. > >> >> Come on. You're joking right? > Digest my comments properly. I couldn't be clearer about what I am suggesting. yes, it's clear. And a -1 from me, no practical value. Henry > > Kingsley >> >> Henry >> >>> Then one can say intuitively: >>> >>> The Address resolves to a description oriented directed graph pictorial where attribute=value or predicate=object pairs coalesce around the URNs in the certs. SAN. >>> >>> I have technology that can walk the Web via de-referencing, but I wouldn't impose immediate comprehension of that capability on anyone trying to implement WebID. Instead, I would prefer they understand that for WebID, the de-reference goals can be achieve in a looser fashion without being exposed to some of the fiddly parts of pure Linked Data URIs. >>> >>> Nobody loses here, and as per usual, we open the tent to those that have resisted in the past. This is how you keep httpRange-14 distractions out of WebID too. Achieving that is also magical re. a Linked Data driven solution :-) >>> >>> Hammer Stack covers this for Email Addresses, and Webfinger puts it to good use. >>> >>> >>> Kingsley >>> >>>>> >>>>> One is prefecty entitled to do what folks to in plaintext email, on detecting a string with a URI syntax (make it clickable). >>>> The distinction is the same as if someone wrote >>>> >>>> <a href="http://fabrikam.com/jeff">Jeff Smith</a>. >>>> >>>> "Jeff Smith" above is not a URI. Could you write >>>> >>>> <a href="http://fabrikam.com/jeff">fabrikam.com/jeff</a> >>>> >>>> yes. Would it be user-friendly? In most cases no. Go check CNN.com or any major consumer web site and see how rarely that is done. is fabrikam.com/jeff a URI? No it needs to to be started by http:// if it were even to have the syntax of a URI. >>>> >>>> Is the string inside anchor below a URI? >>>> >>>> <a href="http://fabrikam.com/jeff">http://fabrikam.com/jeff</a> >>>> >>>> Not really either. It is a string that looks like a URI. And no browser will treat it as a URI. you have to distinguish between URI looking strings and URIs. >>>> >>>> >>>>> >>>>> Is the policy qualifier extension parameters type a URI? If you look at the Microsoft cert display UI (see Issue button), it interprets said field as a URI. Click it, and up pops a web page (or actually any resource, as identified by the scheme and path, as usual) >>>> Click what? the CN or the DN? Click >>>> >>>> <a href="http://fabrikam.com/jeff">Jeff Smith</a>. >>>> >>>> And you will end up on http://fabrikam.com/jeff but that is not because "Jeff Smith" is a URI! >>>> >>>>> Peter is not 100% correct that CN are unique in that feature. X.500 allows one to define ones own tags, and one can define ones own (with the CN properties). Its just that noone else knows about it, typically. CNs are used, BECUASE they are infinitely flexible. Thats why folks graictate towards using them (being "right" for operational modalities) >>>>> >>>>> >>>>> if you look in the Microsoft trust list (that by default cues on the first CN in the list (in most significant order), there is one set of root keys that have Idisplayed) CNs with URIs. They stand out when you look through the list. The rest indicate some kind of "official" name of the firm. In one case, the official name of the firm was the URI (cast as a string, I suppose). Thats becuase, in Scotland, one's official name is what one says it is. Its a free society (for naming). >>>>> >>>>> >>>>> >>>>> However, if the cert does not have a CN, other rules apply to what gets shown. >>>>> >>>>> >>>>> >>>>> So Scotland and CNs are very happy with each other. Scottish law doesnt have a cow, on account of the mere lack of 100% control by the state over official naming, as we discussed earlier. >>>>> >>>>> >>>>> >>>>> Other countries based on the napoleanic tradition of naming (which includes the US) hate this. They want control in the hands of officialdom (so things like loyalty tests can be applied as a condition of citizenship). The state can exclude those from self-government who it deems not loyal (the old English "with-out-law [outlaw]" concept: to exist without the benefit of law and its perogative). In Scotland, one can only be excluded from Royal things, since the King/Queen (unlike the US president) does not have full perogative to define what the state is. >>>>> >>>>> >>>>> >>>>> I seem to remember some civil war over this very point. it was about the only things Scots and the English really agree on (but its vital and binding). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Webid is supposed to be about decentralized this and that. In reality, its about removing one semi-centralized trust structure and replacing it with another, with a different set of guardians. But, so was openid. And openid and webid share common history. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Social Web Architect >>>> http://bblfish.net/ >>>> >>>> >>>> >>> >>> -- >>> >>> 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 >>> >>> >>> >>> >>> >>> >> Social Web Architect >> http://bblfish.net/ >> >> >> > > > -- > > 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 > > > > > > Social Web Architect http://bblfish.net/
Received on Wednesday, 4 January 2012 00:43:35 UTC