profile.d/00base: Make key information public for public keys.
[distorted-keys] / profile.d / 00base
1 ;;; -*-conf-*-
2 ;;;
3 ;;; Basic profile configuration for key management
4 ;;;
5 ;;; (c) 2011 Mark Wooding
6 ;;;
7
8 ;;;----- Licensing notice ---------------------------------------------------
9 ;;;
10 ;;; This file is part of the distorted.org.uk key management suite.
11 ;;;
12 ;;; distorted-keys is free software; you can redistribute it and/or modify
13 ;;; it under the terms of the GNU General Public License as published by
14 ;;; the Free Software Foundation; either version 2 of the License, or
15 ;;; (at your option) any later version.
16 ;;;
17 ;;; distorted-keys is distributed in the hope that it will be useful,
18 ;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
19 ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
20 ;;; GNU General Public License for more details.
21 ;;;
22 ;;; You should have received a copy of the GNU General Public License
23 ;;; along with distorted-keys; if not, write to the Free Software Foundation,
24 ;;; Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
25
26 ;;;--------------------------------------------------------------------------
27 ;;; Profile syntax.
28 ;;;
29 ;;; The configuration file is divided into sections, each beginning with a
30 ;;; header enclosed in square brackets. Within a section, lines of the form
31 ;;;
32 ;;; NAME = VALUE
33 ;;;
34 ;;; define properties within that section. Property names may consist of
35 ;;; alphanumeric characters, hyphens `-', underscores `_', and percent signs
36 ;;; `%'; hyphens and underscores are equivalent. Several section headers may
37 ;;; use the same name: this is entirely equivalent to a single section
38 ;;; containing the same definitions in the same order. If two definitions in
39 ;;; the same section have the same property name, the earlier definition is
40 ;;; silently ignored. Properties whose names contain percent signs are
41 ;;; used internally only, and not emitted.
42 ;;;
43 ;;; There are special pseudoproperties whose names begin with `@'.
44 ;;; Currently, the only pseudoproperty defined is `@include'. The value is a
45 ;;; list of section names separated by whitespace: the named sections are
46 ;;; `directly included'; a section includes directly included sections, and
47 ;;; sections included by directly included sections. It is an error for a
48 ;;; section to include itself. If a property is defined in an included
49 ;;; section, but not in the including section, then the property is added to
50 ;;; (`inherited by') the including section. The property's value is
51 ;;; determined as follows. A `candidate definition' for the property is a
52 ;;; definition in a section S such that no section which includes S contains
53 ;;; a definition for the property. It is an error for two candidate
54 ;;; definitions to provide different values for the property; otherwise, the
55 ;;; inherited value is the common value of the candidate definitions.
56 ;;;
57 ;;; Property definitions before the first section heading are placed in the
58 ;;; special section `@GLOBAL', which is implicitly included in every other
59 ;;; section.
60 ;;;
61 ;;; Property values (but not pseudoproperties) may contain substitution
62 ;;; placeholders of the form $NAME or ${NAME}, which are replaced by the
63 ;;; value of the (possibly inherited) property NAME. It is an error if there
64 ;;; is no definition for the property. Substitution placeholders in the
65 ;;; replacement value are also expanded, recursively; the search begins
66 ;;; relative to the original section. (There is not a well-defined
67 ;;; containing section for the replacement property.) References to the
68 ;;; special property name `@name' is replaced by the name of the section.
69
70 ;;;--------------------------------------------------------------------------
71 ;;; Structure and conventions.
72 ;;;
73 ;;; It's probably best if you don't edit this file. Instead, install it as
74 ;;; `00base' in the system profiles directory, and apply your local
75 ;;; customizations in separate files. The numbers on the front of the
76 ;;; filenames ensure that they're read in the right order. The first digit
77 ;;; describes the source of the configuration:
78 ;;;
79 ;;; 0 Global defaults. The configuration files distributed
80 ;;; with distorted-keys go here. So should the default
81 ;;; profiles for any other key types and client packages.
82 ;;;
83 ;;; 1--4 Overrides for operating system vendors, packagers,
84 ;;; etc.
85 ;;;
86 ;;; 5--8 Overrides for organizational and site-specific
87 ;;; configuration.
88 ;;;
89 ;;; 9 Host-specific overrides.
90 ;;;
91 ;;; Section names beginning with `%' are not intended to be used directly,
92 ;;; but included into other sections.
93 ;;;
94 ;;; Each key type KTYPE should define two or three sections:
95 ;;;
96 ;;; %KTYPE Basic configuration common to all uses of the key
97 ;;; type. All profiles using the key type should include
98 ;;; this section. The `type' property should be defined
99 ;;; appropriately. The settings should be suitable for
100 ;;; general use by a technically able user who is not a
101 ;;; cryptography expert, and should aim to provide at
102 ;;; least a 128-bit security level.
103 ;;;
104 ;;; %KTYPE-infra Additional configuration for use as an infrastructure
105 ;;; key (e.g., a keeper, recovery, or archive key). If
106 ;;; the key type is not suitable for use as an
107 ;;; infrastructure key, don't define this section at
108 ;;; all.
109 ;;;
110 ;;; KTYPE Additional configuration for use as a user key. In
111 ;;; particular, this should include either `%symmetric'
112 ;;; or `%asymmetric' as appropriate, in order to make
113 ;;; available appropriate default ACLs. Typically, no
114 ;;; other settings will be needed.
115 ;;;
116 ;;; Other section names beginning `KTYPE-' or `%KTYPE-' are reserved for the
117 ;;; the use of the key type.
118
119 ;;;--------------------------------------------------------------------------
120 ;;; Common settings.
121
122 ;; Random bit source, for generating nubs and similar.
123 random = random
124
125 ;; Nub generation parameters. Note that the specifics of nub generation are
126 ;; key-type specific.
127 nub-hash = sha384
128 nub-random-bytes = 512
129
130 ;; Hash function for computing nub hashes.
131 nubid-hash = sha256
132
133 ;;;--------------------------------------------------------------------------
134 ;;; Common policy for user keys.
135 ;;;
136 ;;; All key-type profiles for user keys should include one of the following
137 ;;; sections.
138 ;;;
139 ;;; %asymmetric-secrecy i.e., public-key encryption and decryption.
140 ;;;
141 ;;; %asymmetric-integrity i.e., issuing and verifying digital signatures.
142 ;;;
143 ;;; %symmetric-secrecy i.e., standard symmetric encryption and decryption.
144 ;;;
145 ;;; %symmetric-integrity i.e., generating and verifyng message authentication
146 ;;; code tags.
147 ;;;
148 ;;; Each of these includes one or other of `%asymmetric' or `%symmetric', and
149 ;;; one or other of `%secrecy' or `%integrity'. Both of these include
150 ;;; `%common', which may therefore contain policy for all user keys.
151 ;;;
152 ;;; The `acl-ACTION' properties define access-control lists for various
153 ;;; ACTIONs. An ACL consists of a sequence of entries separated by spaces.
154 ;;; An ACL entry has the form
155 ;;;
156 ;;; [-]PATTERN
157 ;;;
158 ;;; where PATTERN may be one of the following.
159 ;;;
160 ;;; !owner The owner of the key, i.e., the user who created it.
161 ;;;
162 ;;; %GROUP Any member of a group whose name or gid matches the
163 ;;; glob pattern GROUP.
164 ;;;
165 ;;; USER A user whose name or uid matches the glob pattern
166 ;;; USER.
167 ;;;
168 ;;; An entry usually grants permission to a user who matches its pattern; if
169 ;;; prefixed by a `-', the entry denies permission instead. Entries are
170 ;;; checked in order, left to right; only the first match is significant. If
171 ;;; no matching entries are found then access is denied.
172 ;;;
173 ;;; ACTIONs currently defined are `encrypt', `decrypt', `sign', `verify', and
174 ;;; `info', corresponding to the like-named `cryptop' commands. Others may
175 ;;; be defined later, but their names won't contain `%' signs. The default
176 ;;; ACLs are defined in terms of the following internal properties.
177 ;;;
178 ;;; acl-%none No access at all, for inapplicable operations.
179 ;;;
180 ;;; acl-%private Access should always be limited to authorized users.
181 ;;;
182 ;;; acl-%public Access may be granted more widely for asymmetric key
183 ;;; types.
184 ;;;
185 ;;; Other useful properties are as follows.
186 ;;;
187 ;;; recovery A list of recovery keys with which encrypted copies
188 ;;; of the key nub should be made. The default is to
189 ;;; make no recovery copies, because this configuration
190 ;;; has no idea which recovery key to use; however, I
191 ;;; /strongly/ recommend that all user keys used for
192 ;;; secrecy be recoverable.
193
194 [%common]
195
196 ;; ACL principal names.
197 acl-%private = !owner
198 acl-%none = -*
199
200 ;; Default ACLs.
201 acl-info = $acl-%private
202 acl-encrypt = $acl-%none
203 acl-decrypt = $acl-%none
204 acl-sign = $acl-%none
205 acl-verify = $acl-%none
206
207 [%symmetric]
208 @include = %common
209 acl-%public = $acl-%private
210
211 [%asymmetric]
212 @include = %common
213 acl-%public = *
214 acl-info = $acl-%public
215
216 [%secrecy]
217 @include = %common
218 acl-encrypt = $acl-%public
219 acl-decrypt = $acl-%private
220
221 [%integrity]
222 @include = %common
223 acl-sign = $acl-%private
224 acl-verify = $acl-%public
225
226 [%asymmetric-secrecy]
227 @include = %asymmetric %secrecy
228
229 [%asymmetric-integrity]
230 @include = %asymmetric %integrity
231
232 [%symmetric-secrecy]
233 @include = %symmetric %secrecy
234
235 [%symmetric-integrity]
236 @include = %symmetric %integrity
237
238 ;;;----- That's all, folks --------------------------------------------------