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

Re: self-signed

From: Peter Williams <home_pw@msn.com>
Date: Mon, 18 Apr 2011 18:30:07 -0700
Message-ID: <BLU0-SMTP17905C5AA7267FF2AF65FAE92900@phx.gbl>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>
To: Kingsley Idehen <kidehen@openlinksw.com>
It's irrelevant how many certs of any type there are, currently. It's trivial in windows to make a new one (self signed). It works widely when unencumbered by v3 - that hits guards if many types.

Henry has the right goal but is slightly off track in getting there (not having decades of experience in cryptopolitics)

What is right is to enable ca, v3 and pki value add. Such is the nature of cryptopolitics, that one has to make such certs  a second class citizen (despite having higher assurance). Folks mint their own certs, usable globally via webid. The same cert is by defn a viable cert " request" to a ca, which can countersign. Both   are now Valid in each (probably compartmented) community of relying parties: but the user selects which to release -since both contain the same modulus. A third ca can countersign, for all it matters, so the co.uk key is also viable in .com.us.


Do this, and individuals retain exclusive control of the keys - whereas the ca retains control over the cert - but not the certs of other cas or the selfsigned cert. It's encoded in rfc1422.

When you argue this, you can easily measurement the resistance points - by those ca who don't want to just issue cert ... But who wish to control the underlying (encryption) keys. These parties always have specious reasons why certs and key mgt must be colocated (and why revocation by one authority must always entirely stops a given key working, anywhere).

You can tell ca firms that are "lobbied" by civilian powers because folks with military ca experience don't make that claim (since key revocation is handled separately from cert revocation for historical reasons). Folks who tie the issues are in the business of delivering a third part based control to fourth parties (not tge authentication between peers one and two): which is what makes them uniquely "trustworthy" (in the eyes if the fourth party trying to run a "policy domain").


On Apr 18, 2011, at 5:43 PM, Kingsley Idehen d <kidehen@openlinksw.com wrote:

> On 4/18/11 5:07 PM, Mo McRoberts wrote:
>> 
>> 
>> On 18 Apr 2011, at 21:52, Kingsley Idehen wrote:
>> 
>> >> 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.
>> 
>> Let's phrase it another way:
>> 
>> How many certificates which are potentially WebID certs (that           is, have some kind of identifier which COULD be resolved if the server knew how) are actually out there?
>> 
>> We already know SSL client certificates pretty much failed. It           doesn't matter how many GMail e-mail addresses are out there if they don't already have certificates, because brand new certs which conform in whatever way the WebID coin lands can be generated.
>> 
>> I can't help but wonder if there is some cross-purpose arguing going on.
>> 
> 
> Yes. 
>> 
>> You're saying “WebID should support more than just http URIs”
>> 
> 
> It shouldn't be scheme specific in any shape or form.
> 
>> 
>> Peter, on the other hand, is saying “WebID should work with X.509v1 certificates, ignore critical extension, basically work with whatever certificates are *already out there* [even though we know that none of them are actually WebID certs!]”
>> 
>> Henry's saying “WebID should be built on X.509v3 with the URI in the SAN [or possibly IAN?], but for the moment let's focus on HTTP[s] URIs in building the testsuite, then move onto other schemes”
>> 
> Yes, but Henry assumes that when I make a comment about WebID and scheme agnosticism I am also making a call for implementation protraction. Whereas I am simply saying: do not encourage breaking the core concept under the subjective use of the "simple" escape. Just have developers understand that :
> 
> 1. WebID is scheme agnostic
> 2. When you implement something that isn't scheme agnostic, say so in a clear way via: UI and/or error messages. Worst case say: I don't understand this scheme or I can't discern a comprehensible WebID; don't say any of the conditions just mentioned == Wrong.
>  
>> 
>> Is that a fair summary?
> Yes.
>> 
>> Kingsley, Henry isn't — I don't think — actually disagreeing with you, it's just a matter of prioritising the initial work.
>> 
> 
> Henry is sort of misunderstanding me, since nothing I am saying affects initial work. Its about making initial implementers     understand the scope of WebID etc..
>> 
>> Correct me if I'm wrong.
>> 
> 
> 100% accurate :-)
> 
> Kingsley
>> 
>> --
>> Mo McRoberts - Data Analyst - Digital Public Space,
>> Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
>> Room 7066, BBC Television Centre, London W12 7RJ,
>> 0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A
>> 
>>  
>> 
>> http://www.bbc.co.uk
>> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
>> If you have received it in error, please delete it from your system.
>> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
>> Please note that the BBC monitors e-mails sent or received.
>> Further communication will signify your consent to this.
> 
> 
> -- 
> 
> 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 01:30:19 UTC

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