d03ab969 |
1 | .\" -*-nroff-*- |
2 | .TH key 1 "5 June 1999" Catacomb |
3 | .SH NAME |
4 | key \- simple key management system |
5 | .SH SYNOPSIS |
6 | .B key |
7 | .RB [ \-k |
8 | .IR keyring ] |
9 | .I command |
10 | .PP |
11 | where |
12 | .I command |
13 | is one of: |
14 | .PP |
15 | .B add |
16 | .RB [ \-b |
17 | .IR bits ] |
18 | .RB [ \-e |
19 | .IR expire ] |
20 | .RB [ \-c |
21 | .IR comment ] |
22 | .I type |
23 | .IR attr ... |
24 | .br |
25 | .B expire |
26 | .IR keyid ... |
27 | .br |
28 | .B delete |
29 | .IR keyid ... |
30 | .br |
31 | .B setattr |
32 | .I keyid |
33 | .IR attr ... |
34 | .br |
35 | .B list |
c9e31e42 |
36 | .RB [ \-quv ] |
d03ab969 |
37 | .br |
38 | .B tidy |
39 | .br |
40 | .B extract |
41 | .I file |
42 | .IR keyid ... |
43 | .br |
44 | .B merge |
45 | .I file |
46 | .SH DESCRIPTION |
47 | The |
48 | .B key |
49 | command performs useful operations on Catacomb keyring files. It |
50 | provides a number of subcommands, by which the various operations may be |
51 | carried out. |
52 | .SS "Global options" |
53 | Before the command name, |
54 | .I "global options" |
55 | may be given. The following global options are supported: |
56 | .TP |
57 | .B "\-h, \-\-help" |
58 | Writes a brief summary of |
59 | .BR key 's |
60 | various options to standard output, and |
61 | returns a successful exit status. |
62 | .TP |
63 | .B "\-v, \-\-version" |
64 | Writes the program's version number to standard output, and returns a |
65 | successful exit status. |
66 | .TP |
67 | .B "\-u, \-\-usage" |
68 | Writes a very terse command line summary to standard output, and returns |
69 | a successful exit status. |
70 | .TP |
c9e31e42 |
71 | .BI "\-k, \-\-keyring " file |
d03ab969 |
72 | Names the keyring file which |
73 | .B key |
74 | is to process. The default keyring, used if this option doesn't specify |
75 | one, is the file named |
76 | .B keyring |
77 | in the current directory. The keyring must be stored in a regular file: |
78 | pipes, sockets, devices etc. are not allowed. |
79 | The |
80 | .B key |
81 | program attempts to lock the keyring before accessing it, using |
82 | .BR fcntl (2) |
83 | locking. It will however time out after a short while (10 seconds) and |
84 | report a failure. |
85 | .SS Concepts |
86 | In addition to the actual key data itself, a Catacomb key has a number |
87 | of other pieces of information attached to it: |
88 | .TP |
89 | .B keyid |
90 | Every key has a 32-bit identifying number, written in hexadecimal. The |
91 | keyid is derived from the actual key contents (although knowledge of a |
92 | key's keyid doesn't help one to guess the key itself). Applications use |
93 | keyids to refer to specific keys. A |
94 | .I deleted |
95 | key cannot be looked up by keyid. |
96 | .TP |
97 | .B type |
98 | A key's type string describes what the key may be used for. The type |
99 | string is arbitrary, except that it may not contain whitespace |
100 | characters. Applications use key types to obtain an arbitrary but |
101 | suitable key for some purpose. An |
102 | .I expired |
103 | key cannot be looked up by type, but may be looked up by keyid. |
104 | .TP |
105 | .B "expiry time" |
106 | Most keys expire after a certain amount of time. Once a key has |
107 | expired, it will no longer be chosen as a result of a lookup by key |
108 | type. However, it is not deleted until its deletion time is also |
109 | reached. |
110 | .TP |
111 | .B "deletion time" |
112 | A key's deletion time is the latest expiry time of any of the objects |
113 | which require that key. For example, a key used for authenticating |
114 | cryptographic cookies should have its deletion time set to the longest |
115 | expiry time of any of the cookies it can authenticate. A key is never |
116 | deleted until it has also expired. Once a key has expired |
117 | .I and |
118 | its deletion time is passed, it can no longer be referred to by |
119 | applications, and will be removed from the keyring next time it's |
120 | written to disk. |
121 | .TP |
122 | .B comment |
123 | A key may be given a comment when it's created. The comment is for the |
124 | benefit of users, and isn't interpreted by applications at all. |
125 | (Hopefully.) |
126 | .TP |
127 | .B attributes |
128 | A key as zero or more name/value pairs. The names and values are |
129 | arbitrary strings, except they may not contain null bytes. Some |
130 | attributes may have meaning for particular applications or key types; |
131 | others may be assigned global meanings in future. |
132 | .SH "COMMAND REFERENCE" |
133 | .SS add |
134 | The |
135 | .B add |
136 | command creates a new key and adds it to the keyring. The command |
137 | accepts the following options: |
138 | .TP |
c9e31e42 |
139 | .BI "\-b, \-\-bits " bits |
d03ab969 |
140 | The length of the key to generate, in bits. The default, if this option |
141 | is not supplied, is 128 bits. The bit length must be nonzero, and must |
142 | be a multiple of 8. |
143 | .TP |
c9e31e42 |
144 | .BI "\-e, \-\-expire " expire |
d03ab969 |
145 | The expiry date for the generated key. This may be the string |
146 | .RB ` forever ' |
147 | if the key should never expire automatically, or any date acceptable to |
148 | the |
149 | .BR getdate (3) |
150 | library function. Briefly, |
151 | .B getdate |
152 | understands absolute dates such as |
153 | .RB ` 1999-08-02 ' |
154 | or |
155 | .RB ` "August 2nd, 1999" ', |
156 | and (perhaps more usefully) relative dates such as |
157 | .RB ` "+2 weeks" '. |
158 | The default is to allow a 2 week expiry, which isn't useful. |
159 | .TP |
c9e31e42 |
160 | .BI "\-c, \-\-comment " comment |
d03ab969 |
161 | Sets a comment for the key. The default is not to attach a comment. |
162 | .PP |
163 | The key's type is given by the required |
164 | .I type |
165 | argument. Following the type are zero or more attributes, which are |
166 | attached to the key in the same way as for the |
167 | .B setattr |
168 | command. |
169 | .PP |
170 | The |
171 | .B key |
172 | program only generates random bitstrings, which are suitable for most |
173 | symmetric algorithms but not for public key cryptography. Generating |
174 | keys for more exotic algorithms is a feature which will be added later. |
175 | The keys are generated using the Catacomb random number generator, using |
176 | the |
177 | .B rand_goodbits |
178 | function. The Catacomb generator is believed to be strong. |
179 | .SS expire |
180 | Forces keys to immediately expire. An expired key is not chosen when a |
181 | program requests a key by its type. The keys to expire are listed by |
182 | their |
183 | .IR keyid s. |
184 | .SS delete |
185 | Deletes keys immediately. The keys to delete are listed by their |
186 | .IR keyid s. |
187 | Be careful when deleting keys. It might be a better idea |
188 | to expire keys rather than deleting them. |
189 | .SS setattr |
190 | Attaches attributes to a key. The key to which the attributes should be |
191 | attached is given by its |
192 | .IR keyid . |
193 | Each attribute has the form |
194 | .IB name = value\fR. |
195 | An attribute can be deleted by assigning it an empty value. Although |
196 | the keyring file format is capable of representing an attribute with an |
197 | empty value as distinct from a nonexistant attribute, this interface |
198 | does not allow empty attributes to be set. |
199 | .SS list |
200 | Lists the keys in the keyring. A couple of options are supported: |
201 | .TP |
202 | .B "\-v, \-\-verbose" |
203 | Increases the amount of information displayed for each key. Repeat for |
204 | a greater effect. |
205 | .TP |
206 | .B "\-q, \-\-quiet" |
207 | Decreases the amount of information displayed for each key. Each use |
208 | cancels a |
209 | .RB ` \-v ' |
210 | option. |
c9e31e42 |
211 | .TP |
212 | .B "\-u, \-\-utc" |
213 | Display key expiry times as UTC rather than using the local time zone. |
d03ab969 |
214 | .PP |
215 | By default, a single line of output is generated for each, showing |
216 | keyids, types, expiry and deletion dates, and comments. Additional |
217 | .RB ` \-v ' |
218 | options show more information, such as the exact time of day for expiry |
219 | and deletion, key attributes, and a hex dump of the actual key data. |
220 | .SS tidy |
221 | Simply reads the keyring from file and writes it back again. This has |
222 | the effect of removing any deleted keys from the file. |
223 | .SS extract |
224 | Writes a selection of keys to the named |
225 | .IR file , |
226 | which may be |
227 | .RB ` \- ' |
228 | to designate standard output. The keys to extract are listed by their |
229 | .IR keyid s. |
230 | The output is a valid keyring file. |
231 | .SS merge |
232 | Merges the keys from the named |
233 | .IR file , |
234 | which may be |
235 | .RB ` \- ' |
236 | to designate standard input, with the keyring. Keys already in the |
237 | keyring are not overwritten: you must explicitly remove them first if |
238 | you want them to be replaced during the merge. |
239 | .SH BUGS |
240 | The ability to generate keys for specific algorithms ought to be added, |
241 | for DES (setting the parity bits correctly), RSA, ElGamal and DSA, at |
242 | the very least. (None of these systems are actually implemented in |
243 | Catacomb at the moment, however.) |
244 | .SH "SEE ALSO" |
245 | .BR keyring (5). |
246 | .SH AUTHOR |
247 | Mark Wooding, <mdw@nsict.org> |
248 | |