[u/mdw/catacomb] / keyring.5

.\" -*-nroff-*-
.TH keyring 5 "5 June 1999" Catacomb
.SH NAME
keyring \- description of Catacomb keyring files
.SH DESCRIPTION
Keyring files are line-oriented text files.  It is recommended that
programs use only the provided interface for reading and modifying
keyring files, for consistency of locking and representation: this
description is provided for the benefit of administrators attempting to
understand or repair keyring files.
.PP
Lines containing only whitespace and lines whose first non-whitespace
character is
.RB ` # '
are ignored, but are not written back to the file.  Thus, the comment
facility is not particularly useful.
.PP
Each other line describes a key.  Key descriptions consist of between 4
and six whitespace-separated fields.  The final comment field may
contain whitespace characters.  The fields are, in order:
.TP
.B type
The key's type string, set when the key was created.
.TP
.B "key data"
The actual key, Base64 encoded, as described in RFC2045.
.TP
.B "expiry time"
The time at which this key expires, represented as an integer number of
seconds since 1970-01-01 00:00:00 UTC, not counting leap seconds.  The
special value \-1 signifies that this key never expires.
.TP
.B "deletion time"
The time at which this key should be deleted, using the same
representation as the expiry time.  The special value 0 signifies that
the key should be deleted on expiry.
.TP
.B attributes
The key's attributes, encoded using the `form-urlencoded' encoding
defined in RFC1866.  This field is optional: if it is omitted, the key
has no attributes.  Alternatively, if there are no attributes, this
field may be given as a single dash
.RB ` \- '.
.TP
.B comment
The comment field.  This field is optional.  It may contain whitespace.
It is deliberately not included as an attribute, since the urlencoded
nature of attributes makes them hard to read when perusing a keyring
file.
.PP
It is not envisaged that the file format will change in the future.  Any
extensions will be made by defining new attributes.
.SH AUTHOR
Mark Wooding, <mdw@nsict.org>
Commit	Line	Data
d03ab969	1	.\" --nroff--
	2	.TH keyring 5 "5 June 1999" Catacomb
	3	.SH NAME
	4	keyring \- description of Catacomb keyring files
	5	.SH DESCRIPTION
	6	Keyring files are line-oriented text files. It is recommended that
	7	programs use only the provided interface for reading and modifying
	8	keyring files, for consistency of locking and representation: this
	9	description is provided for the benefit of administrators attempting to
	10	understand or repair keyring files.
	11	.PP
	12	Lines containing only whitespace and lines whose first non-whitespace
	13	character is
	14	.RB ` # '
	15	are ignored, but are not written back to the file. Thus, the comment
	16	facility is not particularly useful.
	17	.PP
	18	Each other line describes a key. Key descriptions consist of between 4
	19	and six whitespace-separated fields. The final comment field may
	20	contain whitespace characters. The fields are, in order:
	21	.TP
	22	.B type
	23	The key's type string, set when the key was created.
	24	.TP
	25	.B "key data"
	26	The actual key, Base64 encoded, as described in RFC2045.
	27	.TP
	28	.B "expiry time"
	29	The time at which this key expires, represented as an integer number of
	30	seconds since 1970-01-01 00:00:00 UTC, not counting leap seconds. The
	31	special value \-1 signifies that this key never expires.
	32	.TP
	33	.B "deletion time"
	34	The time at which this key should be deleted, using the same
	35	representation as the expiry time. The special value 0 signifies that
	36	the key should be deleted on expiry.
	37	.TP
	38	.B attributes
	39	The key's attributes, encoded using the `form-urlencoded' encoding
	40	defined in RFC1866. This field is optional: if it is omitted, the key
	41	has no attributes. Alternatively, if there are no attributes, this
	42	field may be given as a single dash
	43	.RB ` \- '.
	44	.TP
	45	.B comment
	46	The comment field. This field is optional. It may contain whitespace.
	47	It is deliberately not included as an attribute, since the urlencoded
	48	nature of attributes makes them hard to read when perusing a keyring
	49	file.
	50	.PP
	51	It is not envisaged that the file format will change in the future. Any
	52	extensions will be made by defining new attributes.
	53	.SH AUTHOR
	54	Mark Wooding, <mdw@nsict.org>