W3C home > Mailing lists > Public > public-webid@w3.org > September 2012

Re: [dane] WebID & Call for Adoption: "Using Secure DNS to Associate Certificates with Domain Names For S/MIME"

From: Henry Story <henry.story@bblfish.net>
Date: Fri, 28 Sep 2012 12:05:51 +0200
Cc: "dane@ietf.org WG list" <dane@ietf.org>, "public-webid@w3.org" <public-webid@w3.org>
Message-Id: <2BC6D443-047B-4371-9C65-4EB8E98A8058@bblfish.net>
To: Ondřej Surý <ondrej.sury@nic.cz>
Just a last note, relevant to draf-hoffman-dane-smime-04 [1] and how it could work
with WebID. I think this is on topic for the IETF group: After all this is a 
"Call for adoption", and I am willing to adopt it. Here is how I came to that
conclusion.

 I have worked out how to get my mail signed with my WebID certificate -
it was pretty easy when I was explained how to do it in Apple Mail.

I went to keychain, and selected my certificate ( created using 
https://my-profile.eu/ ), right clicked on it and selected "New Identity Preference".

Those of you that have a client that shows the certificate - if the ietf passes that information
on - should see that the mail was correctly signed but that your client was not
able to verify the message signature: Apple mail does not know the certificate 
authority webid.fcns.eu, and why should it? Apple Mail has a yellow tab that says:
"Unable to verify message signature". I can then choose to accept that certificate
as representing me.

It would therefore be easy to write a plugin for Mail to do the following whenever a mail 
is signed by an unknown CA, but has a WebID in the SAN field:
  - do an HTTP GET on the URL
  - verify that the WebID listed in the profile document declares the public 
    key of the user as one of the user's public keys
    ( as specified by the webid spec https://webid.info/spec/ )

That would allow it then to use personal information listed in the WebID profile
to fill in my address book info, including for example a picture which it could
then show in the e-mail reader for mnemonic purposes [2]. 

Still that leaves an open problem that the IETF spec under discussion [1] will 
help with. WebID by itself could be used to check the social network of people I 
know to see if they refer to this WebID. But it would not help for knowing if
the e-mail was indeed really mine. The e-mail client could use WebFinger [3]
(another IETF spec) to go from the e-mail to the WebID. That would be one method
of verification. But WebFinger has the problem I think for the moment that it
does not necessarily go through https to do the verification, and so could be open
to a man in the middle attack.

So the draft-spec in question could be very useful by specifying in DNSSEC a 
signing key for certificates that guarantee that it was one the e-mail service
stands behind. Ie: it would have to be a guarantee that any certificate signed with that
key is one that only that user has access to. 

Still. This leaves the problem that the e-mail address itself would need to
appear in the certificate too. (which mine does not have at present! Oops!)

So it does indeed look like these two protocols are complimentary and can
work with each other - indeed may need each other. 

Given that what could WebID provide in addition to draft-hoffman-dane-smime?
I think the following:
 1. A way to easily verify that they certificate is still valid.
   If I were to loose my certificate, or think it had been copied, 
   I could just go to my profile and delete the public key associated with that
   certificate from the profile.
 2. As stated earlier it can be a way to add information flexibly to the
   certificate - a link to my social network, to my photos, to my bog,
   which would not require one to change the certificate each time one changed
   that information: the webid places information on the web, instead of placing
   it in a certificate.

Good. Given that this is a call for adoption, I would be willing to adopt this,
and even implement this in the social network I am building. That is if I have
understood the intent of draft-hoffman-dane-smime correctly.

Sincerely,

	Henry Story


[1] http://tools.ietf.org/html/draft-hoffman-dane-smime-04
[2] http://bblfish.net/blog/page9.html#2005/08/26/01-50-23-870
[3] http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06
  
On 28 Sep 2012, at 10:34, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 28 Sep 2012, at 09:22, Ondřej Surý <ondrej.sury@nic.cz> wrote:
> 
>> 
>> On 25. 9. 2012, at 18:32, Henry Story <henry.story@bblfish.net> wrote:
>>> But that is exactly what WebID makes simple:
>> [...snip...]
>> 
>> With my chair hat on, I would prefer you to stop promoting unrelated technology unless you prove it's somehow related to work in this working group.  To say the truth I have seen too many emails in this WG to be reading about what WebID does and what doesn't, I just don't care (here).  Either make some clear the connection to our charter or please stop and let us focus on the work which _can_ be done in this WG.
> 
> ???
> 
> I don't think I have been posting anything here for the past few days.
> The discussion has moved on the the WebID Community group in the mean time:
> 
> http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html
> 
> Anyway, I am very keen on DANE being adopted widely. It is a very important
> standard. The work we are doing would be hugely enhanced by it. As I said
> it is likely that we work done here to use DANE for Mime could be combined 
> with WebID to go even further.
> 
> Sincerely,
> 
> 	Henry Story
> 
>> 
>> O.
>> --
>> Ondřej Surý -- Chief Science Officer
>> -------------------------------------------
>> CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
>> Americka 23, 120 00 Praha 2, Czech Republic
>> mailto:ondrej.sury@nic.cz    http://nic.cz/
>> tel:+420.222745110       fax:+420.222745112
>> -------------------------------------------
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/



Received on Friday, 28 September 2012 10:06:33 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:41:00 UTC