| 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 |
| 36 | .RB [ \-quv ] |
| 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 |
| 71 | .BI "\-k, \-\-keyring " file |
| 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 |
| 139 | .BI "\-b, \-\-bits " bits |
| 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 |
| 144 | .BI "\-e, \-\-expire " expire |
| 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 |
| 160 | .BI "\-c, \-\-comment " comment |
| 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. |
| 211 | .TP |
| 212 | .B "\-u, \-\-utc" |
| 213 | Display key expiry times as UTC rather than using the local time zone. |
| 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 | |