- 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