Re: EmailSigning feedback

On 1 Oct 2012, at 19:04, Jürgen Jakobitsch <j.jakobitsch@semantic-web.at> wrote:

> On Mon, 2012-10-01 at 11:53 -0400, Kingsley Idehen wrote:
>> On 10/1/12 11:37 AM, Jürgen Jakobitsch wrote:
>>> hi,
>>> 
>>> thanks, i'm clear about that, thing is that i would like to have signed
>>> mails a "green" footer in most cases anyway. i already had feedback from
>>> people who were not able to open my signed mails and i'm thinking about
>>> not scaring people if there should be some sort of viral effect.
>> 
>> We have the following choices:
>> 
>> 1. leave people scared and in the dark
>> 2. enlighten them about what's amiss re. identity and eventually privacy.

3.   I don't think it is so much the users you need to convince as the
 people who make the software at this point.

 You need to convince the e-mail vendors to add the functionality for WebID
lookup. This requires to go through a standards process, produce a document 
that gets accepted with the right players. You probably need to go through
the IETF. You can get there earlier by making plugins that show how it works
to convince them. 

This is why WebID in the browser is much much easier to get going. The software
already works in the browser. It is not perfect, but it works. You can change 
the servers and put them up yourself. And see how even here were we control 
the software how slow we are .

Still learning how this works in e-mail is interesting, because it can help
us decide what is possible and what needs to be standardised.

> 
> i'm choosing this option :-) ... preparing to introduce signed emails
> with webid in our company.. but need to make sure this doesn't end in
> chaos :-)
> 
> for info of evolution mail users : 
> 
> just filed a bug report (certificate extensions are not readable)
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=685230
> 
> wkr turnguard
> 
> 
>> 
>> We have to turn these miscues into triggers for knowledge exchange.
>> 
>>> i don't
>>> want my signed mails to be rejected or deleted by someone who just
>>> doesn't know that it has no meaning.
>> 
>> So you can explain to them the value of clicking on the scary icon. For 
>> example, copy and pasting the WebID into their browser (since most email 
>> clients you treat the WebID as an actual live link) .
>> 
>> 
>>> i also don't want to change my
>>> email signature to include an argument about why an "invalid" or "not
>>> trusted" certificate doesn't really matter.
>> 
>> Correct, no need for that.
>> 
>>> 
>>> i just started a small survey in our company per email, with some
>>> questions like :
>>> 
>>> -do you notice at all, this email is signed
>>> -does it look invalid, not trusted
>>> -if yes, does this scare you somehow
>> 
>> They are all scared. That's why they are all under the control of broken 
>> email clients and dysfunctional PKI. Net effect, we have social network 
>> silos emerging around what's already addressed by existing open 
>> standards :-(
>> 
>> Kingsley
>>> 
>>> will report back
>>> 
>>> wkr turnguard
>>> 
>>> 
>>> 
>>> 
>>> On Mon, 2012-10-01 at 11:05 -0400, Kingsley Idehen wrote:
>>>> On 10/1/12 9:12 AM, Jürgen Jakobitsch wrote:
>>>>> apparently this whole emailSigning thing not so easy and there is a
>>>>> plethora of "reactions" from different email clients.
>>>>> 
>>>>> maybe we should set up a wiki-page with a matrix of the creation process
>>>>> and the experiences with different mail clients to come up with a
>>>>> solution that suits most people.
>>>> I wrote a number of howtos [1] for all the major email clients due to
>>>> what you outline above. Sadly, the world of PKI exploitation has been
>>>> turned on its head by the overbearing nature of those in the CA business.
>>>> 
>>>> In the world of eCommerce, 3rd party verification of vendor identity is
>>>> crucially important. Sadly, that's a single use-case pattern that's come
>>>> to cloud (obscure) the entire realm of PKI exploitation as you are now
>>>> experiencing with inconsistent behavior across S/MIME clients.
>>>> 
>>>> For social networking, 3rd party identity verification doesn't have to
>>>> follow centralized CA pattern. In short, therein lies the fundamental
>>>> essence of the WebID authentication protocol. Even without adding the
>>>> requirement for IdP's to generate certificates with the issuer/signer's
>>>> WebID in the Issuer Alternative Name (IAN) slot, it is still possible to
>>>> ignore email client behavior en route to looking up the WebID that
>>>> watermarks a senders certificate. This is base #1, the first step.
>>>> 
>>>> Beyond the basics above, without the tedium associated with writing
>>>> plugins for each email client, it is possible to incorporate WebID into
>>>> IMAP4 which enables smart organization of mailboxes. This is what I'll
>>>> demonstrate next as we've implemented this feature a while back as part
>>>> of our exercising the practical utility of WebID within the context of
>>>> existing protocols.
>>>> 
>>>> Links:
>>>> 
>>>> 1. http://bit.ly/U9tvcP -- various G+ howtos for different email clients .
>>>> 
>> 
>> 
> 
> -- 
> | Jürgen Jakobitsch, 
> | Software Developer
> | Semantic Web Company GmbH
> | Mariahilfer Straße 70 / Neubaugasse 1, Top 8
> | A - 1070 Wien, Austria
> | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
> 
> COMPANY INFORMATION
> | web       : http://www.semantic-web.at/
> | foaf      : http://company.semantic-web.at/person/juergen_jakobitsch
> PERSONAL INFORMATION
> | web       : http://www.turnguard.com
> | foaf      : http://www.turnguard.com/turnguard
> | g+        : https://plus.google.com/111233759991616358206/posts
> | skype     : jakobitsch-punkt
> | xmlns:tg  = "http://www.turnguard.com/turnguard#"

Social Web Architect
http://bblfish.net/