;;; -*-conf-*-
;;;
;;; Basic profile configuration for key management
;;;
;;; (c) 2011 Mark Wooding
;;;

;;;----- Licensing notice ---------------------------------------------------
;;;
;;; This file is part of the distorted.org.uk key management suite.
;;;
;;; distorted-keys is free software; you can redistribute it and/or modify
;;; it under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 2 of the License, or
;;; (at your option) any later version.
;;;
;;; distorted-keys is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with distorted-keys; if not, write to the Free Software Foundation,
;;; Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

;;;--------------------------------------------------------------------------
;;; Profile syntax.
;;;
;;; The configuration file is divided into sections, each beginning with a
;;; header enclosed in square brackets.  Within a section, lines of the form
;;;
;;;	NAME = VALUE
;;;
;;; define properties within that section.  Property names may consist of
;;; alphanumeric characters, hyphens `-', underscores `_', and percent signs
;;; `%'; hyphens and underscores are equivalent.  Several section headers may
;;; use the same name: this is entirely equivalent to a single section
;;; containing the same definitions in the same order.  If two definitions in
;;; the same section have the same property name, the earlier definition is
;;; silently ignored.  Properties whose names contain percent signs are
;;; used internally only, and not emitted.
;;;
;;; There are special pseudoproperties whose names begin with `@'.
;;; Currently, the only pseudoproperty defined is `@include'.  The value is a
;;; list of section names separated by whitespace: the named sections are
;;; `directly included'; a section includes directly included sections, and
;;; sections included by directly included sections.  It is an error for a
;;; section to include itself.  If a property is defined in an included
;;; section, but not in the including section, then the property is added to
;;; (`inherited by') the including section.  The property's value is
;;; determined as follows.  A `candidate definition' for the property is a
;;; definition in a section S such that no section which includes S contains
;;; a definition for the property.  It is an error for two candidate
;;; definitions to provide different values for the property; otherwise, the
;;; inherited value is the common value of the candidate definitions.
;;;
;;; Property definitions before the first section heading are placed in the
;;; special section `@GLOBAL', which is implicitly included in every other
;;; section.
;;;
;;; Property values (but not pseudoproperties) may contain substitution
;;; placeholders of the form $NAME or ${NAME}, which are replaced by the
;;; value of the (possibly inherited) property NAME.  It is an error if there
;;; is no definition for the property.  Substitution placeholders in the
;;; replacement value are also expanded, recursively; the search begins
;;; relative to the original section.  (There is not a well-defined
;;; containing section for the replacement property.)  References to the
;;; special property name `@name' is replaced by the name of the section.

;;;--------------------------------------------------------------------------
;;; Structure and conventions.
;;;
;;; It's probably best if you don't edit this file.  Instead, install it as
;;; `00base' in the system profiles directory, and apply your local
;;; customizations in separate files.  The numbers on the front of the
;;; filenames ensure that they're read in the right order.  The first digit
;;; describes the source of the configuration:
;;;
;;; 0			Global defaults.  The configuration files distributed
;;;			with distorted-keys go here.  So should the default
;;;			profiles for any other key types and client packages.
;;;
;;; 1--4		Overrides for operating system vendors, packagers,
;;;			etc.
;;;
;;; 5--8		Overrides for organizational and site-specific
;;;			configuration.
;;;
;;; 9			Host-specific overrides.
;;;
;;; Section names beginning with `%' are not intended to be used directly,
;;; but included into other sections.
;;;
;;; Each key type KTYPE should define two or three sections:
;;;
;;; %KTYPE		Basic configuration common to all uses of the key
;;;			type.  All profiles using the key type should include
;;;			this section.  The `type' property should be defined
;;;			appropriately.  The settings should be suitable for
;;;			general use by a technically able user who is not a
;;;			cryptography expert, and should aim to provide at
;;;			least a 128-bit security level.
;;;
;;; %KTYPE-infra	Additional configuration for use as an infrastructure
;;;			key (e.g., a keeper, recovery, or archive key).  If
;;;			the key type is not suitable for use as an
;;;			infrastructure key, don't define this section at
;;;			all.
;;;
;;; KTYPE		Additional configuration for use as a user key.  In
;;;			particular, this should include either `%symmetric'
;;;			or `%asymmetric' as appropriate, in order to make
;;;			available appropriate default ACLs.  Typically, no
;;;			other settings will be needed.
;;;
;;; Other section names beginning `KTYPE-' or `%KTYPE-' are reserved for the
;;; the use of the key type.

;;;--------------------------------------------------------------------------
;;; Common settings.

;; Random bit source, for generating nubs and similar.
random = random

;; Nub generation parameters.  Note that the specifics of nub generation are
;; key-type specific.
nub-hash = sha384
nub-random-bytes = 512

;; Hash function for computing nub hashes.
nubid-hash = sha256

;;;--------------------------------------------------------------------------
;;; Common policy for user keys.
;;;
;;; All key-type profiles for user keys should include one of the following
;;; sections.
;;;
;;; %asymmetric-secrecy	i.e., public-key encryption and decryption.
;;;
;;; %asymmetric-integrity i.e., issuing and verifying digital signatures.
;;;
;;; %symmetric-secrecy	i.e., standard symmetric encryption and decryption.
;;;
;;; %symmetric-integrity i.e., generating and verifyng message authentication
;;;			code tags.
;;;
;;; Each of these includes one or other of `%asymmetric' or `%symmetric', and
;;; one or other of `%secrecy' or `%integrity'.  Both of these include
;;; `%common', which may therefore contain policy for all user keys.
;;;
;;; The `acl-ACTION' properties define access-control lists for various
;;; ACTIONs.  An ACL consists of a sequence of entries separated by spaces.
;;; An ACL entry has the form
;;;
;;;	[-]PATTERN
;;;
;;; where PATTERN may be one of the following.
;;;
;;; !owner		The owner of the key, i.e., the user who created it.
;;;
;;; %GROUP		Any member of a group whose name or gid matches the
;;;			glob pattern GROUP.
;;;
;;; USER		A user whose name or uid matches the glob pattern
;;;			USER.
;;;
;;; An entry usually grants permission to a user who matches its pattern; if
;;; prefixed by a `-', the entry denies permission instead.  Entries are
;;; checked in order, left to right; only the first match is significant.  If
;;; no matching entries are found then access is denied.
;;;
;;; ACTIONs currently defined are `encrypt', `decrypt', `sign', `verify', and
;;; `info', corresponding to the like-named `cryptop' commands.  Others may
;;; be defined later, but their names won't contain `%' signs.  The default
;;; ACLs are defined in terms of the following internal properties.
;;;
;;; acl-%none		No access at all, for inapplicable operations.
;;;
;;; acl-%private	Access should always be limited to authorized users.
;;;
;;; acl-%public		Access may be granted more widely for asymmetric key
;;;			types.
;;;
;;; Other useful properties are as follows.
;;;
;;; recovery		A list of recovery keys with which encrypted copies
;;;			of the key nub should be made.  The default is to
;;;			make no recovery copies, because this configuration
;;;			has no idea which recovery key to use; however, I
;;;			/strongly/ recommend that all user keys used for
;;;			secrecy be recoverable.

[%common]

;; ACL principal names.
acl-%private = !owner
acl-%none = -*

;; Default ACLs.
acl-info = $acl-%private
acl-encrypt = $acl-%none
acl-decrypt = $acl-%none
acl-sign = $acl-%none
acl-verify = $acl-%none

[%symmetric]
@include = %common
acl-%public = $acl-%private

[%asymmetric]
@include = %common
acl-%public = *

[%secrecy]
@include = %common
acl-encrypt = $acl-%public
acl-decrypt = $acl-%private

[%integrity]
@include = %common
acl-sign = $acl-%private
acl-verify = $acl-%public

[%asymmetric-secrecy]
@include = %asymmetric %secrecy

[%asymmetric-integrity]
@include = %asymmetric %integrity

[%symmetric-secrecy]
@include = %symmetric %secrecy

[%symmetric-integrity]
@include = %symmetric %integrity

;;;----- That's all, folks --------------------------------------------------