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