Re: Web ID as passwordless authentication for debian web services
Jonas Smedegaard <dr@jones.dk> writes:
> Quoting Russ Allbery (2013-05-16 19:57:59)
>> Sure, but if you have control over the server certificate and are tying
>> the server certificate to the user certificate via some mechanism like
>> Monkeysphere, why do the whole indirection dance through a URI at all?
> Because when identifier is a URI then it is reusable for other purposes
> than authentication.
Thank you -- this and your other message clarifies for me. The idea is to
create a persistent representation of identity on the web that can be
linked to, included in other graphs, etc. The problem with a certificate
is that, while you can link *from* it, you can't (easily) link *to* it or
include it in graphs that can be followed with simple HTTP requests.
I'm not sure what I personally think of this use case (I'm in general not
a fan of rich social graphs, since I think the privacy drawbacks of making
all of that data easy to mine outweigh the benefits in most cases), but
it's definitely a use case a lot of people care about.
One further note, though:
> For PGP keysigning, a common way to "authenticate" is to look at a
> passport or drivers license. But we cannot really authenticate that
> way.
> In airports when showing a passport, it is matched against a centralized
> database. The government issuing the passports also provides ways for
> police and other governmental appointed people to authenticate
> passports.
> ...but noone else are allowed access to those centralized databases.
The passport verification system works this way partly because it predates
public key cryptography and partly because the government wants to store
confidential data about you that it doesn't want other people (often
including, and perhaps even *particularly*, you) to be able to see.
For the former, one does a central database lookup to prevent people from
forging passports for new identities. Note that this is actually not a
very good authentication system; it prevents people from creating all-new
identities, and it prevents people from crosslinking identifies to
different identities, but it doesn't prevent someone from simply forging
another person's identity completely if they happen to know their passport
number and the necessary demographic data to fill out the rest of the
passport.
Public key signature verification is as good or better (it still doesn't
prevent straight duplication of the passport, but you have to have access
to the original passport to copy the signed data; you can't just generate
a new passport from demographic information), and is therefore superior
from an authentication perspective to just looking up the passport number
and checking that the name and birthdate match the central database. I
suspect most machine-readable passports these days actually contain public
key signatures on the machine-readable data.
The government therefore doesn't need to (and doesn't want) to expose that
sort of validation service to let other people use passports as an
authentication tool. Rather, they would switch to a public key signature
and just publish the root CA public key. That's already what the US
government does for government-issued PIV hardware smartcards, such as
those given to government employees. Anyone can verify the identity on
those cards given the root CA public key.
The lookup the government does at the airport will persist and will
continue to not be available to the general public for the second reason:
the government wants a place to store additional metadata about people
that can be updated at any time without refreshing their passport, that
isn't public, and that can be kept from the person themselves. (Things
like whether you're on a terrorism watch list, for example.)
This is an important use case for the government, but Debian probably
doesn't have quite the same use case. I suspect we'd rather put the
person's metadata, apart from a few key things like "is this a person a
member of the project," under the user's control. At that point, it's
reasonable to have the user re-mint their certificate if they want to
change the metadata.
You do still need some way of recording that the certificate is no longer
valid and shouldn't be trusted, but for that you probably want to use a
CRL protocol that's specifically designed for that purpose and has the
necessary cryptographic glue so that you can trust the results.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: