[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on the draft

At 07:43 PM 8/27/96 EDT, Angelos D. Keromytis wrote:
>Another example:
>Imagine an international Passport Certificate, which holds information
>about your person (name, address, nationality etc); each time you want
>to travel to some country which would require some sort of visa, you
>just go to their embassy and get your certificate signed (and it would
>expire when the visa would expire). Now, instead of having one
>certificate for each country, it might be easier to have just one
>certificate and multiple signatures.
>It also seems that some support for multiple signatures is there
>already, even if just to support the DUAL-SIG: attribute.


        I think we made this as a conscious decision back in the beginning
of the discussion -- not to have a grab-bag style of certificate.  Brian had
some experience with the latter and found it unwieldy.

        You can achieve the same thing by having a construct in the user's
application code which holds related certificates together and releases
relevant ones on demand.

        There's always the problem with certificates of privacy violation
through dossier building.  A person's certificates, taken together, form a
kind of dossier and the more <auth>s you gather together, the more sensitive
the bag of certs becomes.  Some people will probably opt for different
SUBJECT keys for different kinds of certificates (one for church membership
showing the member to be up to date in tithing; one for membership in a porn
of the month club), just to prevent such dossier building.

        The passport certificate is a great example, come to think of it.
It might be destined for PolicyMaker treatment, rather than a straight SPKI

        The permission being granted is to enter a particular country -- say
the UK or Cuba, for two examples.  That permission is in the form of a visa.
A visa is clearly a certificate and could be a direct SPKI cert.  It doesn't
need the passport cert itself, but the agency which issues the visa might
require a passport as an input to the process.  In the digital world, you
wouldn't need a passport to enter the country -- just the visa.  Of course,
an immigration officer at the border might accept a passport and issue a
visa on the spot (or just let you in without the visa).  If that's to be
automated, then there's a program which takes a passport and generates a
visa.  To me, that's PolicyMaker domain.

        The interesting problem comes in when the USA wants to prohibit
citizens from getting a Cuban visa.  I don't know of any convenient way to
make sure the USA itself is involved in all visa processes, unless the US
generates passport certs on demand, each lasting a short lifetime, and
generating different ones depending on who asks.

        Is this even desirable?

 - Carl

|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |