- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 15 May 2013 11:21:44 +0200
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Jonas Smedegaard <dr@jones.dk>, public-webid <public-webid@w3.org>, Kingsley Idehen <kidehen@openlinksw.com>
- Message-Id: <2FCAC39C-43E9-4D65-89D9-66D53D98FDA7@bblfish.net>
Good work. Some comments below. Please pass that on.
On 15 May 2013, at 09:48, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
>
> On 15 May 2013 09:33, Jonas Smedegaard <dr@jones.dk> wrote:
> Hi,
>
> [resent, also Cc'ing a few members discrete in case it still fails]
>
> A discussion at the Debian developers' mailinglist touches WebID, with
> sceptical input from one of our "wise guys", Russ Allbery [and since a
> more optimistic and inviting followup from Daniel].
>
> I think it might be helpful if someone knowledgeable on WebID crypto
> details read https://lists.debian.org/debian-devel/2013/05/msg00886.html
> and consider if relevant to clarify some details.
>
> NB! Please beware it is a looong thread where WebID is only *briefly*
> touched: While helpful to "clue us in" on specific details, I suspect it
> high risk of being misunderstood as "hijacking the conversation" or even
> "spamming" if expanding to educate us more generally on the virtues of
> WebID.
>
> Best would be a short, sharp input, preferrably referencing hardcore
> documentation on the topic, I think. Unless Russ' judgement is fully
> correct.
>
> Thanks Jonas
>
> Pasting the text for convenience
>
> [[
> I'd never heard of WebID before this thread, but looking briefly at the
> spec, I share Daniel's concerns. I don't see how this eliminates reliance
> on the normal CAs. You still have to do certificate validation to be able
> to trust the link between URL and keypair, and the WebID protocol provides
> no way to do that certificate validation other than the normal CA process
> (and doesn't provide any alternative CA).
>
> If you're going to trust the normal CAs anyway, all that WebID is really
> giving you is the ability to add additional metadata to the user's public
> certificate by publishing it at a linked URL; you're still trusting the
> public CAs implicitly to verify that user's certificate.
Also note:
- The DANE protocol will allow us to bypass CAs by placing keys
in secure DNS
http://tools.ietf.org/html/rfc6698
- One can also use WebID with Tor, but that is something to do
at the next stage . For many businesses and associations CAs are
not a problem, and they can get going with the technology as is.
>
> Furthermore, you're not even using a direct CA signature, but rather are
> using the server certificate of the web server the user gives you in the
> URL to validate that their *client* certificate is owned by them. I
> haven't fully thought through the implications of that, but at first
> glance it strikes me as a repurposing of authentication data in a way that
> isn't theoretically sound.
>
> WebID is trying to solve both the authentication problem and the
> distributed identity management problem. Do we actually need the identity
> management functionality? If not, then the FOAF data isn't needed, and an
> X.509 certificate from a Debian CA that issues certificates based on
> GnuPG-signed requests would be sufficient for us to bootstrap our own
> X.509 infrastructure without all the additional complexity of WebID.
> (With the caveat, as mentioned previously, that we'd have to do some
> thinking about expiration times and revocation.)
> ]]
>
> Para (1) -- Russ is correct ... if your HTTP URI is not https you can be impersonated via MITM. The natural conclusion is to think that you need a CA certificate. But that's only on first call, and assumes you dont have a normative key cached. Every time you notice a key change you should be suspicious (as with SSH) ... but this is not documented in the spec, afaik.
Also see Dane and TOR remarks above
>
> Para (2) -- Russ seems to be slightly dismissive of the utility of Linked data. I think the parabolic growth of LD is going make it's case more compelling over time.
>
> Para (3) -- Seems like an unfounded concern. Client certs and server certs do different things and that's OK.
>
> Para (4) -- WebID is about distributed identity. WebID+TLS (which is actually +FOAF+RSA) is one authentication method layered on top of WebID. People almost always couple the two together, and I dont think the community really emphasises the value proposition of the modularity. This goes back to the days when WebID was called FOAF+SSL ... today FOAF isnt mentioned in the core WebID spec.
>
> Quick Question: does debian have a CA, or is this a proposal?
>
>
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
>
> [x] quote me freely [ ] ask before reusing [ ] keep private
>
Social Web Architect
http://bblfish.net/
Received on Wednesday, 15 May 2013 09:22:15 UTC