[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: one-body, one-cert
From: Carl Ellison <cme@cybercash.com>
> There was a request on another list a few days ago for a one-body,
> one-valid-cert service. The writer assumed that a standard ID cert like
> one from VeriSign would give him that service. [Ie., once you get one cert
> from them, you'll never be given another -- where "you" are the person with
> your DNA.] He didn't realize how easy it is to get a cert under an assumed
> name (or someone else's name) from an on-line cert issuer.
>
> He also wanted this cert to be anonymous.
His reason was that he wanted to let people use a service anonymously,
but if they abused it he wanted to be able to kick them off or at least
discourage them in some way. One way to do this is for him to give a
blind certificate to each person who identifies himself to the service,
then cancel certs (by putting them on a "bad" list) if they abuse. He
doesn't know who abused, he just knows their cert (which is unlinkable
to their identity).
Another way is to have an infrastructure for these kinds of certificates,
sometimes called "is a person" credentials or certificates. If this
existed then someone could use the server by showing his is-a-person cert.
If he abused then that cert would be put on the black list.
This provides more limited privacy though because all service providers
see the is-a-person certificate, and although it is not linkable to the
identity of the holder, it in effect becomes an on-line identity since
all the on-line activities are linkable.
More privacy is achieved by a second level of blinding. People show their
is-a-person cert when they register, and receive another blinded cert
specific to that service. Then only the second cert is shown when the
person uses the service. The is-a-person cert is used by the service to
make sure they don't give two service-specific certs to the same person.
Ideally people go around and get service-specific certs in huge batches,
even for services they probably won't ever use, so that just in case
they decide to use one there won't even be any indication that their
particular is-a-person cert is actually using that service.
David Chaum has an even more elaborate scheme in which all the certs have
a certain mathematical structure, so that credentials like "good customer"
or "pays bills on time" can be transferred from one blinded cert to another.
> Our INDIRECT-SUBJECT: construct allows someone to issue certs (e.g., for
> voter registration) which are anonymous even to the issuer, but I'm not
> entirely sure anyone except voter registration will ever set up such a
> service.
>
> I'm also not sure it's desirable to have a (one body):(one active cert)
> service. Such a service could be misused to become like the hated national
> ID card -- required to get work, to pay taxes, get paid, get medical care,
> travel, ..., and subject to threat of revocation, in case you do something
> the service disapproves of.
It is possible there could be multiple competing bodies offering
is-a-person certs, although this becomes inefficient if there are too
many, since the customer and the service must share an is-a-person
cert issuer. Ideally the is-a-person issuer is not in the business of
policies but is very agnostic about such things, just sticking to the
non-duplication business. So they would not go around cancelling certs
on people they don't like.
Businesses or governments could then leverage off the is-a-person
infrastructure by issuing their own certs with various restrictions as
in the example above. Then it is true that people could be punished by
having their service-specific certs revoked if they do something the
issuer doesn't like. However when looked at as an alternative to the
fully identified system we have now with credit ratings and identity
profiles (like when they will identify suspicious airline passengers by
their VISA bills), it isn't so bad. Anonymous contracts will be easier
if people know their partners have something to lose if they break the
contract.
> As I mentioned on that list, the Chicago folklore is that (one body):(one
> vote) is uninforceable. I'm not sure such a service could succeed in its
> stated purpose.
I agree that the expense of setting up a system accurate enough to be
useful for such purposes makes it unlikely to happen. There is also the
difficulty of persuading service providers to move away from their tried
and true TRW credit reports and such.
> Meanwhile, there's the problem of revocation of an anonymous blind cert.
> Since the blind signature isn't part of a cert itself, it can't be revoked
> without revoking the blind signature key and therefore all the certs issued
> by that blind signature key. You can allow single user revocation, but
> only by using a different bind signature key for each applicant -- in which
> case anonymity to the issuer is lost.
I don't fully understand the technical issue here. Revocation of a blind
cert would mean issuing a signature on that cert stating that it is
revoked, and probably putting it on a CRL for people to find.
> Meanwhile, if he sets up such a service just for his members (e.g., an
> on-line Alcoholics Anonymous group, for example), the list of people who
> have requested blinded certs is itself an unacceptable leakage of
> information. He needs a worldwide (one body):(one cert) service.
Yes, this is a good point. This is an area where there are advantages
in tackling the problem at the large scale. There is also a psychological
problem that people who are interested in anonymity are particularly
*uninterested* in getting their names on lists. You should hear the story
about the time ViaCrypt tried to do a customer survey of people who had
bought PGP.
Hal