-----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-----