W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

RE: placing WebIDs in SANs or elsewhere - was: self-signed

From: peter williams <home_pw@msn.com>
Date: Mon, 18 Apr 2011 21:28:05 -0700
Message-ID: <SNT143-ds18F76BDEB75A47B2D94D7092900@phx.gbl>
To: "'Kingsley Idehen'" <kidehen@openlinksw.com>, <public-xg-webid@w3.org>
3 topics:

1. webfinger, and proving webid is more than http.

So I don't like webfinger, simply because its associated with Google. I
don't trust Google policy on crypto any further than I can throw them
(though I have the highest respect for their engineering, including their
crypto work for commodity systems).

The way to solve this issue is to do two scheme, not just one. It proves the
point, that https is not only what we care about - as proven by action.

There seems little reason why a willing VA (webid validation agent) cannot
resolve a mailto: schemed URI in the SAN_URI field to an http URI (using
webfinger), and thereafter do the same thing with the resultant as native
URIs.

I don't see this as being much different to a world in which a web proxy
intercepts the native URI request (directly from SAN), and redirects to
another. The resource server has to follow 302 redirects, no ? a mailto
redirect to a URI.... a 302 redirect to a URI.... are the same thing, in
essence.

Finding this middle ground will show that we are NOT operating a double
standard, or punting (hoping impurities just go away....if we keep the faith
long enuf). The group admits its nature, and doesn't get hung up on all the
usual reasons why standard fail to get adopted.

2. moving along the adoption curve, measuring where we are..

This all reminds me of openid about 2 years ago, which want to deny the role
of the bridge (between openid and say Ws-fedp). I just rejoined the openid
general list, on the basis that openid is now useful to us. Its entirely
hidden.... behind the Microsoft bridge. The fact that google and yahoo are
doing openid is entirely transparent to our users. They have adopted SAML
for all it matters, the role of bridging being to make protocols and dogmas
entirely irrelevant.

3. recognition in mature cert-using communities

I think we should stop fooling ourselves that US govt could give a damn
about webid - a trivial little validating mechanism for certs and public
keys, for commodity client certs in commodity browsers, using fields
standardized for the very purpose, a decade ago. The only thing that will
impress anyone, is that the web of trust based on foaf shows itself for what
it is - capable of scaling to a billion users, with various user-centric
meshes that showcase de-centralization is viable. 

Personally, Id focus on this element of our IN ANY GUISE (hint websso),
rather than waiting for the world to fix browser's client authn popups,
adopt RDF engines in browsers, find a way to sign RDF scripts....  What
matters right now is the demo that the community has moved past its startup
religion phase - and that the mission can interface to and cooperate with
all the other nascent identity schemes/components - and that includes
webfinger (ugh! not that I...<rant excluded>).


-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Kingsley Idehen
Sent: Monday, April 18, 2011 6:02 PM
To: public-xg-webid@w3.org
Subject: Re: placing WebIDs in SANs or elsewhere - was: self-signed

On 4/18/11 5:17 PM, Henry Story wrote:
> On 18 Apr 2011, at 22:52, Kingsley Idehen wrote:
>
>> On 4/18/11 4:10 PM, Henry Story wrote:
>>> On 18 Apr 2011, at 17:42, Kingsley Idehen wrote:
>>>
>>>> On 4/18/11 10:50 AM, Henry Story wrote:
>>>>> On 18 Apr 2011, at 16:25, Kingsley Idehen wrote:
>>>>>
>>>>>> Note: there is a mailto: scheme URI attribute=value pair associated
with 'Subject':
>>>>>>
>>>>>> Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>>>>>>                 OU=FreeSoft,
CN=www.freesoft.org/emailAddress=baccala@freesoft.org
>>>>> That is indeed an option.
>>>>>
>>>>>> If that's all there is in a Certificate, bearing in mind this is the
very cheapest Certificate to produce in the real world.
>>>>> I am not sure there is a price difference between a self signed v3
cert and a v1 certificate. If you can make one you can make the other.
>>>> Who is "You" ?
>>>>
>>>> The issue boils down to HTTP scheme URI and SAN entry.
>>>>
>>>> Cost, to be clearer (on my part) also included fact that when something
exists out in the wild the cost of production == $0.00 :-) Thus, I really
meant: there are lots of certs like this already in the wild that don't use
HTTP scheme URIs and nothing in SAN. This is really where Webfinger,
Fingerpoint come into their own re. WebID vector potential.
>>> A good idea, but let's speak numbers.
>>>
>>> How many certs with e-mail addresess as you published are there really?
>>> Of those how many are client certs? How many of those have mailto uris
that are backed by webfinger?
>> Please re-read the sentences above.
>>
>> This has nothing to do with Webfinger bar the fact that it solves the
bigger issue of making a "mailto:" scheme URI a de-referencable URI. That's
it.
> But that can also be solved in the Subject Alternative Name.

That's fine. Think of me of a person that's autistic to mutual 
exclusion. I am all about options. SAN doesn't have to be the end of the 
story re. these WebID bearing Certs.  :-)
>> This isn't about WebID vs Webfinger or anything like that.
> I did not think it was. The discusssion as I understand it is about where
to place the WebID uri, be it mailto, accnt, ftp or https.

More to do with heuristic for determining the canonical URI in the Cert. 
to be used as WebID re. validation bearing in mind the existence of at 
least one URI, irrespective of location. This also means that 
"emaiAddress=baccala@freesoft.org" == mailto:baccala@freesoft.org re., 
earlier example (Note. to Nathan too).

>> The issue boils down to this, and I don't need to go on a stats adventure
with you re. this matter: there are may Certs generated without any SAN
entries. The existing ecosystem for X.509 cert generation doesn't have SANs.
Google and friends already have email addresses as resolvable URIs courtesy
of Webfinger.
> Yes Google has e-mail addresses, and they have Webfinger, as you know I
know since I wrote this up
> http://blogs.sun.com/bblfish/entry/web_finger_proposals_overview
>
> But they don't have the uris in certificates they are sending out to their
users, do they?

No they don't, but a WebID IdP can piggyback on to this etc.. More to 
the point, the Cert. example is common amongst issuers and issued certs 
in the wild. Asking for a count is not the way to respond to the point 
at hand. This whole game is shaping up, and we don't control the rules 
of evolution in this ecosystem.
>> WebID can simply play along with this reality.
>>
>> I'll get you stats if you can prove to me that GMAIL numbers are
inconsequential :-)
> Gmail numbers are not inconsequential. But as stated above that has
nothing to do with the issue.
>
> If you can come here with the relevant Google employees to tell us that
they don't want to use SANs for some reason but really have to use  URIs
placed in the the Distinguished Name, then I'll be all ears. I doubt you'll
find them, because Subject Alternative Names are so easy and standard that
they have everything going for them. They also have the advantage that in
Chromium you can see the SAN in the certificate view clearly and click on
them.

It's not the argument. I think we are now drifting somewhat.

I just want WebID to stick to its architecture which means its Leverages 
Linked Data via URIs.

>>> How many of those 'backed' by a link to a document that publishes a
public key?
>> Sorry, it really isn't as important as you're trying to make out. Here is
a much more pragmatic question (IMHO): how easy would it be to associate
these mailto: scheme URIs with profile oriented Linked Data graphs bearing
public keys. That's the reality out there.
> It's not difficult to do, but who is doing it? And why place the mailto in
the Distinguished Name, rather than in the SAN?

See my earlier comment. Those Certs exist, as per example where Certs. 
have been in use. This isn't the argument. I can ask you where are the 
WebIDs? That isn't the point either.

>>> I think we are speaking of close to 0 above.
>> Sorry, but you are jumping to conclusions that are very easy to disprove.
That said, you are sorta missing my point. Grasp my points and you really
won't veer down this cul-de-sac :-)
> Your point is that one could put the WebID in many places in the
certificate other than the WebID.

No, I am saying: what happens when there is a single URI in the Cert. 
that doesn't happen to be in the SAN. How do we deal with this reality 
bearing in mind Certs in the wild. Or this sort of Cert. being the one 
that easiest to generate by folks who don't have a clue about WebID. How 
does WebID piggback as we've showcased re. OpenID for instance? 
OpenID+WebID remains my most effect WebID value prop. demo.

>   True. But you don't have any arguments for why we should not put it in
the place designed for it.

See comment above.

>   That Google has many e-mail addresses is not the issue, since we are not
arguing here over whether one should or should not use webfinger. That would
be completely compatible with using the SAN.

I am talking about Certs. generated by folks that are clueless about WebID.
>>>   Those that would wish to do any of the above would certainly find it
not difficult at all to add a SAN field to the new certificates. And if we
should at some point find a real measurable advantage to using these other
methods, we can certainly leave that open.
>>>
>>> But doing that now, seems pre-mature.
>> No comment. Digest my earlier comments.
> I have understood them very well Kingsley, as you will notice from my
above replies. :-)

Sorta :-)

Kingsley
>
>>>>>> Ditto most prevalent i.e., no SAN, why shouldn't WebID be capable of
doing this?
>>>>> It would be able to do this. It's a question of trying to keep things
simple.
>>>> But when you say that its akin to someone saying: although I talk about
Semantics, I oriented towards Syntax for sake of simplicity. We can't keep
on using "simple" in very subjective way.
>>>>
>>>> As you know, I don't think WebID is about "Simply Simple" its is about
"Deceptively Simple", that's inherited from its AWWW DNA courtesy of Linked
Data.
>>> I mean let's implement the tests for what we have got, and then evolve.
>> I am not asking you to do otherwise. I am saying get the tests right from
the onset.
> great! Here we agree for sure.
>
>> Test the right thing i.e, WebID conformance without unnecessary
specificity.
> Tests are by definition specific. We should not be too specific of course.
The tests we are putting together will be able to test https schemes, other
to test accnt schemes.... But why not start with the well understood http
schemes and get us all to base0.
>
>> Nothing stops anyone making what they subjective perceive to be pragmatic
decisions in whatever they code. I am trying to encourage practice whereby
those decisions are crystal clear rather than letting subjectivity taint the
broader concept via bad conformance and interop test results.
> The test will be very objective, and we can have many implementations of
them. The tests will make these things crystal clear, and we can then bounce
back between spec and tests as each of these develop.
>
>>> Until I see everyone interacting at the level we have defined now, I
won't call anything above that simple.
>> "Simple" means different things to us, clearly. Nothing to me is "Simple"
the trick is to create the illusion of "Simplicity" en route to bootstrap.
>>
>> Being a cognitive being ensures we are incapable of making anything that
is truly just "simple", where longevity and broad adoption are essential
characteristics. In my world view, things simply start off being "simple" as
prerequisite for initial attention acquisition. In my quarters we refer to
the aforementioned as being about: minimizing the "activation threshold" :-)
> exactly. We need to minimise the activation threshold, by bootstrapping
what we have. Anyway, that's what some of us are working on with the tests.
It helps focus our attention.
>
> Henry
>
>>
>> Kingsley
>>>>> The advantage of SAN is that they are clearly defined for the purpose
we are using them for, and you can put e-mail addresses in there too.
>>>> I understand that, but the real world already have Certs. constructed
in the manner outlined. I really believe minimizing inertia is the key to
boostrap. When I architect products at OpenLink I always oriented to
"minimal inertia". To the uninitiated this appears to be a bizarre
preoccupation with protocol implementation, but that's far from it. It about
the pragmatics of real technology bootstrap by dealing with the realities
out in the wild.
>>>>
>>>> We don't need to tell people what's best for them if we can show them
how a new technology makes what they already have better, with minimal (if
any) inertia associated infrastructure changes etc..
>>>>
>>>>>   I am not sure of the issues that come up with the above scheme, how
standards based they are, etc... It is good to have it as an option if we
need it. But I don't see that the arguments for it are very strong yet.
>>>>>
>>>>>> It just boils down to being scheme agnostic
>>>>> You're not being scheme agnostic with mailto uris it seems to me.
>>>> Of course I am, the IdP is going to determine the canonical WebID and
then de-reference it. You can de-reference a "mailto:" scheme URI using HTTP
as exemplified by Webfinger and Fingerpoint.
>>> I am talking about the wikipedia example that contained
>>>
>>>   Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>>>                 OU=FreeSoft,
CN=www.freesoft.org/emailAddress=baccala@freesoft.org
>>>
>>> the emailAddress is not schema agnostic I believe.
>>>
>>>>>   And it seems that sending e-mail uris around the web is not such a
good idea as far as spam is concerned.
>>>> If WebID can't alleviate the scourge of SPAM, what on earth is its
ultimate purpose?
>>> It will very likely by removing the need for e-mail altogther. E-mail is
problematic in itself also because it is easy to run MITM attacks on it.
>>>
>>>>> SANs and IANs are scheme agnostic on the other hand.
>>>> So what? No the point when dealing with inertia reduction based on
working with what exists already (however imperfect it might be).
>>> You have not proven any inertia gain from using emailAddress= in the DN
field.
>>>
>>>> You are making the same old mistake that most programmers have made
repeatedly over time i.e., technology implementer (the coder, typically)
knows best. Sadly, that isn't true. Users are typically domain and subject
matter experts that are time challenged and don't write code. Being the one
that writes the code != best comprehend-er of the discourse domain or the
subject matter intrinsic to the domain.
>>> We have all got reasonably interoperable code working in many languages
with SANs. When we have this well documented and find things we can't do
this way, then we can move on to work on other things.
>>>>>> and letting the IdP deal with the de-reference functionality.
Remember, Linked Data is just a Webby way of handling de-reference and
address-of operators that lies at the root of all forms of data access by
reference.
>>>>>
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>>
>>>>>
>>>>>
>>>> -- 
>>>>
>>>> Regards,
>>>>
>>>> Kingsley Idehen	
>>>> President&    CEO
>>>> OpenLink Software
>>>> Web: http://www.openlinksw.com
>>>> Weblog: http://www.openlinksw.com/blog/~kidehen
>>>> Twitter/Identi.ca: kidehen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>>
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> President&   CEO
>> OpenLink Software
>> Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
>>
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Tuesday, 19 April 2011 04:28:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:24 UTC