1993-08-21 - Key Mgmt GUI

Header Data

From: felix@hu.se (Felix Ungman)
To: cypherpunks@toad.com
Message Hash: 36767d6c16c6f732b546e3a637f1e78c96f456fbf1d06d384c88cfa9a5568175
Message ID: <199308210824.AA01679@mail.swip.net>
Reply To: N/A
UTC Datetime: 1993-08-21 07:11:25 UTC
Raw Date: Sat, 21 Aug 93 00:11:25 PDT

Raw message

From: felix@hu.se (Felix Ungman)
Date: Sat, 21 Aug 93 00:11:25 PDT
To: cypherpunks@toad.com
Subject: Key Mgmt GUI
Message-ID: <199308210824.AA01679@mail.swip.net>
MIME-Version: 1.0
Content-Type: text/plain


I'm designing a (public) key managament utility. I have no experiense with
cryptography, but I have worked much with GUI design. Please let me know
your opinion on the following questions.

1 - Is the key/keyring methaphor the easiest one to understand (both
respect to encryption and signatures)? Is there another better methaphor,
such as users (instead of keys) having a public and a secret id. For
example, Apple OCE uses the notation of signer objects instead of keys.

2 - Each keyring is naturally stored as a file. The obvious way to view a
keyring is to show a list of all keys in it. How much information should be
visible in the list, and how should it be presented (so that the user can
navigate thru very large keyrings)? Should the list include certificates?
If not, how are they managed.

3 - How should key pairs be treated? Should a user's public key be
"associated" with his secret key (and maybe stored together)? Should it be
possible to mix public and secrets keys in a keyring? Is it neccesary to
have a secret key ring when there's only one secret key?
----------------------------------------------------------------------
- RealName: Felix Ungman   InterNet: felix@hu.se   AppleLink: SW0358 -
-                     Felix gor det goda godare!                     -
----------------------------------------------------------------------





Thread