[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Example 2: POP server, telnet proxy, ftp proxy, ....
On Wed, 10 Apr 1996, Mark S Feldman wrote:
> ...
> > Why generate tickets?
> >
> > 1) this keeps down the code size and execution time of the proxy to a bare
> > minimum
>
> This is a local optimization which needs not be imposed on the PKI.
> If the implementation supports some way of verifying trust for a
> certain period of time without having to run up the certification
> chain each and every time, great.
OTOH, while it could be considered a local optimization, if we know (to
one degree or another) that tickets are of a given format, 'ticket
manager' code can become standard. This has several advantages:
(1) Less code for people to write
(2) Fewer bugs in critical code (eventually)
(3) "Ticket management" code could be put into, for example, web browsers
so that the correct ticket can be "handed back" to a given website on
request.
> It doesn't matter if Organizational Units within CyberCash are managed
> together or separately -- the hierarchy still works. The I in PKI is
> infrastructure. The above directives make use of the infrasturture
> that can be provided with certificates. A ticket here, a ticket there
> is just that -- not an infrastructure.
But the processing time for a certificate is (probably) significantly
greater than for tickets, because the security erquirements of a cert are
greater.
> You're putting a lot of responsibility on your oracle's shoulders. I
> can see it working in small communities, but don't see it scaling for
> larger organizations.
Chaum's DigiCash (as I understand it, anyway) is essentially identical to
tickets, in that it's not a permanant certificate. (Not that this
_proves_ it'll scale well, but just noting that there are other, perhaps
significant, consequences if it does not.)
> On one hand there are the users of PGP who realize that some sort of
> certificate infrastructure is needed for PGP to scale well. On the
> other hand you appear to be reducing the PKI to the current PGP web of
> trust or something even simpler. There seems to be a dichotomy here.
I'm a user of PGP; I don't think it's possible to replace the web of
trust, because that means I have to trust somebody else's assessment that
"x is y" (key is equivilant to person). What's needed isn't a replacement
for the web of trust, but a set of tools which allow people to build
their own little pyramids of trust. This is interesting; one Giant,
government-run Pyramid of Trust (ie a certificate heirarchy run by the
government and tied to true names, though this is just one possibility)
is highly undesirable.
I have a strong feeling against building technologies which provide more
power for large authorities than they provide for smaller authorities.
Jon
----------
Jon Lasser (410)494-3072 - Obscenity is a crutch for
jlasser@rwd.goucher.edu inarticulate motherfuckers.
http://www.goucher.edu/~jlasser/
Finger for PGP key (1024/EC001E4D) - Fuck the CDA.
References: