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
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
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.
|
