From: "Michael Peponis" <mianigand@outlook.net>
Date: Sun, 10 Nov 1996 18:20:08 -0800 (PST)
To: "David K. Merriman" <cypherpunks@toad.com
Subject: Re: Rarity: Crypto question enclosed
Message-ID: <199611110219.SAA26107@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

> Sorry that this message doesn't include any flames, "outings",
> denigrations, or other stuff......

Hey, that "stuff" comes in useful.

Some of the more origional ones are posted on my office wall,
so when people accuse me of being a childish, insensitive and
 egotistical  I just show them some cypherpunk postings, "See, I'm not
this bad, count yourself fortunate how would you like to work for some
of these guys?"

> My simple question is regarding key/certificate distribution:
> 
>         Is there any particular reason that such can't be
accomplished via 
> on-line lists, and made available via a service on a port, using
standard 
> (textual) commands, like mail and such are now?

Conceptual, I had the same idea about a year ago, but never enough
time to do it. Practically, it could be painful.

It's possible to have a key-server listen on a port and accept
requests, then it would
fork a process, process the result, and return an answer set.

But how many CPU cycles would it take for a machine to process a
request, ie going through
1000 of keys?  I am not exactly sure, it took a long while on my
pentium.

In my opinion, if I were to run a key server as a service, with
clients connecting and requesting a key
it shouldn't take more than a minute to get a responce.

>         The things that come to mind are a 'client' request for a
key, a 
> 'client' submission of a key, an external host requesting a key
exchange, 
> and the host itself requesting a key exchange with another system
(only 
> new/changed keys being swapped).

Had the exact same idea, but came up with an interesting concept. When
a person submits a key, a PGP process is spawned yeilding the
following information 1.) The name (peponmc@cris.com) 2.) The real
name (Michael Peponis) 3.) The key size 4.) Creation date of the key
5.) Key finger print

This information, along with the acutal key would be inserted into a
SQL Database table

With a structure similar to this

Name           varchar2
Real_name   Varchar2
KeySize        Integer
CreationDate date
PGPKEY       Varchar(a fairly large one)
Submission_date  Date

The idea here being that the key would be added as a field, and
requests from clients
and other key servers would do a simple Database query, which are very
quick.





>         The way I see it working is similar to (but not as slow as,
or 
> requiring the human intervention) of the key servers already
existing. 
> Granted that the first few such servers might carry a higher load,
but I'd 
> think that would taper off as the (presumably free) software became

> available, similar to the growth of remailer software (which would
seem to 
> be a fairly reasonable relationship....).

>         Hooks into existing PGP-fluent software shouldn't be
difficult with 
> a standardized protocol, and I wouldn't think that the servers
would be 
> that difficult to code and implement on a 'standard' (consistently
used, 
> that is) port.


It's not that hard, it's performance that's more of an issue.  The
beauty of my approch would be that initially, there would be alot of
"Add" requests, resulting in many PGP processes running on the box,
but eventually, they would tapper off.

Database requests pose no real problems, on Unix boxes, especially
with Oracle, the SGA is always running, it's just one more request,
going up against a realatively small table.  The box could return an
answer in a matter of seconds, as opposed to over a two minutes.

Server updates would be swift too, they would just transfer well
defined SQL Datasets between themselves.

>         I'm willing to have a try at the first server, if the
parameters 
> can be defined.


Let me know what you think of my idea 
> Dave Merriman


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850

iQCVAwUBMoZirkUffSIjnthhAQFBpAQAw1a48NY/IPai8FqAkqlfi2tLoreGlQlW
RaWLVnSE/dl4CpRf+nLXjRRYQL6FlmKxfVkgv68yS3srFlx9KpkGqOT3k9hZGfzU
3X+ADKI2oKzSZM92vmYoM+BGtxggdgg/SjoPwyxq76FuiHt6SnDcCvXeRUDclFHi
CMqPPKvaqBo=
=Yudv
-----END PGP SIGNATURE-----