bugs.txt

1 files changed, 69 insertions, 0 deletions

diff --git a/bugs.txt b/bugs.txt
new file mode 100644
index 0000000..2ba2c68
--- /dev/null
+++ b/bugs.txt
@@ -0,0 +1,69 @@
+
+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.
+