1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
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.
|
