Re: WebID discussion in Debian

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.

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.

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
>