Expired Keys Bug
================
Currently, kiki does not convey the information that a key has expired.
Suggest appending [Expired] to the end of the line.

Q. What should happen if a master key expires but the subkey is still valid?
Probably treat the subkey as if expired as well. OR at the very least remove
the back arrows.


Nest level (network level) on user id
======================================
Next to the word `signed', but before the colon, perhaps a number in parenthesis
should be placed (0) indicates a signature of the working key, (1) implies it is
signed by a key the working key signed. (2) it is signed by a key that was signed
by a key that the working key has signed.

Some symbol could be used for signatures that are completely outside of the web,
(oo) perhaps. Where oo suggests the infinity symbol. It might also mean signatures
greater than some predefined nest-level for efficiency reasons, so nest levels 
greater than say 5, for example, are treated as (oo).


Orphaned subkeys
================
it is probably useful to track and convey information about keys that are not under
the authority of any known master key. It is possible to treat such keys as masters
or to treat them as subkeys, but as it is conventional that masters have uids and
subkeys have usage tags, it may be preferable to treat an ssh key as a sub key.

Another possibility is to treat them as both a master and a sub key, making duplicate
entries in the keyring for the key. If this is done, then of course, we can treat them
as if they are cross certified (<->). 

Whatever policy is adopted, it should keep in mind that the user may wish later on
to reclassify said keys under a master, or to have them automatically reclassified
when a master is imported which has a subkey which matches the orphan.

Perhaps kiki should have the concept of a ghost master, where a user id is given, but
there is no private, nor public key. Then later on if a master key is imported with the 
exact same user id, and it is signed by the working key, then all of the subkeys that are 
currently under the ghost can hop over to the new master. Back signatures will only show
if they were also imported.

User Interface
==============
Yet Another UI Proposal
	*As stated in the kiki.txt proposal, kiki should have top level commands and then
         options under those commands.

	*Top level commands: show, sync-secret, import-public, export-public..

		- The idea of this proposal is to keep the KEYSPEC notation, SPEC=file{SHELL_CMD}
                  but to use it across the board, on import as well as sync, and export.

		- The difference between import and sync is merely whether the file being
                  imported is also updated or not. Export using a similar interface again
                  but only writing to the specified files, possibly appending, but never 
                  adding information to the gpg keyrings.
	
		- At some point the interface can be expanded with analogous sync-public and
                  import-secret, etc... there is a clear suggested place to put any new 
                  functionality. 
	
		- Since import commands are not allowed to write to files, it makes little sense
                  to allow them to be created with SHELL_CMD. If that is what the user intends,
                  he can simply run SHELL_CMD manually and then run kiki using only the SPEC=file.

	Note:
		sync-secret is equivelent to the currently implemented 'sync' command.
		Therefore, it accepts keyring files consisting of only public keys. 
		Thus, the user should beware, -secret versions of commands are not prohibited
		from altering the public key database.

		For consistency, import-secret will also be capable of importing public keyring
		files.

		The SPEC=file syntax is only useful for importing PEM files, and so the
		import-public command, which is for importing other people's pgp keys, need
		not accept this syntax.
			Question: Since all supplied files to import-public are public keyrings,
				is it necessary to document (or even implement) the --keyrings
				option since no other mode is possible?

		The SPEC=file syntax is useful for the import-secret command which can be 
		identical to sync-secret except that it does not attempt to lock or write
		any files outside of GNUPGHOME.