pem-dev
[Top] [All Lists]

Re: policy based delegate issuing authority

1995-10-10 20:28:00
Its seems strange that as publickey gets massively freer - in terms
of licensing etc,. the next enforcement problem suddenly gets much, much
larger - certification!

I think that one of the factors at work here is that as people attempt to
actually deploy and use some of this technology, it becomes apparent that
the underlying technology itself (public key cryptography and digital
signatures) do not so much solve problems in and of themselves as it
simply moves some of them around.  Now, some of this "moving around" is
extremely useful indeed, but many issues remain when you get down to actually
constructing systems with these tools.

Certification authorities, for example, work great in limited domains, and
allow secure communication without prior arrangement within those domains.
However, there's still prior arrangement living underneath the surface--it's
just become prior agreement to trust the certification authority(-ies)
involved.  Imagine a black market in PK certificates, if only through the
use of bogus CAs.  After all, a certificate is only as strong as the "real
world" bona fides that back it and the trustworthiness of the agent creating
the certficate.  Neither of these are secure a priori, however finely we
try to calibrate degress of assurance and such.  The one thing that the
experimentation so far seems to show is that it is much easier to
guarantee anonymity than it is to guarantee authentication.  This may
end up have much more far-reaching effects than any kind of certification
structures that get set up.  It's hard to tell just yet.

And even with reliable certificates, public key cryptography only solves
a few specific problems (though this can be applied in many ways).  It
solves the conventional secure key distribution problem, which works great
when you're using cryptography in conventional applications, or variations
of them.  Network-based payment authorization, for example--two parties,
small discrete messages.

How would you build a secure IRC channel, though?  It's not always obvious
what "secure" even means in some contexts, much less how one might profitably
apply the current spectrum of tools.  One answer is "constrain the problem
until it fits the capability of the tools available"--the military is great
at doing this, at least for tactical communications.  Didn't help Adm.
Poindexter and Ollie North in court, though :).

The utility of modern cryptographic technology to the solution of real-world
problems is still in its infancy, in my opinion.  There's a lot of extremely
clever discrete mathematics here, but not a lot of experience of what
can and cannot be built with it.


Amanda Walker
InterCon Systems Corporation

<Prev in Thread] Current Thread [Next in Thread>