[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Depository Proposal (revised)
Just thought I'd forward on something that's cooking in Fidoland.
This guy has code running already. I haven't even looked at it yet
myself If it's a crock, please be kind and forward suggestions to the
author...
[email protected]
-------------------- begin forwarded message
(Please note that examples still have not been included with this text)
Public Keys Depository Proposal
By Marcos R. Della
(1:125/180 or [email protected])
Def: De.pos.i.to.ry (di-POZ-i-tohr-ee) n. a storehouse, a place for
safekeeping of things
-+---------------------------------------------------------------------+-
With the latest release of the PGP20 program, public key availability
has fallen into the hands of the individual. This provides a relative
degree of security over messages that are sent from user to user in
various formats (text, binary, etc) over different transportation
mechanisms. I will not go into the system that allows public keys to
work nor public key history. Instead I'll point you to the rather
complete documentation that comes with the PGP program.
Unfortunately, there is a major drawback to this system (also pointed
out in the PGP documentation). Public key distribution has few
security elements involved to insure the validity of a particular key.
PGP attempts to address this problem by providing a "signature" system
to each public key to give reasonable validity to its origin.
Unfortunately, this depends upon trust of the individual who signs the
key to begin with. Who polices the policemen?
Unfortunatly, the issue of key validity is yet another topic that
cannot be easily addressed since authenticity lies in one persons
trust of another. Yet there still needs to be a system in which keys
can be distributed or held for later use. This system should be
multiply redundant and have some degree of immediate access in order
to make the information stored useful. One such system would be a
depository, a place to store public keys for later retrieval.
This proposal will attempt to describe a system whereby you can get
around the validation of public keys problem without requiring someone
to police the Depository itself!
--------
Problems Involved:
- How do you know the key depositor isn't faking his/her keys?
- How do you verify (at the depository) that a key being deposited is
from the key originator or is even valid?
- What is to prevent the depository from faking keys that is "signs"?
- How can this system be resonably redundant and easy to access?
First off, the depository is NOT a validation center. The system
never will verify the users as existing or if they are even honest
users. The depository key signature only verifies that the key has
been deposited and is available for access at any time. Again, the
depository DOES NOT verify users, only the fact that a deposit has
been made. (A better form of deposit slip)
If a user wants to deposit his/her key, what is to prevent the sysop
from intercepting this public key, making a substitution replacement,
and then forwarding the new public key? Unfortunately, there are
sysops out there that have already done this in some respects.
Thereby the system has to place the responsibility upon the user for
key deposit verification. To prevent the sysop from changing the
deposit, the user should use the Depository Public Key (hereafter
referred to as DepoKey) to send his/her key for deposit.
Again, what prevents the "bad" sysop from just throwing this message
away (obviously he can't read it) and sending a fake message (also
encrypted with the DepoKey)? Although this eventually thwarts the
entire system (the sysop cannot fake the users public key unless the
user uploads it in plain text to the sysop), it still causes problems.
To prevent this, the user should include some sort of text in the
deposit that the depository will mail back to the user, ENCRYPTED
along with the user's public key. When the user receives a valid
message back that contains his original text, things are fine. If the
user does not receive a response in a few days or gets an incorrect
return message, then the user should send a cancel message to the
depository and re-deposit his or her key. The complete the handshake,
the user should send an authentication back to the depository stating
that the key was recieved correctly (instructions on how to do this
should be returned with the key). If a return reciept isn't back in a
resonable period of time, the depository will remove the key from its
deposit keyring. NOTE: This will never invalidate a public key, it
will only prevent it from being distributed via the depository system.
What is to prevent the depository from faking keys that it "signs"?
Well, in order to be effective with fake keys, you need to be in the
transport path of the messages that you are planning on "stealing".
Since the depository is not a major hub or node (except possibly to a
few people) this negates any effect of faking keys. Also, once a user
has received verification that the depository has his public key, he can
then also post it anywhere. The depository will return his public key
with a depository signature on it. This allows the user to upload a
verified key to anywhere. When keys are distributed with a depository
signature on them, then they are on file with the depository in case
someone wants to withdraw them later.
As long as the public key for the depository is made worldwide public,
this system will work.
As for creating a multiply redundant system, there should be several
sites that are listed as depositories. These systems will on a weekly
basis, exchange acknowledged keys (ie, keys that have undergone the
handshaking process) with one another. A user can then request a key
from ANY of the depository sites and get the same information.
For those that want certified keys (other than from the users) such as a
BBS system needing the public key of another, there will be a withdrawal
mechanism built into the depository to pull single or multiple keys.
Also, the complete public keyring may optionally be pulled (FREQing).
-----------
The actual mechanism:
Below is the Depository Public Key. Any public key that has been signed
with this depository key will be assumed to have undergone the handshake
process to verify that the originator of the key pair has in fact issued
a valid key. This signature only verifies the deposit (a reciept).
*** THIS KEY DOES NOT VERIFY THE IDENTITY OF THE USER!!! ONLY THAT ***
*** THE USER WAS IN FACT THE ORIGINATOR OF THE PUBLIC KEY ***
*** AND HAS DEPOSITED IT INTO THE PUBLIC KEY DEPOSITORY!!! ***
For user identification, there should be a second or third signature
from a BBS or known friend. This will give the key a verification
level. If the user wishes to deposit a key with another person's
signature, there will be no problem since the handshake method still
insures the source and destination of the message. (Note: This is
preferred since depository keys will then be distributed with dual
signatures)
The depository allow four functions: Deposit, Withdrawal, Cancel, and
Acknowledgement of Deposit. To use these function...
DEPOSIT: Address a message to "Depository" at one of the listed
depositories at the end of this document. The subject will be "Deposit"
and the text body will contain your Public Key (in Ascii format) and
some small body of text that will be reflected back to you. NOTE: The small
body of text and your public key should be encoded WITH the Depository Key.
WITHDRAWAL: Address a message to "Depository". The subject will be
"Withdrawal" and the text body will contain what you are looking for on
each line just as if you were polling your own PGP program. You will be
sent back a list of keys with the depository signature verifying the
message. Note that a * for the body text will give a LONG list back to
you... For fidonet, this MIGHT require a poll to recieve your return list.
See Appendix A
CANCEL: Address a message to "Depository". The subject will be
"Cancel" and the text body will contain the text "CANCEL PUBLIC KEY"
with your signature on the message. The cancel will not take place
without your signature! You will receive a cleartext response to this.
All this does is to remove your public key from the depository keyring. If
this comes with a "kill" signature for the key, then it will be moved from
the deposit keyring to the invalid/killed keyring.
ACKNOWLEDGE: Address a message to "Depository". The subject will be
"Acknowledge" and the text body will contain the text "ACKNOWLEDGE" with
your signature on the message. Without the signature, your public key
will continue the daily countdown to keyring removal. A cleartext message
will be returned upon any receipt of this message.
Anything that doesn't fit one of these will be rejected and a return
message will be bounced back.
-------------------------------------------------------------------------
*** WARNING ***
This proposal ONLY provides a method of storing keys for public
distribution and withdrawl. This in NOW WAY verifies or even attempts
to verify the authenticity of the issuer of the key.
*** WARNING ***
----------------------------[ CUT HERE ]---------------------------------
Depository #1 (1:125/180) [KeyID:77854F] "Depository #1 [Public Keys]"
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0
mQCNAirV7H4AAAEEAMgk39sU7OvZGr/Ig/g0Kaw2cY3FpQOFvRXp9OXmlAch3FBA
Ow2/oD8dbKdiQamuIMFw6qpg0Bw2k8mhKXCfFhLIZjH3FJeqKQrV7UvELBJdCT4q
b7wRg8jeLos2rR9a4jt+s0srNS/LznfLvquESEhMuzcxSTC27OyxS4Fbd4VPAAUT
tBtEZXBvc2l0b3J5ICMxIFtQdWJsaWMgS2V5c10=
=rC+3
-----END PGP PUBLIC KEY BLOCK-----
--- GEcho 1.00/beta
* Origin: The Babble Underground (Home of the Jabber QWK Reader) (1:125/180)
SEEN-BY: 125/111 125 180 185 374/14
;;
-------------------- End forwarded message
--
Tom Jennings / World Power Systems
email: [email protected]
FidoNet: 1:125/111, BBS +1-415-863-2739
postal: Box 77731, San Francisco CA 94107 USA
--
tom jennings - via FidoNet node 1:125/555
UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET: [email protected]