This commit was manufactured by cvs2svn to create branch

'GNUPG-1-9-BRANCH'.

30 files changed, 0 insertions, 13917 deletions

diff --git a/doc/ChangeLog b/doc/ChangeLog
deleted file mode 100644
index 7c200a409..000000000
--- a/doc/ChangeLog
+++ /dev/null
@@ -1,500 +0,0 @@
-2002-10-12  Werner Koch  <wk@gnupg.org>
-
-	* DETAILS (KEY_CREATED): Enhanced by fingerprint.
-
-2002-10-03  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Note that '#' means secret-key-unavailable, and that
-	keyserver schemes are case-insensitive.
-
-2002-09-30  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Note that --pgp2 disables --textmode when encrypting.
-
-2002-09-20  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Some minor language cleanup.
-
-2002-09-20  Werner Koch  <wk@gnupg.org>
-
-	* DETAILS: s/XORed/ORed/.
-
-2002-09-15  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Add rebuild-keydb-caches.
-
-2002-09-12  David Shaw  <dshaw@jabberwocky.com>
-
-	* DETAILS: Fix batch key generation example.
-
-2002-09-11  Werner Koch  <wk@gnupg.org>
-
-	* Makefile.am (EXTRA_DIST): Include gnupg-32.reg
-
-2002-09-02  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Updated the charset option.
-
-	* DETAILS: Added status IMPORT_OK.
-
-	* gnupg.7: New mini man page.
-
-2002-08-30  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Document keyserver-option include-subkeys.  Note that
-	honor-http-proxy is a keyserver-option now.
-
-	* DETAILS: Add "Key not trusted" to INV_RECP status code.
-
-2002-08-23  Werner Koch  <wk@gnupg.org>
-
-	* faq.raw: Updated.  New Maintainer is David D. Scribner.
-
-2002-08-22  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Clarify meaning of keyserver option include-revoked.
-
-2002-08-21  Werner Koch  <wk@gnupg.org>
-
-	* DETAILS: Added IMPORT_PROBLEM.
-
-2002-08-20  David Shaw  <dshaw@jabberwocky.com>
-
-	* DETAILS: Clarify that trust letters 'q' and '-' can be treated
-	identically.
-
-	* gpg.sgml: Document --ignore-mdc-error.
-
-2002-08-06  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Clarify that only long-form options can go in the
-	config file.
-
-2002-08-06  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Fixed doc regarding the name change of the option
-	file.
-
-2002-07-30  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Clarify --edit/addrevoker (sensitive), and
-	--keyserver-options (--import/export-options may be used as well).
-	Document --import-options and --export-options with their various
-	options.  --show-photos now works during signature verification as
-	well.  Document --exec-path.  Note in --simple-sk-checksum that
-	the passphrase must be changed for this to take effect.  Note that
-	--pgp7 does not disable MDC.  Document --no-mdc-warning.
-
-2002-07-25  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Document new --delete behaviour.
-
-2002-07-25  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Clarify the differences between "pref" and "showpref".
-	Note in "setpref" that a list of available algorithms can be
-	printed with "gpg -v --version".  Note in "updpref" that we don't
-	select keys via attribute uids, so preferences there will be
-	ignored.
-
-2002-07-01  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Clarify "group".
-
-2002-07-01  Werner Koch  <wk@gnupg.org>
-
-	* Makefile.am: Due to problems with VPATH builds we don't try to
-	build the texi vesions of the manual pages anymore automatically.
-
-2002-06-30  Werner Koch  <wk@gnupg.org>
-
-	* README.W32: Adjusted some descriptions.  Fixed the regsitry
-	entry descriptions.
-
-2002-06-21  David Shaw  <dshaw@jabberwocky.com>
-
-	* DETAILS: Document "uat".
-
-	* gpg.sgml: Document
-	--personal-{compress|digest|compress}-preferences, --group, and
-	add comments to --expert.
-
-2002-06-17  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Grammar fix.
-
-2002-06-03  David Shaw  <dshaw@jabberwocky.com>
-
-	* DETAILS: Details of ATTRIBUTE.
-
-	* gpg.sgml: Document --attribute-fd
-
-2002-06-03  Timo Schulz  <ts@winpt.org>
-
-	* DETAILS: Add ATTRIBUTE.
-	
-2002-05-31  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Add "edit/addrevoker".  Document --desig-revoke.  Note
-	that -z and --compress are the same option.  Note that
-	--digest-algo can no longer violate OpenPGP with a non-160 bit
-	hash with DSA.  Document --cert-digest-algo with suitable warnings
-	not to use it.  Note the default s2k-cipher-algo is now CAST5.
-	Note that --force-v3-sigs overrides --ask-sig-expire.  Revise
-	--expert documentation, as it is now definitely legal to have more
-	than one photo ID on a key.  --preference-list is now
-	--default-preference-list with the new meaning.  Document
-	--personal-preference-list.
-
-	* DETAILS: Document "Revoker" for batch key generation.
-
-2002-05-22  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: sgml syntax fix.
-
-2002-05-12  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Fixed URL in the description section.
-
-	* faq.raw: Minor typo fixes noted by kromJx@myrealbox.com.
-
-2002-05-11  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Typo fix.
-
-2002-05-07  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Add entries for --sk-comments, --no-sk-comments,
-	--pgp7, and --no-pgp7.  Fix --pgp2 and --pgp6: the proper name is
-	--escape-from-lines and not --escape-from.
-
-2002-04-30  Timo Schulz  <ts@winpt.org>
-
-	* gpg.sgml: Add an entry for --encrypt-files and --decrypt-files.
-	
-2002-04-29  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Fix minor error in --pgp6 documentation: it does not
-	imply --digest-algo MD5
-
-2002-04-29  Werner Koch  <wk@gnupg.org>
-
-	* samplekeys.asc: Added gnupg distribution key 57548DCD.
-
-	* faq.raw: Inserted Douglas Calvert as new maintainer. Acknowledge
-	Nils.  Add entry about trust packet parsing problems.
-
-2002-04-24  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Add some documentation for
-	--edit/{addphoto|showphoto|nrsign|nrlsign}, and the difference
-	between %t and %T in photo viewer command lines.
-
-2002-04-23  Stefan Bellon  <sbellon@sbellon.de>
-
-	* gpg.sgml: Moved options from section "COMMANDS" to
-	section "OPTIONS".
-
-2002-04-20  David Shaw  <dshaw@jabberwocky.com>
-
-	* samplekeys.asc: Added 0x5B0358A2
-
-2002-04-19  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Add "%t" flag for photo IDs, a note about primary
-	having different meanings for photo and regular IDs, rename
-	--default-check-level to --default-cert-check-level, add
-	--auto-check-trustdb, and --pgp6.
-
-	* DETAILS: Add EXPSIG, EXPKEYSIG, and KEYEXPIRED.  Add notes to
-	SIGEXPIRED (deprecated), and VALIDSIG (added expiration date).
-	Add "Preferences" command to unattended key generation
-	instructions.  Also fixed a few typos.
- 
-	* samplekeys.asc: new (added to EXTRA_DIST in Makefile.am as well)
-
-2002-01-31  Marcus Brinkmann  <marcus@g10code.de>
-
-	* DETAILS: Fix a spelling error, correct IMPORTED_RES to IMPORT_RES,
-	correct INV_RECP (the second occurence) to NO_RECP.
-
-2002-04-03  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: auto-key-retrieve is a keyserver-option (noted by
-	Roger Sondermann).
-	
-2002-03-27  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: --pgp2 also means --disable-mdc, --no-ask-sig-expire,
-	and --no-ask-cert-expire.  It does not mean --no-force-v3-sigs
-	(noted by Timo).
-
-2002-03-27  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Add a few notes about --pgp2 meaning MIT PGP 2.6.2,
-	and keyserver details about HKP and NAI HKP.
-
-2002-03-18  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Change meaning of --allow-non-selfsigned-uid to match
-	change in code, and add --no-allow-non-selfsigned-uid.
-
-2002-03-13  Werner Koch  <wk@gnupg.org>
-
-	* faq.raw: Due to a lack of time Nils can't serve anymore as a
-	maintainer.  Removed his address and setup a generic address.
-
-2002-03-06  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Add an entry for --export-ownertrust.  Suggested by
-	Bernhard Reiter.
-
-2002-01-26  Timo Schulz  <ts@winpt.org>
-
-	* gnupg-w32.reg: New. Registry file for W32 in registry format.
-       
-2002-01-26  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: A few words about --gpg-agent-info and GPG_AGENT_INFO.
-
-2002-01-25  Timo Schulz  <ts@winpt.org>
-
-	* README.W32: Modify the filename because now the .exe extension
- 	is automatically added to the binary.
-	
-2002-01-14  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Talk about PGP 5 and higher.
-
-2002-01-11  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Added documentation for --{no-}ask-cert-expire,
-	--{no-}ask-sig-expire, and revise --expert (it doesn't switch on
-	the expiration prompt anymore) and --default-check-level (to be
-	clearer as to what makes a good key check before signing).
-
-2002-01-07  Werner Koch  <wk@gnupg.org>
-
-	* DETAILS: Removed the comment that unattended key generation is
-	experimental.  It is now a standard feature.
-
-2001-12-22  David Shaw  <dshaw@jabberwocky.com>
-
-	* gpg.sgml: Fixed a few typos.
-
-	* gpg.sgml: Added documentation for --show-photos,
-	--no-show-photos, --photo-viewer, --nrsign-key,
-	--default-check-level, --search-keys, --keyserver-options,
-	--show-notation, --no-show-notation, --show-policy-url,
-	--no-show-policy-url, --for-your-eyes-only,
-	--no-for-your-eyes-only, --pgp2, --no-pgp2,
-	--no-permission-warning, --expert, --no-expert.
-
-2001-10-31  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Add a remark on how to get the long key ID.  Suggested
-	by Sebastian Klemke.
-
-2001-10-23  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Add missing tag.
-
-2001-09-28  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Add a note on option parsing.
-
-2001-09-24  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Described --{update,check}-trustdb.
-
-2001-09-03  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml, gpgv.sgml: Removed GDBM stuff.
-
-2001-08-29  Werner Koch  <wk@gnupg.org>
-
-	* faq.raw: Described how to delete a secret key w/o a public key
-	and changed the entry on updating the preferences.
-
-2001-08-08  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Documented --print-mds and marked the --print-md * as
-	deprecated because it does not work in the W32 version.  Suggested
-	by John Kane.
-	(WARNINGS): Typo fix.
-	(--with-colons): Clarified that the output is in UTF-8.
-
-2001-08-01  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Added --ignore-valid-from
-
-2001-04-20  Werner Koch  <wk@gnupg.org>
-
-	* faq.raw (Maintained-by): Removed note that load-extension is not
-	available under Windoze.
-
-	* gpg.sgml: Add new --charset UTF-8.
-
-2001-04-19  Werner Koch  <wk@gnupg.org>
-
-	* faq.raw: Add a note about dates displayed as ????-??-??.
-
-2001-04-17  Werner Koch  <wk@gnupg.org>
-
-	* Makefile.am (%.texi): Add rules to create .texi from .sgml.
-	However we can't automate this because automake does not like
-	.texi files as BUILT_SOURCES.
-	(%.dvi,%.ps): Removed these rules, because they are not needed
-	and get in the way of automake's dvi target
-
-	* HACKING: Changed CVS description.
-
-2001-04-06  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Small typo fixes by Florian Weimer.
-
-2001-03-27  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Add --no-sig-cache and --no-sig-create-check.
-
-2001-03-23  Werner Koch  <wk@gnupg.org>
-
-	* DETAILS: New status UNEXPECTED.
-
-2001-03-13  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Described --fixed-list-mode.
-
-2001-03-06  Werner Koch  <wk@gnupg.org>
-
-	* gpgv.sgml: Changed some gpg to gpgv. Thanks to John A. Murdie.
-
-2001-03-03  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Tell something about the 0x12345678! key ID syntax.
-
-2001-01-18  Werner Koch  <wk@gnupg.org>
-
-	* README.W32: Changed building instructions for MinGW32/CPD 0.3 
-
-2001-01-09  Werner Koch  <wk@gnupg.org>
-
-	* DETAILS: Fixed docs for NEED_PASSPHRASE and added USERID_HINT.
-
-2000-11-30  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Fixed the description of --verify.  Add a short note
-	the warnings sections.
-
-2000-10-19  Werner Koch  <wk@gnupg.org>
-
-	* gpg.sgml: Fixed doc for --allow-non-selfsigned-uid.
-	Add entry for --ignore-crc-error.
-
-2000-10-18  Werner Koch  <wk@gnupg.org>
-
-	* OpenPGP: Dropped the paragraph that RSA is not implemented.
-
-2000-10-14  Werner Koch  <wk@gnupg.org>
-
-	* faq.raw: Add an answer to the problem of multiple signatures.
-
-Wed Oct  4 15:50:18 CEST 2000  Werner Koch  <wk@openit.de>
-
-        * gpgv.sgml: New.
-        * Makefile.am: build it.
-
-Thu Sep 14 14:20:38 CEST 2000  Werner Koch  <wk@openit.de>
-
-        * faq.raw: New.
-        * Makefile.am: Support to build FAQs
-
-Wed Jul 12 13:32:06 CEST 2000  Werner Koch  <wk@>
-
-        * gpg.sgml: Add a note about the availability of the GPH.
-
-2000-07-03 13:59:24  Werner Koch  (wk@habibti.openit.de)
-
-        * DETAILS, FAQ: Typo fixes by Yosiaki IIDA.
-
-2000-05-12 10:57:21  Werner Koch  (wk@habibti.openit.de)
-
-	* gpg.sgml: Documented --no-tty.
-
-2000-03-09 15:01:51  Werner Koch  (wk@habibti.openit.de)
-
-	* DETAILS: Ad a short blurb about unattended key generation.
-
-Wed Feb  9 15:33:44 CET 2000  Werner Koch  <wk@gnupg.de>
-
-	* gpg.sgml: Describe --ignore-time-conflict.
-
-	* gpg.sgml: Fixed a few typos.	Thanks to Holger Trapp.
-
-Wed Jan  5 11:51:17 CET 2000  Werner Koch  <wk@gnupg.de>
-
-	* FAQ: Enhanced answer for the 3des-s2k bug.
-
-Sat Dec  4 12:30:28 CET 1999  Werner Koch  <wk@gnupg.de>
-
-	* gpg.sgml: Add section about the user ID
-
-Mon Nov 22 11:14:53 CET 1999  Werner Koch  <wk@gnupg.de>
-
-	* gph: Removed the directory from the dist becuase it will
-	go into it's own package.
-
-Thu Sep 23 09:52:58 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
-
-	* README.W32: New.
-
-Mon Sep  6 19:59:08 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
-
-
-	* Makefile.am (SUBDIRS): New subdir gph for the manual.
-
-Thu Jul 22 20:03:03 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
-
-
-	* gpg.sgml (--always-trust): Added.
-
-Wed Jul 14 19:42:08 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
-
-
-	* Makefile.am: Create a dummy man page if docbook-to-man is missing.
-
-Wed Jun 16 20:16:21 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
-
-
-	* gpg1.pod: Removed.
-	* gpg.sgml: New. Replaces the pod file
-	* Makefile.am: Add rule to make a man file from sgml
-
-Tue Jun 15 12:21:08 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
-
-
-	* Makefile.in.in: Use DESTDIR.
-
-Mon May 31 19:41:10 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
-
-	* gpg.1pod: Enhanced the Bugs section (Michael).
-
-Wed Feb 10 17:15:39 CET 1999  Werner Koch  <wk@isil.d.shuttle.de>
-
-
-	* gpg.1pod: Spelling and grammar corrections (John A. Martin)
-	* FAQ: Ditto.
-	* DETAILS: Ditto.
-
-
- Copyright 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
-
- This file is free software; as a special exception the author gives
- unlimited permission to copy and/or distribute it, with or without
- modifications, as long as this notice is preserved.
-
- This file is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
- implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-
diff --git a/doc/DETAILS b/doc/DETAILS
deleted file mode 100644
index 1ba9df159..000000000
--- a/doc/DETAILS
+++ /dev/null
@@ -1,990 +0,0 @@
-
-Format of colon listings
-========================
-First an example:
-
-$ gpg --fixed-list-mode --with-colons --list-keys \
-   --with-fingerprint --with-fingerprint wk@gnupg.org
-
-pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC:
-fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013:
-uid:f::::::::Werner Koch <wk@g10code.com>:
-uid:f::::::::Werner Koch <wk@gnupg.org>:
-sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e:
-fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1:
-sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc:
-fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4:
-
-The double --with-fingerprint prints the fingerprint for the subkeys
-too, --fixed-list-mode is themodern listing way printing dates in
-seconds since Epoch and does not merge the first userID with the pub
-record.
-
-
- 1. Field:  Type of record
-	    pub = public key
-            crt = X.509 certificate
-            crs = X.509 certificate and private key available
-	    sub = subkey (secondary key)
-	    sec = secret key
-	    ssb = secret subkey (secondary key)
-	    uid = user id (only field 10 is used).
-	    uat = user attribute (same as user id except for field 10).
-            sig = signature
-            rev = revocation signature
-	    fpr = fingerprint: (fingerprint is in field 10)
-	    pkd = public key data (special field format, see below)
-            grp = reserved for gpgsm
-            rvk = revocation key
-
- 2. Field:  A letter describing the calculated trust. This is a single
-	    letter, but be prepared that additional information may follow
-	    in some future versions. (not used for secret keys)
-		o = Unknown (this key is new to the system)
-                i = The key is invalid (e.g. due to a missing self-signature)
-		d = The key has been disabled
-		r = The key has been revoked
-		e = The key has expired
-		- = Unknown trust (i.e. no value assigned)
-		q = Undefined trust
-	            '-' and 'q' may safely be treated as the same
-		    value for most purposes
-		n = Don't trust this key at all
-		m = There is marginal trust in this key
-		f = The key is full trusted.
-		u = The key is ultimately trusted; this is only used for
-		    keys for which the secret key is also available.
- 3. Field:  length of key in bits.
- 4. Field:  Algorithm:	1 = RSA
-		       16 = ElGamal (encrypt only)
-		       17 = DSA (sometimes called DH, sign only)
-		       20 = ElGamal (sign and encrypt)
-	    (for other id's see include/cipher.h)
- 5. Field:  KeyID either of 
- 6. Field:  Creation Date (in UTC)
- 7. Field:  Key expiration date or empty if none.
- 8. Field:  Used for serial number in crt records (used to be the Local-ID)
- 9. Field:  Ownertrust (primary public keys only)
-	    This is a single letter, but be prepared that additional
-	    information may follow in some future versions.
-10. Field:  User-ID.  The value is quoted like a C string to avoid
-	    control characters (the colon is quoted "\x3a").
-            This is not used with --fixed-list-mode in gpg.
-            A UAT record puts the attribute subpacket count here, a
-	    space, and then the total attribute subpacket size.
-            In gpgsm the issuer name comes here
-            An FPR record stores the fingerprint here.
-            The fingerprint of an revocation key is stored here.
-11. Field:  Signature class.  This is a 2 digit hexnumber followed by
-            either the letter 'x' for an exportable signature or the
-            letter 'l' for a local-only signature.
-            The class byte of an revocation key is also given here,
-            'x' and 'l' ist used the same way.
-12. Field:  Key capabilities:
-                e = encrypt
-                s = sign
-                c = certify
-            A key may have any combination of them.  The primary key has in
-            addition to these letters, uppercase version of the letter to
-            denote the _usable_ capabilities of the entire key.  
-13. Field:  Used in FPR records for S/MIME keys to store the fingerprint of
-            the issuer certificate.  This is useful to build the
-            certificate path based on certificates stored in the local
-            keyDB; it is only filled if the issue certificate is
-            available. The advantage of using this value is that it is
-            guaranteed to have been been build by the same lookup
-            algorithm as gpgsm uses.
-            For "uid" recods this lists the preferences n the sameway the 
-            -edit menu does.
-14. Field   Flag field used in the --edit menu output:
-
-
-All dates are displayed in the format yyyy-mm-dd unless you use the
-option --fixed-list-mode in which case they are displayed as seconds
-since Epoch.  More fields may be added later, so parsers should be
-prepared for this. When parsing a number the parser should stop at the
-first non-number character so that additional information can later be
-added.
-
-If field 1 has the tag "pkd", a listing looks like this:
-pkd:0:1024:B665B1435F4C2 .... FF26ABB:
-    !  !   !-- the value
-    !  !------ for information number of bits in the value
-    !--------- index (eg. DSA goes from 0 to 3: p,q,g,y)
-
- 
-
-Format of the "--status-fd" output
-==================================
-Every line is prefixed with "[GNUPG:] ", followed by a keyword with
-the type of the status line and a some arguments depending on the
-type (maybe none); an application should always be prepared to see
-more arguments in future versions.
-
-
-    GOODSIG	<long keyid>  <username>
-	The signature with the keyid is good.  For each signature only
-        one of the three codes GOODSIG, BADSIG or ERRSIG will be
-        emitted and they may be used as a marker for a new signature.
-        The username is the primary one encoded in UTF-8 and %XX
-        escaped.
-
-    EXPSIG	<long keyid>  <username>
-	The signature with the keyid is good, but the signature is
-	expired. The username is the primary one encoded in UTF-8 and
-	%XX escaped.
-
-    EXPKEYSIG	<long keyid>  <username>
-	The signature with the keyid is good, but the signature was
-	made by an expired key. The username is the primary one
-	encoded in UTF-8 and %XX escaped.
-
-    BADSIG	<long keyid>  <username>
-	The signature with the keyid has not been verified okay.
-        The username is the primary one encoded in UTF-8 and %XX
-        escaped.
-
-    ERRSIG  <long keyid>  <pubkey_algo> <hash_algo> \
-	    <sig_class> <timestamp> <rc>
-	It was not possible to check the signature.  This may be
-	caused by a missing public key or an unsupported algorithm.
-	A RC of 4 indicates unknown algorithm, a 9 indicates a missing
-	public key. The other fields give more information about
-	this signature.  sig_class is a 2 byte hex-value.
-
-    VALIDSIG	<fingerprint in hex> <sig_creation_date> <sig-timestamp>
-		<expire-timestamp>
-
-	The signature with the keyid is good. This is the same
-	as GOODSIG but has the fingerprint as the argument. Both
-	status lines are emitted for a good signature.
-	sig-timestamp is the signature creation time in seconds after
-	the epoch. expire-timestamp is the signature expiration time
-	in seconds after the epoch (zero means "does not expire").
-
-    SIG_ID  <radix64_string>  <sig_creation_date>  <sig-timestamp>
-	This is emitted only for signatures of class 0 or 1 which
-	have been verified okay.  The string is a signature id
-	and may be used in applications to detect replay attacks
-	of signed messages.  Note that only DLP algorithms give
-	unique ids - others may yield duplicated ones when they
-	have been created in the same second.
-
-    ENC_TO  <long keyid>  <keytype>  <keylength>
-	The message is encrypted to this keyid.
-	keytype is the numerical value of the public key algorithm,
-	keylength is the length of the key or 0 if it is not known
-	(which is currently always the case).
-
-    NODATA  <what>
-	No data has been found. Codes for what are:
-	    1 - No armored data.
-	    2 - Expected a packet but did not found one.
-	    3 - Invalid packet found, this may indicate a non OpenPGP message.
-	You may see more than one of these status lines.
-
-    UNEXPECTED <what>
-        Unexpected data has been encountered
-            0 - not further specified               1       
-  
-
-    TRUST_UNDEFINED <error token>
-    TRUST_NEVER  <error token>
-    TRUST_MARGINAL
-    TRUST_FULLY
-    TRUST_ULTIMATE
-	For good signatures one of these status lines are emitted
-	to indicate how trustworthy the signature is.  The error token
-        values are currently only emiited by gpgsm.
-
-    SIGEXPIRED
-	This is deprecated in favor of KEYEXPIRED.
-
-    KEYEXPIRED <expire-timestamp>
-	The key has expired.  expire-timestamp is the expiration time
-	in seconds after the epoch.
-
-    KEYREVOKED
-	The used key has been revoked by its owner.  No arguments yet.
-
-    BADARMOR
-	The ASCII armor is corrupted.  No arguments yet.
-
-    RSA_OR_IDEA
-	The IDEA algorithms has been used in the data.  A
-	program might want to fallback to another program to handle
-	the data if GnuPG failed.  This status message used to be emitted
-        also for RSA but this has been dropped after the RSA patent expired.
-        However we can't change the name of the message.
-
-    SHM_INFO
-    SHM_GET
-    SHM_GET_BOOL
-    SHM_GET_HIDDEN
-
-    GET_BOOL
-    GET_LINE
-    GET_HIDDEN
-    GOT_IT
-
-    NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength>
-	Issued whenever a passphrase is needed.
-	keytype is the numerical value of the public key algorithm
-	or 0 if this is not applicable, keylength is the length
-	of the key or 0 if it is not known (this is currently always the case).
-
-    NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash>
-	Issued whenever a passphrase for symmetric encryption is needed.
-
-    MISSING_PASSPHRASE
-	No passphrase was supplied.  An application which encounters this
-	message may want to stop parsing immediately because the next message
-	will probably be a BAD_PASSPHRASE.  However, if the application
-	is a wrapper around the key edit menu functionality it might not
-	make sense to stop parsing but simply ignoring the following
-	BAD_PASSPHRASE.
-
-    BAD_PASSPHRASE <long keyid>
-	The supplied passphrase was wrong or not given.  In the latter case
-	you may have seen a MISSING_PASSPHRASE.
-
-    GOOD_PASSPHRASE
-	The supplied passphrase was good and the secret key material
-	is therefore usable.
-
-    DECRYPTION_FAILED
-	The symmetric decryption failed - one reason could be a wrong
-	passphrase for a symmetrical encrypted message.
-
-    DECRYPTION_OKAY
-	The decryption process succeeded.  This means, that either the
-	correct secret key has been used or the correct passphrase
-	for a conventional encrypted message was given.  The program
-	itself may return an errorcode because it may not be possible to
-	verify a signature for some reasons.
-
-    NO_PUBKEY  <long keyid>
-    NO_SECKEY  <long keyid>
-	The key is not available
-
-    IMPORTED   <long keyid>  <username>
-	The keyid and name of the signature just imported
-
-    IMPORT_OK  <reason> [<fingerprint>]
-        The key with the primary key's FINGERPRINT has been imported.
-        Reason flags:
-          0 := Not actually changed
-          1 := Entirely new key.
-          2 := New user IDs
-          4 := New signatures
-          8 := New subkeys 
-         16 := Contains private key.
-        The flags may be ORed.
-
-    IMPORT_PROBLEM <reason> [<fingerprint>]
-        Issued for each import failure.  Reason codes are:
-          0 := "No specific reason given".
-          1 := "Invalid Certificate".
-          2 := "Issuer Certificate missing".
-          3 := "Certificate Chain too long".
-          4 := "Error storing certificate".
-
-    IMPORT_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
-	<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups> <not_imported>
-	Final statistics on import process (this is one long line)
-
-    FILE_START <what> <filename>
-	Start processing a file <filename>.  <what> indicates the performed
-	operation:
-	    1 - verify
-            2 - encrypt
-            3 - decrypt        
-
-    FILE_DONE
-	Marks the end of a file processing which has been started
-	by FILE_START.
-
-    BEGIN_DECRYPTION
-    END_DECRYPTION
-	Mark the start and end of the actual decryption process.  These
-	are also emitted when in --list-only mode.
-
-    BEGIN_ENCRYPTION  <mdc_method> <sym_algo>
-    END_ENCRYPTION
-	Mark the start and end of the actual encryption process.
-
-    DELETE_PROBLEM reason_code
-	Deleting a key failed.	Reason codes are:
-	    1 - No such key
-	    2 - Must delete secret key first
-            3 - Ambigious specification
-
-    PROGRESS what char cur total
-	Used by the primegen and Public key functions to indicate progress.
-	"char" is the character displayed with no --status-fd enabled, with
-	the linefeed replaced by an 'X'.  "cur" is the current amount
-	done and "total" is amount to be done; a "total" of 0 indicates that
-	the total amount is not known.	100/100 may be used to detect the
-	end of operation.
-
-    SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
-	A signature has been created using these parameters.
-	    type:  'D' = detached
-		   'C' = cleartext
-		   'S' = standard
-		   (only the first character should be checked)
-	    class: 2 hex digits with the signature class
-        
-    KEY_CREATED <type> <fingerprint>
-        A key has been created
-            type: 'B' = primary and subkey
-                  'P' = primary
-                  'S' = subkey
-        The fingerprint is one of the primary key for type B and P and
-        the one of the subkey for S.
-
-    SESSION_KEY  <algo>:<hexdigits>
-	The session key used to decrypt the message.  This message will
-	only be emmited when the special option --show-session-key
-	is used.  The format is suitable to be passed to the option
-	--override-session-key
-
-    NOTATION_NAME <name> 
-    NOTATION_DATA <string>
-        name and string are %XX escaped; the data may be splitted
-        among several notation_data lines.
-
-    USERID_HINT <long main keyid> <string>
-        Give a hint about the user ID for a certain keyID. 
-
-    POLICY_URL <string>
-        string is %XX escaped
-
-    BEGIN_STREAM
-    END_STREAM
-        Issued by pipemode.
-
-    INV_RECP <reason> <requested_recipient>
-        Issued for each unusable recipient. The reasons codes
-        currently in use are:
-          0 := "No specific reason given".
-          1 := "Not Found"
-          2 := "Ambigious specification"
-          3 := "Wrong key usage"
-          4 := "Key revoked"
-          5 := "Key expired"
-          6 := "No CRL known"
-          7 := "CRL too old"
-          8 := "Policy mismatch"
-          9 := "Not a secret key"
-	 10 := "Key not trusted"
-
-        Note that this status is also used for gpgsm's SIGNER command
-        where it relates to signer's of course.
-
-    NO_RECP <reserved>
-        Issued when no recipients are usable.
-
-    ALREADY_SIGNED <long-keyid>
-        Warning: This is experimental and might be removed at any time.
-
-    TRUNCATED <maxno>
-        The output was truncated to MAXNO items.  This status code is issued
-        for certain external requests
-
-    ERROR <error location> <error code> 
-        This is a generic error status message, it might be followed
-        by error location specific data. <error token> and
-        <error_location> should not contain a space.
-
-    ATTRIBUTE <fpr> <octets> <type> <index> <count>
-	      <timestamp> <expiredate> <flags>
-	This is one long line issued for each attribute subpacket when
-	an attribute packet is seen during key listing.  <fpr> is the
-	fingerprint of the key. <octets> is the length of the
-	attribute subpacket. <type> is the attribute type
-	(1==image). <index>/<count> indicates that this is the Nth
-	indexed subpacket of count total subpackets in this attribute
-	packet.  <timestamp> and <expiredate> are from the
-	self-signature on the attribute packet.  If the attribute
-	packet does not have a valid self-signature, then the
-	timestamp is 0.  <flags> are a bitwise OR of:
-		0x01 = this attribute packet is a primary uid
-		0x02 = this attribute packet is revoked
-		0x04 = this attribute packet is expired
-
-
-Key generation
-==============
-    Key generation shows progress by printing different characters to
-    stderr:
-	     "."  Last 10 Miller-Rabin tests failed
-	     "+"  Miller-Rabin test succeeded
-	     "!"  Reloading the pool with fresh prime numbers
-	     "^"  Checking a new value for the generator
-	     "<"  Size of one factor decreased
-	     ">"  Size of one factor increased
-
-    The prime number for ElGamal is generated this way:
-
-    1) Make a prime number q of 160, 200, 240 bits (depending on the keysize)
-    2) Select the length of the other prime factors to be at least the size
-       of q and calculate the number of prime factors needed
-    3) Make a pool of prime numbers, each of the length determined in step 2
-    4) Get a new permutation out of the pool or continue with step 3
-       if we have tested all permutations.
-    5) Calculate a candidate prime p = 2 * q * p[1] * ... * p[n] + 1
-    6) Check that this prime has the correct length (this may change q if
-       it seems not to be possible to make a prime of the desired length)
-    7) Check whether this is a prime using trial divisions and the
-       Miller-Rabin test.
-    8) Continue with step 4 if we did not find a prime in step 7.
-    9) Find a generator for that prime.
-
-    This algorithm is based on Lim and Lee's suggestion from the
-    Crypto '97 proceedings p. 260.
-
-
-Unattended key generation
-=========================
-This feature allows unattended generation of keys controlled by a
-parameter file.  To use this feature, you use --gen-key together with
---batch and feed the parameters either from stdin or from a file given
-on the commandline.
-
-The format of this file is as follows:
-  o Text only, line length is limited to about 1000 chars.
-  o You must use UTF-8 encoding to specify non-ascii characters.
-  o Empty lines are ignored.
-  o Leading and trailing spaces are ignored.
-  o A hash sign as the first non white space character indicates a comment line.
-  o Control statements are indicated by a leading percent sign, the
-    arguments are separated by white space from the keyword.
-  o Parameters are specified by a keyword, followed by a colon.  Arguments
-    are separated by white space.
-  o The first parameter must be "Key-Type", control statements
-    may be placed anywhere.
-  o Key generation takes place when either the end of the parameter file
-    is reached, the next "Key-Type" parameter is encountered or at the
-    control statement "%commit"
-  o Control statements:
-    %echo <text>
-	Print <text>.
-    %dry-run
-	Suppress actual key generation (useful for syntax checking).
-    %commit
-	Perform the key generation.  An implicit commit is done
-	at the next "Key-Type" parameter.
-    %pubring <filename>
-    %secring <filename>
-	Do not write the key to the default or commandline given
-	keyring but to <filename>.  This must be given before the first
-	commit to take place, duplicate specification of the same filename
-	is ignored, the last filename before a commit is used.
-	The filename is used until a new filename is used (at commit points)
-	and all keys are written to that file.	If a new filename is given,
-	this file is created (and overwrites an existing one).
-	Both control statements must be given.
-   o The order of the parameters does not matter except for "Key-Type"
-     which must be the first parameter.  The parameters are only for the
-     generated keyblock and parameters from previous key generations are not
-     used. Some syntactically checks may be performed.
-     The currently defined parameters are:
-     Key-Type: <algo-number>|<algo-string>
-	Starts a new parameter block by giving the type of the
-	primary key. The algorithm must be capable of signing.
-	This is a required parameter.
-     Key-Length: <length-in-bits>
-	Length of the key in bits.  Default is 1024.
-     Key-Usage: <usage-list>
-        Space or comma delimited list of key usage, allowed values are
-        "encrypt" and "sign".  This is used to generate the key flags.
-        Please make sure that the algorithm is capable of this usage.
-     Subkey-Type: <algo-number>|<algo-string>
-	This generates a secondary key.  Currently only one subkey
-	can be handled.
-     Subkey-Length: <length-in-bits>
-	Length of the subkey in bits.  Default is 1024.
-     Subkey-Usage: <usage-list>
-        Similar to Key-Usage.
-     Passphrase: <string>
-	If you want to specify a passphrase for the secret key,
-	enter it here.	Default is not to use any passphrase.
-     Name-Real: <string>
-     Name-Comment: <string>
-     Name-Email: <string>
-	The 3 parts of a key. Remember to use UTF-8 here.
-	If you don't give any of them, no user ID is created.
-     Expire-Date: <iso-date>|(<number>[d|w|m|y])
-	Set the expiration date for the key (and the subkey).  It
-	may either be entered in ISO date format (2000-08-15) or as
-	number of days, weeks, month or years. Without a letter days
-	are assumed.
-     Preferences: <string>
-        Set the cipher, hash, and compression preference values for
-	this key.  This expects the same type of string as "setpref"
-	in the --edit menu.
-     Revoker: <algo>:<fpr> [sensitive]
-        Add a designated revoker to the generated key.  Algo is the
-	public key algorithm of the designated revoker (i.e. RSA=1,
-	DSA=17, etc.)  Fpr is the fingerprint of the designated
-	revoker.  The optional "sensitive" flag marks the designated
-	revoker as sensitive information.  Only v4 keys may be
-	designated revokers.
-
-Here is an example:
-$ cat >foo <<EOF
-     %echo Generating a standard key
-     Key-Type: DSA
-     Key-Length: 1024
-     Subkey-Type: ELG-E
-     Subkey-Length: 1024
-     Name-Real: Joe Tester
-     Name-Comment: with stupid passphrase
-     Name-Email: joe@foo.bar
-     Expire-Date: 0
-     Passphrase: abc
-     %pubring foo.pub
-     %secring foo.sec
-     # Do a commit here, so that we can later print "done" :-)
-     %commit
-     %echo done
-EOF
-$ gpg --batch --gen-key foo
- [...]
-$ gpg --no-default-keyring --secret-keyring ./foo.sec \
-				  --keyring ./foo.pub --list-secret-keys
-/home/wk/work/gnupg-stable/scratch/foo.sec
-------------------------------------------
-sec  1024D/915A878D 2000-03-09 Joe Tester (with stupid passphrase) <joe@foo.bar>
-ssb  1024g/8F70E2C0 2000-03-09
-
-
-
-Layout of the TrustDB
-=====================
-The TrustDB is built from fixed length records, where the first byte
-describes the record type.  All numeric values are stored in network
-byte order. The length of each record is 40 bytes. The first record of
-the DB is always of type 1 and this is the only record of this type.
-
-FIXME:  The layout changed, document it here.
-
-  Record type 0:
-  --------------
-    Unused record, can be reused for any purpose.
-
-  Record type 1:
-  --------------
-    Version information for this TrustDB.  This is always the first
-    record of the DB and the only one with type 1.
-     1 byte value 1
-     3 bytes 'gpg'  magic value
-     1 byte Version of the TrustDB (2)
-     1 byte marginals needed
-     1 byte completes needed
-     1 byte max_cert_depth
-	    The three items are used to check whether the cached
-	    validity value from the dir record can be used.
-     1 u32  locked flags
-     1 u32  timestamp of trustdb creation
-     1 u32  timestamp of last modification which may affect the validity
-	    of keys in the trustdb.  This value is checked against the
-	    validity timestamp in the dir records.
-     1 u32  timestamp of last validation
-	    (Used to keep track of the time, when this TrustDB was checked
-	     against the pubring)
-     1 u32  record number of keyhashtable
-     1 u32  first free record
-     1 u32  record number of shadow directory hash table
-	    It does not make sense to combine this table with the key table
-	    because the keyid is not in every case a part of the fingerprint.
-     1 u32  record number of the trusthashtbale
-
-
-  Record type 2: (directory record)
-  --------------
-    Informations about a public key certificate.
-    These are static values which are never changed without user interaction.
-
-     1 byte value 2
-     1 byte  reserved
-     1 u32   LID     .	(This is simply the record number of this record.)
-     1 u32   List of key-records (the first one is the primary key)
-     1 u32   List of uid-records
-     1 u32   cache record
-     1 byte  ownertrust
-     1 byte  dirflag
-     1 byte  maximum validity of all the user ids
-     1 u32   time of last validity check.
-     1 u32   Must check when this time has been reached.
-	     (0 = no check required)
-
-
-  Record type 3:  (key record)
-  --------------
-    Informations about a primary public key.
-    (This is mainly used to lookup a trust record)
-
-     1 byte value 3
-     1 byte  reserved
-     1 u32   LID
-     1 u32   next   - next key record
-     7 bytes reserved
-     1 byte  keyflags
-     1 byte  pubkey algorithm
-     1 byte  length of the fingerprint (in bytes)
-     20 bytes fingerprint of the public key
-	      (This is the value we use to identify a key)
-
-  Record type 4: (uid record)
-  --------------
-    Informations about a userid
-    We do not store the userid but the hash value of the userid because that
-    is sufficient.
-
-     1 byte value 4
-     1 byte reserved
-     1 u32  LID  points to the directory record.
-     1 u32  next   next userid
-     1 u32  pointer to preference record
-     1 u32  siglist  list of valid signatures
-     1 byte uidflags
-     1 byte validity of the key calculated over this user id
-     20 bytes ripemd160 hash of the username.
-
-
-  Record type 5: (pref record)
-  --------------
-    This record type is not anymore used.
-
-     1 byte value 5
-     1 byte   reserved
-     1 u32  LID; points to the directory record (and not to the uid record!).
-	    (or 0 for standard preference record)
-     1 u32  next
-     30 byte preference data
-
-  Record type 6  (sigrec)
-  -------------
-    Used to keep track of key signatures. Self-signatures are not
-    stored.  If a public key is not in the DB, the signature points to
-    a shadow dir record, which in turn has a list of records which
-    might be interested in this key (and the signature record here
-    is one).
-
-     1 byte   value 6
-     1 byte   reserved
-     1 u32    LID	    points back to the dir record
-     1 u32    next   next sigrec of this uid or 0 to indicate the
-		     last sigrec.
-     6 times
-	1 u32  Local_id of signatures dir or shadow dir record
-	1 byte Flag: Bit 0 = checked: Bit 1 is valid (we have a real
-			     directory record for this)
-			 1 = valid is set (but may be revoked)
-
-
-
-  Record type 8: (shadow directory record)
-  --------------
-    This record is used to reserve a LID for a public key.  We
-    need this to create the sig records of other keys, even if we
-    do not yet have the public key of the signature.
-    This record (the record number to be more precise) will be reused
-    as the dir record when we import the real public key.
-
-     1 byte value 8
-     1 byte  reserved
-     1 u32   LID      (This is simply the record number of this record.)
-     2 u32   keyid
-     1 byte  pubkey algorithm
-     3 byte reserved
-     1 u32   hintlist	A list of records which have references to
-			this key.  This is used for fast access to
-			signature records which are not yet checked.
-			Note, that this is only a hint and the actual records
-			may not anymore hold signature records for that key
-			but that the code cares about this.
-    18 byte reserved
-
-
-
-  Record Type 10 (hash table)
-  --------------
-    Due to the fact that we use fingerprints to lookup keys, we can
-    implement quick access by some simple hash methods, and avoid
-    the overhead of gdbm.  A property of fingerprints is that they can be
-    used directly as hash values.  (They can be considered as strong
-    random numbers.)
-      What we use is a dynamic multilevel architecture, which combines
-    hashtables, record lists, and linked lists.
-
-    This record is a hashtable of 256 entries; a special property
-    is that all these records are stored consecutively to make one
-    big table. The hash value is simple the 1st, 2nd, ... byte of
-    the fingerprint (depending on the indirection level).
-
-    When used to hash shadow directory records, a different table is used
-    and indexed by the keyid.
-
-     1 byte value 10
-     1 byte reserved
-     n u32  recnum; n depends on the record length:
-	    n = (reclen-2)/4  which yields 9 for the current record length
-	    of 40 bytes.
-
-    the total number of such record which makes up the table is:
-	 m = (256+n-1) / n
-    which is 29 for a record length of 40.
-
-    To look up a key we use the first byte of the fingerprint to get
-    the recnum from this hashtable and look up the addressed record:
-       - If this record is another hashtable, we use 2nd byte
-	 to index this hash table and so on.
-       - if this record is a hashlist, we walk all entries
-	 until we found one a matching one.
-       - if this record is a key record, we compare the
-	 fingerprint and to decide whether it is the requested key;
-
-
-  Record type 11 (hash list)
-  --------------
-    see hash table for an explanation.
-    This is also used for other purposes.
-
-    1 byte value 11
-    1 byte reserved
-    1 u32  next 	 next hash list record
-    n times		 n = (reclen-5)/5
-	1 u32  recnum
-
-    For the current record length of 40, n is 7
-
-
-
-  Record type 254 (free record)
-  ---------------
-    All these records form a linked list of unused records.
-     1 byte  value 254
-     1 byte  reserved (0)
-     1 u32   next_free
-
-
-
-Packet Headers
-===============
-
-GNUPG uses PGP 2 packet headers and also understands OpenPGP packet header.
-There is one enhancement used with the old style packet headers:
-
-   CTB bits 10, the "packet-length length bits", have values listed in
-   the following table:
-
-      00 - 1-byte packet-length field
-      01 - 2-byte packet-length field
-      10 - 4-byte packet-length field
-      11 - no packet length supplied, unknown packet length
-
-   As indicated in this table, depending on the packet-length length
-   bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field
-   are a "packet-length field".  The packet-length field is a whole
-   number field.  The value of the packet-length field is defined to be
-   the value of the whole number field.
-
-   A value of 11 is currently used in one place: on compressed data.
-   That is, a compressed data block currently looks like <A3 01 . .  .>,
-   where <A3>, binary 10 1000 11, is an indefinite-length packet. The
-   proper interpretation is "until the end of the enclosing structure",
-   although it should never appear outermost (where the enclosing
-   structure is a file).
-
-+  This will be changed with another version, where the new meaning of
-+  the value 11 (see below) will also take place.
-+
-+  A value of 11 for other packets enables a special length encoding,
-+  which is used in case, where the length of the following packet can
-+  not be determined prior to writing the packet; especially this will
-+  be used if large amounts of data are processed in filter mode.
-+
-+  It works like this: After the CTB (with a length field of 11) a
-+  marker field is used, which gives the length of the following datablock.
-+  This is a simple 2 byte field (MSB first) containing the amount of data
-+  following this field, not including this length field. After this datablock
-+  another length field follows, which gives the size of the next datablock.
-+  A value of 0 indicates the end of the packet. The maximum size of a
-+  data block is limited to 65534, thereby reserving a value of 0xffff for
-+  future extensions. These length markers must be inserted into the data
-+  stream just before writing the data out.
-+
-+  This 2 byte field is large enough, because the application must buffer
-+  this amount of data to prepend the length marker before writing it out.
-+  Data block sizes larger than about 32k doesn't make any sense. Note
-+  that this may also be used for compressed data streams, but we must use
-+  another packet version to tell the application that it can not assume,
-+  that this is the last packet.
-
-
-GNU extensions to the S2K algorithm
-===================================
-S2K mode 101 is used to identify these extensions.
-After the hash algorithm the 3 bytes "GNU" are used to make
-clear that these are extensions for GNU, the next bytes gives the
-GNU protection mode - 1000.  Defined modes are:
-  1001 - do not store the secret part at all
-
-
-Usage of gdbm files for keyrings
-================================
-    The key to store the keyblock is its fingerprint, other records
-    are used for secondary keys.  Fingerprints are always 20 bytes
-    where 16 bit fingerprints are appended with zero.
-    The first byte of the key gives some information on the type of the
-    key.
-      1 = key is a 20 bit fingerprint (16 bytes fpr are padded with zeroes)
-	  data is the keyblock
-      2 = key is the complete 8 byte keyid
-	  data is a list of 20 byte fingerprints
-      3 = key is the short 4 byte keyid
-	  data is a list of 20 byte fingerprints
-      4 = key is the email address
-	  data is a list of 20 byte fingerprints
-
-    Data is prepended with a type byte:
-      1 = keyblock
-      2 = list of 20 byte padded fingerprints
-      3 = list of list fingerprints (but how to we key them?)
-
-
-
-Pipemode
-========
-This mode can be used to perform multiple operations with one call to
-gpg. It comes handy in cases where you have to verify a lot of
-signatures. Currently we support only detached signatures.  This mode
-is a kludge to avoid running gpg n daemon mode and using Unix Domain
-Sockets to pass the data to it.  There is no easy portable way to do
-this under Windows, so we use plain old pipes which do work well under
-Windows.  Because there is no way to signal multiple EOFs in a pipe we
-have to embed control commands in the data stream: We distinguish
-between a data state and a control state.  Initially the system is in
-data state but it won't accept any data.  Instead it waits for
-transition to control state which is done by sending a single '@'
-character.  While in control state the control command os expected and
-this command is just a single byte after which the system falls back
-to data state (but does not necesary accept data now).  The simplest
-control command is a '@' which just inserts this character into the
-data stream.
-
-Here is the format we use for detached signatures:
-"@<"  - Begin of new stream
-"@B"  - Detached signature follows.
-        This emits a control packet (1,'B')
-<detached_signature>
-"@t"  - Signed text follows. 
-        This emits the control packet (2, 'B')
-<signed_text>
-"@."  - End of operation. The final control packet forces signature
-        verification
-"@>"  - End of stream   
-
-
-
-
-
-
-Other Notes
-===========
-    * For packet version 3 we calculate the keyids this way:
-	RSA	:= low 64 bits of n
-	ELGAMAL := build a v3 pubkey packet (with CTB 0x99) and calculate
-		   a rmd160 hash value from it. This is used as the
-		   fingerprint and the low 64 bits are the keyid.
-
-    * Revocation certificates consist only of the signature packet;
-      "import" knows how to handle this.  The rationale behind it is
-      to keep them small.
-
-
-
-
-
-
-
-Keyserver Message Format
-=========================
-
-The keyserver may be contacted by a Unix Domain socket or via TCP.
-
-The format of a request is:
-
-====
-command-tag
-"Content-length:" digits
-CRLF
-=======
-
-Where command-tag is
-
-NOOP
-GET <user-name>
-PUT
-DELETE <user-name>
-
-
-The format of a response is:
-
-======
-"GNUPG/1.0" status-code status-text
-"Content-length:" digits
-CRLF
-============
-followed by <digits> bytes of data
-
-
-Status codes are:
-
-     o	1xx: Informational - Request received, continuing process
-
-     o	2xx: Success - The action was successfully received, understood,
-	and accepted
-
-     o	4xx: Client Error - The request contains bad syntax or cannot be
-	fulfilled
-
-     o	5xx: Server Error - The server failed to fulfill an apparently
-	valid request
-
-
-
-Documentation on HKP (the http keyserver protocol):
-
-A minimalistic HTTP server on port 11371 recognizes a GET for /pks/lookup.
-The standard http URL encoded query parameters are this (always key=value):
-
-- op=index (like pgp -kv), op=vindex (like pgp -kvv) and op=get (like
-  pgp -kxa)
-
-- search=<stringlist>. This is a list of words that must occur in the key.
-  The words are delimited with space, points, @ and so on. The delimiters
-  are not searched for and the order of the words doesn't matter (but see
-  next option).
-
-- exact=on. This switch tells the hkp server to only report exact matching
-  keys back. In this case the order and the "delimiters" are important.
-
-- fingerprint=on. Also reports the fingerprints when used with 'index' or
-  'vindex'
-
-The keyserver also recognizes http-POSTs to /pks/add. Use this to upload
-keys.
-
-
-A better way to do this would be a request like:
-
-   /pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
-
-This can be implemented using Hurd's translator mechanism.
-However, I think the whole key server stuff has to be re-thought;
-I have some ideas and probably create a white paper.
-
diff --git a/doc/HACKING b/doc/HACKING
deleted file mode 100644
index 811179e53..000000000
--- a/doc/HACKING
+++ /dev/null
@@ -1,301 +0,0 @@
-		      A Hacker's Guide to GNUPG
-		   ================================
-		   (Some notes on GNUPG internals.)
-
-
-		   ===> Under construction <=======
-
-
-CVS Access
-==========
-Anonymous read-only CVS access is available:
-
-  cvs -z3 -d :pserver:anoncvs@cvs.gnupg.org:/cvs/gnupg login
-
-use the password "anoncvs".  To check out the the complete
-archive use:
-
-  cvs -z3 -d :pserver:anoncvs@cvs.gnupg.org:/cvs/gnupg \
-        checkout -R STABLE-BRANCH-1-0 gnupg
-
-This service is provided to help you in hunting bugs and not to deliver
-stable snapshots; it may happen that it even does not compile, so please
-don't complain. CVS may put a high load on a server, so please don't poll
-poll for new updates but wait for an announcement; to receive this you may
-want to subscribe to:
-
-    gnupg-commit-watchers@gnupg.org
-
-by sending a mail with subject "subscribe" to
-
-    gnupg-commit-watchers-request@gnupg.org
-
-
-You must run scripts/autogen.sh before doing the ./configure,
-as this creates some needed while which are not in the CVS.
-autogen.sh should checks that you have all required tools
-installed.
-
-
-RSYNC access
-============
-The FTP archive is also available by anonymous rsync.  A daily snapshot
-of the CVS head revision is also available.  See rsync(1) and try
-"rsync ftp.gnupg.org::" to see available resources.
-
-
-
-Special Tools
-=============
-Documentation is based on the docbook DTD.  Actually we have only the
-man page for now.  To build a man page you need the docbook-to-man
-tool and all the other thinks needed for SGML processing.  Debian
-comes with the docbook tools and you only need this docbook-to-man
-script which is comes with gtk-doc or download it from
-ftp.openit.de:/pub/devel/sgml.	If you don't have it everything
-should still work fine but you will have only a dummy man page.
-
-
-RFCs
-====
-
-1423  Privacy Enhancement for Internet Electronic Mail:
-      Part III: Algorithms, Modes, and Identifiers.
-
-1489  Registration of a Cyrillic Character Set.
-
-1750  Randomness Recommendations for Security.
-
-1991  PGP Message Exchange Formats.
-
-2015  MIME Security with Pretty Good Privacy (PGP).
-
-2144  The CAST-128 Encryption Algorithm.
-
-2279  UTF-8, a transformation format of ISO 10646.
-
-2440  OpenPGP.
-
-
-
-Debug Flags
------------
-Use the option "--debug n" to output debug information. This option
-can be used multiple times, all values are ORed; n maybe prefixed with
-0x to use hex-values.
-
-     value  used for
-     -----  ----------------------------------------------
-      1     packet reading/writing
-      2     MPI details
-      4     ciphers and primes (may reveal sensitive data)
-      8     iobuf filter functions
-      16    iobuf stuff
-      32    memory allocation stuff
-      64    caching
-      128   show memory statistics at exit
-      256   trust verification stuff
-
-
-
-
-Directory Layout
-----------------
-  ./		Readme, configure
-  ./scripts	Scripts needed by configure and others
-  ./doc 	Documentation
-  ./util	General purpose utility function
-  ./mpi 	Multi precision integer library
-  ./cipher	Cryptographic functions
-  ./g10 	GnuPG application
-  ./tools	Some helper and demo programs
-  ./keybox	The keybox library (under construction)
-  ./gcrypt	Stuff needed to build libgcrypt (under construction)
-
-
-Detailed Roadmap
-----------------
-g10/g10.c	Main module with option parsing and all the stuff you have
-		to do on startup.  Also has the exout handler and some
-		helper functions.
-g10/sign.c      Create signature and optionally encrypt
-
-g10/parse-packet.c
-g10/build-packet.c
-g10/free-packet.c
-		Parsing and creating of OpenPGP message packets.
-
-g10/getkey.c    Key selection code
-g10/pkclist.c   Build a list of public keys
-g10/skclist.c   Build a list of secret keys
-g10/ringedit.c  Keyring I/O
-g10/keydb.h
-
-g10/keyid.c	Helper functions to get the keyid, fingerprint etc.
-
-
-g10/trustdb.c    
-g10/trustdb.h
-g10/tdbdump.c
-               Management of the trustdb.gpg
-
-g10/compress.c Filter to handle compression
-g10/filter.h   Declarations for all filter functions
-g10/delkey.c   Delete a key
-g10/kbnode.c   Helper for the KBNODE linked list
-g10/main.h     Prototypes and some constants
-g10/mainproc.c Message processing
-g10/armor.c    Ascii armor filter 
-g10/mdfilter.c Filter to calculate hashs
-g10/textfilter.c Filter to handle CR/LF and trailing white space
-g10/cipher.c   En-/Decryption filter
-g10/misc.c     Utlity functions
-g10/options.h  Structure with all the command line options
-               and related constants
-g10/openfile.c Create/Open Files
-g10/tdbio.c    I/O handling for the trustdb.gpg
-g10/tdbio.h
-g10/hkp.h      Keyserver access
-g10/hkp.c
-g10/packet.h   Defintion of OpenPGP structures.
-g10/passphrase.c  Passphrase handling code
-g10/pubkey-enc.c  
-g10/seckey-cert.c
-g10/seskey.c
-g10/import.c
-g10/export.c
-g10/comment.c
-g10/status.c
-g10/status.h
-g10/sign.c
-g10/plaintext.c
-g10/encr-data.c
-g10/encode.c
-g10/revoke.c
-g10/keylist.c
-g10/sig-check.c
-g10/signal.c
-g10/helptext.c
-g10/verify.c
-g10/decrypt.c
-g10/keyedit.c
-g10/dearmor.c
-g10/keygen.c
-
-
-
-Memory allocation
------------------
-Use only the functions:
-
-    m_alloc()
-    m_alloc_clear()
-    m_strdup()
-    m_free()
-
-If you want to store a passphrase or some other sensitive data you may
-want to use m_alloc_secure() instead of m_alloc(), as this puts the data
-into a memory region which is protected from swapping (on some platforms).
-m_free() works for both.  This functions will not return if there is not
-enough memory available.
-
-
-
-Logging
--------
-
-
-
-
-
-
-Option parsing
----------------
-GNUPG does not use getopt or GNU getopt but functions of it's own.  See
-util/argparse.c for details.  The advantage of these functions is that
-it is more easy to display and maintain the help texts for the options.
-The same option table is also used to parse resource files.
-
-
-
-What is an IOBUF
-----------------
-This is the data structure used for most I/O of gnupg.	It is similar
-to System V Streams but much simpler.  Because OpenPGP messages are nested
-in different ways; the use of such a system has big advantages.  Here is
-an example, how it works:  If the parser sees a packet header with a partial
-length, it pushes the block_filter onto the IOBUF to handle these partial
-length packets: from now on you don't have to worry about this.  When it sees
-a compressed packet it pushes the uncompress filter and the next read byte
-is one which has already been uncompressed by this filter. Same goes for
-enciphered packet, plaintext packets and so on.  The file g10/encode.c
-might be a good staring point to see how it is used  - actually this is
-the other way: constructing messages using pushed filters but it may be
-easier to understand.
-
-
-How to use the message digest functions
----------------------------------------
-cipher/md.c implements an interface to hash (message digest functions).
-
-a) If you have a common part of data and some variable parts
-   and you need to hash of the concatenated parts, you can use this:
-	md = md_open(...)
-	md_write( md,  common_part )
-	md1 = md_copy( md )
-	md_write(md1, part1)
-	md_final(md1);
-	digest1 = md_read(md1)
-	md2 = md_copy( md )
-	md_write(md2, part2)
-	md_final(md2);
-	digest2 = md_read(md2)
-
-   An example are key signatures; the key packet is the common part
-   and the user-id packets are the variable parts.
-
-b) If you need a running digest you should use this:
-	md = md_open(...)
-	md_write( md, part1 )
-	digest_of_part1 = md_digest( md );
-	md_write( md, part2 )
-	digest_of_part1_cat_part2 = md_digest( md );
-	....
-
-Both methods may be combined. [Please see the source for the real syntax]
-
-
-
-
-How to use the cipher functions
--------------------------------
-cipher/cipher.c implements the interface to symmetric encryption functions.
-As usual you have a function to open a cipher (which returns a handle to be used
-with all other functions), some functions to set the key and other stuff and
-a encrypt and decrypt function which does the real work.  You probably know
-how to work with files - so it should really be easy to work with these
-functions.  Here is an example:
-
-    CIPHER_HANDLE hd;
-
-    hd = cipher_open( CIPHER_ALGO_TWOFISH, CIPHER_MODE_CFB, 0 );
-    if( !hd )
-	oops( use other function to check for the real error );
-    rc = cipher_setkey( hd, key256bit, 32 ) )
-    if( rc )
-	oops( weak key or something like this );
-    cipher_setiv( hd, some_IV_or_NULL_for_all_zeroes );
-    cipher_encrypt( hd, plain, cipher, size );
-    cipher_close( hd );
-
-
-
-How to use the public key functions
------------------------------------
-cipher/pubkey.c implements the interface to asymmetric encryption and
-signature functions. This is basically the same as with the symmetric
-counterparts, but due to their nature it is a little bit more complicated.
-
-   [Give an example]
-
-
diff --git a/doc/OpenPGP b/doc/OpenPGP
deleted file mode 100644
index a511ad7fd..000000000
--- a/doc/OpenPGP
+++ /dev/null
@@ -1,108 +0,0 @@
-		    GnuPG and OpenPGP
-		    =================
-
-   See RFC2440 for a description of OpenPGP.  We have an annotated version
-   of this RFC online:	http://www.gnupg.org/rfc2440.html
-
-
-
-  Compatibility Notes
-  ===================
-   GnuPG (>=1.0.3) is in compliance with RFC2440 despite these exceptions:
-
-    * (9.2) states that IDEA SHOULD be implemented.  This is not done
-      due to patent problems.
-
-
-   All MAY features are implemented with this exception:
-
-    * multi-part armored messages are not supported.
-      MIME (rfc2015) should be used instead.
-
-   Most of the OPTIONAL stuff is implemented.
-
-   There are a couple of options which can be used to override some
-   RFC requirements.  This is always mentioned with the description
-   of that options.
-
-   A special format of partial packet length exists for v3 packets
-   which can be considered to be in compliance with RFC1991;  this
-   format is only created if a special option is active.
-
-   GnuPG uses a S2K mode of 101 for GNU extensions to the secret key
-   protection algorithms.  This number is not defined in OpenPGP, but
-   given the fact that this number is in a range which used at many
-   other places in OpenPGP for private/experimenat algorithm identifiers,
-   this should be not a so bad choice.	The 3 bytes "GNU" are used
-   to identify this as a GNU extension - see the file DETAILS for a
-   definition of the used data formats.
-
-
-
-  Some Notes on OpenPGP / PGP Compatibility:
-  ==========================================
-
-     * PGP 5.x does not accept V4 signatures for anything other than
-       key material.  The GnuPG option --force-v3-sigs mimics this
-       behavior.
-
-     * PGP 5.x does not recognize the "five-octet" lengths in
-       new-format headers or in signature subpacket lengths.
-
-     * PGP 5.0 rejects an encrypted session key if the keylength
-       differs from the S2K symmetric algorithm. This is a bug in its
-       validation function.
-
-     * PGP 5.0 does not handle multiple one-pass signature headers and
-       trailers. Signing one will compress the one-pass signed literal
-       and prefix a V3 signature instead of doing a nested one-pass
-       signature.
-
-     * When exporting a private key, PGP 2.x generates the header
-       "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY
-       BLOCK". All previous versions ignore the implied data type, and
-       look directly at the packet data type.
-
-     * In a clear-signed signature, PGP 5.0 will figure out the correct
-       hash algorithm if there is no "Hash:" header, but it will reject
-       a mismatch between the header and the actual algorithm used. The
-       "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x
-       rejects the "Hash:" header and assumes MD5. There are a number
-       of enhanced variants of PGP 2.6.x that have been modified for
-       SHA-1 signatures.
-
-     * PGP 5.0 can read an RSA key in V4 format, but can only recognize
-       it with a V3 keyid, and can properly use only a V3 format RSA
-       key.
-
-     * Neither PGP 5.x nor PGP 6.0 recognize ElGamal Encrypt and Sign
-       keys. They only handle ElGamal Encrypt-only keys.
-
-
-  Parts of this document are taken from:
-  ======================================
-
-			 OpenPGP Message Format
-		   draft-ietf-openpgp-formats-07.txt
-
-
-   Copyright 1998 by The Internet Society. All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph
-   are included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-
diff --git a/doc/README.W32 b/doc/README.W32
deleted file mode 100644
index 61aa05f0e..000000000
--- a/doc/README.W32
+++ /dev/null
@@ -1,100 +0,0 @@
-This is a binary version of GnuPG for MS-Windows 95, 98, WNT and W2000.
-
-A FAQ comes with this package and a probably more recent one can be
-found online at http://www.gnupg.org/faq.html.  See
-http://www.gnupg.org/docs-mls.html for a list of mailing lists. In
-particular the list gnupg-users@gnupg.org might be useful to answer
-questions - but please read the FAQ first.
-
-Installation instructions:
---------------------------
- 1. Unpack the ZIP archive (alright, you already did this).
- 2. Copy "gpg.exe" and "gpgv.exe" to some place where you
-    usually store your binaries.
- 3. Create a directory "c:\gnupg" (or any other as you like)
- 4. If you did not use the default directory "c:\gnupg", you
-    should enter a string with the directory into the Registry
-    under the key:
-	 HKEY_CURRENT_USER -> Software -> GNU -> GnuPG
-    (you probably need to create the keys GNU and GnuPG) and insert a
-    new string under the name "HomeDir" with the value of the default
-    directory you want to use.  Please use forward slashes and not the
-    backslashes when setting filenames for GnuPG into the Registry.
- 5. Enter "gpg" and see what happens
- 6. Read the file README and the online HOWTOs
-
-
-Internationalization support:
------------------------------
-  1. Decide where to store the translation files for your language.
-     Here we assume the directory "c:/gnu/locale/fr"
-
-  2. Set the directory with the translations into the Registry under
-     the key:
-	HKEY_CURRENT_USER -> Control Panel -> Mingw32 -> NLS
-     (you probably need to create the keys Mingw32 and NLS) using a string
-     entry with the name "MoDir".
-  3. Select which language to use and copy the currect translation file
-     under the name "gnupg.mo" into the directory set in step 2
-     (Example:	"copy fr.mo c:\gnu\locale\fr\gnupg.mo")
-  4. Done.
-
-Currently we only support the Codepages 437, 850 und Latin1.  If you have
-problems, either delete the gnupg.mo file or don't set the environment
-variable
-
-
-
-How to build it from the source:
---------------------------------
-This version has been build with the Mingw32/CPD kit using the latest
-stable version of GnuPG.
-
-First get the source: It has to be available at the same location you
-found this binary package - if not you should have received a written
-offer to get the source delivered to you See the file COPYING (section
-3) for details.
-
-If you got this package from its canonical place (ftp.gnupg.org), the
-source is available at:
-
-  ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.2.n.tar.gz
-
-or for development snapshots
-
-  ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.x.n.tar.gz
-
-this is the same source as for the Unix version.  If your binary
-version of GnuPG is called something like gnupg-w32-1.0.4-1.zip, you
-should find a patch file named gnupg-w32-1.0.4-1.0.4-1.diff.gz at the
-same location, which has to be applied to the stock gpg source file.
-Instructions are at the top of this file.
-
-To build it, you need the MingW32/CPD kit, which is available at
-
-  ftp://ftp.gnupg.org/people/werner/cpd/mingw32-cpd-0.3.0.tar.gz
-  ftp://ftp.gnupg.org/people/werner/cpd/gcc-core-2.95.2.tar.gz
-  ftp://ftp.gnupg.org/people/werner/cpd/binutils-2.9.1.tar.gz
-
-gcc and binutils are stock GNU source which are available
-at every GNU mirror. 
-
-After you have installed this environment you should be able to do this:
-
- $ scripts/autogen.sh --build-w32
- $ make
- $ mingw32 strip g10/gpg.exe
- $ cp g10/gpg.exe  /some_windows_drive/
-
-And everything hopefully works. 
-
-
-Don't forget that MS-Windows ist just a temporary workaround until
-you can switch to a GNU system ;-)
-
-Be the source always with you.
-
-    Werner
-
-
-
diff --git a/doc/credits-1.0 b/doc/credits-1.0
deleted file mode 100644
index 977910652..000000000
--- a/doc/credits-1.0
+++ /dev/null
@@ -1,41 +0,0 @@
-The GNU Privacy Guard has been created by the GnuPG team:
-Matthew Skala, Michael Roth, Niklas Hernaeus, Rémi Guyomarch
-and Werner Koch.  Gael Queri, Gregory Steuck, Janusz A. Urbanowicz,
-Marco d'Itri, Thiago Jung Bauermann, Urko Lusa and Walter Koch
-did the official translations.	Mike Ashley is working on the
-GNU Privacy Handbook.
-
-The following people helped greatly by suggesting improvements,
-testing, fixing bugs, providing resources and doing other important
-tasks:	Allan Clark, Anand Kumria, Ariel T Glenn, Bodo Moeller,
-Bryan Fullerton, Brian Moore, Brian Warner, Caskey L. Dickson,
-Cees van de Griend, Charles Levert, Christian von Roques,
-Christopher Oliver, Christian Recktenwald, Daniel Eisenbud,
-Daniel Koenig, David Ellement, Detlef Lannert, Dirk Lattermann,
-Ed Boraas, Enzo Michelangeli, Ernst Molitor, Fabio Coatti,
-Felix von Leitner, Frank Heckenbach, Frank Stajano, Gaël Quéri,
-Greg Louis, Greg Troxel, Gregory Steuck, Geoff Keating, Harald Denker,
-Hendrik Buschkamp, Holger Schurig, Hugh Daniel, Ian McKellar,
-Janusz A. Urbanowicz, James Troup, Jean-loup Gailly, Jens Bachem,
-Joachim Backes, John A. Martin, Johnny Teveßen, Jörg Schilling,
-Jun Kuriyama, Karl Fogel, Karsten Thygesen, Katsuhiro Kondou,
-Kazu Yamamoto, Lars Kellogg-Stedman, Marco d'Itri, Mark Adler,
-Mark Elbrecht, Markus Friedl, Martin Kahlert, Martin Hamilton,
-Martin Schulte, Matthew Skala, Max Valianskiy, Michael Roth,
-Michael Sobolev, Nicolas Graner, NIIBE Yutaka, Niklas Hernaeus,
-Nimrod Zimerman, N J Doye, Oliver Haakert, Oskari Jääskeläinen,
-Paul D. Smith, Philippe Laliberte, Peter Gutmann, QingLong,
-Ralph Gillen, Rat, Reinhard Wobst, Rémi Guyomarch, Reuben Sumner,
-Roland Rosenfeld, Ross Golder, Serge Munhoven, SL Baur, Stefan Karrmann,
-Stefan Keller, Steffen Ullrich, Steffen Zahn, Steven Bakker,
-Susanne Schultz, Thiago Jung Bauermann, Thomas Roessler, Tom Spindler,
-Tom Zerucha, Tomas Fasth, Thomas Mikkelsen, Ulf Möller, Urko Lusa,
-Walter Koch, Wim Vandeputte and Gerlinde Klaes.
-
-This software has been made possible by the previous work of
-Chris Wedgwood, Jean-loup Gailly, Jon Callas, Mark Adler, Martin Hellmann
-Paul Kendall, Philip R. Zimmermann, Peter Gutmann, Philip A. Nelson,
-Taher ElGamal, Torbjorn Granlund, Whitfield Diffie, some unknown NSA
-mathematicians and all the folks who have worked hard to create complete
-and free operating systems.
-
diff --git a/doc/faq.raw b/doc/faq.raw
deleted file mode 100644
index ec4212326..000000000
--- a/doc/faq.raw
+++ /dev/null
@@ -1,1019 +0,0 @@
-[$htmltitle=GnuPG FAQ]
-[$sfaqheader=The GnuPG FAQ says:]
-[$sfaqfooter=
-The most recent version of the FAQ is available from
-<http://www.gnupg.org/>
-]
-[$usenetheader=
-]
-[$maintainer=David D. Scribner, <faq 'at' gnupg.org>]
-[$hGPG=http://www.gnupg.org]
-
-[H body bgcolor=#ffffff text=#000000 link=#1f00ff alink=#ff0000 vlink=#9900dd]
-[H H1]GnuPG Frequently Asked Questions[H /H1]
-
-
-[H p]
-Version: 1.5.7[H br]
-Last-Modified: Aug 21, 2002[H br]
-Maintained-by: [$maintainer]
-[H /p]
-
-
-This is the GnuPG FAQ. The latest HTML version is available
-[H a href=[$hGPG]/faq.html]here[H/a].
-
-The index is generated automatically, so there may be errors here. Not
-all questions may be in the section they belong to. Suggestions about
-how to improve the structure of this FAQ are welcome.
-
-Please send additions and corrections to the maintainer. It would be
-most convenient if you could provide the answer to be included here
-as well. Your help is very much appreciated.
-
-Please, don't send message like "This should be a FAQ - what's the answer?".
-If it hasn't been asked before, it isn't a FAQ. In that case you could
-search in the mailing list archive.
-
-[H HR]
-<C>
-[H HR]
-
-
-<S> GENERAL
-
-<Q> What is GnuPG?
-
-    [H a href=[$hGPG]]GnuPG[H /a] stands for GNU Privacy Guard and
-    is GNU's tool for secure communication and data storage. It can be
-    used to encrypt data and to create digital signatures. It includes
-    an advanced key management facility and is compliant with the
-    proposed OpenPGP Internet standard as described in [H a href=http://www.gnupg.org/rfc2440.html]RFC 2440[H/a].
-    As such, it is aimed to be compatible with PGP from NAI, Inc.
-
-<Q> Is GnuPG compatible with PGP?
-
-    In general, yes. GnuPG and newer PGP releases should be implementing
-    the OpenPGP standard. But there are some interoperability
-    problems. See question <Rcompat> for details.
-
-
-<S> SOURCES of INFORMATION
-
-<Q> Where can I find more information?
-
-    Here's a list of on-line resources:
-
-    [H UL] 
-    [H LI]The documentation page is located at [H a href=[$hGPG]/docs.html]<[$hGPG]/docs.html>[H/a].
-    Have a look at the HOWTOs and the GNU Privacy Handbook (GPH, available
-    in English, Spanish and Russian). The latter provides a detailed user's
-    guide to GnuPG. You'll also find a document about how to convert from
-    PGP 2.x to GnuPG.
-
-    [H LI]On [H a href=http://lists.gnupg.org]<http://lists.gnupg.org>[H/a] you'll find an online archive of the
-    GnuPG mailing lists. Most interesting should be gnupg-users for all
-    user-related issues and gnupg-devel if you want to get in touch with
-    the developers.
-
-    In addition, searchable archives can be found on MARC, e.g.: [H br]
-    GnuPG-users: [H a href=http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2]<http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2>[H/a],[H br]
-    GnuPG-devel: [H a href=http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2]<http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2>[H/a].[H br]
-
-    [H B]PLEASE:[H/B]
-    Before posting to a list, read this FAQ and the available
-    documentation. In addition, search the list archive - maybe your
-    question has already been discussed. This way you help people focus
-    on topics that have not yet been resolved.
-
-    [H LI]The GnuPG source distribution contains a subdirectory:
-
-    [H PRE]
-     ./doc
-    [H /PRE]
-
-    where some additional documentation is located (mainly interesting
-    for hackers, not the casual user).
-    [H /UL]
-
-<Q> Where do I get GnuPG?
-
-    You can download the GNU Privacy Guard from its primary FTP server
-    [H a href=ftp://ftp.gnupg.org/pub/gcrypt]ftp.gnupg.org[H /a] or from one of the mirrors:
-
-    [H a href=[$hGPG]/mirrors.html]
-     <[$hGPG]/mirror.html>
-    [H /a]
-
-    The current version is 1.0.4, please upgrade to this version as it
-    fixes a security bug regarding the verification of multiple signatures.
-
-
-<S> INSTALLATION 
-
-<Q> Which OSes does GnuPG run on?
-
-    It should run on most Unices as well as Windows 95 and Windows NT. A
-    list of OSes reported to be OK is presented at:
-
-    [H a href=http://www.gnupg.org/backend.html#supsys]
-     <http://www.gnupg.org/gnupg.html#supsys>
-    [H /a]
-
-<Q> Which random gatherer should I use?
-
-    "Good" random numbers are crucial for the security of your encryption.
-    Different operating systems provide a variety of more or less quality
-    random data. Linux and *BSD provide kernel generated random data
-    through /dev/random - this should be the preferred choice on these
-    systems. Also Solaris users with the SUNWski package installed have
-    a /dev/random. In these cases, use the configure option:
-
-    [H pre]
-     --enable-static-rnd=linux
-    [H/pre]
-
-    In addition, there's also the kernel random device by Andi Maier
-    [H a href= http://www.cosy.sbg.ac.at/~andi]<http://www.cosy.sbg.ac.at/~andi>[H /a], but it's still beta. Use at your
-    own risk!
-
-    On other systems, the Entropy Gathering Daemon (EGD) is a good choice.
-    It is a perl-daemon that monitors system activity and hashes it into
-    random data. See the download page [H a href=http://www.gnupg.org/download.html]<http://www.gnupg.org/download.html>[H /a]
-    to obtain egd. Use:
-
-    [H pre]
-     --enable-static-rnd=egd
-    [H/pre]
-
-    here.
-
-    If the above options do not work, you can use the random number
-    generator "unix". This is [H B]very[H /B] slow and should be avoiced. The
-    random quality isn't very good so don't use it on sensitive data.
-
-<Didea>
-<Q> How do I include support for RSA and IDEA?
-
-    RSA is included as of GnuPG 1.0.3.
-
-    The official GnuPG distribution does not contain IDEA due to a
-    patent restriction. The patent does not expire before 2007 so don't
-    expect official support before then.
-
-    However, there is an unofficial module to include it even
-    in earlier versions of GnuPG. It's available from
-    [H a href=ftp://ftp.gnupg.org/pub/gcrypt/contrib/]<ftp://ftp.gnupg.org/pub/gcrypt/contrib/>[H /a]. Look for:
-
-    [H pre]
-     idea.c
-    [H /pre]
-
-    Compilation directives are in the headers of these files. Then add
-    the following line to your ~/.gnupg/options:
-
-    [H pre]
-     load-extension idea
-    [H /pre]
-
-
-<S> USAGE
-
-<Q> What is the recommended key size?
-
-    1024 bit for DSA signatures; even for plain ElGamal signatures
-    this is sufficient as the size of the hash is probably the weakest
-    link if the key size is larger than 1024 bits. Encryption keys may
-    have greater sizes, but you should then check the fingerprint of
-    this key:
-
-    [H pre]
-     gpg --fingerprint <user ID>
-    [H /pre]
-
-    As for the key algorithms, you should stick with the default (i.e.,
-    DSA signature and ElGamal encryption). A ElGamal signing key has the
-    following disadvantages: the signature is larger, it is hard to
-    create such a key useful for signatures which can withstand some
-    real world attacks, you don't get any extra security compared to
-    DSA, and there might be compatibility problems with certain PGP
-    versions. It has only been introduced because at the time it was
-    not clear whether there was a patent on DSA.
-
-<Q> Why does it sometimes take so long to create keys?
-
-    The problem here is that we need a lot of random bytes and for that
-    we (on Linux the /dev/random device) must collect some random data.
-    It is really not easy to fill the Linux internal entropy buffer; I
-    talked to Ted Ts'o and he commented that the best way to fill the
-    buffer is to play with your keyboard. Good security has its price.
-    What I do is to hit several times on the shift, control, alternate,
-    and caps lock keys, because these keys do not produce output to the
-    screen. This way you get your keys really fast (it's the same thing
-    PGP2 does).
-
-    Another problem might be another program which eats up your random
-    bytes (a program (look at your daemons) that reads from /dev/random).
-
-<Q> And it really takes long when I work on a remote system. Why?
-
-    Don't do this at all! You should never create keys or even use GnuPG
-    on a remote system because you normally have no physical control
-    over your secret key ring (which is in most cases vulnerable to
-    advanced dictionary attacks) - I strongly encourage everyone to only
-    create keys on a local computer (a disconnected laptop is probably
-    the best choice) and if you need it on your connected box (I know:
-    We all do this) be sure to have a strong password for your account
-    and for your secret key and that you can trust your system
-    administrator.
-
-    When I check GnuPG on a remote system via ssh (I have no Alpha here
-    ;-) I have the same problem. It takes a *very* long time to create
-    the keys, so I use a special option, --quick-random, to generate
-    insecure keys which are only good for some tests.
-
-<Q> What is the difference between options and commands?
-
-    If you do a 'gpg --help', you will get two separate lists. The first
-    is a list of commands. The second is a list of options. Whenever you
-    run GPG, you [H B]must[H /B] pick exactly one command (with one exception,
-    see below). You [H B]may[H /B] pick one or more options. The command should,
-    just by convention, come at the end of the argument list, after all
-    the options. If the command takes a file (all the basic ones do),
-    the filename comes at the very end. So the basic way to run gpg is:
-
-    [H pre]
-     gpg [--option something] [--option2] [--option3 something] --command file
-    [H/pre]
-
-    Some options take arguments. For example, the --output option (which
-    can be abbreviated -o) is an option that takes a filename. The
-    option's argument must follow immediately after the option itself,
-    otherwise gpg doesn't know which option the argument is supposed to
-    go with. As an option, --output and its filename must come before
-    the command. The --recipient (-r) option takes a name or keyid to
-    encrypt the message to, which must come right after the -r argument.
-    The --encrypt (or -e) command comes after all the options followed
-    by the file you wish to encrypt. So use:
-
-    [H pre]
-     gpg -r alice -o secret.txt -e test.txt
-    [H/pre]
-
-    If you write the options out in full, it is easier to read:
-
-    [H pre]
-     gpg --recipient alice --output secret.txt --encrypt test.txt
-    [H/pre]
-
-    If you're saving it in a file called ".txt" then you'd probably
-    expect to see ASCII-armored text in there, so you need to add the
-    --armor (-a) option, which doesn't take any arguments:
-
-    [H pre]
-     gpg --armor --recipient alice --output secret.txt --encrypt test.txt
-    [H/pre]
-
-    If you imagine square brackets around the optional parts, it becomes
-    a bit clearer:
-
-    [H pre]
-     gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
-    [H/pre]
-
-    The optional parts can be rearranged any way you want:
-
-    [H pre]
-     gpg --output secret.txt --recipient alice --armor --encrypt test.txt
-    [H/pre]
-
-    If your filename begins with a hyphen (e.g. "-a.txt"), GnuPG assumes
-    this is an option and may complain. To avoid this you have either
-    to use "./-a.txt" or stop the option and command processing with two
-    hyphens: "-- -a.txt". [H B]The exception:[H /B] signing and encrypting at the
-    same time. Use:
-
-    [H pre]
-     gpg [--options] --sign --encrypt foo.txt
-    [H/pre]
-
-<Q> I can't delete a user ID because it is already deleted on my public
-    keyring?
-
-    Because you can only select from the public key ring, there is no
-    direct way to do this. However it is not very complicated to do
-    anyway. Create a new user ID with exactly the same name and you
-    will see that there are now two identical user IDs on the secret
-    ring. Now select this user ID and delete it. Both user IDs will be
-    removed from the secret ring.
-
-<Q> I can't delete the secret key because my public key disappeared?
-
-    To select a key a search is always done on the public keyring,
-    therefore it is not possible to select an secret key without
-    having the public key. Normally it shoud never happen that the
-    public key got lost but the secret key is still available. The
-    reality is different, so GnuPG implements a special way to deal
-    with it: Simply use the long keyid which can be obtained by using
-    the --with-colons options (it is the fifth field in the lines
-    beginning with "sec").
-
-<Q> What are trust, validity and ownertrust?
-
-    "ownertrust" is used instead of "trust" to make clear that this is
-    the value you have assigned to a key to express how much you trust
-    the owner of this key to correctly sign (and so introduce) other
-    keys. "validity", or calculated trust, is a value which says how
-    much GnuPG thinks a key is valid (that it really belongs to the one
-    who claims to be the owner of the key).  For more see the chapter
-    "The Web of Trust" in the Manual.
-
-<Q> How do I sign a patch file?
-
-    Use "gpg --clearsign --not-dash-escaped ...". The problem with
-    --clearsign is that all lines starting with a dash are quoted with
-    "- "; obviously diff produces many lines starting with a dash and
-    these are then quoted and that is not good for a patch ;-). To use a
-    patch file without removing the cleartext signature, the special
-    option --not-dash-escaped may be used to suppress generation of
-    these escape sequences. You should not mail such a patch because
-    spaces and line endings are also subject to the signature and a
-    mailer may not preserve these. If you want to mail a file you can
-    simply sign it using your MUA.
-
-<Q> Where is the "encrypt-to-self" option?
-
-    Use "--encrypt-to your_keyid". You can use more than one of these
-    options. To temporarily override the use of this additional key,
-    you can use the option "--no-encrypt-to".
-
-<Q> How can I get rid of the Version and Comment headers in armored
-    messages?
-
-    Use "--no-version --comment ''". Note that the left over blank line
-    is required by the protocol.
-
-<Q> What does the "You are using the xxxx character set." mean?
-
-    This note is printed when UTF8 mapping has to be done. Make sure
-    that the displayed charset is the one you have activated on your
-    system. Since "iso-8859-1" is the charset most used, this is the
-    default. You can change the charset with the option "--charset".
-    It is important that your active character set matches the one
-    displayed - if not, restrict yourself to plain 7 bit ASCII and no
-    mapping has to be done.
-
-<Q> How can a get list of key IDs used to encrypt a message?
-
-    [H pre]
-     gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | \
-     awk '/^\[GNUPG:\] ENC_TO / { print $3 }'
-    [H /pre]
-
-<Q> I can't decrypt my symmetrical only (-c) encrypted message with
-    a new version of GnuPG.
-
-    There used to be a bug in GnuPG < 1.0.1 which happens only if 3DES
-    or Twofish has been used for symmetric only encryption (this has
-    never been the default). The bug has been fixed but to enable you
-    to decrypt old messages, you should run gpg with the option
-    "--emulate-3des-s2k-bug", decrypt the message and encrypt it again
-    without this option. The option will be removed in 1.1, so better
-    re-encrypt your message now.
-
-<Q> How can I use GnuPG in an automated environment?
-
-    You should use the option --batch and don't use pass phrases as
-    there is usually no way to store it more secure than the secret
-    keyring itself. The suggested way to create the keys for the
-    automated environment is:
-
-    On a secure machine:
-    [H OL]
-    [H LI] If you want to do automatic signing, create a signing
-           subkey for your key (edit menu, choose "addkey" and the DSA).
-    [H LI] Make sure that you use a passphrase (needed by the current
-           implementation).
-    [H LI] gpg --export-secret-subkeys --no-comment foo >secring.auto
-    [H LI] Copy secring.auto and the public keyring to a test directory.
-    [H LI] Change to this directory.
-    [H LI] gpg --homedir . --edit foo and use "passwd" to remove the
-           passphrase from the subkeys.  You may also want to remove all
-           unused subkeys.
-    [H LI] Copy secring.auto to a floppy and carry it to the target box.
-    [H /OL]
-
-    On the target machine:
-    [H OL]
-    [H LI] Install secring.auto as secret keyring.
-    [H LI] Now you can start your new service. It is a good idea to
-           install some intrusion detection system so that you hopefully
-           get a notice of an successful intrusion, so that you in turn
-           can revoke all the subkeys installed on that machine and
-           install new subkeys.
-    [H /OL]
-
-<Q> Which email-client can I use with GnuPG?
-
-    Using GnuPG to encrypt email is one of the most popular uses.
-    Several mail clients or mail user-agents (MUA) support GnuPG at
-    varying degrees. Simplifying a bit, there are two ways mail can be
-    encrypted with GnuPG: the "old style" ASCII armor, i.e. plain text
-    encryption, and RFC2015 style (previously PGP/MIME, now OpenPGP).
-    The latter has full MIME support. Some MUAs support only one of
-    them, so whichever you actually use depends on your needs as well
-    as the capabilities of your addressee.
-
-    The following list is probably not exhaustive:
-
-    OpenPGP: Mutt (Unix), Emacs/Mew, Becky2 (Windows, with plugin),
-             TkRat (Unix). There is effort for a Mozilla plugin and
-	     Emacs/GNUS has support in the current CVS.
-
-    ASCII:   Emacs/{VM,GNUS}/MailCrypt, Mutt(Unix), Pine(Unix), and
-             probably many more.
-
-    Good overviews of OpenPGP-support can be found at 
-    [H a href=http://cryptorights.org/pgp-users/pgp-mail-clients.html]http://cryptorights.org/pgp-users/pgp-mail-clients.html[H /a]
-    and [H a href=http://www.geocities.com/openpgp/courrier_en.html]http://www.geocities.com/openpgp/courrier_en.html[H /a].
-
-<Q> Can't we have a gpg library?
-
-    This has been frequently requested. However, the current viewpoint
-    of the GnuPG maintainers is that this would lead to several security
-    issues and will therefore not be implemented in the foreseeable
-    future. However, for some areas of application gpgme could do the
-    trick. You'll find it at [H a href=ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme]ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme[H /a].
-
-<Q> I have successfully generated a revocation certificate, but I don't
-    understand how to send it to the key servers.
-
-    Most keyservers don't accept a 'bare' revocation certificate. You
-    have to import the certificate into gpg first:
-
-    [H pre]
-     gpg --import my-revocation.asc
-    [H /pre]
-
-    then send the revoked key to the keyservers:
-
-    [H pre]
-     gpg --keyserver certserver.pgp.com --send-keys mykeyid
-    [H /pre]
-
-    (or use a keyserver web interface for this).
-
-<Q> How do I put my keyring in a different directory?
-
-    GnuPG keeps several files in a special homedir directory. These
-    include the options file, pubring.gpg, secring.gpg, trustdb.gpg,
-    and others. GnuPG will always create and use these files. On unices,
-    the homedir is usually ~/.gnupg; on Windows "C:\gnupg\".
-
-    If you want to put your keyrings somewhere else, use:
-
-    [H pre]
-     --homedir /my/path/
-    [H /pre]
-
-    to make GnuPG create all its files in that directory. Your keyring
-    will be "/my/path/pubring.gpg". This way you can store your secrets
-    on a floppy disk. Don't use "--keyring" as its purpose is to specify
-    additional keyring files.
-
-
-<S> COMPATIBILITY ISSUES
-
-<Dcompat>
-<Q> How can I encrypt a message with GnuPG so that PGP is able to decrypt it?
-
-    It depends on the PGP version.
-
-    [H UL]
-    [H LI]PGP 2.x[H br]
-    You can't do that because PGP 2.x normally uses IDEA which is not
-    supported by GnuPG as it is patented (see <Ridea>), but if you have a
-    modified version of PGP you can try this:
-
-    [H pre]
-     gpg --rfc1991 --cipher-algo 3des ...
-    [H/pre]
-
-    Please don't pipe the data to encrypt to gpg but provide it using a
-    filename; otherwise, PGP 2 will not be able to handle it.
-
-    As for conventional encryption, you can't do this for PGP 2.
-
-    [H LI]PGP 5.x and higher[H br]
-    You need to provide two additional options:
-
-    [H pre]
-     --compress-algo 1 --cipher-algo cast5
-    [H/pre]
-
-    You may also use "3des" instead of "cast5", and "blowfish" does not
-    work with all versions of PGP 5. You may also want to put:
-
-    [H pre]
-     compress-algo 1
-    [H/pre]
-
-    into your ~/.gnupg/options file - this does not affect normal GnuPG
-    operation.
-
-    This applies to conventional encryption as well.
-    [H /UL]
-
-<Q> How do I migrate from PGP 2.x to GnuPG?
-
-    PGP 2 uses the RSA and IDEA encryption algorithms. Whereas the RSA
-    patent has expired and RSA is included as of GnuPG 1.0.3, the IDEA
-    algorithm is still patented until 2007. Under certain conditions you
-    may use IDEA even today. In that case, you may refer to Question
-    <Ridea> about how to add IDEA support to GnuPG and read
-    [H a href=http://www.gnupg.org/gph/en/pgp2x.html]http://www.gnupg.org/gph/en/pgp2x.html[H /a] to perform the migration.
-
-<Q> (removed)
-
-    (empty)
-
-<Q> Why is PGP 5.x not able to encrypt messages with some keys?
-
-    PGP, Inc. refuses to accept ElGamal keys of type 20 even for
-    encryption. They only support type 16 (which is identical at least
-    for decryption). To be more inter-operable, GnuPG (starting with
-    version 0.3.3) now also uses type 16 for the ElGamal subkey which is
-    created if the default key algorithm is chosen. You may add a type
-    16 ElGamal key to your public key, which is easy as your key
-    signatures are still valid.
-
-<Q> Why is PGP 5.x not able to verify my messages?
-
-    PGP 5.x does not accept v4 signatures for data material but OpenPGP
-    requests generation of v4 signatures for all kind of data, that's why
-    GnuPG defaults to them. Use the option "--force-v3-sigs" to generate
-    v3 signatures for data.
-
-<Q> How do I transfer owner trust values from PGP to GnuPG?
-
-    There is a script in the tools directory to help you. After you have
-    imported the PGP keyring you can give this command:
-
-    [H pre]
-     $ lspgpot pgpkeyring | gpg --import-ownertrust
-    [H /pre]
-
-    where pgpkeyring is the original keyring and not the GnuPG keyring
-    you might have created in the first step.
-
-<Q> PGP does not like my secret key.
-
-    Older PGPs probably bail out on some private comment packets used by
-    GnuPG. These packets are fully in compliance with OpenPGP; however
-    PGP is not really OpenPGP aware. A workaround is to export the
-    secret keys with this command:
-
-    [H pre]
-     $ gpg --export-secret-keys --no-comment -a your-key-id
-    [H /pre]
-
-    Another possibility is this: by default, GnuPG encrypts your secret
-    key using the Blowfish symmetric algorithm. Older PGPs will only
-    understand 3DES, CAST5, or IDEA symmetric algorithms. Using the
-    following method you can re-encrypt your secret gpg key with a
-    different algo:
-
-    [H pre]
-     $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \
-           --compress-algo=1  --edit-key <username>
-    [H /pre]
-
-    Then use passwd to change the password (just change it to the same
-    thing, but it will encrypt the key with CAST5 this time).
-
-    Now you can export it and PGP should be able to handle it.
-
-    For PGP 6.x the following options work to export a key:
-
-    [H pre]
-     $ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 \
-           --export-secret-keys <key-ID>
-    [H /pre]
-
-
-<S> PROBLEMS and ERROR MESSAGES
-
-<Q> Why do I get "gpg: Warning: using insecure memory!"
-
-    On many systems this program should be installed as setuid(root).
-    This is necessary to lock memory pages. Locking memory pages prevents
-    the operating system from writing them to disk and thereby keeping your
-    secret keys really secret. If you get no warning message about insecure
-    memory your operating system supports locking without being root. The
-    program drops root privileges as soon as locked memory is allocated.
-
-    On UnixWare 2.x and 7.x you should install GnuPG with the 'plock'
-    privilege to get the same effect:
-
-    [H pre]
-     filepriv -f plock /path/to/gpg
-    [H /pre]
-
-    If you can't or don't want to install GnuPG setuid(root), you can
-    use the option "--no-secmem-warning" or put:
-
-    [H pre]
-     no-secmem-warning
-    [H /pre]
-
-    in your ~/.gnupg/options file (this disables the warning).
-
-    On some systems (e.g., Windows) GnuPG does not lock memory pages
-    and older GnuPG versions (<=1.0.4) issue the warning:
-
-    [H pre]
-     gpg: Please note that you don't have secure memory
-    [H /pre]
-
-    This warning can't be switched off by the above option because it
-    was thought to be too serious an issue. However, it confused users
-    too much, so the warning was eventually removed.
-
-<Q> Large File Support doesn't work ...
-
-    LFS is correctly working in post-1.0.4 CVS. If configure doesn't
-    detect it correctly, try a different (i.e., better) compiler. egcs
-    1.1.2 works fine, other gccs sometimes don't. BTW, several
-    compilation problems of GnuPG 1.0.3 and 1.0.4 on HP-UX and Solaris
-    were due to broken LFS support.
-
-<Q> In the edit menu the trust values is not displayed correctly after
-    signing uids - why?
-
-    This happens because some information is stored immediately in
-    the trustdb, but the actual trust calculation can be done after the
-    save command. This is a "not easy to fix" design bug which will be
-    addressed in some future release.
-
-<Q> What does "skipping pubkey 1: already loaded" mean?
-
-    As of GnuPG 1.0.3, the RSA algorithm is included. If you still have
-    a "load-extension rsa" in your options file, the above message
-    occurs. Just remove the load command from the options file.
-
-<Q> GnuPG 1.0.4 doesn't create ~/.gnupg ...
-
-    That's a known bug, already fixed in newer versions.
-
-<Q> An ElGamal signature does not verify anymore since version 1.0.2 ...
-
-    Use the option --emulate-md-encode-bug.
-
-<Q> Old versions of GnuPG can't verify ElGamal signatures
-
-    Update to GnuPG 1.0.2 or newer.
-
-<Q> When I use --clearsign, the plain text has sometimes extra dashes
-    in it - why?
-
-    This is called dash-escaped text and is required by OpenPGP.
-    It always happens when a line starts with a dash ("-") and is
-    needed to make the lines that structure signature and text
-    (i.e., "-----BEGIN PGP SIGNATURE-----") to be the only lines
-    that start with two dashes.
-
-    If you use GnuPG to process those messages, the extra dashes
-    are removed. Good mail clients remove those extra dashes when
-    displaying such a message.      
-
-<Q> What is the thing with "can't handle multiple signatures"?
-
-    Due to different message formats GnuPG is not always able to split
-    a file with multiple signatures unambiguously into its parts. This
-    error message informs you that there is something wrong with the input.
-
-    The only way to have multiple signatures in a file is by using the
-    OpenPGP format with one-pass-signature packets (which is GnuPG's
-    default) or the cleartext signed format.
-
-<Q> If I submit a key to a keyserver, nothing happens ...
-
-    You are most likely using GnuPG 1.0.2 or older on Windows. That's
-    feature isn't yet implemented, but it's a bug not to say it. Newer
-    versions issue a warning. Upgrade to 1.0.4 or newer.
-
-<Q> I get "gpg: waiting for lock ..."
-
-    A previous gpg has most likely exited abnormally and left a lock
-    file. Go to ~/.gnupg and look for .*.lock files and remove them.
-
-<Q> Older gpg's (e.g., 1.0) have problems with keys from newer gpgs ...
-
-    As of 1.0.3, keys generated with gpg are created with preferences to
-    TWOFISH (and AES since 1.0.4) and that also means that they have the
-    capability to use the new MDC encryption method. This will go into
-    OpenPGP soon and is also suppoted by PGP 7. This new method avoids
-    a (not so new) attack on all email encryption systems.
-
-    This in turn means that pre-1.0.3 gpg's have problems with newer
-    keys. Because of security fixes, you should keep your GnuPG
-    installation in a recent state anyway. As a workaround, you can
-    force gpg to use a previous default cipher algo by putting:
-
-    [H pre]
-     cipher-algo cast5
-    [H /pre]
-
-    into your options file.
-
-<Q> With 1.0.4, I get "this cipher algorithm is deprecated ..."
-
-    If you just generated a new key and get this message while
-    encrypting, you've witnessed a bug in 1.0.4. It uses the new AES
-    cipher Rijndael that is incorrectly being referred as "deprecated".
-    Ignore this warning, more recent versions of gpg are corrected.
-
-<Q> Some dates are displayed as ????-??-??, why?
-
-    Due to constraints in most libc implementations, dates beyond
-    2038-01-19 can't be displayed correctly. 64 bit OSes are not
-    affected by this problem. To avoid printing wrong dates, GnuPG
-    instead prints some question marks. To see the correct value, you
-    can use the options --with-colons and --fixed-list-mode.
-
-<Q> I still have a problem. How do I report a bug?
-
-    Are you sure that it's not been mentioned somewhere on the mailing
-    lists? Did you have a look at the bug list (you'll find a link to
-    the list of reported bugs on the documentation page). If you're not
-    sure about it being a bug, you can send mail to the gnupg-devel
-    list. Otherwise, use the GUUG bug tracking system 
-    [H a href=http://bugs.guug.de/Reporting.html]http://bugs.guug.de/Reporting.html[H /a].
-
-<Q> Why doesn't GnuPG support X509 certificates?
-
-    GnuPG, first and foremost, is an implementation of the OpenPGP
-    standard (RFC 2440), which is a competing infrastructure, different
-    from X509.
-
-    They are both public-key cryptosystems, but how the public keys are
-    actually handled is different.
-
-<Q> Why do national characters in my user ID look funny?
-
-    According to OpenPGP, GnuPG encodes user ID strings (and other
-    things) using UTF-8. In this encoding of Unicode, most national
-    characters get encoded as two- or three-byte sequences. For
-    example, &aring; (0xE5 in ISO-8859-1) becomes &Atilde;&yen; (0xC3,
-    0xA5). This might also be the reason why keyservers can't find
-    your key.
-
-<Q> I get 'sed' errors when running ./configure on Mac OS X ...
-
-    This will be fixed after GnuPG has been upgraded to autoconf-2.50.
-    Until then, find the line setting CDPATH in the configure script
-    and place a:
-
-    [H pre]
-     unset CDPATH
-    [H /pre]
-
-    statement below it.
-
-<Q> Why does GnuPG 1.0.6 bail out on keyrings used with 1.0.7?
-
-    There is a small bug in 1.0.6 which didn't parse trust packets
-    correctly. You may want to apply this patch if you can't upgrade:
-
-    [H pre]
-     http://www.gnupg.org/developer/gpg-woody-fix.txt
-    [H /pre]
-
-
-<S> ADVANCED TOPICS
-
-<Q> How does this whole thing work?
-
-    To generate a secret/public keypair, run:
-
-    [H pre]
-     gpg --gen-key
-    [H/pre]
-
-    and choose the default values.
-
-    Data that is encrypted with a public key can only be decrypted by
-    the matching secret key. The secret key is protected by a password,
-    the public key is not.
-
-    So to send your friend a message, you would encrypt your message
-    with his public key, and he would only be able to decrypt it by
-    having the secret key and putting in the password to use his secret
-    key.
-
-    GnuPG is also useful for signing things. Things that are encrypted
-    with the secret key can be decrypted with the public key. To sign
-    something, a hash is taken of the data, and then the hash is in some
-    form encoded with the secret key. If someone has your public key, they
-    can verify that it is from you and that it hasn't changed by checking
-    the encoded form of the hash with the public key.
-
-    A keyring is just a large file that stores keys. You have a public
-    keyring where you store yours and your friend's public keys. You have
-    a secret keyring that you keep your secret key on, and should be very
-    careful with. Never ever give anyone else access to it and use a *good*
-    passphrase to protect the data in it.
-
-    You can 'conventionally' encrypt something by using the option 'gpg -c'.
-    It is encrypted using a passphrase, and does not use public and secret
-    keys. If the person you send the data to knows that passphrase, they
-    can decrypt it. This is usually most useful for encrypting things to
-    yourself, although you can encrypt things to your own public key in the
-    same way. It should be used for communication with partners you know
-    and where it is easy to exchange the passphrases (e.g. with your boy
-    friend or your wife). The advantage is that you can change the
-    passphrase from time to time and decrease the risk, that many old
-    messages may be decrypted by people who accidently got your passphrase.
-
-    You can add and copy keys to and from your keyring with the 'gpg
-    --import' and 'gpg --export' option. 'gpg --export-secret-keys' will
-    export secret keys. This is normally not useful, but you can generate
-    the key on one machine then move it to another machine.
-
-    Keys can be signed under the 'gpg --edit-key' option. When you sign a
-    key, you are saying that you are certain that the key belongs to the
-    person it says it comes from. You should be very sure that is really
-    that person: You should verify the key fingerprint with:
-
-    [H pre]
-     gpg --fingerprint user-id
-    [H/pre]
-
-    over the phone (if you really know the voice of the other person), at a
-    key signing party (which are often held at computer conferences), or at
-    a meeting of your local GNU/Linux User Group.
-
-    Hmm, what else. You may use the option "-o filename" to force output
-    to this filename (use "-" to force output to stdout). "-r" just lets
-    you specify the recipient (which public key you encrypt with) on the
-    command line instead of typing it interactively.
-
-    Oh yeah, this is important. By default all data is encrypted in some
-    weird binary format. If you want to have things appear in ASCII text
-    that is readable, just add the '-a' option. But the preferred method
-    is to use a MIME aware mail reader (Mutt, Pine and many more).
-
-    There is a small security glitch in the OpenPGP (and therefore GnuPG)
-    system; to avoid this you should always sign and encrypt a message
-    instead of only encrypting it.
-
-<Q> Why are some signatures with an ELG-E key valid?
-
-    These are ElGamal keys generated by GnuPG in v3 (RFC 1991) packets.
-    The OpenPGP draft later changed the algorithm identifier for ElGamal
-    keys which are usable for signatures and encryption from 16 to 20.
-    GnuPG now uses 20 when it generates new ElGamal keys but still
-    accepts 16 (which is according to OpenPGP "encryption only") if this
-    key is in a v3 packet. GnuPG is the only program which had used
-    these v3 ElGamal keys - so this assumption is quite safe.
-
-<Q> How does the whole trust thing work?
-
-    It works more or less like PGP. The difference is that the trust is
-    computed at the time it is needed. This is one of the reasons for
-    the trustdb which holds a list of valid key signatures. If you are
-    not running in batch mode you will be asked to assign a trust
-    parameter (ownertrust) to a key.
-
-    You can see the validity (calculated trust value) using this
-    command.
-
-    [H pre]
-     gpg --list-keys --with-colons
-    [H/pre] 
-
-    If the first field is "pub" or "uid", the second field shows you the
-    trust:
-
-    [H pre]
-     o = Unknown (this key is new to the system)
-     e = The key has expired
-     q = Undefined (no value assigned)
-     n = Don't trust this key at all
-     m = There is marginal trust in this key
-     f = The key is full trusted
-     u = The key is ultimately trusted; this is only used
-         for keys for which the secret key is also available.
-     r = The key has been revoked
-     d = The key has been disabled
-    [H/pre]
-
-    The value in the "pub" record is the best one of all "uid" records.
-    You can get a list of the assigned trust values (how much you trust
-    the owner to correctly sign another person's key) with:
-
-    [H pre]
-     gpg --list-ownertrust
-    [H/pre]
-
-    The first field is the fingerprint of the primary key, the second
-    field is the assigned value:
-
-    [H pre]
-     - = No Ownertrust value yet assigned.
-     n = Never trust this keyholder to correctly verify others signatures.
-     m = Have marginal trust in the keyholders capability to sign other
-         keys.
-     f = Assume that the key holder really knows how to sign keys.
-     u = No need to trust ourself because we have the secret key.
-    [H/pre]
-
-    Keep these values confidential because they express your opinions
-    about others. PGP stores this information with the keyring thus it
-    is not a good idea to publish a PGP keyring instead of exporting the
-    keyring. GnuPG stores the trust in the trustdb.gpg file so it is okay
-    to give a gpg keyring away (but we have a --export command too).
-
-<Q> What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
-
-    This is the internal representation of a user ID in the trustdb.
-    "C26EE891" is the keyid, "298" is the local ID (a record number in
-    the trustdb) and "09FB" is the last two bytes of a ripe-md-160 hash
-    of the user ID for this key.
-
-<Q> How do I interpret some of the informational outputs?
-
-    While checking the validity of a key, GnuPG sometimes prints some
-    information which is prefixed with information about the checked
-    item.
-
-    [H pre]
-     "key 12345678.3456"
-    [H/pre]
-
-    This is about the key with key ID 12345678 and the internal number
-    3456, which is the record number of the so called directory record
-    in the trustdb.
-
-    [H pre]
-     "uid 12345678.3456/ACDE"
-    [H/pre]
-
-    This is about the user ID for the same key. To identify the user ID
-    the last two bytes of a ripe-md-160 over the user ID ring is printed.
-
-    [H pre]
-     "sig 12345678.3456/ACDE/9A8B7C6D"
-    [H/pre]
-
-    This is about the signature with key ID 9A8B7C6D for the above key
-    and user ID, if it is a signature which is direct on a key, the user
-    ID part is empty (..//..).
-
-<Q> Are the header lines of a cleartext signature part of the signed
-    material?
-
-    No. For example you can add or remove "Comment:" lines. They have
-    a purpose like the mail header lines. However a "Hash:" line is
-    needed for OpenPGP signatures to tell the parser which hash
-    algorithm to use.
-
-<Q> What is the list of preferred algorithms?
-
-    The list of preferred algorithms is a list of cipher, hash and
-    compression algorithms stored in the self-signature of a key during
-    key generation. When you encrypt a document, GnuPG uses this list
-    (which is then part of a public key) to determine which algorithms
-    to use. Basically it tells other people what algorithms the
-    recipient is able to handle and provides an order of preference.
-
-<Q> How do I change the list of preferred algorithms?
-
-    In version 1.0.7 or later, you can use the edit menu and set the
-    new list of preference using the command "setpref"; the format of
-    this command resembles the output of the command "pref". The
-    preference is not changed immediately but the set preference will
-    be used when a new user ID is created. If you want to update the
-    preferences for existing user IDs, select those user IDs (or select
-    none to update all) and enter the command "updpref". Note that the
-    timestamp of the self-signature is increased by one second when
-    running this command.
-
-
-<S> ACKNOWLEDGEMENTS
-
-    Many thanks to Nils Ellmenreich for maintaining this FAQ file for
-    a long time, Werner Koch for the original FAQ file, and to all
-    posters to gnupg-users and gnupg-devel. They all provided most
-    of the answers.
-
-    Also thanks to Casper Dik for providing us with a script to generate
-    this FAQ (he uses it for the excellent Solaris2 FAQ).
-
-[H HR]
-
-Copyright (C) 2000-2002 Free Software Foundation, Inc.,
-59 Temple Place - Suite 330, Boston, MA 02111, USA
-
-Verbatim copying and distribution of this entire article is permitted in
-any medium, provided this notice is preserved.
diff --git a/doc/fr/ChangeLog b/doc/fr/ChangeLog
deleted file mode 100644
index 167093dcc..000000000
--- a/doc/fr/ChangeLog
+++ /dev/null
@@ -1,17 +0,0 @@
-2001-09-10 Gilbert Fernandes <gilbertf@posse-press.com>
-
-	* Traduction en français des documents doc/*
-
-
-Copyright 2001 Free Software Foundation, Inc.
-
-Ce fichier est un logiciel libre ; l'auteur vous donne une autorisation
-spéciale de copies illimitées et/ou distribution illimitée avec ou sans
-modifications attendu que cette notice de copyright et note associée
-se trouve conservée dans le document.
-
-This file is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
-implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-
diff --git a/doc/fr/DETAILS b/doc/fr/DETAILS
deleted file mode 100644
index 5c7246c9d..000000000
--- a/doc/fr/DETAILS
+++ /dev/null
@@ -1,945 +0,0 @@
-
-Format des listings "---with-colons"
-====================================
-
-sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
-ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
-
- 1. Champ:  Type d'enregistrement
-	    pub = clef publique
-	    sub = sous-clef (clef secondaire)
-	    sec = clef secrète
-	    ssb = sous-clef secrète (clef secondaire)
-	    uid = id d'utilisateur (seul le champ 10 est utilisé)
-            sig = signature
-	    fpr = fingerprint: (le champ 10 est le fingerprint)
-	    pkd = données publiques de la clef
-		(champ au format spécial, voir ci-dessous)
-
- 2. Champ:  Une lettre décrivant la confiance calculée. Ce n'est qu'une
-	seule lettre, mais elle fera peut-être l'objet d'une information
-	supplémentaire pour les versions futures, comme décrit ici
-	(ceci ne sera pas utilisé pour les clefs privées)
-		o = Inconnu (cette clef est nouvelle au système)
-                i = La clef est invalide (eg. il manque sa propre signature)
-		d = La clef a été désactivée
-		r = La clef a été révoquée
-		e = La clef a expiré
-		q = Non-défini (pas de valeur attribuée)
-		n = Ne jamais faire confiance à cette clef
-		m = Cette clef dispose d'une confiance marginale
-		f = Cette clef dispose d'une confiance totale
-		u = Cette clef dispose d'une confiance ultime. Cette valeur
-			n'est utilisée que pour les clefs où la clef secrète est
-			également disponibles.
- 3. Champ:  taille de la clef en bits.
- 4. Champ:  Algorithme utilisé:	1 = RSA
-		       16 = ElGamal (chiffrement uniquement)
-		       17 = DSA (parfois appellé DH, signature seulement)
-		       20 = ElGamal (signe et chiffre)
-	    (pour d'autres is, consultez include/cipher.h)
- 5. Champ:  ID de clef (KeyID)
- 6. Champ:  Date de création (en UTC)
- 7. Champ:  Date d'expiration de la clef, vide si aucune.
- 8. Champ:  ID local : numéro d'enregistrement du répertoire dans la
-			trustdb. Cette valeur n'est valide que tant que la
-			trustdb n'est pas effacée. Vous pouvez utiliser
-			"#<local-id>" comme id d'utilisateur lorsque vous spécifiez
-			la clef. Ceci est requis puisque les id de clef ne sont pas
-			toujours uniques - un programme peut donc utiliser ce numéro
-			pour accéder aux clefs ultérieurement.
- 9. Champ:  Confiance propre (clef publiques primaires uniquement)
-	    C'est une simple lettre, mais une information supplémentaire pourrait
-		se voir ajoutée dans les versions futures.
-10. Champ:  ID utilisateur. La valeur est placée entre guillemets comme une
-		chaîne en C, par exemple : "\x3a".
-11. Champ:  Classe de signature. C'est un nombre hexadécimal à deux chiffres
-		suivi par la lettre "x" si la signature peut être exportée ou la
-		lettre "l" si la signature est uniquement locale.
-12. Champ:  Capacités de la clef :
-                e = chiffrement
-                s = signature
-                c = certification
-            Une clef peut disposer de toute combinaison de ces caractéristiques.
-		La clef primaire dispose, en plus de ces lettres, une version en
-		majuscule des lettres pour marquer les capacités "d'utilisation"
-		de la totalité de la clef.
-
-Toutes les dates sont affichées dans le format :
-
-yyyy-mm-dd
-
-Sauf si vous utilisez l'option --fixed-list-mode où dans ce cas précis les
-dates sont affichées en secondes depuis Epoch. Plus de champs feront l'objet
-d'additions dans les futures versions et les parsers doivent y être préparés.
-Lorsque le parser traitera ces données, il devra s'arrêter au premier
-caractère non-numérique afin que des informations supplémentaires soient
-ajoutées à l'avenir.
-
-Le champ 1 dispose d'un tag "pkd" dont le listing ressemble à ceci :
-
-pkd:0:1024:B665B1435F4C2 .... FF26ABB:
-    !  !   !-- la valeur
-    !  !------ indicateur du nombre de bits de la valeur
-    !--------- index (eg. DSA va de 0 à 3 : p,q,g,y)
-
-
-
-Format de la sortie "--status-fd"
-=================================
-
-Chaque ligne dispose d'un préfixe :
-
-"[GNUPG:] "
-
-Suivie par un mot clef indiquant le type de la ligne de statut,
-et quelques arguments selon le type (probablement aucun) ; une application
-devrait toujours assumer que des arguments supplémentaires seront
-présents dans les versions futures.
-
-    GOODSIG	<long keyid>  <username>
-	La signature keyid est valide.
-	Pour chaque signature seul l'un des trois codes GOODSIG, BADSIG ou
-	ERRSIG seront produits et ils pourront être utilisés comme
-	marqueurs pour les nouvelles signatures.
-
-    BADSIG	<long keyid>  <username>
-	La signature keyid n'a pas été vérifiée correctement.
-
-    ERRSIG  <long keyid>  <pubkey_algo> <hash_algo> \
-	    <sig_class> <timestamp> <rc>
-	Il n'a pas été possible de vérifier la signature. Ceci peut provenir
-	d'une clef publique manquante, ou bien à cause d'un algorithme non-
-	supporté. Un RC de 4 indique un algorithme inconnu, un 9 indique
-	une clef publique manquante. Les autres champs donnent plus d'information
-	sur la signature. sig_class est une valeur hexadécimale de 2 octets.
-
-    VALIDSIG	<fingerprint in hex> <sig_creation_date> <sig-timestamp>
-	La signature keyid est valide. C'est ici la même chose que GOODSIG
-	mais avec le fingerprint comme argument. Les lignes de statut seront
-	émises pour une bonne signature.
-	sig-timestamp est la date de création de la signature en secondes
-	depuis Epoch.
-
-    SIG_ID  <radix64_string>  <sig_creation_date>  <sig-timestamp>
-	N'est émis que pour les signatures de classe 0 ou 1 qui ont été
-	vérifiées comme valides. Le chaîne est un identifiant d'utilisateur
-	et peut être utilisée dans les applications pour détecter les
-	attaques par rejeu de messages signés. Notez que seuls les
-	algorithmes DLP offrent des identifiants uniques ; les autres peuvent
-	produire des id dupliqués lorsqu'ils furent créés à la même seconde.
-
-    ENC_TO  <long keyid>  <keytype>  <keylength>
-	Le message est chiffré avec ce keyid.
-	keytype est une valeur numérique de l'algorithme à clef publique,
-	keylength est la taille de la clef ou 0 si elle n'est pas connue
-	(ce qui est toujours le cas).
-
-    NODATA  <what>
-	Aucune donnée n'a été trouvée. Les codes suivants sont utilisés :
-	    1 - Pas de données sous ARMOR.
-	    2 - Un paquet attendu n'a pas été trouvé.
-	    3 - Paquet invalide trouvé ; ceci peut indiquer un message
-		non-OpenPGP. Vous devez vous attendre à une extension
-		de ces lignes de statu à l'avenir.
-
-    UNEXPECTED <what>
-        Des données innatendues ont été rencontrées
-            0 - pas de détail supplémentaire
-
-    TRUST_UNDEFINED
-    TRUST_NEVER
-    TRUST_MARGINAL
-    TRUST_FULLY
-    TRUST_ULTIMATE
-	Pour les signatures valides, l'une de ces lignes de statut sera produite
-	pour indiquer le niveau de confiance attribué à la clef. Pas d'arguments
-	pour l'instant.
-
-    SIGEXPIRED
-	La clef de signature a expiré. Pas d'arguments pour l'instant.
-
-    KEYREVOKED
-	L'utilisateur a révoqué sa clef. Pas d'arguments pour l'instant.
-
-    BADARMOR
-	L'ARMOR ASCII est corrompu. Pas d'arguments pour l'instant.
-
-    RSA_OR_IDEA
-	Les algorithmes IDEA ont été utilisés sur les données. Un programme
-	pourra basculer sur un autre programme de traitement si GnuPG échoue.
-	Ce message de statut sera affiché pour le RSA aussi, mais ceci a été
-	abandonné puisque le brevêt sur le RSA a expiré.
-	Toutefois, nous ne pouvons modifier le nom du message.
-
-    SHM_INFO
-    SHM_GET
-    SHM_GET_BOOL
-    SHM_GET_HIDDEN
-
-    GET_BOOL
-    GET_LINE
-    GET_HIDDEN
-    GOT_IT
-
-    NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength>
-	Sera affiché à chaque fois qu'une phrase passe sera requise.
-	keytype est la valeur numérique de l'algorithme à clef publique
-	ou bien 0 si cela n'est pas applicable. keylength est la taille de la
-	clef ou 0 si la taille n'est pas connue (ceci est actuellement
-	toujours le cas).
-
-    NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash>
-	Affiché à chaque fois qu'une phrase passe pour un chiffrement
-	symétrique sera requise.
-
-    MISSING_PASSPHRASE
-	Aucune phrase passe n'a été fournie. Une application qui rencontre
-	ce message devrait stopper immédiatement le parsing car le prochain
-	message sera probablement BAD_PASSPHRASE. Toutefois, si l'application
-	n'est qu'un wrapper autour de la fonctionnalité d'édition de clefs,
-	ceci pourrait avoir un autre sens et stopper le parsing pourrait
-	être incorrect, et il faudra ignorer le BAD_PASSPHRASE.
-
-    BAD_PASSPHRASE <long keyid>
-	La phrase passe fournie est soit invalide, soit n'a pas été fournie.
-	Dans le seconde cas vous devriez voir un MISSING_PASSPHRASE.
-
-    GOOD_PASSPHRASE
-	La phrase passe fournie est valide et le matériel de clefs secrète
-	est utilisable.
-
-    DECRYPTION_FAILED
-	La déchiffrement symétrique a échoué. Il s'agit généralement d'une
-	mauvaise phrase passe ne correspondant pas au message chiffré.
-
-    DECRYPTION_OKAY
-	Succès du déchiffrement. Ceci signifie que soit la clef secrète
-	adaptée a été utilisée avec succès, soit que la phrase passe
-	valide pour un chiffrement symétrique aura conduit au déchiffrement.
-	Le programme pourait toutefois renvoyer un message d'erreur s'il
-	n'a pas été possible de vérifier la signature.
-
-    NO_PUBKEY  <long keyid>
-    NO_SECKEY  <long keyid>
-	La clef n'est pas utilisable.
-
-    IMPORTED   <long keyid>  <username>
-	Le keyid et la signature ont été importés.
-
-    IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
-	<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
-	Statistiques finales sur le processus d'importation (cette ligne est longue!)
-
-    FILE_START <what> <filename>
-	Début de traitement du fichier <filename>. <what> indique l'opération
-	réalisée :
-	    1 - vérifier
-
-    FILE_DONE
-	Marque la fin de traitement d'un fichier, ayant débuté avec FILE_START.
-
-    BEGIN_DECRYPTION
-    END_DECRYPTION
-	Marque le début et la fin du processus de déchiffrement. Ces messages
-	seront également produits lors de l'utilisation du mode --list-only.
-
-    BEGIN_ENCRYPTION
-    END_ENCRYPTION
-	Marque le début et la fin du processus de chiffrement.
-
-    DELETE_PROBLEM reason_code
-	L'effacement d'une clef a échoué. Un code indique la raison de l'erreur :
-	    1 - La clef spécifiée n'existe pas
-	    2 - La clef privée doit être détruite avant !
-
-    PROGRESS what char cur total
-	Utilisé par les fonctions primegen et de clef publique pour indiquer
-	la progression de l'opération. "char" est le caractère affiché sans
-	--status-fd avec les retours à la ligne marqués par "X". "cur" indique
-	la quantitité de traitement terminée et "total" indique la valeur
-	finale à atteindre. Un total de 0 indique que le total n'est pas
-	connu. 100/100 peut être utilisé pour détecter la fin de l'opération.
-
-    SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
-	Une signature a été créée à l'aide de ces paramètres.
-	    type:  'D' = détachée
-		   'C' = en texte clair
-		   'S' = standard
-		   (seul le premier caractère doit être vérifié)
-	    class: 2 chiffres hexadécimaux avec la classe de signature
-        
-    KEY_CREATED <type>
-        Une clef a été créée
-            type: 'B' = primaire et sous-clef
-                  'P' = primaire
-                  'S' = sous-clef
-
-    SESSION_KEY  <algo>:<hexdigits>
-	La clef de session utilisée pour déchiffrer le message. Ce message
-	sera seulement affiché si l'option --show-session est utilisée.
-	Le format est utilisable pour un passage direct à la fonction
-	--override-session-key.
-
-    NOTATION_NAME <name> 
-    NOTATION_DATA <string>
-	Le nom et la chaîne sont "escaped" à l'aide de %XX et les données
-	peuvent être découpées sur plusieurs lignes notation_data.
-
-    USERID_HINT <long main keyid> <string>
-	Donne un indice sur l'ID utilisateur pour un keyID donné.
-
-    POLICY_URL <string>
-	La chaîne est "escaped" en %XX
-
-    BEGIN_STREAM
-    END_STREAM
-	Produit par pipemode.
-
-
-Génération de clef
-==================
-
-La génération de clef marque sa progression à l'aide de différents caractères, dont
-voici la signification :
-
-"." : les 10 derniers tests Miller-Rabin ont échoué.
-"+" : réussite du test Miller-Rabin.
-"!" : Rechargement du pool avec des nombres premiers frais.
-"^" : Vérification d'une nouvelle valeur pour le générateur.
-"<" : La taille d'un facteur a été réduite.
-">" : La taille d'un facteur a été augmentée.
-
-Le nombre premier pour l'ElGamal est généré de la manière suivante :
-
-1. On crée un nombre premier q de 160, 200 ou 240 bits (selon la taille
-	de la clef).
-2. On sélectionne la taille de l'autre facteur premier, afin qu'elle soit
-	au moins de la taille de q et on calcule le nombre de facteurs premiers
-	requis.
-3. On crée un pool de nombres premiers, chacun dont la longueur fut déterminée
-	à l'étape 2.
-4. On obtient une nouvelle permutation du pool et nous continuons avec
-	l'étape 3 une fois toutes les permutations testées.
-5. Le premier cancidat est calculé par p = 2 * q * p[1] * ... * p[n] + 1
-6. On vérifie que ce premier dispose de la taille désirée (ceci peut changer
-	q s'il ne semble pas possible de produire un premier de la taille voulue)
-7. On vérifie si ce nombre est premier à l'aide de divisions d'essai et par
-	le test de Miller-Rabin.
-8. On continue à l'étape 4 si on n'a pas trouvé de premier à l'étape 7.
-9. On trouve un générateur pour ce premier.
-
-Cet algorithme se base sur la suggestion de Lim et Lee du Crypto' 97 (p. 260).
-
-Génération de clef innatendue
-=============================
-
-Cette fonction est actuellement expérimentale et permet la production de
-clefs innatendues avec un contrôle depuis un fichier de paramètres.
-Cette fonctionnalité n'a pas fait l'objet de tests poussés ! Veuillez ne
-PAS vous plaindre si nous décidons d'apporter des modifications importantes
-à cette commande.
-
-Pour utiliser cette fonctionnalité, vous devez utiliser --gen-key en
-combinaison avec --batch et fournir les paramètres soit depuis stdin,
-soit depuis un fichier dont le nom est fourni en ligne de commande.
-
-Ce fichier devra utiliser le format suivant :
-
- o En texte uniquement, chaque ligne étant limitée à environ 1000 caractères.
- o Vous devez utiliser un codage UTF-8 pour marquer les caractères non ASCII.
- o Les lignes vides seront ignorées.
- o Les espaces en début et fin de ligne seront ignorés.
- o Un signe "-" en tant que premier caractère "non white space" marque
-	une ligne de commentaire.
- o Les commandes sont marquées par un signe "%" en début de ligne,
-	suivi par la commande et ses arguments sont séparés par des espaces.
- o Les paramètres sont indiqués par un mot clef, suivi par un ":". Les
-	arguments sont séparés par des espaces.
- o Le premier paramètre doit être "Key-Type" et ses contrôles peuvent
-	être placés à votre discrétion.
- o La génération de clef aura lieu soit à la fin du fichier de paramètres,
-	soit lorsque le premier "Key-Type" est rencontré au sein du fichier,
-	dans un ensenble de contrôle "%commit".
- o Les ensembles de contrôle sont :
-	%echo <texte>
-	Affiche <texte>
-
-	%dry-run
-	Ne réalise pas la production de clef (pratique pour vérifier la
-	syntaxe).
-
-	%commit
-	Réalise la production de clef. Un commit implicite est produit
-	à chaque rencontre de "Key-Type".
-
-    %pubring <filename>
-    %secring <filename>
-	Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring
-	indiqué en ligne de commande, mais vers le fichier <filename>. Ce
-	contrôle doit être utilisé avant que le commit ne soit rencontré.	
-	Toute double mention sera ignorée et le dernier nom de fichier
-	rencontré sera celui utilisé. Le fichier sera utilisé jusqu'à ce
-	qu'un nouveau fichier soit spécifié (au points de commit) sinon
-	toutes les clefs seront placées dans le même fichier. Si un nouveau
-	nom de fichier est indiqué, le fichier sera créé (et tout ancien
-	fichier sera alors écrasé). Les deux indications doivent être
-	fournies au contrôle.
-
- o L'ordre des paramètres n'a pas d'importance, sauf pour "Key-Type" qui
-	doit être le premier paramètre rencontré. Les paramètres ne sont
-	destinés qu'au bloc keybloc généré et les paramètres des productions
-	précédentes de clefs ne seront pas pris en compte. Certaines
-	vérifications syntaxiques seront mises en place et peuvent être
-	ou non actives. Les paramètres actuellement définis sont :
-
-     Key-Type: <algo-number>|<algo-string>
-	Débute un nouveau bloc de paramètres indiquant le type de la clef
-	primaire à produire. L'algorithme doit être capable de produire
-	des signatures. Ce paramètre est indispensable !
-
-     Key-Length: <length-in-bits>
-	Indique la taille de la clef, en bits. La valeur par défaut est
-	1024.
-
-     Subkey-Type: <algo-number>|<algo-string>
-	Permet de produire une clef secondaire. Actuellement, seule une
-	sous-clef peut être gérée.
-
-     Subkey-Length: <length-in-bits>
-	Taille de la sous-clef en bits. La valeur par défaut est
-	1024.
-
-     Passphrase: <string>
-	Si vous souhaitez spécifier une phrase passe pour la clef
-	secrète vous pouvez utiliser cette commande. Par défaut,
-	aucune phrase passe ne sera associée aux clefs privées.
-
-     Name-Real: <string>
-     Name-Comment: <string>
-     Name-Email: <string>
-	Voici les trois composantes d'une clef. Vous devez ici
-	n'utiliser que de l'UTF-8. Si vous ne fournissez aucune
-	de ces indications, aucun ID d'utilisateur ne sera créé.
-
-     Expire-Date: <iso-date>|(<number>[d|w|m|y])
-	Spécifie la date d'expiration de la clef (et de sa sous-clef)
-	La date doit être entrée sous la forme d'une date au format
-	ISO (année-mois-jour) ou bien sous forme d'un nombre de
-	jours, de semaines, de mois ou d'années. Si vous n'utilisez
-	pas de lettre pour indiquer la durée, des "jours" sont
-	assumés par défaut.
-
-Voici un exemple :
-$ cat >foo <<EOF
-     %echo Génération d'une clef standard
-     Key-Type: DSA
-     Key-Length: 1024
-     Subkey-Type: ELG-E
-     Subkey-Length: 1024
-     Name-Real: Joe le testeur
-     Name-Comment: ma phrase passe est stupide
-     Name-Email: joe@foo.bar
-     Expire-Date: 0
-     Passphrase: abc
-     %pubring foo.pub
-     %secring foo.sec
-     # Un commit est requis ici, pour pouvoir afficher un "done" :-)
-     %commit
-     %echo done
-EOF
-$ gpg --batch --gen-key -a foo
- [...]
-$ gpg --no-default-keyring --secret-keyring foo.sec \
-				  --keyring foo.pub --list-secret-keys
-/home/wk/work/gnupg-stable/scratch/foo.sec
-------------------------------------------
-sec  1024D/915A878D 2000-03-09 Joe le testeur (ma phrase passe est stupide) <joe@foo.bar>
-ssb  1024g/8F70E2C0 2000-03-09
-
-
-
-Composition de la TrustDB
-=========================
-
-La TrustDB est construire à partir d'enregistrements à taille fixe, où le premier
-octet décrit le type d'enregistrement. Toutes les valeurs numériques sont
-conservées dans un réseau d'ordre d'octets. La longueur de chaque enregistrement
-est de 40 octets. Le premier enregistrement de la TrustDB est toujours de type 1
-et c'est le seul enregistrement de ce type.
-
-  Record type 0:
-  --------------
-
-	Cet enregistrement n'est pas utilisé. Il peut être utilisé
-	à votre discrétion.
-
-  Record type 1:
-  --------------
-
-	Indique la version de la TrustDB. Cet enregistrement doit toujours être
-	le premier enregistrement de la base de données et c'est le seul
-	enregistrement de type 1.
-
-     1 octet valeur : 1
-     3 octets 'gpg'  valeur "magic"
-     1 octet Version de la TrustDB (2)
-     1 octet marginales requises
-     1 octet complètes requises
-     1 octet max_cert_depth
-
-	Ces trois éléments sont utilisés pour vérifier si la valeur de validité
-	mise en cache dans l'enregistrement du répertoire peut être utilisée :
-
-     1 u32  locked flags
-     1 u32  datation de la création de la trustdb
-     1 u32  datation de la dernière modification
-
-	Cette datation pourrait affecter la validité des clefs dans la base de
-	données. Cette valeur sera comparée à celle de la datation de validité
-	des enregistrements dir :
-
-     1 u32  datation de la dernière validation
-
-	Cette valeur sera utilisée pour stocker le passage du temps, lorsque
-	cette TrustDB sera comparée au trousseau de clefs publiques :
-
-     1 u32  numéro de l'enregistrement du keyhashtable
-     1 u32  premier enregistrement libre
-     1 u32  numéro de l'enregistrement répertoire shadow de la table de hachage
-
-	Cette table ne devrait pas être combinée avec la table de clefs car le
-	keyid n'est pas dans chaque cas un élément du fingerprint.
-
-     4 bytes réservés pour l'enregistrement d'extension de version
-
-
-  Record type 2: (enregistrement répertoire)
-  --------------
-
-	Regroupe les informations sur un certificat de clef publique.
-	Ces valeur sont statiques et ne sont jamais modifiées sans une
-	interaction avec l'utilisateur :
-
-     1 octet valeur : 2
-     1 octet  réservé
-     1 u32   LID     .	(numéro d'enregistrement de cet enregistrement)
-     1 u32   Liste de key-records (le premier est la clef primaire)
-     1 u32   Liste de uid-records
-     1 u32   cache record
-     1 octet  ownertrust
-     1 octet  dirflag
-     1 octet  validité maximale de tous les id utilisateurs
-     1 u32   datation de la dernière vérification de validité
-     1 u32   Vérification requise lorsque cette datation sera atteinte
-	     (0 = pas de vérification requise)
-
-
-  Record type 3:  (enregistrement de clef)
-  --------------
-
-	Regroupe les informations sur une clef publique primaire.
-	(ces informations sont principalement utilisées pour réaliser les lookup
-	dans l'enregistrement trust)
-
-     1 octet valeur : 3
-     1 octet  réservé
-     1 u32   LID
-     1 u32   next   - prochain enregistrement
-     7 octets réservés
-     1 octet  keyflags
-     1 octet  algorithme de la clef publique
-     1 octet  taille du fingerprint (en octets)
-     20 octets fingerprint de la clef publique
-	      (Cette valeur est utilisée pour identifier toute clef)
-
-  Record type 4: (enregistrement uid)
-  --------------
-
-	Regroupe les informations sur un id utilisateur (un "uid").
-	Nous ne stockons par l'uid mais un hachage de l'uid : cela semble suffire.
-
-     1 octet valeur : 4
-     1 octet réservé
-     1 u32  LID  pointe vers l'enregistrement directory
-     1 u32  next   le userid suivant
-     1 u32  pointeur vers l'enregistrement preference
-     1 u32  siglist  liste de signatures valides
-     1 octet uidflags
-     1 octet validité de la clef calculée pour cet userid
-     20 bytes ripemd160 hachage du nom de l'utilisateur
-
-
-  Record type 5: (enregistrement pref)
-  --------------
-
-	Regroupe les informations formant les préférences.
-
-     1 octet valeur : 5
-     1 octet   réservé
-     1 u32  LID; pointe vers l'enregistrement directory (et PAS vers le uid !!!)
-	    (égal à 0 pour un enregistrement de préférences standard)
-     1 u32  suivant
-     30 byte données de préférences
-
-  Record type 6  (sigrec)
-  -------------
-
-	Cet enregistrement est utilisé pour traquer les signatures de clefs. Les
-	auto-signatures ne sont pas conservées. Si une clef publique ne se trouve
-	pas dans la TrustDB, la signature pointe vers un enregistrement dir fantôme,
-	lequel contient une liste des enregistrements qui seraient intéressés
-	par cette clef (et l'enregistrement signature en fait partie).
-
-     1 octet   valeur : 6
-     1 octet   réservé
-     1 u32    LID	    pointe en retour vers l'enregistrment dir
-     1 u32    next   prochain sigrec de cet uid ou bien 0 pour indiquer que ce
-					sigrec est le dernier.
-     6 times
-	1 u32  Local_id des dir signatures ou de l'enregistrement dir fantôme
-	1 octet Flag: Bit 0 = vérifié: Bit 1 est valide (nous avons un
-				véritable enregistrement directory)
-			 1 = valide est vrai (mais pourrait être révoqué)
-
-
-
-  Record type 8: (enregistrement répertoire (dir) fantôme)
-  --------------
-
-	Cet enregistrement est utilisé pour réserver un LID pour une clef publique.
-	Nous avons besoin de cet enregistrement pour créer les enregistrements sigs
-	des autres clefs, même si nous ne disposons pas d'une signature de la clef
-	publique.
-	Cet enregistrement (le numéro d'enregistrement pour être plus précis)
-	sera réutilisé dans l'enregistrement dir lorsque nous importerons la
-	véritable clef publique.
-
-     1 octet valeur : 8
-     1 octet  réservé
-     1 u32   LID      (Ceci est simplement le numéro d'enregistrement de ce record.)
-     2 u32   keyid
-     1 octet  algorithme de la clef publique
-     3 octets réservé
-     1 u32   hintlist
-
-	hintlist contient la liste des enregistrements qui ont des références qui pointent
-	vers cette clef. Nous utilisons cet élément pour augmenter la vitesse d'accès
-	des enregistrements de signature qui ne sont pas encore vérifiés. Notez que ces
-	données ne sont qu'un indice, une indication ("hint") mais les enregistrements actuels	
-	pourraient ne pas détenir d'enregistrement de signature pour la clef, mais le
-	code du programme saura prendre soin de tout cela.
-
-    18 octets réservés
-
-
-
-  Record Type 10 (table de hachage)
-  --------------
-
-	Comme nous utilisons les fingerprint pour accéder aux clefs, nous devons
-	implémenter un accès rapide en utilisant des méthodes de hachages simples,
-	afin d'éviter une surcharge de gdbm. La propriété des fingerprint
-	est qu'ils permettent un usage direct en tant que valeurs hachées (ils
-	peuvent être considérés comme des nombres aléatoires cryptographiquement
-	forts).
-	Nous utilisons une architecture à multiples niveaux dynamique, qui combine
-	les tables de hachage, les listes d'enregistrements et les listes
-	chaînées.
-
-	Cet enregistrement est une table de hachages de 256 entrées ; une propriété
-	spéciale est que tous les enregistrements sont stockés consécutivement
-	pour produire une grande table. La valeur hachée est simplement le 1er,
-	2nd.. octet du fingerprint (selon le niveau d'indirection).
-
-	Lorsque nous les utilisons pour hacher les enregistrements de répertoires
-	shadow, une différente table est utilisée, et elle se trouve indexée
-	par le keyid.
-
-     1 octet valeur : 10
-     1 octet réservé
-     n u32  recnum; n dépend de la taille de l'enregistrement :
-	    n = (reclen-2)/4  ce qui donne 9 pour la taille actuelle
-		d'enregistrement de 40 octets.
-
-	Le nombre total de ces enregistrements constituant la table est :
-
-	 m = (256+n-1) / n
-
-	ce qui donne 29 pour une taille d'enregistrement de 40.
-
-	Pour rechercher une clef, nous utilisons le premier octet du fingerprint
-	pour obtenir le recnum de la table de hachage et nous étudions l'enregistrement
-	adressé :
-
-	o Si cet enregistrement est une autre table de hachage, nous pouvons
-	utiliser le second octet pour indexer cette table de hachage et continuer.
-
-	o Si cet enregistrement est une liste de hachages, nous pouvons parcourir
-	toutes les entrées jusqu'à trouver la bonne.
-
-	o Si cet enregistrement est un enregistrement de clef, nous comparons
-	le fingerprint avec celui recherché et nous déterminons s'il s'agit
-	de la clef recherchée.
-
-
-
-  Record type 11 (liste hachée)
-  --------------
-
-	Consultez la table hachée pour une explication.
-	Ceci sera également utilisé à d'autres fins.
-
-    1 octet valeur : 11
-    1 octet réservé
-    1 u32  next 	 enregistrement de liste hachée suivant
-    n times		 n = (reclen-5)/5
-	1 u32  recnum
-
-	Pour la taille actuelle utilisée par les enregistrements (taille 40) nous avons n = 7.
-
-
-
-
-  Record type 254 (enregistrement libre)
-  ---------------
-
-Tous ces enregistrements forment une liste chaînée d'enregistrements non-utilisés.
-
-     1 octet  valeur 254
-     1 octet  réservé (0)
-     1 u32   next_free
-
-
-
-En-têtes de paquets
-===================
-
-GnuPG utilise des en-têtes PGP 2 et il est aussi capable de comprendre
-les en-têtes de type OpenPGP. C'est une amélioration utilisée sur les anciens
-en-têtes de paquets :
-
-Les CTB bits 10, les "packet-length length bits" ont leurs valeurs listées
-dans la table suivante :
-
-      00 - 1-octet champ packet-length
-      01 - 2-octets champ packet-length
-      10 - 4-octets champ packet-length
-      11 - pas de taille de paquet fournie, taille inconnue
-
-Comme indiqué dans cette table, selon la taille du packet-length les
-octets restants (1, 2, 4 ou 0) du champ de structure de paquets sont
-un "champ packet-length". Ce champ est une valeur numérique à part entière.
-La valeur du champ packet-length est définie par la valeur de la
-totalité du champ numérique.
-
-La valeur 11 est actuellement utilisée dans un cas : les données
-compressées. C''est à dire qu'un bloc de données compressées
-ressemble à : <A3 01 .. .. > où A3 est le binaire "10 1000 11" et
-produit ici un paquet de taille non-définie. L'interprétation
-correcte en est : "jusqu'à la fin de la structure englobante"
-bien qu'en fait la structure englobante soit généralement
-le fichier.
-
-+ Ceci sera modifié dans une future version, où la signification de la
-+ valeur 11 (voir ci-dessous) aura aussi sa place.
-+
-+ Une valeur de 11 pour d'autres paquets active un codage spécial
-+ de la taille, où la taille du paquet suivant ne pourra pas être
-+ déterminée avant l'écriture du paquet, en particulier ceci sera
-+ utilisé si de grande quantités de données sont à traiter dans
-+ un mode filtre.
-+
-+ Ceci fonctionne de la manière suivante : après le CTB (qui est un
-+ champ de longueur de 11) un champ marqueur sera utilisé, il indiquera
-+ alors la taille du bloc de données suivant. C'est un simple champ
-+ de deux octets (MSB en premier) contenant la quantité de données qui
-+ suivent le champ, sans inclure le champ de taille toutefois. Après
-+ ce bloc de données un autre champ de taille suivra, qui donnera la taille
-+ du bloc de données suivant. Une valeur de 0 indique une fin de paquet.
-+ La taille maximale d'un bloc de données est limitée à 65534, ce qui
-+ réserve la valeur 0xffff pour des extensions futures. Ces marqueurs de
-+ taille devront être insérés dans le flux de données avant que les
-+ données ne soient envoyées en sortie.
-+
-+ Ce champ de deux octets est largement suffisant, car l'application
-+ doit placer en tampon cette quantité de données pour précéder le
-+ marqueur de taille avant de produire une sortie. Les blocs de données
-+ d'une taille supérieure à 32 Ko n'ont aucun sens. Notez que ceci pourra
-+ également être utilisé pour les flux de données compressées, mais
-+ nous devrons alors utiliser une autre version de paquet afin de dire à
-+ l'application qu'elle ne peut assumer qu'il s'agit du dernier paquet.
-
-
-Extensions GNU à l'algorithme S2K
-=================================
-
-Le S2K mode 101 est utilisé pour identifier ces extensions.
-Après l'algorithme de hachage les trois octets "GNU" sont utilisés
-pour indiquer clairement qu'il s'agit d'extensions GNU et les octets
-qui suivent donnent le mode de protection GNU utilisé : 1000. Les
-modes définis sont :
-
-  1001 - ne pas conserver du tout de partie secrète
-
-
-
-Usage des fichiers gdbm pour les trousseaux de clefs
-====================================================
-
-La clef utilisé pour stocker le keyblock est son propre fingerprint,
-les autres enregistrements sont utilisés pour les clefs secondaires.
-Les fingerprint font toujours 20 octets où 16 bits de fingerprint
-sont suivis par 0. Le premier octet de chaque clef indique une
-information sur le type de clef :
-
-      1 = la clef est un fingerprint de 20 octets (16 octets fpr "paddés" de 0)
-	  les données sont le keyblock
-      2 = la clef est un keyid complet de 8 octets
-	  les données sont une liste de 20 octets fingerprints
-      3 = la clef est un keyid court de 4 octets
-	  les données sont une liste de 20 octets fingerprints
-      4 = la clef est une adresse email
-	  les données sont une liste de 20 octets fingerprints
-
-	Les données sont pre-appended (précédées) par un octet de type :
-
-      1 = keyblock
-      2 = liste de 20 octets fingerprints "paddés"
-      3 = liste de liste de fingerprints ("but how to we key them?")
-
-
-
-Pipemode
-========
-
-Ce mode est utilisé pour réaliser des opérations multiples avec un
-unique appel à gpg. C'est assez pratique lorsqu'il faut pouvoir vérifier
-un grand nombre de signatures. Actuellement nous n'avons qu'un support
-des signatures détachées. Ce mode est une astuce qui permet d'éviter
-de faire fonctionner gpg n en daemon mode et d'utiliser les Unix Domain
-Sockets pour lui faire passer les données. Il n'existe aucun moyen
-pratique de portabilité de ce concept sous Windows, alors nous utilisons
-des pipes simples pour faire fonctionner ce mode sous Windows. Comme nous
-n'avons aucun moyen de signaler des EOF multiples dans un pipe nous
-devons laisser le contrôle s'insérer dans le flux de données lui-même.
-Nous réalisons alors une distinction entre les données du flux et un
-état de contrôle. A son lancement, le système se trouve dans un état
-de données mais n'acceptera aucune donnée. Il attend en fait une
-transition vers un mode de contrôle qui s'obtient en envoyant un simple
-caractère '@'. Une fois dans le mode de contrôle, des commandes sont
-attendues et ces commandes sont à un octet après lequel le système
-revient au mode de données (mais cela n'implique pas qu'il acceptera
-des données immédiatement). La commande de contrôle la plus simple
-est '@' qui permet d'insérer ce caractère dans le flux de données.
-
-Voici le format que nous utilisons pour les signatures détachées :
-
-"@<"  - Début d'un nouveau flux
-"@B"  - La signature détachée suit.
-        Ceci émet le paquet de contrôle (1,'B')
-<detached_signature>
-"@t"  - Le texte signé suit. 
-        Ceci émet le paquet de contrôle (2, 'B')
-<signed_text>
-"@."  - Fin de l'opération. Le paquet de contrôle final force la
-	vérification de la signature.
-"@>"  - Fin du flux.
-
-
-
-Autres notes
-============
-
-Dans la version* 3 de version de paquet nous calculons les keyid de cette manière :
-
-RSA : les 64 bits de poids faible de n
-ELGAMAL : nous construisons un paquet de clef publique v3 (avec CTB 0x99)
-	et nous calculons une valeur hachée rmd160 à partir de ce paquet.
-	Il est utilisé comme fingerprint avec les 64 bits de poids faible
-	qui produisent le keyid.
-
-* Les certificats de révocation ne comportent qu'un paquet de signature ;
-"import" sait comment traiter ces paquets. L'idée derrière ce principe
-est de conserver une petite taille de paquet.
-
-
-
-Format des messages Keyserver
-=============================
-
-Le serveur de clef peut être contacté par un Unix Domain Socket ou via TCP.
-
-Le format des requêtes est :
-
-====
-command-tag
-"Content-length:" digits
-CRLF
-=======
-
-Où le command-tag est :
-
-NOOP
-GET <user-name>
-PUT
-DELETE <user-name>
-
-
-Le format de réponse utilisé est :
-
-======
-"GNUPG/1.0" status-code status-text
-"Content-length:" digits
-CRLF
-============
-
-suivi par <digits> octets de données.
-
-
-Les codes de statut utilisés sont :
-
-     o	1xx: Information: requête reçue, traitement en cours.
-
-     o	2xx: Succès - L'action a été reçue, comprise et acceptée.
-
-     o	4xx: Erreur client : la requête contient une erreur, mauvaise syntaxe
-		ou demande irréalisable.
-
-     o	5xx: Erreur serveur - Le serveur n'a pu traiter une demande
-		qui semble valide.
-
-
-Documentation sur HKP (le protocol de serveurs de clefs http)
-=============================================================
-
-Un serveur HTTP minimal sur port 11371 reconnaît les requêtes GET
-pour /pks/lookup. Les paramètres standard encodés URL de la requête
-sont toujours ceux-ci : (toujours key=valeur)
-
-- op=index (comme pgp -kv), op=vindex (comme pgp -kvv) and op=get (comme
-  pgp -kxa)
-
-- search=<stringlist>. Nous avons ici une liste de mots qui doivent
-	apparaître dans la clef. Ces mots sont séparés par des espaces,
-	points, @, etc. Les délimiteurs ne feront pas partie de la
-	recherche et l'ordre des mots n'a aucune importance (mais consultez
-	l'option suivante).
-
-- exact=on. Ce switch permet d'indiquer au serveur hkp qu'il ne doit
-	rechercher que les correspondances exactes. Dans ce cas, les
-	délimiteurs et l'ordre des mots sera considéré.
-
-- fingerprint=on. Renvoie également les fingerprint, lorsque utilisé
-	avec 'index' ou 'vindex'
-
-Les serveurs de clefs savent aussi reconnaître le format http-POST vers /pks/add.
-Vous utilisez ceci pour envoyer des clefs au serveur.
-
-Le mieux pour produire une requête reste :
-
-   /pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
-
-Ceci peut être implémenté en utilisant le mécanisme de traduction Hurd.
-Toutefois, nous pensons que les traitements du serveur de clef doivent
-faire l'objet d'une refonte.
diff --git a/doc/fr/FAQ b/doc/fr/FAQ
deleted file mode 100644
index 48c28ae76..000000000
--- a/doc/fr/FAQ
+++ /dev/null
@@ -1,1111 +0,0 @@
-
-GNUPG : FOIRE AUX QUESTIONS
-
-Version : 1.2
-Dernière modification : 10 septembre 2001
-Maintenu par : Nils Ellmenreich <nils 'at' gnupg.org>
-Traduction : Gilbert Fernandes <gilbertf 'at' posse-press.com>
-
-Ce document est la FAQ de GnuPG. La dernière version HTML est
-disponble ici : <http://www.gnupg.org/faq.html>
-
-L'index est produit automatiquement. Des erreurs peuvent donc
-s'y trouver. Toutes les questions ne seront pas situées dans leurs
-sections afférentes. Les suggestions quand à l'amélioration de cette
-FAQ seront les bienvenues.
-
-Veuilez envoyer vos additions et corrections au mainteneur de la FAQ.
-Il serait plus pratique si vous pouviez fournir une réponse à inclure
-directement dans la FAQ. Toute aide sera fortement appréciée.
-
-Veuillez ne pas nous envoyer de message du type : "Ceci devrait
-être une FAQ, quelle est la réponse ?". Si la réponse ne se trouve
-pas dans la FAQ c'est que la question n'a pas été considérée.
-Dans ce cas, recherchez dans les archives de la liste de
-distribution par email.
-
-
-
-
- 1. GENERAL
-   1.1) Qu'est-ce que GnuPG ?
-   1.2) GnuPG est-il compatible avec PGP ?
-
- 2. SOURCES D'INFORMATION
-   2.1) Où puis-je trouver plus d'informations ?
-   2.2) Où puis-je obtenir GnuPG ?
-
- 3. INSTALLATION 
-   3.1) Sur quels systèmes fonctionne GnuPG ?
-   3.2) Quel collecteur d'entropie dois-je utiliser ?
-   3.3) Comment puis-je inclure le support du RSA et de l'IDEA ?
-
- 4. UTILISATION
-   4.1) Quelle est la taille de clef recommandée ?
-   4.2) Pourquoi la création de clefs est-elle aussi longue ?
-   4.3) Pourquoi tout est si lent quand je travaille sur un système distant ?
-   4.4) Quelle est la différence entre options et commandes ?
-   4.5) Je ne peux pas effacer un userid car il a déjà été effacé dans mon
-	trousseau de clefs publiques ?
-   4.6) Que sont la confiance, la validité et l'ownertrust ?
-   4.7) Comment puis-je signer un fichier de patch ?
-   4.8) Où se trouve l'option "encrypt-to-self" ?
-   4.9) Comment puis-je me débarasser de la version et du champ de commentaire
-	dans la version "armor" des messages ?
-   4.10) Que signifie le message "You are using the xxxx character set" ?
-   4.11) Comment puis-je obtenir la liste des keyid ayant servi à
-	chiffrer un message ?
-   4.12) Je ne peux plus déchiffrer mon message chiffré symétriquement (-c) avec la nouvelle
-version de GnuPG ?
-   4.13) Comment puis-je utiliser GnuPG en environnement automatisé ?
-   4.14) Quel client email puis-je utiliser avec GnuPG ?
-   4.15) On ne peut pas avoir une librairie gpg ?
-   4.16) J'ai produit avec succès un certificat de révocation, mais comment dois-je
-	le transmettre aux serveurs de clefs ?
-
- 5. QUESTIONS SUR LA COMPATIBILITE
-   5.1) Comment puis-je chiffrer un message avec GnuPG pour que PGP soit capable de le déchiffrer ?
-   5.2) Comment migrer de PGP 2.x vers GnuPG ?
-   5.3) (supprimé)
-   5.4) Pourquoi PGP 5.x n'est pas capable de déchiffrer les messages pour certaines clefs ?
-   5.5) Pourquoi PGP 5.x ne peut vérifier mes messages ?
-   5.6) Comment puis-je transférer mes valeurs de confiance de PGP vers GnuPG ?
-   5.7) PGP n'aime pas ma clef privée.
-
- 6. PROBLEMES ET MESSAGES D'ERREUR
-   6.1) Pourquoi GnupG me dit sans cesse "Warning  : using insecure memory!" ?
-   6.2) Le support des fichiers de grande taille ne fonctionne pas ..
-   6.3) Dans le menu d'édition les valeurs de confiance ne sont pas affichées
-	correctement après la signature des uid : pourquoi ?
-   6.4) Que signifie "skipping pubkey 1: already loaded" ?
-   6.5) GnuPG 1.0.4 ne tient pas compte de ~/.gnupg ...
-   6.6) Une signature ElGamal ne vérifie plus rien depuis la 1.0.2 ..
-   6.7) Les anciennes versions de GnuPG ne vérifient pas les anciennes
-	signatures ElGamal
-   6.8) Lorsque j'utilise --clearsign le texte en clair comporte parfois des
-	tirets supplémentaires : pourquoi ?
-   6.9) Que signifie "can't handle multiple signatures" ?
-   6.10) Si je soumet une clef au serveur de clefs, rien ne survient !
-   6.11) J'obtiens un "gpg: waiting for lock ..."
-   6.12) Les anciennes versions de GnuPG (e.g. 1.0) ont des problèmes
-	avec les clefs de GnuPG récents ..
-   6.13) Avec GnuPG 1.0.4 j'obtiens un "this cipher algorithm is deprecated ..."
-   6.14) Les dates sont affichées par ????-??-??, pourquoi ?
-   6.15) J'ai encore un problème, dois-je produire un message de bogue ?
-   6.16) Pourquoi GnuPG ne supporte pas les certificats X.509 ?
-
- 7. SUJETS AVANCES
-   7.1) Comment tout cela fonctionne-t-il ?
-   7.2) Pourquoi certaines signatures avec une clef ELG-E sont valides ?
-   7.3) Comment tout le système de confiance fonctionne au juste ?
-   7.4) Quel est ce genre de sortie : "key C26EE891.298, uid 09FB: ...."?
-   7.5) Comment interpréter certaines sorties informatives ?
-   7.6) Les lignes d'en-tête des messages font-elles parties des éléments signés ?
-   7.7) Quelle est la liste des algorithmes préférés ?
-   7.8) Comment puis-je changer la liste des algorithmes préférés ?
-
- 8. REMERCIEMENTS
-
-
-
-1. GENERAL
-
-1.1) Qu'est-ce que GnuPG ?
-
-GnuPG signifie GNU Privacy Guard et <http://www.gnupg.org> est
-l'outil GNU destiné aux communications protégées par chiffrement,
-ainsi que le stockage protégé d'informations. Ce programme peut
-être utilisé pour chiffrer des données et produire des signatures
-numériques. Il comprend une gestion avancée des clefs et respecte
-le standard Internet proposé OpenPGP comme décrit dans le
-RFC 2440 : <http://www.gnupg.org/rfc2440.html> et il se destine
-à une parfaite compatibilité avec le PGP produit par NAI Inc.
-
-1.2) GnuPG est-il compatible avec PGP ?
-
-En règle générale, oui. GnuPG et les distributions récentes de PGP
-devraient respecter le standard OpenPGP et fonctionner de concert.
-Il existe toutefois quelques problèmes d'interopérabilité. Consultez
-les questions 5.1ff pour plus de détails.
-
-2. SOURCES D'INFORMATION
-
-2.1) Où puis-je trouver plus d'informations ?
-
-Voici une liste de ressources en ligne :
-
-<http://www.gnupg.org/docs.html>
-
-Cette page regroupe la page de documentation GnuPG. Vous pouvez consulter
-les HOWTO ainsi que le manuel de GnuPG :  le GNU Privacy Handbook
-actuellement disponible en anglais, espagnol et russe. Ce dernier offre par
-ailleurs une présentation étendue de GnuPG. Vous trouverez aussi des
-documentations expliquant la conversion de PGP 2.x vers GnuPG.
-
-<http://lists.gnupg.org> 
-
-Vous trouverez ici une archive en ligne des listes de distribution par
-courrier électronique de GnuPG. La liste la plus intéressante sera
-probablement gnupg-users où toutes les questions en rapport avec
-l'utilisation de GnuPG se trouvent rassemblées. Si le développement
-vous intéresse vous consulterez avec joie la liste gnupg-devel et
-vous pourrez également prendre contact avec les développeurs.
-
-S'IL-VOUS-PLAIT !
-
-Avant de poster sur une liste, veuillez lire avec attention la FAQ et
-toutes les documentations disponibles. D'autre part, vous devez ensuite
-consulter les archives afin de découvrir si votre question n'a pas été
-déjà posée et résolue. Vous épargnerez des pertes de temps et la
-liste pourra se concentrer sur les problèmes qui n'ont pas encore
-été résolus.
-
-La distribution des sources de GnuPG comprend également un
-sous-répertoire /doc qui contient des documentations supplémentaires
-et ces informations seront précieuses aux hackers (pas beaucoup aux
-utilisateurs habituels, sauf les plus curieux).
-
-2.2) Où puis-je obtenir GnuPG ?
-
-Vous pouvez télécharger GNU Privacy Guard depuis son FTP primaire :
-
-<ftp.gnupg.org>
-
-Ou depuis l'un des mirroirs :
-
-<http://www.gnupg.org/mirror.html>
-
-La version actuelle est la version 1.0.6 et nous vous encourageons à migrer
-vers cette version rapidement : elle corrige des bogues et améliore le
-fonctionnement du programme, ainsi que votre sécurité de fait.
-
-
-3. INSTALLATION 
-
-3.1) Sur quels systèmes fonctionne GnuPG ?
-
-GnuPG devrait fonctionner sur tous les Unices ainsi que Windows (95, 98..) et les variantes
-NT. Une liste de systèmes d'exploitation fonctionnels se trouve à :
-
-<http://www.gnupg.org/gnupg.html#supsys>
-
-3.2) Quel collecteur d'entropie dois-je utiliser ?
-
-Les "bons" générateurs de nombres aléatoires sont cruciaux pour la sécurité de vos
-chiffrements. Les différents systèmes d'exploitation proposent des valeurs
-aléatoires de qualité variable. Linux et les systèmes *BSD produisent généralement
-de bonnes valeurs grâce au /dev/random et cette méthode devrait rester la
-méthode de choix pour ces systèmes. Les utilisateurs de Solaris devraient opter
-pour pe paquetage SUNWski afin de disposer d'un /dev/random. Dans ces cas,
-vous devriez utiliser l'option --enable-static-rnd=linux. D'autre part, il existe également
-un dispositif au niveau kernel pour la production de valeurs aléatoires développé
-par Andi Maier :
-
-< http://www.cosy.sbg.ac.at/~andi>
-
-Ce logiciel est au stade de beta : vous ne l'utilisez que sous votre seule
-responsabilité !
-
-Sur les autres systèmes, l'utilisation de l'EGC ou "Entropy Gathering Daemon"
-se montre un bon choix. C'est un daemon écrit en Perl qui surveille l'activité du
-système et produit des hachages permettant d'obtenir des valeurs aléatoires.
-Vous devriez en consulter la page de téléchargement depuis :
-
-<http://www.gnupg.org/download.html>
-
-Pour l'utiliser vous devrez utiliser l'option --enable-static-rnd=egd
-
-Si les options ci-dessus ne fonctionne pas, vous pourrez utiliser le producteur
-d'entropie "unix". Il est *TRES* lent et il devrait être évité lorsque possible.
-Sa qualité d'entropie laisse vraiment à désirer et vous ne devrez jamais
-l'utiliser dans la protection de données sensibles.
-
-3.3) Comment puis-je inclure le support du RSA et de l'IDEA ?
-
-RSA se trouve inclus dans GnuPG depuis la version 1.0.3 et supérieures.
-
-La distribution officielle de GnuPG ne comprend pas l'IDEA à cause
-d'une restriction par brevêt. Le brevêt devrait expirer en 2007 et nous
-attendons cette date pour l'inclure dans GnuPG.
-
-Toutefois, il existe des modules officieux qui permettent de l'inclure
-même dans les versions de GnuPG avant cette date. Ces modules
-sont disponibles depuis :
-
-<ftp://ftp.gnupg.org/pub/gcrypt/contrib/>
-
-Recherchez 'idea.c'
-
-Les directives de compilation se trouvent dans les fichiers "headers" de
-ces fichiers. Vous pourrez ensuite ajouter la ligne suivante à votre
-fichier ~/.gnupg/options :
-
-    load-extension idea 
-
-4. USAGE
-
-4.1) Quelle est la taille de clef recommandée ?
-
-Nous vous recommandons un minimum de 1024 bits pour les clefs de type
-DSA et également pour les signatures simples de type ElGamal. La taille
-du hachage est probablement le lien le plus faible si la taille de la clef
-augmente à plus de 1024 bits. Les clefs de chiffrement peuvent avoir
-des tailles supérieures, mais vous devriez alors vérifier le fingerprint
-de la clef de cette manière :
-
-gpg --fingerprint --fingerprint <user ID>
-
-Comme pour les algorithmes de clef, vous devriez vous en tenir aux
-valeurs par défaut (i.e. les chiffrements ElGamal avec signature
-DSA). Une clef de signature ElGamal comporte les désavantages
-suivants : si la signature est grosse, il est difficile de créer une
-clef correspondante utile pour les signatures et capable de résister
-aux attaques réelles, et vous n'obtiendrez pas de sécurité
-supplémentaire face au DSA. Il pourrait y avoir des problèmes
-de compatibilité avec certaines versions de PGP. Il n'aura été
-introduit que parce à l'époque, il n'était pas clair de savoir si
-un brevêt s'appliquait ou non au DSA.
-
-4.2) Pourquoi la création de clefs est-elle aussi longue ?
-
-Le problème est ici que nous avons besoin d'une grande quantité d'octets aléatoires et que
-nous devons pour ce faire collecter une certaine quantité d'entropie depuis, sous Linux,
-le /dev/random. Il n'est pas vraiment facile de remplir l'entropie de Linux ; nous en avons
-discuté avec Ted Ts'o et il a expliqué que la meilleure méthode pour remplir le buffer
-n'est autre que de jouer avec votre clavier. Une bonne sécurité implique un coût.
-Vous pouvez utiliser les touches Shift, Control, Alt en appuyant dessus de manière aléatoire,
-d'autant que ces touches ne produisent aucune sortie à l'écran et vous pourrez accélérer
-la production des clefs.
-
-Un autre programme pourrait également consommer une partie de l'entropie du système
-dont vous avez besoin (jettez un oeil à vos daemons actifs).
-
-4.3) Pourquoi tout est si lent quand je travaille sur un système distant ?
-
-Vous ne devez SURTOUT pas faire cela ! Vous ne devez jamais créer de
-clef GnuPG sur un système distant car vous n'aurez alors aucun contrôle
-physique sur votre clef privée, ni même votre trousseau de clefs privées.
-Ces clefs seront alors suspectibles de subir une attaque par dictionnaire.
-Nous vous encourageons vivement à ne produire vos clefs que sur une
-machine personnelle (un portable déconnecté de toute alimentation
-et connexion réseau est le meilleur choix) et si vous devez conserver
-votre clef privée sur une machine fixe, assurez-vous qu'une phrase
-passe solide en protège le contenu et que vous pouvez faire confiance
-à votre administrateur système.
-
-Lorsque nous devons utiliser GnuPG à distance c'est au-travers de SSH
-et nous rencontrons le même problème. Il faut *beaucoup* de temps
-pour produire des clefs de toute manière. Il ne faut pas créer de clefs
-à distance. Si vous avez juste besoin de clefs à fins de tests, vous
-pouvez utiliser l'optoin --quick-random pour produire rapidement des
-clefs *faibles* qui permettent de vérifier quelques tests.
-
-4.4) Quelle est la différence entre options et commandes ?
-
-Si vous tapez 'gpg --help' vous obtiendrez deux listes séparées. La première
-liste vous répertorie les commandes. La seconde liste regroupe elle les
-options. A chaque fois que vous utiliserez GnuPG vous devrez utiliser
-*UNE* commande (avec une exception, voir ci-dessous) et vous pourrez
-utiliser une ou *plusieurs* options en combinaison avec la commande.
-
-Par convention, la commande doit se trouver à la fin de la liste d'arguments
-après toutes les options. Si la commande requiert un nom de fichier,
-ce dernier sera donné à GnuPG en *dernier* sur la ligne de commande.
-
-L'usage basique de GnuPG est donc :
-
-    gpg [--option something] [--option2] [--option3 something] --command file 
-
-Certaines options demandent des arguments. Par exemple, l'option
---output (que l'on peut raccourcir par -o) requiert un nom de fichier
-en argument. L'argument de l'option doit suivre celle-ci immédiatement !
-GnuPG ne sera sinon pas capable de différencier le nom de fichier comme
-option. Comme option, --output et son nom de fichier doivent se trouver
-avant la commande donnée à GnuPG. L'option --recipient (ou -r) demande
-un nom ou un keyID pour chiffrer le message et ces informations devront
-imméditamenet suivre l'option --recipient/-r. La commande --encrypt ou
--e sera fournie après ces options, avec en final le nom du fichier à
-chiffrer. En voici un exemple :
-
-    gpg -r alice -o secret.txt -e test.txt 
-
-Mais l'utilisation des options sous leur forme longue permet de simplifier
-la compréhension des lignes de commande :
-
-    gpg --recipient alice --output secret.txt --encrypt test.txt 
-
-Si vous sauvez dans un fichier nommé ".txt" alors vous devriez probablement
-utiliser l'option ARMOR en ajoutant l'option --armor ou -a qui ne prend aucun
-argument :
-
-    gpg --armor --recipient alice --output secret.txt --encrypt test.txt
-
-Si nous plaçons des crochets autour des parties optionnelles, les choses
-deviennent plus claires :
-
-    gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt 
-
-Les parties entre crochets peuvent être placées dans l'ordre de votre
-choix :
-
-    gpg --output secret.txt --recipient alice --armor --encrypt test.txt
-
-Si votre nom de fichier commence par un tiret, GnuPG risque de penser
-qu'il s'agit d'un paramètre et pour éviter cette situation vous pouvez
-soit utiliser un "./-a.txt" soit utiliser un double-tiret comme ceci :
-
--- -a.txt
-
-* L'exception concerne le chiffrement ET la signature au même moment.
-On utilise alors gpg [--options] --sign --encrypt foo.txt
-
-4.5) Je ne peux pas effacer un userid car il a déjà été effacé dans mon
-	trousseau de clefs publiques ?
-
-Comme vous ne pouvez sélectionner que depuis le trousseau de clefs
-publiques, vous ne pouvez pas directement effacer le userid. Toutefois,
-ce n'est pas très compliqué à faire. Vous devez créer un nouvel
-utilisateur, disposant du même userid ce qui vous permet d'obtenir deux
-utilisateurs identiques avec un seul disposant d'une correspondance
-dans la clef privée. Vous pouvez désormais sélectionner cet utilisateur
-et l'effacer. Les deux identifiants seront affacés du trousseau de clefs
-privées.
-
-4.6) Que sont la confiance, la validité et l'ownertrust ?
-
-Le terme "ownertrust" est utilisé en remplacement de "trust" lorsqu'il
-s'agit de la valeur que vous avez attribuée à une clef en fonction
-du degré de confiance que vous accordez à son propriétaire, et si
-vous l'autorisez à introduire de nouvelles clefs avec votre signature
-jointe. La "validité" est un terme de confiance calculée, une valeur
-numérique calculée par GnuPG en fonction des paramètres de
-confiance des clefs et vous donne une idée de la confiance que
-GnuPG attribue ou n'attribue pas à une clef et s'il estime que la clef
-est valide pour un usage de chiffrement. Pour plus de détails consultez
-le chapître "The web of trust"
-
-4.7) Comment puis-je signer un fichier de patch ?
-
-Vous pouvez utiliser :
-
-gpg --clearsign --not-dash-espaced ...
-
-Le problème avec --clearsign c'est que toutes les lignes qui
-commençent par un tiret sont "quotées" avec "- " et comme diff
-produit beaucoup de lignes de ce type, le patch risque d'être
-détruit par la signature. Pour utiliser un fichier patch en le signant
-et sans perdre la signature claire, l'option spéciale :
-
---not-dash-escaped
-
-Permet de supprimer la production de ces séquences d'échappement.
-Vous ne devriez pas transmettre par courrier électronique un patch
-de ce type car les espaces et les fins de ligne font également
-partie de la signature et un logiciel de messagerie risque de modifier
-l'espacement et/ou les tailles de lignes, invalidant la signature. Si vous
-souhaitez transmettre le fichier, le plus simple reste de le signer à l'aide
-de votre MUA.
-
-4.8) Où se trouve l'option "encrypt-to-self" ?
-
-Utilisez l'option :
-
---encrypt-to <votre_keyID>
-
-Vous pouvez utiliser une combinaison de cette option pour spécifier
-plus d'un keyID. Pour désactiver temporairement l'utilisation de clefs
-additionnelles, vous pouvez utiliser l'option : --no-encrypt-to.
-
-4.9) Comment puis-je me débarasser de la version et du champ de commentaire
-	dans la version "armor" des messages ?
-
-Utilisez l'option --no-version --comment ""
-
-Veuillez noter que la ligne vide laissée en place est *requise* par le format
-et le protocole.
-
-4.10) Que signifie le message "You are using the xxxx character set" ?
-
-Cette note est affichée lorsque une conversion UTF-8 a été réalisée.
-Veuillez vous assurer que le jeu de caractères utilisé pour l'affichage
-correspond bien à celui du système. Le plus utilisé reste "iso-8859-1" et
-c'est le jeu de caractères par défaut. Vous pouvez modifier ce jeu
-de caractères à l'aide de l'option "--charset". Il faut que le jeu de
-caractères utilisé corresponde à celui de votre affichage ou des
-caractères pourraient ne plus correspondre dans le message une
-fois transmis. Sinon, n'utilisez que de l'ASCII 7 bits pour qu'aucune
-conversion ne puisse survenir.
-
-4.11) Comment puis-je obtenir la liste des keyid ayant servi à
-	chiffrer un message ?
-
-     gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | \
-    awk '/^\[GNUPG:\] ENC_TO / { print $3 }' 
-
-4.12) Je ne peux plus déchiffrer mon message chiffré symétriquement
-	(-c) avec la nouvelle version de GnuPG ?
-
-Il existait un bogue dans les versions 1.0.1 et antérieures de GnuPG
-qui surveniait lorsque 3DES ou Twofish avaient été utilisé pour des
-chiffrements symétriques (ce qui n'a jamais été le cas par défaut).
-Ce bogue a été corrigé afin de permettre le déchiffrement des anciens
-messages, en utilisant l'option :
-
----emulate-3des-s2k-bug
-
-Vous devriez déchiffrer puis rechiffrer (correctement) le ou les
-messages concernés. Cette option sera retirée dans la version 1.1
-de GnuPG : n'attendez pas pour convertir vos messages !
-
-4.13) Comment puis-je utiliser GnuPG en environnement automatisé ?
-
-Vous devriez utiliser l'option --batch et ne pas utiliser de phrase
-passe car il n'existe alors aucun moyen de conserver cette
-information de manière plus secrète que le trousseau de clefs
-lui-même. Nous vous suggérons de créer vos clefs, en environnement
-automatisé, de la manière suivante :
-
-Sur une machine protégée :
-
-Créez une sous-clef de signature pour votre clef, en utilisant le menu
-edit et en utilisant l'option "addkeu" puis DSA. Vous devez ensuite
-vous assurer que vous utilisez une phrase passe (requise par
-l'implémentation actuelle) puis utiliser :
-
-gpg --export-secret-subkeys --no-comment foo
-    >secring.auto
-
-Copiez secring.auto et le trousseau de clefs publiques dans un
-répertoire test. Entrez dans le répertoire, puis :
-
-gpg --homedir . --edit foo
-
-Et utilisez "passwd" pour retirer la phrase passe des sous-clefs.
-Vous devriez également retirer toutes les sous-clefs qui ne sont
-pas utilisées et copier secring.auto sur une disquette et la
-porter jusqu'à la machine cible.
-
-Sur celle-ci, installez secring.auto comme trousseau de clefs
-secrètes. Vous pouvez maintenant faire démarrer votre
-nouveau service. C'est aussi une bonne idée que d'installer
-un système de détection d'intrusions afin de pouvoir repérer
-les intrusions ce qui vous permettra alors de révoquer toutes
-les sous-clefs installées sur cette machine et de procéder à une
-nouvelle installation de sous-clefs.
-
-4.14) Quel client email puis-je utiliser avec GnuPG ?
-
-Utiliser GnuPG pour le chiffrement de courrier électronique est
-probablement l'usage le plus répandu. De nombreux logiciels de
-messagerie (les "MUA") supportent GnuPG à divers degrés. Pour simplifier,
-il existe deux moyens de chiffrer les emails avec GnuPG : l'ancien style
-qui repose sur l'utilisation de l'ASCII Armor (un chiffrement classique
-suivi par une conversion selon le RFC2015) ce qu'on appellait le
-PGP/MIME et qui s'appelle désormais l'OpenPGP. Ce dernier supporte
-d'autre part le MIME. Certains MUA ne supportent qu'un seul de ces
-formats et vous devrez utiliser ce qui correspond aux capacités
-de votre client de messagerie.
-
-La liste suivante n'est probablement pas exhaustive :
-
-    OpenPGP: Mutt (Unix), Emacs/Mew, Becky2 (Windows avec plugin),
-	TkRat (Unix). Il y a un effort pour disposer d'un plug-in
-	Mozilla et Emacs/GNUS dispose d'un support en CVS.
-
-    ASCII:   Emacs/{VM,GNUS}/MailCrypt, Mutt(Unix), Pine(Unix), et
-	probablement beaucoup d'autres.
-
-Un bon aperçu du support de PGP se trouve à l'adresse :
-
-http://cryptorights.org/pgp-users/pgp-mail-clients.html
-
-Le support direct de GnuPG n'est pas indiqué, toutefois dans certains
-cas il doit être possible d'utiliser un "wrapper".
-
-4.15) On ne peut pas avoir une librairie gpg ?
-
-Cette question aura souvent été posée. Toutefois, le point de vue
-actuel est que GnuPG en tant que librairie risque de conduire à des
-problèmes de sécurité. Dans un futur proche, GnuPG ne sera pas
-implémenté sous forme de librairie. Toutefois, pour quelques domaines
-d'application le programme gpgme doit pouvoir assurer ces questions.
-Vous pouvez obtenir ce programme depuis :
-
-ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme
-
-
-4.16) J'ai produit avec succès un certificat de révocation, mais comment
-	dois-je le transmettre aux serveurs de clefs ?
-
-La plupart des serveurs de clefs n'accepteront pas une simple et "dure"
-révocation. Vous devez d'abord importer le certificat dans GnuPG :
-
-    gpg --import my-revocation.asc
-
-Puis transmettre la révocation au serveurs de clefs :
-
-    gpg --keyserver certserver.pgp.com --send-keys mykeyid
-
-5. COMPATIBILITY ISSUES 
-
-5.1) Comment puis-je chiffrer un message avec GnuPG pour que PGP
-	soit capable de le déchiffrer ?
-
-Tout ceci dépend de la version de PGP.
-
-     PGP 2.x 
-
-Vous ne pourrez pas dans ce cas, car PGP 2.x utilise l'IDEA qui n'est
-pas un algorithme supporté par GnuPG à cause de son brevêt (voir
-la section 3.3) mais si vous disposez d'une version modifiée de PGP
-vous pouvez essayer ceci :
-
-     gpg --rfc1991 --cipher-algo 3des ...  
-
-Attention ! N'utlisez pas de pipe des données à chiffrer vers gpg,
-mais donnez à gpg un nom de fichier sinon PGP 2 ne sera pas
-capable de le prendre en charge.
-
-Quand à ce qui concerne le chiffrement conventionnel, vous ne
-pouvez l'obtenir avec PGP 2.
-
-
-     PGP 5.x et ultérieurs
-
-Vous devrez utiliser deux options additionnelles :
-
-    --compress-algo 1 --cipher-algo cast5  
-
-Vous devrez parfois utiliser "3des" au lieu de "cast5". PGP 5 ne
-supporte pas l'algorithme "blowfish". Vous devrez aussi insérer
-un "compress-algo 1" au sein de votre fichier ~/.gnupg/options
-et ceci n'affectera pas le fonctionnement général de GnuPG.
-
-Ceci s'applique également au chiffrement conventionnel.
-
-5.2) Comment migrer de PGP 2.x vers GnuPG ?
-
-PGP 2 utilise les algorithmes RSA et IDEA pour le chiffrement. Depuis que le
-brevêt sur le RSA a expiré GnuPG incorpore ce dernier, depuis la version
-1.0.3 et ultérieures. L'algorithme IDEA reste sous brevêt jusqu'en 2007.
-Sous certaines conditions vous pouvez utiliser l'IDEA, même aujourd'hui.
-Dans ce cas, vous devriez consulter la réponse à la question 3.3 qui
-explique l'ajout du support de l'IDEA à GnuPG et également lire ce
-document :
-
-http://www.gnupg.org/gph/en/pgp2x.html
-
-Pour procéder à la migration.
-
-5.3) (supprimé)
-
-    (vide)
-
-5.4) Pourquoi PGP 5.x n'est pas capable de déchiffrer les messages
-	pour certaines clefs ?
-
-PGP Inc refuse d'accepter les clefs ElGamal de type 20 même pour
-le chiffrement. Ils ne supportent que le type 16 (qui est identifique en tout
-cas en ce qui concerne le déchiffrement). Pour être plus inter-opérable,
-GnuPG (depuis la version 0.3.3) utilise également le type 16 pour la sous-
-clef ElGamal qui est créée par l'algorithme par défaut. Vous pouvez
-aussi ajouter une clef de type 16 à votre trousseau de clefs publiques
-tout en assurant que vos signatures sont valides.
-
-5.5) Pourquoi PGP 5.x ne peut vérifier mes messages ?
-
-PGP 5.x n'accepte pas les signatures en version 4 pour les données
-mais OpenPGP demande la production de clefs V4 pour tous les types
-de données et c'est pourquoi GnuPG les utilise... Vous devrez utiliser
-l'option --force-v3-sigs pour produir'e des signatures V3 sur les
-données.
-
-5.6) Comment puis-je transférer mes valeurs de confiance de
-	PGP vers GnuPG ?
-
-Il existe un script au sein du répertoire tools qui pourra vous aider. Après
-avoir importé le trousseau de clefs publiques PGP vous pouvez utiliser
-cette commande :
-
-    $ lspgpot pgpkeyring | gpg --import-ownertrust 
-
-où "pgpkeyring" est le trousseau de clefs originels et NON celui de GnuPG
-que vous avez produit à la première étape.
-
-5.7) PGP n'aime pas ma clef privée.
-
-Les anciens PGP échouent parfois au traitement des commentaires privés
-sur les paquets utilisés par GnuPG. Ces paquets sont en *totale* conformité
-avec OpenPGP mais vous l'aurez compris, PGP n'est pas vraiment soucieux
-d'OpenPGP. Pour contourner ce problème il faut exporter les clefs privées
-à l'aide de cette commande :
-
-     $ gpg --export-secret-keys --no-comment -a your-key-id 
-
-Une autre possibilité : par défaut, GnuPG chiffre votre clef privée à l'aide
-de l'algorithme symétrique Blowfish. Les anciennes versions de PGP
-ne peuvent comprendre que le 3DES, CAST5 ou l'IDEA sous leurs formes
-symétriques. L'utilisation de la méthode suivante permet de rechiffrer
-vos clefs privées à l'aide d'un algorithme différent :
-
-     $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \
-          --compress-algo=1  --edit-key <username>
-
-Vous utiliserez alors l'option passwd pour modifier le mot de passe ; il suffit
-de choisir la même phrase passe mais cette fois la clef sera chiffrée
-symétriquement par du CAST5.
-
-Vous pouvez maintenant exporter la clef et PGP devrait pouvoir la gérer.
-
-Pour PGP 6.x les options suivantes permettent d'exporter une clef :
-
-     $ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 \
-           --export-secret-keys <Key-ID>
-
-6. PROBLEMS and ERROR MESSAGES
-
-6.1) Pourquoi GnupG me dit sans cesse "Warning  : using insecure memory!" ?
-
-Sur beaucoup de systèmes, ce programme doit être installé en tant que
-setuid(root). Ceci est requis afin de pouvoir produire un blocage en mémoire
-des pages utilisées (et d'éviter tout transfert en swap ou sur disque). Ce "lock"
-permet de verrouiller dans la pratique les informations sensibles en RAM
-afin de conserver ces données comme secrètes. Si vous n'obtenez aucun
-message d'erreur c'est que votre système supporte le verrouillage de pages
-mémoire depuis l'accès root (le programme s'exécute en tant que root grâce
-à son setuid). Le programme quitte le mode d'exécution "root" dès que les
-pages sont verrouillées en mémoire qui plus est.
-
-Sur Unixware 2.x et 7.x vous devriez installer GnuPG avec le privilège
-"plock" pour obtenir le même effet :
-
-	filepriv -f plock /path/to/gpg
-
-Si vous ne pouvez pas installer GnuPG en tant que setuid(root) ou si vous
-ne voulez pas, vous pouvez utiliser l'option :
-
---no-secmem-warning
-
-Ou bien le placer en tant qu'option (sans les deux tirets) dans votre
-fichier ~/.gnupg/options ce qui permet de désactiver le warning.
-
-Sur quelques systèmes (e.g; Windows) GnuPG ne verrouille pas les
-pages en mémoire (ce n'est pas toujours possible selon les systèmes)
-et les anciennes versions de GnuPG (1.0.4 et antérieures) produisent
-sur ces systèmes le message d'erreur suivant :
-
-    gpg: Please note that you don't have secure memory
-
-Cet avertissement ne peut être désactivé en utilisant l'option décrite
-ci-dessus car nous considérons que cet avertissement forme une
-faille de sécurité importante. Toutefois, comme il provoquait une trop
-forte confusion auprès des utilisateurs de ces systèmes, le message
-d'avertissement a été retiré.
-
-6.2) Le support des fichiers de grande taille ne fonctionne pas ..
-
-Le LFS fonctionne correctement depuis les versions 1.0.4 et ultérieures.
-Si le configure ne le détecte pas correctement, essayez un autre
-compilateur : egcs 1.1.2 fonctionne parfaitement mais d'autres
-versions semblent poser problème. D'autre part, certains problèmes
-de compilation rencontrés dans GnuPG 1.0.3 et 1.0.4 sur HP-UX et
-Solaris étaient provoqués par un support "cassé" du LFS dans les
-sources ...
-
-6.3) Dans le menu d'édition les valeurs de confiance ne sont pas affichées
-	correctement après la signature des uid : pourquoi ?
-
-Ceci survient car certaines informations sont stockées immédiatement
-dans la TrustDB, mais le calcul ne se réalisé qu'au moment de la
-sauvegarde effective. Ce n'est pas un bogue vraiment facile à corriger
-mais nous pensons régler ce problème dans une future version.
-
-6.4) Que signifie "skipping pubkey 1: already loaded" ?
-
-Depuis la version 1.0.3 de GnuPG l'algorithme RSA est inclus. Si vous
-avez toujours l'option :
-
-load-extension rsa
-
-Dans votre fichier .options le message en question apparaîtra.
-Il vous suffira de retirer la commande qui n'est plus requise
-du fichier .options pour que le message cesse.
-
-6.5) GnuPG 1.0.4 ne tient pas compte de ~/.gnupg ...
-
-Ce bogue est connu et il a été corrigé dans les versions ultérieures.
-
-6.6) Une signature ElGamal ne vérifie plus rien depuis la 1.0.2 ..
-
-Utilisez l'option :
-
---emulate-md-encode-bug
-
-    Use the option --emulate-md-encode-bug.
-
-6.7) Les anciennes versions de GnuPG ne vérifient pas les anciennes
-	signatures ElGamal
-
-Veuillez migrer vers la version 1.0.2 au minimum, et de préférence
-une version ultérieure (1.0.6 par exemple).
-
-6.8) Lorsque j'utilise --clearsign le texte en clair comporte parfois des
-	tirets supplémentaires : pourquoi ?
-
-Ceci s'appelle le "dash-escaped" et il est requis par le format
-OpenPGP. A chaque fois qu'une ligne commence par un tiret, ceci
-risque de survenir. Cela permet aux programmes de retrouver
-sans difficulté les lignes de marquage du format, comme :
-
------BEGIN PGP SIGNATURE-----
-
-Seules ces lignes doivent pouvoir commencer par deux tirets. Si vous
-utilisez GnuPG pour traiter ces messages, les tirets supplémentaires
-seront retirés et les clients de messagerie "corrects" devraient
-également retirer ces tirets lorsqu'ils affichent le message.
- 
-6.9) Que signifie "can't handle multiple signatures" ?
-
-A cause des différents formats de messages, GnuPG n'est pas toujours
-capable de découper un fichier contenant des signatures multiples.
-Ce message d'erreur vous informe que les données en entrée
-comportent un problème. Le seul moyen pour disposer correctement
-de signatures multiples revient à utiliser le standard : le format
-OpenPGP avec les paquets "one-pass-signature" qui sont utilisés
-par défaut par GnuPG ou bien de recourir au format de texte en clair.
-
-6.10) Si je soumet une clef au serveur de clefs, rien ne survient !
-
-Vous utilisez probablement GnuPG sur Windows en version 1.0.2 ou
-antérieure. Cette fonctionnalité n'était alors pas encore disponible,
-et il ne s'agit pas d'un bogue. Vous devriez adopter une version
-plus récente, qui dispose de toutes les fonctionnalités :-)
-
-6.11) J'obtiens un "gpg: waiting for lock ..."
-
-Les anciennes versions de GnuPG ne quittaient pas correctement
-et laissaient un fichier "lock". Allez dans le répertoire ~/.gnupg et
-effacez les fichiers *.lock qui s'y trouvent pour continuer.
-
-6.12) Les anciennes versions de GnuPG (e.g. 1.0) ont des problèmes
-	avec les clefs de GnuPG récents ..
-
-Depuis la version 1.0.3 les clefs produites par GnuPG sont créées avec
-une préférence pour Twofish (et l'AES depuis la version 1.0.4 à savoir,
-l'algorithme Rijndael) et ceci signifie également qu'elles disposent de la
-capacité d'utilisation de la nouvelle méthode de chiffrement MDC. Ceci
-sera disponible dans OpenPGP très rapidement et sera supporté en
-tout logique par PGP 7. Cette nouvelle méthode de chiffrement permet
-de se protéger votre des attaques (des anciennes attaques en fait)
-contre les systèmes de chiffrement du courrier électronique.
-
-Ceci signifie également que les versions 1.0.3 et antérieures de GnuPG
-auront des problèmes avec les clefs plus récentes. A cause des
-correctifs de sécurité, vous devriez conserver votre installation
-de GnuPG à jour de toute manière. Comme manière de régler le
-problème vous devriez demander à GnuPG de n'utiliser que l'ancien
-algorithme de chiffrement en utilisant la ligne :
-
-cipher-algo cast5
-
-dans votre fichiers d'options.
-
-6.13) Avec GnuPG 1.0.4 j'obtiens un "this cipher algorithm is deprecated ..."
-
-Si vous venez de produire une nouvelle clef et que vous obtenez ce message
-pendant un chiffrement, il s'agit d'un bogue de la version 1.0.4 ; le nouvel
-algorithme AES Rijndael est utilisé mais il n'est pas enregistré sous le bon
-numéro d'algorithme ce qui produit ce message d'erreur "deprecated".
-Vous pouvez ignorer cet avertissement et les versions plus récentes
-de GnuPG sont corrigées sur ce point.
-
-6.14) Les dates sont affichées par ????-??-??, pourquoi ?
-
-A cause de contraintes dans la plupart des implémentations de la libc,
-les dates au-delà de 2038-01-19 ne seront pas affichées correctement.
-Les systèmes 64-bit ne sont pas affectés par ce problème. Pour éviter
-d'afficher les dates de manière incorrecte, GnuPG utilise des signes
-"?" au lieu des chiffres. Pour obtenir la valeur correcte vous devrez
-utiliser l'option :
-
---with-colons --fixed-list-mode
-
-6.15) J'ai encore un problème, dois-je produire un message de bogue ?
-
-Si vous êtes sûr(e) que le problème n'est mentionné nulle part, ni dans
-cette FAQ ni dans aucune liste de distribution GnuPG, commencez
-par consulter la liste de bogues qui sont en cours de traitement (la page
-de documentation dispose d'un lien vers la page de bogues). Si vous
-ne savez pas trop s'il s'agit d'un bogue, envoyez un courrier
-électronique à la liste : gnupg-devel. Sinon, vous pouvez utiliser
-le système de suivi de bogues GUUG à l'adresse :
-
-http://bugs.guug.de/Reporting.html.   
-
-6.16) Pourquoi GnuPG ne supporte pas les certificats X.509 ?
-
-GnuPG est avant tout une implémentation du standard OpenPGP,
-défini dans le RFC 2440. Ce standard propose une infrastructure
-complète et différente du X.509
-
-Ces deux systèmes sont des cryptosystèmes à clef publique, mais
-la manière dont les clefs sont traitées diffèrent.
-
-7. SUJETS AVANCES
-
-7.1) Comment tout cela fonctionne-t-il ?
-
-Pour produire une paire de clefs publique/privée, utilisez la commande
-
-gpg --gen-key
-
-Puis répondez aux questions en adoptant de préférence les valeurs
-par défaut.
-
-Les données qui sont chiffrées par une clef publique ne peuvent être
-déchiffrées que par la clef privée correspondante. La clef secrète
-est d'autre part protégée par une phrase-passe ce qui n'est pas le cas
-de la clef publique, librement distribuable.
-
-Pour transmettre à vos amis un message, il vous suffit de le chiffrer
-à l'aide de leurs clefs publiques. Seules leurs clefs privées seront
-capables de déchiffrer le message.
-
-GnuPG est pratique pour signer de manière numérique les choses.
-Les éléments qui sont chiffrés à l'aide de la clef publique ne peuvent
-être déchiffrés que par la clef publique, ce qui permet de signer
-des documents. On commence par produire un hachage, une sorte
-d'empreinte à taille fixe d'un document (de taille variable). Ensuite,
-votre clef privée est utilisée pour chiffrer ce hachage. Par la suite,
-toute personne disposant de votre clef publique et du document
-peut vérifier si le hachage du document correspond bien au
-déchiffrement du hachage, obtenu par votre clef publique dont
-disposent vos destinataires.
-
-Un trousseau de clefs n'est qu'un gros fichier (selon le nombre de
-clefs qu'il contient). Vous avez un trousseau de clefs publiques
-qui contient vos clefs publiques et celles de vos amis. Vous avez
-également un trousseau de clefs privées qui ne contient que vos
-clefs privées (chiffrées et protégées par votre phrase-passe). Vous
-devez faire très *attention* à ce fichier. Personne ne devra jamais
-y avoir accès et la phrase-passe qui le protège devra être
-complexe, et longue afin de bien protéger le secret.
-
-Vous pouvez aussi chiffrer des données de manière conventionnelle,
-en utilisant l'option "-c" de GnuPG. Dans ce cas, la phrase-passe
-utilisée servira de clef pour protéger le message. Aucun usage
-de clef publique ou de clef privée ici : il s'agit d'un chiffrement
-classique où il n'existe qu'une seule clef, utilisée pour chiffrer et
-déchiffrer les données. Généralement, on utilise cette méthode
-pour chiffrer ses propres documents à l'aide d'une phrase-passe
-secrète qui vous est propre. Cette méthode de chiffrement ne
-doit être utilisée pour des communications que si vous avez
-physiquement rencontré vos destinataires et que vous partagez
-dans le plus grand secret la phrase-passe (votre propre époux ou
-épouse, ou un ami de confiance). L'avantage est que vous pouvez
-changer de temps en temps la phrase-passe et en réduire le
-risque afin qu'en cas de découverte de la phrase-passe toutes
-vos données ne soient pas lisibles ;-)
-
-Vous pouvez ajouter et copier des clefs depuis votre trousseau
-de clefs publiques à l'aide des commandes "gpg --import" et
-"gpg --export". Vous pouvez également (ATTENTION !!) exporter
-vos clefs privées à l'aide de la commande : "gpg --export-secret-keys"
-mais ce n'est généralement pas utile sauf si vous devez déplacer
-vos clefs privées d'une machine à l'autre.
-
-Les clefs peuvent être signées à l'aide de l'option "gpg --edit-key". Lorsque
-vous signez une clef, vous certifiez que la clef appartient selon vous
-à la personne dont l'identité se trouve mentionnée dans la clef. Vous
-devez absolument être sûr(e) que la clef appartient bien à cette
-personne, sans le moindre doute. Vous devez vérifier son fingerprint
-à l'aide de la commande :
-
-gpg --fingerprint userid
-
-Et recevoir le même finger par téléphone ou de visu par la personne
-concernée. Généralement, on procède à des "fêtes" où chaque personne
-amène sa pièce d'identité, une carte de visite comprenant le fingerprint
-et l'on procède à un échange des fingerprint, ou directement des clefs.
-
-Vous pouvez également utiliser l'option "-o filename" pour forcer
-la sortie vers le fichier "filename". Pour forcer une sortie en console
-par défaut on utilise un tiret. La commande "-r" permet de spécifier
-le destinataire (avec quelle clef publique vous allez chiffrer) en ligne
-de commande au lieu d'avoir à taper le nom du destinataire dans
-le mode interactif.
-
-Autre chose d'importance. Par défaut, TOUTES les données sont chiffrées
-dans un format binaire particulier; Si vous souhaitez transmettre les données
-par courrier électronique (par exemple) vous devez les protéger dans
-un format d'amure qu'on appelle ASCII ARMOR. Ce format sera obtenu
-en utilisant l'option "-a" mais la méthode préférée reste d'utiliser
-un client de messagerie respectueux du format MIME comme Mutt, Pine
-et bien d'autres.
-
-Enfin, il existe une petite faille de sécurité dans OpenPGP (et donc dans PGP)
-et vous devriez TOUJOURS chiffrer PUIS signer un message. Il ne faut
-pas seulement chiffrer afin d'être totalement protégé. N'oubliez jamais.
-
-7.2) Pourquoi certaines signatures avec une clef ELG-E sont valides ?
-
-Ces clefs ElGamal furent produites par GnuPG en version 3 de paquets
-(selon le RFC 1991). Le brouillon OpenPGP a été modifié par la suite
-afin de modifier l'identifiant d'algorithme pour les clefs ElGamal qui est
-utilisable pour les signatures et le chiffrement des modes 16 à 20.
-GnuPG utilise le mode 20 quand il produit ses nouvelles clefs ElGamal
-mais il accepte toujours les clefs de type 16 qui selon le standard
-OpenPGP ne peuvent servir qu'au chiffrement, si la clef se trouve
-dans un paquet en version 3 du format. GnuPG est le seul programme
-ayant jamais utilisé les clefs au sein de paquets v3 - vous ne risquez
-donc pas grand chose.
-
-7.3) Comment tout le système de confiance fonctionne au juste ?
-
-Il fonctionne d'une manière proche de PGP. La différence c'est que
-la confiance est calculée uniquement lorsqu'elle est requise. C'est
-pourquoi la TrustDB contient une liste des signatures de clefs
-valides. Si vous ne fonctionnez pas en mode batch, vous devrez
-assigner un paramètre de confiance aux clefs (un ownertrust).
-
-Vous pouvez consulter la validité (la valeur de confiance
-calculée) en utilisant cette commande :
-
-     gpg --list-keys --with-colons  
-
-Si le premier champ est "pub" ou "uid" le second champ vous
-indiquera le niveau de confiance :
-
-o = Inconnu (cette clef est nouvelle au système)
-i = La clef est invalide (eg. il manque sa propre signature)
-d = La clef a été désactivée
-r = La clef a été révoquée
-e = La clef a expiré
-q = Non-défini (pas de valeur attribuée)
-n = Ne jamais faire confiance à cette clef
-m = Cette clef dispose d'une confiance marginale
-f = Cette clef dispose d'une confiance totale
-u = Cette clef dispose d'une confiance ultime. Cette valeur
-	n'est utilisée que pour les clefs où la clef secrète est
-	également disponibles.
-
-La valeur dans l'enregistrement "pub" est la meilleure valeur
-obtenue depuis les enregistrements "uid".
-
-Vous pouvez obtenir la liste des valeurs de confiance attribuées ;
-i.e. la confiance que vous accordez aux autres lorsqu'il s'agit
-de signer la clef d'un autre individu) :
-
-     gpg --list-ownertrust
-
-Le premier champ est le fingerprint de la clef primaire, le second
-champ est la valeur assignée :
-
-_ = Aucune valeur d'ownertrust assignée
-n = Ne jamais faire confiance au propriétaire de cette clef
-	lorsqu'il s'agit de vérifier d'autres signatures.
-m = Une confiance marginale est accordée au détenteur de cette clef
-	lorsqu'il s'agit de signer d'autres clefs.
-f = Assumer que le détenteur de cette clef est une personne de confiance
-	lorsqu'il s'agit de signer des clefs.
-u = Nous n'avons pas besoin de nous faire confiance à nous-même puisque
-	nous détenons notre propre clef privée.
-
-Vous devez conserver ces valeurs confidentielles, car elles représentent
-la confiance que vous accordez ou non à d'autres individus. PGP stocke
-cette information au sein de trousseau de clefs et le publier n'est PAS
-une bonne idée. Vous devez utiliser la commande d'exportation pour
-transmettre des clefs. Quoi qu'il en soit, GnuPG
-évite ces problèmes en ne conservant ces valeurs qu'aun sein de sa
-TrustDB donc vous pouvez copier un trousseau de clefs publiques
-si vous utilisez GnuPG (et nous disposons aussi de la commande
-d'exportation).
-
-7.4) Quel est ce genre de sortie : "key C26EE891.298, uid 09FB: ...."?
-
-Cette sortie est la représentation interne d'un userid au sein
-de la TrustDB. Le keyid est "C26EE891" et le "298" est le keyid local,
-un simple numéro d'enregistrement dans la TrustDB. Enfin, le "09FB"
-sont les deux derniers octets d'un ripe-md-160 de l'identifiant de
-l'utilisateur pour cette clef.
-
-7.5) Comment interpréter certaines sorties informatives ?
-
-Lorsque vous vérifiez la validité d'une clef, GnuPG affiche
-parfois une information préfixée par l'information en rapport
-avec le sujet vérifié. Par exemple : "key 12345678.3456" indique
-que la clef disposant de l'ID 12345678, et du numéro interne 3456
-est considérée au sein de la TrustDB au sein de ce qu'on
-appelle un enregistrement "directory". Un "uid 12345678.3456/ACDE"
-indique quel est l'identifiant d'utilisateur qui correspond
-à cette clef. Il s'agit d'une information sur la signature de la
-clef 9A8B7C6D disposant de cet ID et s'il s'agit d'une signature
-directe sur la clef, la partie User ID sera vide :
-
-(..//..)
-
-7.6) Les lignes d'en-tête des messages font-elles parties des
-	éléments signés ?
-
-Non. Par exemple, vous pouvez retirer les lignes "Comment:"
-Elles n'ont pas vraiment d'objet comme les lignes "header" des
-courriers électroniques. Toutefois, une ligne qui débute par
-"Hash: ..." est requise par les signatures OpenPGP afin de permettre
-au parser de déterminer quel algorithme de hachage utiliser.
-
-7.7) Quelle est la liste des algorithmes préférés ?
-
-La liste des algorithmes préférés est une liste d'algorithmes
-de chiffrement, de hachage et de compression stockés dans
-la signature propre de la clef durant sa production. Lorsque
-vous chiffrez un document, GnuPG utilise cette liste (elle fait
-partie de la clef publique) pour déterminer quels algorithmes
-doivent être utilisés. De manière basique, ces indications
-expliquent aux autres utilisateurs quels algorithmes vous
-acceptez en entrée avec un ordre de préférence.
-
-7.8) Comment puis-je changer la liste des algorithmes préférés ?
-
-Actuellement la liste et les préférences sont directement intégrées
-dans les codes sources de GnuPG. Vous devrez modifier le fichier
-g10/keygen afin de modifier cette liste et procéder à une
-nouvelle compilation. La fonction que vous devrez modifier est
-keygen_add_std_prefs. Le code est d'ailleurs assez simple à
-comprendre. Les constantes utilisées pour différencier les
-algorithmes sont définies au sein du fichier include/cipher.h
-
-Après avoir modifié ces fichiers, générez une nouvelle paire
-de clefs (ou une nouvelle sous-clef de chiffrement) avec
-la version modifiée de l'exécutable. La nouvelle clef disposera
-des nouvelles préférences et pourra être utilisée depuis des
-exécutables non modifiés.
-
-Pour modifier les préférénces d'une clef existante, vous devrez
-utiliser un exécutable modifié (voir ci-dessus) afin de modifier
-la date d'expiration puis sauvegardez les changements. Les
-préférences seront automatiquement modifiées lors de la
-sauvegarde et vous pouvez désormais utiliser la clef modifiée
-avec tout exécutable, modifié ou non.
-
-La modification de la liste de préférences à l'aide d'une
-version non-modifiée de GnuPG (probablement depuis le menu
-d'édition) fait partie de la liste TODO (A FAIRE) prévue
-pour les prochaines versions de GnuPG.
-
-
-8. REMERCIEMENTS
-
-Nous souhaitons remercier Werker Kosh pour la rédaction de la
-première FAQ originelle et pour tous les participants aux listes
-de discussion gnupg-users et gnupg-devel. La quasi-totalité
-des réponses de ce document proviennent de leurs efforts.
-
-Nous souhaitons également remercier Casper Dik pour nous
-avoir fourni le script permettant de générer cette FAQ,
-qu'il utilise d'autre part pour son excellente FAQ Solaris2 ;-)
-
-Copyright (C) 2000 Free Software Foundation, Inc. , 
-59 Temple Place - Suite 330, Boston, MA 02111, USA 
-
-Verbatim copying and distribution of this entire article is permitted in
-any medium, provided this notice is preserved.
diff --git a/doc/fr/README.fr b/doc/fr/README.fr
deleted file mode 100644
index 3a5d8485e..000000000
--- a/doc/fr/README.fr
+++ /dev/null
@@ -1,10 +0,0 @@
-You find here translations to French of some of the documents in
-../doc.  Those translations are not necessary up-to-date and should
-not be used as reference without checking the original English
-versions.
-
-Gilbert Fernandes kindly contributed thses translatons.
-
-
-
-
diff --git a/doc/gnupg-w32.reg b/doc/gnupg-w32.reg
deleted file mode 100644
index 7a6e346a8..000000000
--- a/doc/gnupg-w32.reg
+++ /dev/null
@@ -1,8 +0,0 @@
-REGEDIT4
-
-[HKEY_CURRENT_USER\Software\GNU\GNUPG]
-"HomeDir"="C:\\GnuPG"
-"gpgProgram"="C:\\GnuPG\\gpg.exe"
-
-[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
-"MODir"="C:\\GnuPG\\Locale"
diff --git a/doc/gnupg.7 b/doc/gnupg.7
deleted file mode 100644
index d11a4c94a..000000000
--- a/doc/gnupg.7
+++ /dev/null
@@ -1,14 +0,0 @@
-.TH GNUPG 7 2002-09-02 GNU "GNU Privacy Guard" 
-.SH NAME
-GnuPG \- The GNU Privacy Guard suite of programs
-.SH DESCRIPTION
-GnuPG is a set of programs for public key encryption and digital
-signatures.  The program most users want to use is 
-the OpenPGP command line tool, named \fBgpg\fP. \fBgpgv\fP
-is a stripped down version of \fBgpg\fP to verify signatures
-against a trusted keyring.  There is also a tool called
-\fBgpgsplit\fP to split OpenPGP messages or keyrings into their packets.
-.SH "SEE ALSO"
-.BR gpg (1),
-.BR gpgv (1),
-
diff --git a/doc/gpg.sgml b/doc/gpg.sgml
deleted file mode 100644
index 83a286172..000000000
--- a/doc/gpg.sgml
+++ /dev/null
@@ -1,2461 +0,0 @@
-<!-- gpg.sgml - the man page for GnuPG
-    Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
-
-    This file is part of GnuPG.
-
-    GnuPG 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.
-
-    GnuPG 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 this program; if not, write to the Free Software
-    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
--->
-<!-- This file should be processed by docbook-to-man to
-     create a manual page.  This program has currently the bug
-     not to remove leading white space. So this source file does
-     not look very pretty
-
-    FIXME: generated a file with entity (e.g. pathnames) from the
-    configure scripts and include it here
--->
-
-
-<!DOCTYPE refentry PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
-<!entity ParmDir "<parameter>directory</parameter>">
-<!entity ParmFile "<parameter>file</parameter>">
-<!entity OptParmFile "<optional>&ParmFile;</optional>">
-<!entity ParmFiles "<parameter>files</parameter>">
-<!entity OptParmFiles "<optional>&ParmFiles;</optional>">
-<!entity ParmNames "<parameter>names</parameter>">
-<!entity OptParmNames "<optional>&ParmNames;</optional>">
-<!entity ParmName  "<parameter>name</parameter>">
-<!entity OptParmName  "<optional>&ParmName;</optional>">
-<!entity ParmKeyIDs "<parameter>key IDs</parameter>">
-<!entity ParmN	    "<parameter>n</parameter>">
-<!entity ParmFlags  "<parameter>flags</parameter>">
-<!entity ParmString "<parameter>string</parameter>">
-<!entity ParmValue  "<parameter>value</parameter>">
-<!entity ParmNameValue	"<parameter>name=value</parameter>">
-<!entity ParmNameValues	"<parameter>name=value1 <optional>value2 value3 ...</optional></parameter>">
-]>
-
-<refentry id="gpg">
-<refmeta>
-  <refentrytitle>gpg</refentrytitle>
-  <manvolnum>1</manvolnum>
-  <refmiscinfo class="gnu">GNU Tools</refmiscinfo>
-</refmeta>
-<refnamediv>
-  <refname/gpg/
-  <refpurpose>encryption and signing tool</>
-</refnamediv>
-<refsynopsisdiv>
-  <synopsis>
-<command>gpg</>
- <optional>--homedir <parameter/name/</optional>
- <optional>--options <parameter/file/</optional>
- <optional><parameter/options/</optional>
- <parameter>command</>
- <optional><parameter/args/</optional>
-  </synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-    <title>DESCRIPTION</title>
-    <para>
-<command/gpg/ is the main program for the GnuPG system.
-    </para>
-    <para>
-This man page only lists the commands and options available.
-For more verbose documentation get the GNU Privacy Handbook (GPH) or
-one of the other documents at http://www.gnupg.org/docs.html .
-</para>
-<para>
-Please remember that option parsing stops as soon as a non option is
-encountered, you can explicitly stop option parsing by using the
-special option "--".
-</para>
-</refsect1>
-
-<refsect1>
-<title>COMMANDS</title>
-<para>
-<command/gpg/ recognizes these commands:
-</para>
-
-<variablelist>
-
-<varlistentry>
-<term>-s, --sign</term>
-<listitem><para>
-Make a signature. This command may be combined
-with --encrypt.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--clearsign</term>
-<listitem><para>
-Make a clear text signature.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-b, --detach-sign</term>
-<listitem><para>
-Make a detached signature.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-e, --encrypt</term>
-<listitem><para>
-Encrypt data. This option may be combined with --sign.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-c, --symmetric</term>
-<listitem><para>
-Encrypt with symmetric cipher only.
-This command asks for a passphrase.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--store</term>
-<listitem><para>
-Store only (make a simple RFC1991 packet).
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--decrypt &OptParmFile;</term>
-<listitem><para>
-Decrypt &ParmFile; (or stdin if no file is specified) and
-write it to stdout (or the file specified with
---output). If the decrypted file is signed, the
-signature is also verified. This command differs
-from the default operation, as it never writes to the
-filename which is included in the file and it
-rejects files which don't begin with an encrypted
-message.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--verify <optional><optional><parameter/sigfile/</optional>
- <optional><parameter/signed-files/</optional></optional></term>
-<listitem><para>
-Assume that <parameter/sigfile/ is a signature and verify it
-without generating any output.	With no arguments,
-the signature packet is read from stdin.  If
-only a sigfile is given, it may be a complete
-signature or a detached signature, in which case
-the signed stuff is expected in a file without the
-".sig" or ".asc" extension. 
-With more than
-1 argument, the first should be a detached signature
-and the remaining files are the signed stuff.  To read the signed
-stuff from stdin, use <literal>-</literal> as the second filename.
-For security reasons a detached signature cannot read the signed
-material from stdin without denoting it in the above way.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--verify-files <optional><parameter/files/</optional></term>
-<listitem><para>
-This is a special version of the --verify command which does not work with
-detached signatures.  The command expects the files to be verified either
-on the command line or reads the filenames from stdin;  each name must be on
-separate line. The command is intended for quick checking of many files.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--encrypt-files <optional><parameter/files/</optional></term>
-<listitem><para>
-This is a special version of the --encrypt command. The command expects
-the files to be encrypted either on the command line or reads the filenames
-from stdin; each name must be on separate line. The command is intended
-for a quick encryption of multiple files.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--decrypt-files <optional><parameter/files/</optional></term>
-<listitem><para>
-The same as --encrypt-files with the difference that files will be
-decrypted. The syntax or the filenames is the same.
-</para></listitem></varlistentry>
-
-<!--
-B<-k> [I<username>] [I<keyring>]
-    Kludge to be somewhat compatible with PGP.
-    Without arguments, all public keyrings are listed.
-    With one argument, only I<keyring> is listed.
-    Special combinations are also allowed, but they may
-    give strange results when combined with more options.
-    B<-kv>    Same as B<-k>
-    B<-kvv>   List the signatures with every key.
-    B<-kvvv>  Additionally check all signatures.
-    B<-kvc>   List fingerprints
-    B<-kvvc>  List fingerprints and signatures
-
-    B<This command may be removed in the future!>
--->
-
-<varlistentry>
-<term>--list-keys &OptParmNames;</term>
-<term>--list-public-keys &OptParmNames;</term>
-<listitem><para>
-List all keys from the public keyrings, or just the
-ones given on the command line.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--list-secret-keys &OptParmNames;</term>
-<listitem><para>
-List all keys from the secret keyrings, or just the ones given on the
-command line.  A '#' after the letters 'sec' means that the secret key
-is not usable (for example, if it was created via
---export-secret-subkeys).
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--list-sigs &OptParmNames;</term>
-<listitem><para>
-Same as --list-keys, but the signatures are listed too.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--check-sigs &OptParmNames;</term>
-<listitem><para>
-Same as --list-sigs, but the signatures are verified.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--fingerprint &OptParmNames;</term>
-<listitem><para>
-List all keys with their fingerprints. This is the
-same output as --list-keys but with the additional output
-of a line with the fingerprint. May also be combined
-with --list-sigs or --check-sigs.
-If this command is given twice, the fingerprints of all
-secondary keys are listed too.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--list-packets</term>
-<listitem><para>
-List only the sequence of packets. This is mainly
-useful for debugging.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--gen-key</term>
-<listitem><para>
-Generate a new key pair. This command is normally only used
-interactively.
-</para>
-<para>
-There is an experimental feature which allows you to create keys
-in batch mode. See the file <filename>doc/DETAILS</filename>
-in the source distribution on how to use this.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--edit-key &ParmName;</term>
-<listitem><para>
-Present a menu which enables you to do all key
-related tasks:</para>
-    <variablelist>
-
-    <varlistentry>
-    <term>sign</term>
-    <listitem><para>
-Make a signature on key of user &ParmName;
-If the key is not yet signed by the default
-user (or the users given with -u), the
-program displays the information of the key
-again, together with its fingerprint and
-asks whether it should be signed. This
-question is repeated for all users specified
-with -u.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>lsign</term>
-    <listitem><para>
-Same as --sign but the signature is marked as
-non-exportable and will therefore never be used
-by others.  This may be used to make keys valid
-only in the local environment.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>nrsign</term>
-    <listitem><para>
-Same as --sign but the signature is marked as non-revocable and can
-therefore never be revoked.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>nrlsign</term>
-    <listitem><para>
-Combines the functionality of nrsign and lsign to make a signature
-that is both non-revocable and
-non-exportable.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>revsig</term>
-    <listitem><para>
-Revoke a signature.  For every signature which has been generated by
-one of the secret keys, GnuPG asks whether a revocation certificate
-should be generated.
-</para></listitem></varlistentry>
-    <varlistentry>
-    <term>trust</term>
-    <listitem><para>
-Change the owner trust value. This updates the
-trust-db immediately and no save is required.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>disable</term>
-    <term>enable</term>
-    <listitem><para>
-Disable or enable an entire key. A disabled key can normally not be used
-for encryption.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>adduid</term>
-    <listitem><para>
-Create an alternate user id.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>addphoto</term>
-    <listitem><para>
-Create a photographic user id.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>deluid</term>
-    <listitem><para>
-Delete a user id.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>addkey</term>
-    <listitem><para>
-Add a subkey to this key.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>delkey</term>
-    <listitem><para>
-Remove a subkey.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>addrevoker</term>
-    <listitem><para>
-Add a designated revoker.  This takes one optional argument:
-"sensitive".  If a designated revoker is marked as sensitive, it will
-not be exported by default (see
-export-options).</para></listitem></varlistentry>
-    <varlistentry>
-    <term>revkey</term>
-    <listitem><para>
-Revoke a subkey.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>expire</term>
-    <listitem><para>
-Change the key expiration time.  If a subkey is selected, the
-expiration time of this subkey will be changed.  With no selection,
-the key expiration of the primary key is changed.
-</para></listitem></varlistentry>
-    <varlistentry>
-    <term>passwd</term>
-    <listitem><para>
-Change the passphrase of the secret key.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>primary</term>
-    <listitem><para>
-Flag the current user id as the primary one, removes the primary user
-id flag from all other user ids and sets the timestamp of all affected
-self-signatures one second ahead.  Note that setting a photo user ID
-as primary makes it primary over other photo user IDs, and setting a
-regular user ID as primary makes it primary over other regular user
-IDs.
-</para></listitem></varlistentry>
-    <varlistentry>
-    <term>uid &ParmN;</term>
-    <listitem><para>
-Toggle selection of user id with index &ParmN;.
-Use 0 to deselect all.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>key &ParmN;</term>
-    <listitem><para>
-Toggle selection of subkey with index &ParmN;.
-Use 0 to deselect all.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>check</term>
-    <listitem><para>
-Check all selected user ids.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>showphoto</term>
-    <listitem><para>
-Display the selected photographic user
-id.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>pref</term>
-    <listitem><para>
-List preferences from the selected user ID.  This shows the actual
-preferences, without including any implied preferences.
-</para></listitem></varlistentry>
-    <varlistentry>
-    <term>showpref</term>
-    <listitem><para>
-More verbose preferences listing for the selected user ID.  This shows
-the preferences in effect by including the implied preferences of
-3DES (cipher), SHA-1 (digest), and Uncompressed (compression) if they
-are not already included in the preference list.
-</para></listitem></varlistentry>
-    <varlistentry>
-    <term>setpref &ParmString;</term>
-    <listitem><para>
-Set the list of user ID preferences to &ParmString;, this should be a
-string similar to the one printed by "pref".  Using an empty string
-will set the default preference string, using "none" will set the
-preferences to nil.  Use "gpg -v --version" to get a list of available
-algorithms.  This command just initializes an internal list and does
-not change anything unless another command (such as "updpref") which
-changes the self-signatures is used.
-</para></listitem></varlistentry>
-    <varlistentry>
-    <term>updpref</term>
-    <listitem><para>
-Change the preferences of all user IDs (or just of the selected ones
-to the current list of preferences.  The timestamp of all affected
-self-signatures will be advanced by one second.  Note that while you
-can change the preferences on an attribute user ID (aka "photo ID"),
-GnuPG does not select keys via attribute user IDs so these preferences
-will not be used by GnuPG.
-</para></listitem></varlistentry>
-    <varlistentry>
-    <term>toggle</term>
-    <listitem><para>
-Toggle between public and secret key listing.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>save</term>
-    <listitem><para>
-Save all changes to the key rings and quit.</para></listitem></varlistentry>
-    <varlistentry>
-    <term>quit</term>
-    <listitem><para>
-Quit the program without updating the
-key rings.</para></listitem></varlistentry>
-    </variablelist>
-    <para>
-The listing shows you the key with its secondary
-keys and all user ids. Selected keys or user ids
-are indicated by an asterisk. The trust value is
-displayed with the primary key: the first is the
-assigned owner trust and the second is the calculated
-trust value.  Letters are used for the values:</para>
-    <variablelist>
-      <varlistentry><term>-</term><listitem><para>No ownertrust assigned / not yet calculated.</para></listitem></varlistentry>
-      <varlistentry><term>e</term><listitem><para>Trust
-calculation has failed; probably due to an expired key.</para></listitem></varlistentry>
-      <varlistentry><term>q</term><listitem><para>Not enough information for calculation.</para></listitem></varlistentry>
-      <varlistentry><term>n</term><listitem><para>Never trust this key.</para></listitem></varlistentry>
-      <varlistentry><term>m</term><listitem><para>Marginally trusted.</para></listitem></varlistentry>
-      <varlistentry><term>f</term><listitem><para>Fully trusted.</para></listitem></varlistentry>
-      <varlistentry><term>u</term><listitem><para>Ultimately trusted.</para></listitem></varlistentry>
-    </variablelist>
-</listitem></varlistentry>
-
-<varlistentry>
-<term>--sign-key &ParmName;</term>
-<listitem><para>
-Signs a public key with your secret key. This is a shortcut version of
-the subcommand "sign" from --edit.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--lsign-key &ParmName;</term>
-<listitem><para>
-Signs a public key with your secret key but marks it as
-non-exportable.  This is a shortcut version of the subcommand "lsign"
-from --edit.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--nrsign-key &ParmName;</term>
-<listitem><para>
-Signs a public key with your secret key but marks it as non-revocable.
-This is a shortcut version of the subcommand "nrsign" from --edit.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--delete-key &ParmName;</term>
-<listitem><para>
-Remove key from the public keyring.  In batch mode either --yes is
-required or the key must be specified by fingerprint.  This is a
-safeguard against accidental deletion of multiple keys.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--delete-secret-key  &ParmName;</term>
-<listitem><para>
-Remove key from the secret and public keyring. In batch mode the key
-must be specified by fingerprint.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--delete-secret-and-public-key  &ParmName;</term>
-<listitem><para>
-Same as --delete-key, but if a secret key exists, it will be removed 
-first. In batch mode the key must be specified by fingerprint.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--gen-revoke</term>
-<listitem><para>
-Generate a revocation certificate for the complete key. To revoke
-a subkey or a signature, use the --edit command.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--desig-revoke</term>
-<listitem><para>
-Generate a designated revocation certificate for a key.  This allows a
-user (with the permission of the keyholder) to revoke someone elses
-key.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--export &OptParmNames;</term>
-<listitem><para>
-Either export all keys from all keyrings (default
-keyrings and those registered via option --keyring),
-or if at least one name is given, those of the given
-name. The new keyring is written to stdout or to
-the file given with option "output".  Use together
-with --armor to mail those keys.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--send-keys &OptParmNames;</term>
-<listitem><para>
-Same as --export but sends the keys to a keyserver.
-Option --keyserver must be used to give the name
-of this keyserver. Don't send your complete keyring
-to a keyserver - select only those keys which are new
-or changed by you.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--export-all &OptParmNames;</term>
-<listitem><para>
-Same as --export, but also exports keys which
-are not compatible with OpenPGP.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--export-secret-keys &OptParmNames;</term>
-<term>--export-secret-subkeys &OptParmNames;</term>
-<listitem><para>
-Same as --export, but exports the secret keys instead.
-This is normally not very useful and a security risk.
-The second form of the command has the special property to
-render the secret part of the primary key useless; this is
-a GNU extension to OpenPGP and other implementations can
-not be expected to successfully import such a key.
-
-See the option --simple-sk-checksum if you want to import such an
-exported key with an older OpenPGP implementation.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--import &OptParmFiles;</term>
-<term>--fast-import &OptParmFiles;</term>
-<listitem><para>
-Import/merge keys. This adds the given keys to the
-keyring.  The fast version is currently just a synonym.
-</para>
-<para>
-There are a few other options which control how this command works.
-Most notable here is the --merge-only option which does not insert new keys
-but does only the merging of new signatures, user-IDs and subkeys.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--recv-keys &ParmKeyIDs;</term>
-<listitem><para>
-Import the keys with the given key IDs from a keyserver. Option
---keyserver must be used to give the name of this keyserver.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--search-keys &OptParmNames;</term>
-<listitem><para>
-Search the keyserver for the given names.  Multiple names given here
-will be joined together to create the search string for the keyserver.
-Option --keyserver must be used to give the name of this keyserver.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--update-trustdb</term>
-<listitem><para>
-Do trust DB maintenance.  This command goes over all keys and builds
-the Web-of-Trust. This is an interactive command because it may has to
-ask for the "ownertrust" values of keys.  The user has to give an
-estimation in how far she trusts the owner of the displayed key to
-correctly certify (sign) other keys.  It does only ask for that value
-if it has not yet been assigned to a key.  Using the edit menu, that
-value can be changed at any time later.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--check-trustdb</term>
-<listitem><para>
-Do trust DB maintenance without user interaction.  Form time to time
-the trust database must be updated so that expired keys and resulting
-changes in the Web-of-Trust can be tracked.  GnuPG tries to figure
-when this is required and then does it implicitly; this command can be
-used to force such a check.  The processing is identically to that of
---update-trustdb but it skips keys with a not yet defined "ownertrust".
-</para>
-<para>
-For use with cron jobs, this command can be used together with --batch
-in which case the check is only done when it is due.  To force a run
-even in batch mode add the option --yes.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--export-ownertrust &OptParmFile;</term>
-<listitem><para>
-Store the ownertrust values into
-&ParmFile; (or stdin if not given).  This is useful for backup
-purposes as these values are the only ones which can't be re-created
-from a corrupted trust DB.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--import-ownertrust &OptParmFiles;</term>
-<listitem><para>
-Update the trustdb with the ownertrust values stored
-in &ParmFiles; (or stdin if not given); existing
-values will be overwritten.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--rebuild-keydb-caches</term>
-<listitem><para>
-When updating from version 1.0.6 to 1.0.7 this command should be used
-to create signature caches in the keyring.  It might be handy in other
-situations too.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--print-md <parameter>algo</parameter> &OptParmFiles;</term>
-<term>--print-mds &OptParmFiles;</term>
-<listitem><para>
-Print message digest of algorithm ALGO for all given files or stdin.
-With the second form (or a deprecated "*" as algo) digests for all
-available algorithms are printed.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--gen-random <parameter>0|1|2</parameter>
-		   <optional><parameter>count</parameter></optional></term>
-<listitem><para>
-Emit COUNT random bytes of the given quality level. If count is not given
-or zero, an endless sequence of random bytes will be emitted.
-PLEASE, don't use this command unless you know what you are doing; it may
-remove precious entropy from the system!
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--gen-prime <parameter>mode</parameter>
-		  <parameter>bits</parameter>
-		   <optional><parameter>qbits</parameter></optional></term>
-<listitem><para>
-Use the source, Luke :-). The output format is still subject to change.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--version</term>
-<listitem><para>
-Print version information along with a list
-of supported algorithms.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--warranty</term>
-<listitem><para>
-Print warranty information.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-h, --help</term>
-<listitem><para>
-Print usage information.  This is a really long list even though it doesn't list
-all options.
-</para></listitem></varlistentry>
-
-
-
-</variablelist>
-</refsect1>
-
-<refsect1>
-<title>OPTIONS</title>
-<para>
-Long options can be put in an options file (default
-"~/.gnupg/gpg.conf").  Short option names will not work - for example,
-"armor" is a valid option for the options file, while "a" is not.  Do
-not write the 2 dashes, but simply the name of the option and any
-required arguments.  Lines with a hash ('#') as the first
-non-white-space character are ignored.  Commands may be put in this
-file too, but that does not make sense.
-</para>
-<para>
-<command/gpg/ recognizes these options:
-</para>
-
-<variablelist>
-
-
-<varlistentry>
-<term>-a, --armor</term>
-<listitem><para>
-Create ASCII armored output.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-o, --output &ParmFile;</term>
-<listitem><para>
-Write output to &ParmFile;.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-u, --local-user &ParmName;</term>
-<listitem><para>
-Use &ParmName as the user ID to sign.
-This option is silently ignored for the list commands,
-so that it can be used in an options file.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--default-key &ParmName;</term>
-<listitem><para>
-Use &ParmName; as default user ID for signatures.  If this
-is not used the default user ID is the first user ID
-found in the secret keyring.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-r, --recipient &ParmName;</term>
-<term></term>
-<listitem><para>
-Encrypt for user id &ParmName;. If this option is not
-specified, GnuPG asks for the user-id unless --default-recipient is given
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--default-recipient &ParmName;</term>
-<listitem><para>
-Use &ParmName; as default recipient if option --recipient is not used and
-don't ask if this is a valid one. &ParmName; must be non-empty.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--default-recipient-self</term>
-<listitem><para>
-Use the default key as default recipient if option --recipient is not used and
-don't ask if this is a valid one. The default key is the first one from the
-secret keyring or the one set with --default-key.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-default-recipient</term>
-<listitem><para>
-Reset --default-recipient and --default-recipient-self.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--encrypt-to &ParmName;</term>
-<listitem><para>
-Same as --recipient but this one is intended for use
-in the options file and may be used with
-your own user-id as an "encrypt-to-self".  These keys
-are only used when there are other recipients given
-either by use of --recipient or by the asked user id.
-No trust checking is performed for these user ids and
-even disabled keys can be used.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-encrypt-to</term>
-<listitem><para>
-Disable the use of all --encrypt-to keys.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-v, --verbose</term>
-<listitem><para>
-Give more information during processing. If used
-twice, the input data is listed in detail.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-q, --quiet</term>
-<listitem><para>
-Try to be as quiet as possible.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-z &ParmN;, --compress &ParmN;</term>
-<listitem><para>
-Set compression level to &ParmN;. A value of 0 for &ParmN;
-disables compression. Default is to use the default
-compression level of zlib (normally 6).
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-t, --textmode</term>
-<listitem><para>
-Use canonical text mode.  If -t (but not
---textmode) is used together with armoring
-and signing, this enables clearsigned messages.
-This kludge is needed for PGP compatibility;
-normally you would use --sign or --clearsign
-to selected the type of the signature.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-n, --dry-run</term>
-<listitem><para>
-Don't make any changes (this is not completely implemented).
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-i, --interactive</term>
-<listitem><para>
-Prompt before overwriting any files.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--batch</term>
-<listitem><para>
-Use batch mode.  Never ask, do not allow interactive
-commands.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-tty</term>
-<listitem><para>
-Make sure that the TTY (terminal) is never used for any output.
-This option is needed in some cases because GnuPG sometimes prints
-warnings to the TTY if --batch is used.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-batch</term>
-<listitem><para>
-Disable batch mode.  This may be of use if --batch
-is enabled from an options file.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--yes</term>
-<listitem><para>
-Assume "yes" on most questions.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no</term>
-<listitem><para>
- Assume "no" on most questions.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--default-cert-check-level &ParmN;</term>
-<listitem><para>
-The default to use for the check level when signing a key.
-</para><para>
-0 means you make no particular claim as to how carefully you verified
-the key.
-</para><para>
-1 means you believe the key is owned by the person who claims to own
-it but you could not, or did not verify the key at all.  This is
-useful for a "persona" verification, where you sign the key of a
-pseudonymous user.
-</para><para>
-2 means you did casual verification of the key.  For example, this
-could mean that you verified that the key fingerprint and checked the
-user ID on the key against a photo ID.
-</para><para>
-3 means you did extensive verification of the key.  For example, this
-could mean that you verified the key fingerprint with the owner of the
-key in person, and that you checked, by means of a hard to forge
-document with a photo ID (such as a passport) that the name of the key
-owner matches the name in the user ID on the key, and finally that you
-verified (by exchange of email) that the email address on the key
-belongs to the key owner.
-</para><para>
-Note that the examples given above for levels 2 and 3 are just that:
-examples.  In the end, it is up to you to decide just what "casual"
-and "extensive" mean to you.
-</para><para>
-This option defaults to 0.
-</para></listitem></varlistentry>
-
-
-
-<varlistentry>
-<term>--trusted-key <parameter>long key ID</parameter></term>
-<listitem><para>
-Assume that the specified key (which must be given
-as a  full 8 byte key ID) is as trustworthy as one of
-your own secret keys. This option is useful if you
-don't want to keep your secret keys (or one of them)
-online but still want to be able to check the validity of a given
-recipient's or signator's key. 
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--always-trust</term>
-<listitem><para>
-Skip key validation and assume that used keys are always fully trusted.
-You won't use this unless you have installed some external validation
-scheme.  This option also suppresses the "[uncertain]" tag printed
-with signature checks when there is no evidence that the user ID
-is bound to the key.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--keyserver &ParmName;</term>
-<listitem><para>
-Use &ParmName as your keyserver.  This is the server that --recv-keys,
---send-keys, and --search-keys will communicate with to receive keys
-from, send keys to, and search for keys on.  The format of the
-&ParmName is a URI: `scheme:[//]keyservername[:port]' The scheme is
-the type of keyserver: "hkp" for the Horowitz (or compatible)
-keyservers, "ldap" for the NAI LDAP keyserver, or "mailto" for the
-Horowitz email keyserver.  Note that your particular installation of
-GnuPG may have other keyserver types available as well.  Keyserver
-schemes are case-insensitive.
-</para><para>
-Most keyservers synchronize with each other, so there is generally no
-need to send keys to more than one server.  Using the command "host -l
-pgp.net | grep wwwkeys" gives you a list of HKP keyservers.  When
-using one of the wwwkeys servers, due to load balancing using
-round-robin DNS you may notice that you get a different key server
-each time.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--keyserver-options <parameter>parameters</parameter></term>
-<listitem><para>
-This is a space or comma delimited string that gives options for the
-keyserver.  Options can be prepended with a `no-' to give the opposite
-meaning.  Valid import-options or export-options may be used here as
-well to apply to importing (--recv-key) or exporting (--send-key) a
-key from a keyserver.  While not all options are available for all
-keyserver types, some common options are:
-<variablelist>
-
-<varlistentry>
-<term>include-revoked</term>
-<listitem><para>
-When searching for a key, include keys that are marked on the
-keyserver as revoked.  Note that this option is always set when using
-the NAI HKP keyserver, as this keyserver does not differentiate
-between revoked and unrevoked keys.  When using the LDAP keyserver,
-this applies to both searching (--search-keys) and receiving
-(--recv-keys).
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>include-disabled</term>
-<listitem><para>
-When receiving or searching for a key, include keys that are marked on
-the keyserver as disabled.  Note that this option is not used with HKP
-keyservers, as they do not support disabling keys.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>include-subkeys</term>
-<listitem><para>
-When receiving a key, include subkeys in the search.  Note that this
-option is not used with HKP keyservers, as they do not support
-retrieving keys by subkey id.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>use-temp-files</term>
-<listitem><para>
-On most Unix-like platforms, GnuPG communicates with the keyserver
-helper program via pipes, which is the most efficient method.  This
-option forces GnuPG to use temporary files to communicate.  On some
-platforms (such as Win32 and RISC OS), this option is always enabled.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>keep-temp-files</term>
-<listitem><para>
-If using `use-temp-files', do not delete the temp files after using
-them.  This option is useful to learn the keyserver communication
-protocol by reading the temporary files.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>verbose</term>
-<listitem><para>
-Tell the keyserver helper program to be more verbose.  This option can
-be repeated multiple times to increase the verbosity level.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>honor-http-proxy</term>
-<listitem><para>
-For keyserver schemes that use HTTP (such as HKP), try to access the
-keyserver over the proxy set with the environment variable
-"http_proxy".
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>auto-key-retrieve</term>
-<listitem><para>
-This option enables the automatic retrieving of keys from a keyserver
-when verifying signatures made by keys that are not on the local
-keyring.
-</para></listitem></varlistentry>
-
-</variablelist>
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--import-options <parameter>parameters</parameter></term>
-<listitem><para>
-This is a space or comma delimited string that gives options for
-importing keys.  Options can be prepended with a `no-' to give the
-opposite meaning.  The options are:
-<variablelist>
-
-<varlistentry>
-<term>allow-local-sigs</term>
-<listitem><para>
-Allow importing key signatures marked as "local".  This is not
-generally useful unless a shared keyring scheme is being used.
-Defaults to no.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>repair-hkp-subkey-bug</term>
-<listitem><para>
-During import, attempt to repair the HKP keyserver mangling multiple
-subkeys bug.  Note that this cannot completely repair the damaged key
-as some crucial data is removed by the keyserver, but it does at least
-give you back one subkey.  Defaults to no for regular --import and to
-yes for keyserver --recv-keys.
-</para></listitem></varlistentry>
-
-</variablelist>
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--export-options <parameter>parameters</parameter></term>
-<listitem><para>
-This is a space or comma delimited string that gives options for
-exporting keys.  Options can be prepended with a `no-' to give the
-opposite meaning.  The options are:
-<variablelist>
-
-<varlistentry>
-<term>include-non-rfc</term>
-<listitem><para>
-Include non-RFC compliant keys in the export.  Defaults to yes.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>include-local-sigs</term>
-<listitem><para>
-Allow exporting key signatures marked as "local".  This is not
-generally useful unless a shared keyring scheme is being used.
-Defaults to no.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>include-attributes</term>
-<listitem><para>
-Include attribute user IDs (photo IDs) while exporting.  This is
-useful to export keys if they are going to be used by an OpenPGP
-program that does not accept attribute user IDs.  Defaults to yes.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>include-sensitive-revkeys</term>
-<listitem><para>
-Include designated revoker information that was marked as
-"sensitive".  Defaults to no.
-</para></listitem></varlistentry>
-
-</variablelist>
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--show-photos</term>
-<listitem><para>
-Causes --list-keys, --list-sigs, --list-public-keys,
---list-secret-keys, and verifying a signature to also display the
-photo ID attached to the key, if any.
-See also --photo-viewer.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-show-photos</term>
-<listitem><para>
-Resets the --show-photos flag.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--photo-viewer &ParmString;</term>
-<listitem><para>
-This is the command line that should be run to view a photo ID.  "%i"
-will be expanded to a filename containing the photo.  "%I" does the
-same, except the file will not be deleted once the viewer exits.
-Other flags are "%k" for the key ID, "%K" for the long key ID, "%f"
-for the key fingerprint, "%t" for the extension of the image type
-(e.g. "jpg"), "%T" for the MIME type of the image (e.g. "image/jpeg"),
-and "%%" for an actual percent sign.  If neither %i or %I are present,
-then the photo will be supplied to the viewer on standard input.
-</para><para>
-The default viewer is "xloadimage -fork -quiet -title 'KeyID 0x%k'
-stdin"
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--exec-path &ParmString;</term>
-<listitem><para>
-Sets a list of directories to search for photo viewers and keyserver
-helpers.  If not provided, keyserver helpers use the compiled-in
-default directory, and photo viewers use the $PATH environment
-variable.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--show-keyring</term>
-<listitem><para>
-Causes --list-keys, --list-public-keys, and --list-secret-keys to
-display the name of the keyring a given key resides on. This is only
-useful when you're listing a specific key or set of keys. It has no
-effect when listing all keys.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--keyring &ParmFile;</term>
-<listitem><para>
-Add &ParmFile to the list of keyrings.
-If &ParmFile begins with a tilde and a slash, these
-are replaced by the HOME directory. If the filename
-does not contain a slash, it is assumed to be in the
-home-directory ("~/.gnupg" if --homedir is not used).
-The filename may be prefixed with a scheme:</para>
-<para>"gnupg-ring:" is the default one.</para>
-<para>It might make sense to use it together with --no-default-keyring.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--secret-keyring &ParmFile;</term>
-<listitem><para>
-Same as --keyring but for the secret keyrings.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--homedir &ParmDir;</term>
-<listitem><para>
-Set the name of the home directory to &ParmDir; If this
-option is not used it defaults to "~/.gnupg". It does
-not make sense to use this in a options file. This
-also overrides the environment variable "GNUPGHOME".
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--charset &ParmName;</term>
-<listitem><para>
-Set the name of the native character set.  This is used
-to convert some strings to proper UTF-8 encoding. If this option is not used, the default character set is determined
-from the current locale.  A verbosity level of 3 shows the used one.
-Valid values for &ParmName; are:</para>
-<variablelist>
-<varlistentry>
-<term>iso-8859-1</term><listitem><para>This is the Latin 1 set.</para></listitem>
-</varlistentry>
-<varlistentry>
-<term>iso-8859-2</term><listitem><para>The Latin 2 set.</para></listitem>
-</varlistentry>
-<varlistentry>
-<term>iso-8859-15</term><listitem><para>This is currently an alias for
-the Latin 1 set.</para></listitem>
-</varlistentry>
-<varlistentry>
-<term>koi8-r</term><listitem><para>The usual Russian set (rfc1489).</para></listitem>
-</varlistentry>
-<varlistentry>
-<term>utf-8</term><listitem><para>Bypass all translations and assume
-that the OS uses native UTF-8 encoding.</para></listitem>
-</varlistentry>
-</variablelist>
-</listitem></varlistentry>
-
-
-<varlistentry>
-<term>--utf8-strings</term>
-<term>--no-utf8-strings</term>
-<listitem><para>
-Assume that the arguments are already given as UTF8 strings.  The default
-(--no-utf8-strings)
-is to assume that arguments are encoded in the character set as specified
-by --charset. These options affect all following arguments.  Both options may
-be used multiple times.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--options &ParmFile;</term>
-<listitem><para>
-Read options from &ParmFile; and do not try to read
-them from the default options file in the homedir
-(see --homedir). This option is ignored if used
-in an options file.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-options</term>
-<listitem><para>
-Shortcut for "--options /dev/null".  This option is
-detected before an attempt to open an option file.
-Using this option will also prevent the creation of a 
-"~./gnupg" homedir.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--load-extension &ParmName;</term>
-<listitem><para>
-Load an extension module. If &ParmName; does not contain a slash it is
-searched for in the directory configured when GnuPG was built
-(generally "/usr/local/lib/gnupg").  Extensions are not generally
-useful anymore, and the use of this option is deprecated.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--debug &ParmFlags;</term>
-<listitem><para>
-Set debugging flags. All flags are or-ed and &ParmFlags; may
-be given in C syntax (e.g. 0x0042).
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--debug-all</term>
-<listitem><para>
- Set all useful debugging flags.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--status-fd &ParmN;</term>
-<listitem><para>
-Write special status strings to the file descriptor &ParmN;.
-See the file DETAILS in the documentation for a listing of them.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--logger-fd &ParmN;</term>
-<listitem><para>
-Write log output to file descriptor &ParmN; and not to stderr.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--attribute-fd &ParmN;</term>
-<listitem><para>
-Write attribute subpackets to the file descriptor &ParmN;.  This is
-most useful for use with --status-fd, since the status messages are
-needed to separate out the various subpackets from the stream
-delivered to the file descriptor.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--sk-comments</term>
-<listitem><para>
-Include secret key comment packets when exporting secret keys.  This
-is a GnuPG extension to the OpenPGP standard, and is off by default.
-Please note that this has nothing to do with the comments in clear
-text signatures or armor headers.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-sk-comments</term>
-<listitem><para>
-Resets the --sk-comments option.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-comment</term>
-<listitem><para>
-See --sk-comments.  This option is deprecated and may be removed soon.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--comment &ParmString;</term>
-<listitem><para>
-Use &ParmString; as comment string in clear text signatures.
-The default is not do write a comment string.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--default-comment</term>
-<listitem><para>
-Force to write the standard comment string in clear
-text signatures.  Use this to overwrite a --comment
-from a config file.  This option is now obsolete because there is no
-default comment string anymore.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-version</term>
-<listitem><para>
-Omit the version string in clear text signatures.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--emit-version</term>
-<listitem><para>
-Force to write the version string in clear text
-signatures.  Use this to overwrite a previous
---no-version from a config file.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-N, --notation-data &ParmNameValue;</term>
-<listitem><para>
-Put the name value pair into the signature as notation data.
-&ParmName; must consist only of alphanumeric characters, digits
-or the underscore; the first character must not be a digit.
-&ParmValue; may be any printable string; it will be encoded in UTF8,
-so you should check that your --charset is set correctly.
-If you prefix &ParmName; with an exclamation mark, the notation
-data will be flagged as critical (rfc2440:5.2.3.15).
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--show-notation</term>
-<listitem><para>
-Show key signature notations in the --list-sigs or --check-sigs
-listings.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-show-notation</term>
-<listitem><para>
-Do not show key signature notations in the --list-sigs or --check-sigs
-listings.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--set-policy-url &ParmString;</term>
-<listitem><para>
-Use &ParmString; as Policy URL for signatures (rfc2440:5.2.3.19).
-If you prefix it with an exclamation mark, the policy URL
-packet will be flagged as critical.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--show-policy-url</term>
-<listitem><para>
-Show any policy URLs set in the --list-sigs or --check-sigs listings.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-show-policy-url</term>
-<listitem><para>
-Do not show any policy URLs set in the --list-sigs or --check-sigs
-listings.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--set-filename &ParmString;</term>
-<listitem><para>
-Use &ParmString; as the name of file which is stored in
-messages.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--for-your-eyes-only</term>
-<listitem><para>
-Set the `for your eyes only' flag in the message.  This causes GnuPG
-to refuse to save the file unless the --output option is given, and
-PGP to use the "secure viewer" with a Tempest-resistant font to
-display the message.  This option overrides --set-filename.
-</para></listitem></varlistentry
-
-<varlistentry>
-<term>--no-for-your-eyes-only</term>
-<listitem><para>
-Resets the --for-your-eyes-only flag.
-</para></listitem></varlistentry
-
-<varlistentry>
-<term>--use-embedded-filename</term>
-<listitem><para>
-Try to create a file with a name as embedded in the data.
-This can be a dangerous option as it allows to overwrite files.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--completes-needed &ParmN;</term>
-<listitem><para>
-Number of completely trusted users to introduce a new
-key signer (defaults to 1).
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--marginals-needed &ParmN;</term>
-<listitem><para>
-Number of marginally trusted users to introduce a new
-key signer (defaults to 3)
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--max-cert-depth &ParmN;</term>
-<listitem><para>
-Maximum depth of a certification chain (default is 5).
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--cipher-algo &ParmName;</term>
-<listitem><para>
-Use  &ParmName; as cipher algorithm. Running the program
-with the command --version yields a list of supported
-algorithms. If this is not used the cipher algorithm is
-selected from the preferences stored with the key.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--digest-algo &ParmName;</term>
-<listitem><para>
-Use &ParmName; as the message digest algorithm. Running the program
-with the command --version yields a list of supported algorithms.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--cert-digest-algo &ParmName;</term>
-<listitem><para>
-Use &ParmName; as the message digest algorithm used when signing a
-key.  Running the program with the command --version yields a list of
-supported algorithms.  Be aware that if you choose an algorithm that
-GnuPG supports but other OpenPGP implementations do not, then some
-users will not be able to use the key signatures you make, or quite
-possibly your entire key.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--s2k-cipher-algo &ParmName;</term>
-<listitem><para>
-Use &ParmName; as the cipher algorithm used to protect secret keys.
-The default cipher is CAST5.  This cipher is also used for
-conventional encryption if --cipher-algo is not given.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--s2k-digest-algo &ParmName;</term>
-<listitem><para>
-Use  &ParmName; as the digest algorithm used to mangle the
-passphrases.  The default algorithm is RIPE-MD-160.
-This digest algorithm is also used for conventional
-encryption if --digest-algo is not given.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--s2k-mode &ParmN;</term>
-<listitem><para>
-Selects how passphrases are mangled. If &ParmN; is 0
-a plain passphrase (which is not recommended) will be used,
-a 1 (default) adds a salt to the passphrase and
-a 3 iterates the whole process a couple of times.
-Unless --rfc1991 is used, this mode is also used
-for conventional encryption.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--simple-sk-checksum</term>
-<listitem><para>
-Secret keys are integrity protected by using a SHA-1 checksum.  This
-method will be part of an enhanced OpenPGP specification but GnuPG
-already uses it as a countermeasure against certain attacks.  Old
-applications don't understand this new format, so this option may be
-used to switch back to the old behaviour.  Using this this option
-bears a security risk.  Note that using this option only takes effect
-when the secret key is encrypted - the simplest way to make this
-happen is to change the passphrase on the key (even changing it to the
-same value is acceptable).
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--compress-algo &ParmN;</term>
-<listitem><para>
-Use compression algorithm &ParmN;. Default is 2 which is RFC1950
-compression. You may use 1 to use the old zlib version (RFC1951) which
-is used by PGP. 0 disables compression. The default algorithm may give
-better results because the window size is not limited to 8K. If this
-is not used the OpenPGP behavior is used, i.e. the compression
-algorithm is selected from the preferences; note, that this can't be
-done if you do not encrypt the data.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--disable-cipher-algo &ParmName;</term>
-<listitem><para>
-Never allow the use of &ParmName; as cipher algorithm.
-The given name will not be checked so that a later loaded algorithm
-will still get disabled.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--disable-pubkey-algo &ParmName;</term>
-<listitem><para>
-Never allow the use of &ParmName; as public key algorithm.
-The given name will not be checked so that a later loaded algorithm
-will still get disabled.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-sig-cache</term>
-<listitem><para>
-Do not cache the verification status of key signatures.
-Caching gives a much better performance in key listings.  However, if
-you suspect that your public keyring is not save against write
-modifications, you can use this option to disable the caching.  It
-probably does not make sense to disable it because all kind of damage
-can be done if someone else has write access to your public keyring.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-sig-create-check</term>
-<listitem><para>
-GnuPG normally verifies each signature right after creation to protect
-against bugs and hardware malfunctions which could leak out bits from
-the secret key.  This extra verification needs some time (about 115%
-for DSA keys), and so this option can be used to disable it.
-However, due to the fact that the signature creation needs manual
-interaction, this performance penalty does not matter in most settings.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--auto-check-trustdb</term>
-<listitem><para>
-If GnuPG feels that its information about the Web-of-Trust has to be
-updated, it automatically runs the --check-trustdb command 
-internally.  This may be a time consuming process.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-auto-check-trustdb</term>
-<listitem><para>
-Resets the --auto-check-trustdb option.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--throw-keyid</term>
-<listitem><para>
-Do not put the keyid into encrypted packets.  This option
-hides the receiver of the message and is a countermeasure
-against traffic analysis.  It may slow down the decryption
-process because all available secret keys are tried.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--not-dash-escaped</term>
-<listitem><para>
-This option changes the behavior of cleartext signatures
-so that they can be used for patch files. You should not
-send such an armored file via email because all spaces
-and line endings are hashed too.  You can not use this
-option for data which has 5 dashes at the beginning of a
-line, patch files don't have this. A special armor header
-line tells GnuPG about this cleartext signature option.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--escape-from-lines</term>
-<listitem><para>
-Because some mailers change lines starting with "From "
-to "&#60;From " it is good to handle such lines in a special
-way when creating cleartext signatures. All other PGP
-versions do it this way too. This option is not enabled
-by default because it would violate rfc2440.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--passphrase-fd &ParmN;</term>
-<listitem><para>
-Read the passphrase from file descriptor &ParmN;. If you use
-0 for &ParmN;, the passphrase will be read from stdin.	This
-can only be used if only one passphrase is supplied.
-<!--fixme: make this print strong-->
-Don't use this option if you can avoid it.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--command-fd &ParmN;</term>
-<listitem><para>
-This is a replacement for the deprecated shared-memory IPC mode.
-If this option is enabled, user input on questions is not expected
-from the TTY but from the given file descriptor.  It should be used
-together with --status-fd. See the file doc/DETAILS in the source
-distribution for details on how to use it.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--use-agent</term>
-<listitem><para>
-Try to use the GnuPG-Agent. Please note that this agent is still under
-development.  With this option, GnuPG first tries to connect to the
-agent before it asks for a passphrase.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--gpg-agent-info</term>
-<listitem><para>
-Override the value of the environment variable
-<literal>GPG_AGENT_INFO</>.  This is only used when --use-agent has been given
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--rfc1991</term>
-<listitem><para>
-Try to be more RFC1991 (PGP 2.x) compliant.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--pgp2</term>
-<listitem><para>
-Set up all options to be as PGP 2.x compliant as possible, and warn if
-an action is taken (e.g. encrypting to a non-RSA key) that will create
-a message that PGP 2.x will not be able to handle.  Note that `PGP
-2.x' here means `MIT PGP 2.6.2'.  There are other versions of PGP 2.x
-available, but the MIT release is a good common baseline.
-</para><para>
-This option implies `--rfc1991 --no-openpgp --disable-mdc
---no-force-v4-certs --no-comment --escape-from-lines --force-v3-sigs
---no-ask-sig-expire --no-ask-cert-expire --cipher-algo IDEA
---digest-algo MD5 --compress-algo 1'.  It also disables --textmode
-when encrypting.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-pgp2</term>
-<listitem><para>
-Resets the --pgp2 option.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--pgp6</term>
-<listitem><para>
-Set up all options to be as PGP 6 compliant as possible.  This
-restricts you to the ciphers IDEA (if the IDEA plugin is installed),
-3DES, and CAST5, the hashes MD5, SHA1 and RIPEMD160, and the
-compression algorithms none and ZIP.  This also disables making
-signatures with signing subkeys as PGP 6 does not understand
-signatures made by signing subkeys.
-</para><para>
-This option implies `--disable-mdc --no-comment --escape-from-lines
---force-v3-sigs --no-ask-sig-expire --compress-algo 1'
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-pgp6</term>
-<listitem><para>
-Resets the --pgp6 option.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--pgp7</term>
-<listitem><para>
-Set up all options to be as PGP 7 compliant as possible.  This is
-identical to --pgp6 except that MDCs are not disabled, and the list of
-allowable ciphers is expanded to add AES128, AES192, AES256, and
-TWOFISH.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-pgp7</term>
-<listitem><para>
-Resets the --pgp7 option.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--openpgp</term>
-<listitem><para>
-Reset all packet, cipher and digest options to OpenPGP behavior. Use
-this option to reset all previous options like --rfc1991,
---force-v3-sigs, --s2k-*, --cipher-algo, --digest-algo and
---compress-algo to OpenPGP compliant values.  All PGP workarounds are
-also disabled.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--force-v3-sigs</term>
-<listitem><para>
-OpenPGP states that an implementation should generate v4 signatures
-but PGP versions 5 and higher only recognize v4 signatures on key
-material.  This option forces v3 signatures for signatures on data.
-Note that this option overrides --ask-sig-expire, as v3 signatures
-cannot have expiration dates.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-force-v3-sigs</term>
-<listitem><para>
-Reset the --force-v3-sigs option.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--force-v4-certs</term>
-<listitem><para>
-Always use v4 key signatures even on v3 keys.  This option also
-changes the default hash algorithm for v3 RSA keys from MD5 to SHA-1.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-force-v4-certs</term>
-<listitem><para>
-Reset the --force-v4-certs option.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--force-mdc</term>
-<listitem><para>
-Force the use of encryption with appended manipulation code.  This is
-always used with the newer ciphers (those with a blocksize greater
-than 64 bit).
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--allow-non-selfsigned-uid</term>
-<listitem><para>
-Allow the import and use of keys with user IDs which are not
-self-signed.  This is not recommended, as a non self-signed user ID is
-trivial to forge.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-allow-non-selfsigned-uid</term>
-<listitem><para>
-Reset the --allow-non-selfsigned-uid option.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--allow-freeform-uid</term>
-<listitem><para>
-Disable all checks on the form of the user ID while generating a new
-one.  This option should only be used in very special environments as
-it does not ensure the de-facto standard format of user IDs.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--ignore-time-conflict</term>
-<listitem><para>
-GnuPG normally checks that the timestamps associated with keys and
-signatures have plausible values.  However, sometimes a signature seems to
-be older than the key due to clock problems.  This option makes these
-checks just a warning.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--ignore-valid-from</term>
-<listitem><para>
-GnuPG normally does not select and use subkeys created in the future.  This
-option allows the use of such keys and thus exhibits the pre-1.0.7
-behaviour.  You should not use this option unless you there is some
-clock problem.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--ignore-crc-error</term>
-<listitem><para>
-The ASCII armor used by OpenPGP is protected by a CRC checksum against
-transmission errors.  Sometimes it happens that the CRC gets mangled
-somewhere on the transmission channel but the actual content (which is
-protected by the OpenPGP protocol anyway) is still okay.  This option
-will let gpg ignore CRC errors.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--ignore-mdc-error</term>
-<listitem><para>
-This option changes a MDC integrity protection failure into a warning.
-This can be useful if a message is partially corrupt, but it is
-necessary to get as much data as possible out of the corrupt message.
-However, be aware that a MDC protection failure may also mean that the
-message was tampered with intentionally by an attacker.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--lock-once</term>
-<listitem><para>
-Lock the databases the first time a lock is requested
-and do not release the lock until the process
-terminates.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--lock-multiple</term>
-<listitem><para>
-Release the locks every time a lock is no longer
-needed. Use this to override a previous --lock-once
-from a config file.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--lock-never</term>
-<listitem><para>
-Disable locking entirely.  This option should be used only in very
-special environments, where it can be assured that only one process
-is accessing those files.  A bootable floppy with a stand-alone
-encryption system will probably use this.  Improper usage of this
-option may lead to data and key corruption.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-random-seed-file</term>
-<listitem><para>
-GnuPG uses a file to store its internal random pool over invocations.
-This makes random generation faster; however sometimes write operations
-are not desired.  This option can be used to achieve that with the cost of
-slower random generation.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-verbose</term>
-<listitem><para>
-Reset verbose level to 0.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-greeting</term>
-<listitem><para>
-Suppress the initial copyright message but do not
-enter batch mode.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-secmem-warning</term>
-<listitem><para>
-Suppress the warning about "using insecure memory".
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-permission-warning</term>
-<listitem><para>
-Suppress the warning about unsafe file permissions.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-mdc-warning</term>
-<listitem><para>
-Suppress the warning about missing MDC integrity protection.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-armor</term>
-<listitem><para>
-Assume the input data is not in ASCII armored format.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--no-default-keyring</term>
-<listitem><para>
-Do not add the default keyrings to the list of
-keyrings.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--skip-verify</term>
-<listitem><para>
-Skip the signature verification step.  This may be
-used to make the decryption faster if the signature
-verification is not needed.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--with-colons</term>
-<listitem><para>
-Print key listings delimited by colons.  Note, that the output will be
-encoded in UTF-8 regardless of any --charset setting.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--with-key-data</term>
-<listitem><para>
-Print key listings delimited by colons (like --with-colons) and print the public key data.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--with-fingerprint</term>
-<listitem><para>
-Same as the command --fingerprint but changes only the format of the output
-and may be used together with another command.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--fast-list-mode</term>
-<listitem><para>
-Changes the output of the list commands to work faster; this is achieved
-by leaving some parts empty.  Some applications don't need the user ID and
-the trust information given in the listings.  By using this options they
-can get a faster listing.  The exact behaviour of this option may change
-in future versions.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--fixed-list-mode</term>
-<listitem><para>
-Do not merge user ID and primary key in --with-colon listing mode and
-print all timestamps as seconds since 1970-01-01.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--list-only</term>
-<listitem><para>
-Changes the behaviour of some commands.  This is like --dry-run but
-different in some cases.  The semantic of this command may be extended in
-the future.  Currently it only skips the actual decryption pass and
-therefore enables a fast listing of the encryption keys.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-literal</term>
-<listitem><para>
-This is not for normal use.  Use the source to see for what it might be useful.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--set-filesize</term>
-<listitem><para>
-This is not for normal use.  Use the source to see for what it might be useful.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--emulate-md-encode-bug</term>
-<listitem><para>
-GnuPG versions prior to 1.0.2 had a bug in the way a signature was encoded.
-This options enables a workaround by checking faulty signatures again with
-the encoding used in old versions.  This may only happen for ElGamal signatures
-which are not widely used.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--show-session-key</term>
-<listitem><para>
-Display the session key used for one message. See --override-session-key
-for the counterpart of this option.
-</para>
-<para>
-We think that Key-Escrow is a Bad Thing; however the user should
-have the freedom to decide whether to go to prison or to reveal the content of
-one specific message without compromising all messages ever encrypted for one
-secret key. DON'T USE IT UNLESS YOU ARE REALLY FORCED TO DO SO.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--override-session-key &ParmString; </term>
-<listitem><para>
-Don't use the public key but the session key &ParmString;.  The format of this
-string is the same as the one printed by --show-session-key.  This option
-is normally not used but comes handy in case someone forces you to reveal the
-content of an encrypted message; using this option you can do this without
-handing out the secret key.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--ask-sig-expire</term>
-<listitem><para>
-When making a data signature, prompt for an expiration time.  If this
-option is not specified, the expiration time is "never".
-</para></listitem></varlistentry
-
-<varlistentry>
-<term>--no-ask-sig-expire</term>
-<listitem><para>
-Resets the --ask-sig-expire option.
-</para></listitem></varlistentry
-
-<varlistentry>
-<term>--ask-cert-expire</term>
-<listitem><para>
-When making a key signature, prompt for an expiration time.  If this
-option is not specified, the expiration time is "never".
-</para></listitem></varlistentry
-
-<varlistentry>
-<term>--no-ask-cert-expire</term>
-<listitem><para>
-Resets the --ask-cert-expire option.
-</para></listitem></varlistentry
-
-<varlistentry>
-<term>--expert</term>
-<listitem><para>
-Allow the user to do certain nonsensical or "silly" things like
-signing an expired or revoked key, or certain potentially incompatible
-things like generating deprecated key types.  This also disables
-certain warning messages about potentially incompatible actions.  As
-the name implies, this option is for experts only.  If you don't fully
-understand the implications of what it allows you to do, leave this
-off.
-</para></listitem></varlistentry
-
-<varlistentry>
-<term>--no-expert</term>
-<listitem><para>
-Resets the --expert option.
-</para></listitem></varlistentry
-
-<varlistentry>
-<term>--merge-only</term>
-<listitem><para>
-Don't insert new keys into the keyrings while doing an import.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--allow-secret-key-import</term>
-<listitem><para>
-This is an obsolete option and is not used anywhere.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--try-all-secrets</term>
-<listitem><para>
-Don't look at the key ID as stored in the message but try all secret keys in
-turn to find the right decryption key.	This option forces the behaviour as
-used by anonymous recipients (created by using --throw-keyid) and might come
-handy in case where an encrypted message contains a bogus key ID.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--enable-special-filenames</term>
-<listitem><para>
-This options enables a mode in which filenames of the form
-<filename>-&#38;n</>, where n is a non-negative decimal number,
-refer to the file descriptor n and not to a file with that name.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--no-expensive-trust-checks</term>
-<listitem><para>
-Experimental use only.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--group &ParmNameValues;</term>
-<listitem><para>
-Sets up a named group, which is similar to aliases in email programs.
-Any time the group name is a receipient (-r or --recipient), it will
-be expanded to the values specified.
-
-The values are &ParmKeyIDs; or fingerprints, but any key description
-is accepted.  Note that a value with spaces in it will be treated as
-two different values.  Note also there is only one level of expansion
-- you cannot make an group that points to another group.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--preserve-permissions</term>
-<listitem><para>
-Don't change the permissions of a secret keyring back to user
-read/write only.  Use this option only if you really know what you are doing.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--personal-cipher-preferences &ParmString;</term>
-<listitem><para>
-Set the list of personal cipher preferences to &ParmString;, this list
-should be a string similar to the one printed by the command "pref" in
-the edit menu.  This allows the user to factor in their own preferred
-algorithms when algorithms are chosen via recipient key preferences.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--personal-digest-preferences &ParmString;</term>
-<listitem><para>
-Set the list of personal digest preferences to &ParmString;, this list
-should be a string similar to the one printed by the command "pref" in
-the edit menu.  This allows the user to factor in their own preferred
-algorithms when algorithms are chosen via recipient key preferences.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--personal-compress-preferences &ParmString;</term>
-<listitem><para>
-Set the list of personal compression preferences to &ParmString;, this
-list should be a string similar to the one printed by the command
-"pref" in the edit menu.  This allows the user to factor in their own
-preferred algorithms when algorithms are chosen via recipient key
-preferences.
-</para></listitem></varlistentry>
-
-<varlistentry>
-<term>--default-preference-list &ParmString;</term>
-<listitem><para>
-Set the list of default preferences to &ParmString;, this list should
-be a string similar to the one printed by the command "pref" in the
-edit menu.  This affects both key generation and "updpref" in the edit
-menu.
-</para></listitem></varlistentry>
-
-
-</variablelist>
-</refsect1>
-
-
-<refsect1>
-    <title>How to specify a user ID</title>
-    <para>
-There are different ways on how to specify a user ID to GnuPG;
-here are some examples:
-    </para>
-
-    <variablelist>
-<varlistentry>
-<term></term>
-<listitem><para></para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>234567C4</term>
-<term>0F34E556E</term>
-<term>01347A56A</term>
-<term>0xAB123456</term>
-<listitem><para>
-Here the key ID is given in the usual short form.
-</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>234AABBCC34567C4</term>
-<term>0F323456784E56EAB</term>
-<term>01AB3FED1347A5612</term>
-<term>0x234AABBCC34567C4</term>
-<listitem><para>
-Here the key ID is given in the long form as used by OpenPGP
-(you can get the long key ID using the option --with-colons).
-</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>1234343434343434C434343434343434</term>
-<term>123434343434343C3434343434343734349A3434</term>
-<term>0E12343434343434343434EAB3484343434343434</term>
-<term>0xE12343434343434343434EAB3484343434343434</term>
-<listitem><para>
-The best way to specify a key ID is by using the fingerprint of
-the key.  This avoids any ambiguities in case that there are duplicated
-key IDs (which are really rare for the long key IDs).
-</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>=Heinrich Heine &#60;heinrichh@uni-duesseldorf.de&#62;</term>
-<listitem><para>
-Using an exact to match string.  The equal sign indicates this.
-</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>&#60;heinrichh@uni-duesseldorf.de&#62;</term>
-<listitem><para>
-Using the email address part which must match exactly.	The left angle bracket
-indicates this email address mode.
-</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>+Heinrich Heine duesseldorf</term>
-<listitem><para>
-All words must match exactly (not case sensitive) but can appear in
-any order in the user ID.  Words are any sequences of letters,
-digits, the underscore and all characters with bit 7 set.
-</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>Heine</term>
-<term>*Heine</term>
-<listitem><para>
-By case insensitive substring matching.  This is the default mode but
-applications may want to explicitly indicate this by putting the asterisk
-in front.
-</para></listitem>
-</varlistentry>
-
-    </variablelist>
-
-    <para>
-Note that you can append an exclamation mark to key IDs or
-fingerprints.  This flag tells GnuPG to use exactly the given primary
-or secondary key and not to try to figure out which secondary or
-primary key to use.
-    </para>
-
-</refsect1>
-
-
-<refsect1>
-    <title>RETURN VALUE</title>
-    <para>
-The program returns 0 if everything was fine, 1 if at least
-a signature was bad, and other error codes for fatal errors.
-    </para>
-</refsect1>
-
-<refsect1>
-    <title>EXAMPLES</title>
-    <variablelist>
-
-<varlistentry>
-<term>gpg -se -r <parameter/Bob/ &ParmFile;</term>
-<listitem><para>sign and encrypt for user Bob</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>gpg --clearsign &ParmFile;</term>
-<listitem><para>make a clear text signature</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>gpg -sb  &ParmFile;</term>
-<listitem><para>make a detached signature</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>gpg --list-keys  <parameter/user_ID/</term>
-<listitem><para>show keys</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>gpg --fingerprint  <parameter/user_ID/</term>
-<listitem><para>show fingerprint</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>gpg --verify  <parameter/pgpfile/</term>
-<term>gpg --verify  <parameter/sigfile/ &OptParmFiles;</term>
-<listitem><para>
-Verify the signature of the file but do not output the data. The second form
-is used for detached signatures, where <parameter/sigfile/ is the detached
-signature (either ASCII armored of binary) and &OptParmFiles are the signed
-data; if this is not given the name of the file holding the signed data is
-constructed by cutting off the extension (".asc" or ".sig") of
-<parameter/sigfile/ or by asking the user for the filename.
-</para></listitem></varlistentry>
-
-    </variablelist>
-</refsect1>
-
-
-<refsect1>
-    <title>ENVIRONMENT</title>
-
-    <variablelist>
-<varlistentry>
-<term>HOME</term>
-<listitem><para>Used to locate the default home directory.</para></listitem>
-</varlistentry>
-<varlistentry>
-<term>GNUPGHOME</term>
-<listitem><para>If set directory used instead of "~/.gnupg".</para></listitem>
-</varlistentry>
-<varlistentry>
-<term>GPG_AGENT_INFO</term>
-<listitem><para>Used to locate the gpg-agent; only honored when
---use-agent is set.  The value consists of 3 colon delimited fields: 
-The first is the path to the Unix Domain Socket, the second the PID of
-the gpg-agent and the protocol version which should be set to 1.  When
-starting the gpg-agent as described in its documentation, this
-variable is set to the correct value.  The option --gpg-agent-info can
-be used to override it.</para></listitem>
-</varlistentry>
-<varlistentry>
-<term>http_proxy</term>
-<listitem><para>Only honored when the keyserver-option
-honor-http-proxy is set.</para></listitem>
-</varlistentry>
-    </variablelist>
-
-</refsect1>
-
-<refsect1>
-    <title>FILES</title>
-    <variablelist>
-
-<varlistentry>
-<term>~/.gnupg/secring.gpg</term>
-<listitem><para>The secret keyring</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>~/.gnupg/secring.gpg.lock</term>
-<listitem><para>and the lock file</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>~/.gnupg/pubring.gpg</term>
-<listitem><para>The public keyring</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>~/.gnupg/pubring.gpg.lock</term>
-<listitem><para>and the lock file</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>~/.gnupg/trustdb.gpg</term>
-<listitem><para>The trust database</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>~/.gnupg/trustdb.gpg.lock</term>
-<listitem><para>and the lock file</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>~/.gnupg/random_seed</term>
-<listitem><para>used to preserve the internal random pool</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>~/.gnupg/gpg.conf</term>
-<listitem><para>Default configuration file</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>~/.gnupg/options</term>
-<listitem><para>Old style configuration file; only used when gpg.conf
-is not found</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>/usr[/local]/share/gnupg/options.skel</term>
-<listitem><para>Skeleton options file</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term>/usr[/local]/lib/gnupg/</term>
-<listitem><para>Default location for extensions</para></listitem>
-</varlistentry>
-
-    </variablelist>
-</refsect1>
-
-<!-- SEE ALSO  not yet needed-->
-
-<refsect1>
-    <title>WARNINGS</title>
-    <para>
-Use a *good* password for your user account and a *good* passphrase
-to protect your secret key.  This passphrase is the weakest part of the
-whole system.  Programs to do dictionary attacks on your secret keyring
-are very easy to write and so you should protect your "~/.gnupg/"
-directory very well.
-</para>
-<para>
-Keep in mind that, if this program is used over a network (telnet), it
-is *very* easy to spy out your passphrase!
-</para>
-<para>
-If you are going to verify detached signatures, make sure that the
-program knows about it; either be giving both filenames on the
-command line or using <literal>-</literal> to specify stdin.
-</para>
-</refsect1>
-
-
-<refsect1>
-    <title>BUGS</title>
-    <para>
-On many systems this program should be installed as setuid(root). This
-is necessary to lock memory pages. Locking memory pages prevents the
-operating system from writing memory pages to disk. If you get no
-warning message about insecure memory your operating system supports
-locking without being root. The program drops root privileges as soon
-as locked memory is allocated.
-</para>
-</refsect1>
-
-</refentry>
-
diff --git a/doc/gpg.texi b/doc/gpg.texi
deleted file mode 100644
index 88cf053f1..000000000
--- a/doc/gpg.texi
+++ /dev/null
@@ -1,1531 +0,0 @@
-\input texinfo
-@c This Texinfo document has been automatically generated by
-@c docbook2texi from a DocBook documentation.  The tool used
-@c can be found at:
-@c <URL:http://shell.ipoline.com/~elmert/hacks/docbook2X/>
-@c Please send any bug reports, improvements, comments, 
-@c patches, etc. to Steve Cheng <steve@ggi-project.org>.
-
-@setfilename gpg.info
-@dircategory GnuPG
-@direntry
-* gpg: (gpg).                         GnuPG encryption and signing tool.
-@end direntry
-
-@node top
-@top gpg
-@menu
-@end menu
-
-@majorheading Name
-gpg ---- encryption and signing tool
-
-@majorheading Synopsis
-
-@majorheading DESCRIPTION
-@code{gpg} is the main program for the GnuPG system.
-
-This man page only lists the commands and options available.
-For more verbose documentation get the GNU Privacy Handbook (GPH) or
-one of the other documents at http://www.gnupg.org/docs.html .
-
-Please remember that option parsing stops as soon as a non option is
-encountered, you can explicitly stop option parsing by using the
-special option "---".
-
-@majorheading COMMANDS
-@code{gpg} recognizes these commands:
-
-@table @asis
-@item -s, ---sign
-Make a signature. This command may be combined
-with ---encrypt.
-
-@item ---clearsign
-Make a clear text signature.
-
-@item -b, ---detach-sign
-Make a detached signature.
-
-@item -e, ---encrypt
-Encrypt data. This option may be combined with ---sign.
-
-@item -c, ---symmetric
-Encrypt with symmetric cipher only.
-This command asks for a passphrase.
-
-@item ---store
-Store only (make a simple RFC1991 packet).
-
-@item ---decrypt @code{file}
-Decrypt @code{file} (or stdin if no file is specified) and
-write it to stdout (or the file specified with
----output). If the decrypted file is signed, the
-signature is also verified. This command differs
-from the default operation, as it never writes to the
-filename which is included in the file and it
-rejects files which don't begin with an encrypted
-message.
-
-@item ---verify @code{sigfile} @code{signed-files}
-Assume that @code{sigfile} is a signature and verify it
-without generating any output. With no arguments,
-the signature packet is read from stdin. If
-only a sigfile is given, it may be a complete
-signature or a detached signature, in which case
-the signed stuff is expected in a file without the
-".sig" or ".asc" extension. 
-With more than
-1 argument, the first should be a detached signature
-and the remaining files are the signed stuff. To read the signed
-stuff from stdin, use @samp{-} as the second filename.
-For security reasons a detached signature cannot read the signed
-material from stdin without denoting it in the above way.
-
-@item ---verify-files @code{files}
-This is a special version of the ---verify command which does not work with
-detached signatures. The command expects the files to be verified either
-on the command line or reads the filenames from stdin; each name must be on
-separate line. The command is intended for quick checking of many files.
-
-@item ---encrypt-files @code{files}
-This is a special version of the ---encrypt command. The command expects
-the files to be encrypted either on the command line or reads the filenames
-from stdin; each name must be on separate line. The command is intended
-for a quick encryption of multiple files.
-
-@item ---decrypt-files @code{files}
-The same as ---encrypt-files with the difference that files will be
-decrypted. The syntax or the filenames is the same.
-
-@item ---list-keys @code{names}
-@itemx ---list-public-keys @code{names}
-List all keys from the public keyrings, or just the
-ones given on the command line.
-
-@item ---list-secret-keys @code{names}
-List all keys from the secret keyrings, or just the
-ones given on the command line.
-
-@item ---list-sigs @code{names}
-Same as ---list-keys, but the signatures are listed too.
-
-@item ---check-sigs @code{names}
-Same as ---list-sigs, but the signatures are verified.
-
-@item ---fingerprint @code{names}
-List all keys with their fingerprints. This is the
-same output as ---list-keys but with the additional output
-of a line with the fingerprint. May also be combined
-with ---list-sigs or --check-sigs.
-If this command is given twice, the fingerprints of all
-secondary keys are listed too.
-
-@item ---list-packets
-List only the sequence of packets. This is mainly
-useful for debugging.
-
-@item ---gen-key
-Generate a new key pair. This command is normally only used
-interactively.
-
-There is an experimental feature which allows you to create keys
-in batch mode. See the file @file{doc/DETAILS}
-in the source distribution on how to use this.
-
-@item ---edit-key @code{name}
-Present a menu which enables you to do all key
-related tasks:
-
-@table @asis
-@item sign
-Make a signature on key of user @code{name}
-If the key is not yet signed by the default
-user (or the users given with -u), the
-program displays the information of the key
-again, together with its fingerprint and
-asks whether it should be signed. This
-question is repeated for all users specified
-with -u.
-
-@item lsign
-Same as ---sign but the signature is marked as
-non-exportable and will therefore never be used
-by others. This may be used to make keys valid
-only in the local environment.
-
-@item nrsign
-Same as ---sign but the signature is marked as non-revocable and can
-therefore never be revoked.
-
-@item nrlsign
-Combines the functionality of nrsign and lsign to make a signature
-that is both non-revocable and
-non-exportable.
-
-@item revsig
-Revoke a signature. GnuPG asks for every
-signature which has been done by one of
-the secret keys, whether a revocation
-certificate should be generated.
-
-@item trust
-Change the owner trust value. This updates the
-trust-db immediately and no save is required.
-
-@item disable
-@itemx enable
-Disable or enable an entire key. A disabled key can normally not be used
-for encryption.
-
-@item adduid
-Create an alternate user id.
-
-@item addphoto
-Create a photographic user id.
-
-@item deluid
-Delete a user id.
-
-@item addkey
-Add a subkey to this key.
-
-@item delkey
-Remove a subkey.
-
-@item addrevoker
-Add a designated revoker. This takes one optional argument:
-"sensitive". If a designated revoker is marked as sensitive, it will
-not be exported by default (see
-export-options).
-
-@item revkey
-Revoke a subkey.
-
-@item expire
-Change the key expiration time. If a key is
-selected, the time of this key will be changed.
-With no selection the key expiration of the
-primary key is changed.
-
-@item passwd
-Change the passphrase of the secret key.
-
-@item primary
-Flag the current user id as the primary one, removes the primary user
-id flag from all other user ids and sets the timestamp of all affected
-self-signatures one second ahead. Note that setting a photo user ID
-as primary makes it primary over other photo user IDs, and setting a
-regular user ID as primary makes it primary over other regular user
-IDs.
-
-@item uid @code{n}
-Toggle selection of user id with index @code{n}.
-Use 0 to deselect all.
-
-@item key @code{n}
-Toggle selection of subkey with index @code{n}.
-Use 0 to deselect all.
-
-@item check
-Check all selected user ids.
-
-@item showphoto
-Display the selected photographic user
-id.
-
-@item pref
-List preferences from the selected user ID. This shows the actual
-preferences, without including any implied preferences.
-
-@item showpref
-More verbose preferences listing for the selected user ID. This shows
-the preferences in effect by including the implied preferences of
-3DES (cipher), SHA-1 (digest), and Uncompressed (compression) if they
-are not already included in the preference list.
-
-@item setpref @code{string}
-Set the list of user ID preferences to @code{string}, this should be a
-string similar to the one printed by "pref". Using an empty string
-will set the default preference string, using "none" will set the
-preferences to nil. Use "gpg -v ---version" to get a list of available
-algorithms. This command just initializes an internal list and does
-not change anything unless another command (such as "updpref") which
-changes the self-signatures is used.
-
-@item updpref
-Change the preferences of all user IDs (or just of the selected ones
-to the current list of preferences. The timestamp of all affected
-self-signatures will be advanced by one second. Note that while you
-can change the preferences on an attribute user ID (aka "photo ID"),
-GnuPG does not select keys via attribute user IDs so these preferences
-will not be used by GnuPG.
-
-@item toggle
-Toggle between public and secret key listing.
-
-@item save
-Save all changes to the key rings and quit.
-
-@item quit
-Quit the program without updating the
-key rings.
-
-@end table
-
-The listing shows you the key with its secondary
-keys and all user ids. Selected keys or user ids
-are indicated by an asterisk. The trust value is
-displayed with the primary key: the first is the
-assigned owner trust and the second is the calculated
-trust value. Letters are used for the values:
-
-@table @asis
-@item -
-No ownertrust assigned / not yet calculated.
-
-@item e
-Trust
-calculation has failed; probably due to an expired key.
-
-@item q
-Not enough information for calculation.
-
-@item n
-Never trust this key.
-
-@item m
-Marginally trusted.
-
-@item f
-Fully trusted.
-
-@item u
-Ultimately trusted.
-
-@end table
-
-@item ---sign-key @code{name}
-Signs a public key with your secret key. This is a shortcut version of
-the subcommand "sign" from ---edit.
-
-@item ---lsign-key @code{name}
-Signs a public key with your secret key but marks it as
-non-exportable. This is a shortcut version of the subcommand "lsign"
-from ---edit.
-
-@item ---nrsign-key @code{name}
-Signs a public key with your secret key but marks it as non-revocable.
-This is a shortcut version of the subcommand "nrsign" from ---edit.
-
-@item ---delete-key @code{name}
-Remove key from the public keyring. In batch mode either ---yes is
-required or the key must be specified by fingerprint. This is a
-safeguard against accidental deletion of multiple keys.
-
-@item ---delete-secret-key @code{name}
-Remove key from the secret and public keyring. In batch mode the key
-must be specified by fingerprint.
-
-@item ---delete-secret-and-public-key @code{name}
-Same as ---delete-key, but if a secret key exists, it will be removed 
-first. In batch mode the key must be specified by fingerprint.
-
-@item ---gen-revoke
-Generate a revocation certificate for the complete key. To revoke
-a subkey or a signature, use the ---edit command.
-
-@item ---desig-revoke
-Generate a designated revocation certificate for a key. This allows a
-user (with the permission of the keyholder) to revoke someone elses
-key.
-
-@item ---export @code{names}
-Either export all keys from all keyrings (default
-keyrings and those registered via option ---keyring),
-or if at least one name is given, those of the given
-name. The new keyring is written to stdout or to
-the file given with option "output". Use together
-with ---armor to mail those keys.
-
-@item ---send-keys @code{names}
-Same as ---export but sends the keys to a keyserver.
-Option ---keyserver must be used to give the name
-of this keyserver. Don't send your complete keyring
-to a keyserver - select only those keys which are new
-or changed by you.
-
-@item ---export-all @code{names}
-Same as ---export, but also exports keys which
-are not compatible with OpenPGP.
-
-@item ---export-secret-keys @code{names}
-@itemx ---export-secret-subkeys @code{names}
-Same as ---export, but exports the secret keys instead.
-This is normally not very useful and a security risk.
-The second form of the command has the special property to
-render the secret part of the primary key useless; this is
-a GNU extension to OpenPGP and other implementations can
-not be expected to successfully import such a key.
-See the option ---simple-sk-checksum if you want to import such an
-exported key with an older OpenPGP implementation.
-
-@item ---import @code{files}
-@itemx ---fast-import @code{files}
-Import/merge keys. This adds the given keys to the
-keyring. The fast version is currently just a synonym.
-
-There are a few other options which control how this command works.
-Most notable here is the ---merge-only option which does not insert new keys
-but does only the merging of new signatures, user-IDs and subkeys.
-
-@item ---recv-keys @code{key IDs}
-Import the keys with the given key IDs from a keyserver. Option
----keyserver must be used to give the name of this keyserver.
-
-@item ---search-keys @code{names}
-Search the keyserver for the given names. Multiple names given here
-will be joined together to create the search string for the keyserver.
-Option ---keyserver must be used to give the name of this keyserver.
-
-@item ---update-trustdb
-Do trust DB maintenance. This command goes over all keys and builds
-the Web-of-Trust. This is an interactive command because it may has to
-ask for the "ownertrust" values of keys. The user has to give an
-estimation in how far she trusts the owner of the displayed key to
-correctly certify (sign) other keys. It does only ask for that value
-if it has not yet been assigned to a key. Using the edit menu, that
-value can be changed at any time later.
-
-@item ---check-trustdb
-Do trust DB maintenance without user interaction. Form time to time
-the trust database must be updated so that expired keys and resulting
-changes in the Web-of-Trust can be tracked. GnuPG tries to figure
-when this is required and then does it implicitly; this command can be
-used to force such a check. The processing is identically to that of
----update-trustdb but it skips keys with a not yet defined "ownertrust".
-
-For use with cron jobs, this command can be used together with ---batch
-in which case the check is only done when it is due. To force a run
-even in batch mode add the option ---yes.
-
-@item ---export-ownertrust @code{file}
-Store the ownertrust values into
-@code{file} (or stdin if not given). This is useful for backup
-purposes as these values are the only ones which can't be re-created
-from a corrupted trust DB.
-
-@item ---import-ownertrust @code{files}
-Update the trustdb with the ownertrust values stored
-in @code{files} (or stdin if not given); existing
-values will be overwritten.
-
-@item ---print-md @code{algo} @code{files}
-@itemx ---print-mds @code{files}
-Print message digest of algorithm ALGO for all given files or stdin.
-With the second form (or a deprecated "*" as algo) digests for all
-available algorithms are printed.
-
-@item ---gen-random @code{0|1|2} @code{count}
-Emit COUNT random bytes of the given quality level. If count is not given
-or zero, an endless sequence of random bytes will be emitted.
-PLEASE, don't use this command unless you know what you are doing; it may
-remove precious entropy from the system!
-
-@item ---gen-prime @code{mode} @code{bits} @code{qbits}
-Use the source, Luke :-). The output format is still subject to change.
-
-@item ---version
-Print version information along with a list
-of supported algorithms.
-
-@item ---warranty
-Print warranty information.
-
-@item -h, ---help
-Print usage information. This is a really long list even though it doesn't list
-all options.
-
-@end table
-
-@majorheading OPTIONS
-Long options can be put in an options file (default
-"~/.gnupg/gpg.conf"). Short option names will not work - for example,
-"armor" is a valid option for the options file, while "a" is not. Do
-not write the 2 dashes, but simply the name of the option and any
-required arguments. Lines with a hash ('#') as the first
-non-white-space character are ignored. Commands may be put in this
-file too, but that does not make sense.
-
-@code{gpg} recognizes these options:
-
-@table @asis
-@item -a, ---armor
-Create ASCII armored output.
-
-@item -o, ---output @code{file}
-Write output to @code{file}.
-
-@item -u, ---local-user @code{name}
-Use @code{name} as the user ID to sign.
-This option is silently ignored for the list commands,
-so that it can be used in an options file.
-
-@item ---default-key @code{name}
-Use @code{name} as default user ID for signatures. If this
-is not used the default user ID is the first user ID
-found in the secret keyring.
-
-@item -r, ---recipient @code{name}
-@itemx 
-Encrypt for user id @code{name}. If this option is not
-specified, GnuPG asks for the user-id unless ---default-recipient is given
-
-@item ---default-recipient @code{name}
-Use @code{name} as default recipient if option ---recipient is not used and
-don't ask if this is a valid one. @code{name} must be non-empty.
-
-@item ---default-recipient-self
-Use the default key as default recipient if option ---recipient is not used and
-don't ask if this is a valid one. The default key is the first one from the
-secret keyring or the one set with ---default-key.
-
-@item ---no-default-recipient
-Reset ---default-recipient and --default-recipient-self.
-
-@item ---encrypt-to @code{name}
-Same as ---recipient but this one is intended for use
-in the options file and may be used with
-your own user-id as an "encrypt-to-self". These keys
-are only used when there are other recipients given
-either by use of ---recipient or by the asked user id.
-No trust checking is performed for these user ids and
-even disabled keys can be used.
-
-@item ---no-encrypt-to
-Disable the use of all ---encrypt-to keys.
-
-@item -v, ---verbose
-Give more information during processing. If used
-twice, the input data is listed in detail.
-
-@item -q, ---quiet
-Try to be as quiet as possible.
-
-@item -z @code{n}, ---compress @code{n}
-Set compression level to @code{n}. A value of 0 for @code{n}
-disables compression. Default is to use the default
-compression level of zlib (normally 6).
-
-@item -t, ---textmode
-Use canonical text mode. If -t (but not
----textmode) is used together with armoring
-and signing, this enables clearsigned messages.
-This kludge is needed for PGP compatibility;
-normally you would use ---sign or --clearsign
-to selected the type of the signature.
-
-@item -n, ---dry-run
-Don't make any changes (this is not completely implemented).
-
-@item -i, ---interactive
-Prompt before overwriting any files.
-
-@item ---batch
-Use batch mode. Never ask, do not allow interactive
-commands.
-
-@item ---no-tty
-Make sure that the TTY (terminal) is never used for any output.
-This option is needed in some cases because GnuPG sometimes prints
-warnings to the TTY if ---batch is used.
-
-@item ---no-batch
-Disable batch mode. This may be of use if ---batch
-is enabled from an options file.
-
-@item ---yes
-Assume "yes" on most questions.
-
-@item ---no
-Assume "no" on most questions.
-
-@item ---default-cert-check-level @code{n}
-The default to use for the check level when signing a key.
-
-0 means you make no particular claim as to how carefully you verified
-the key.
-
-1 means you believe the key is owned by the person who claims to own
-it but you could not, or did not verify the key at all. This is
-useful for a "persona" verification, where you sign the key of a
-pseudonymous user.
-
-2 means you did casual verification of the key. For example, this
-could mean that you verified that the key fingerprint and checked the
-user ID on the key against a photo ID.
-
-3 means you did extensive verification of the key. For example, this
-could mean that you verified the key fingerprint with the owner of the
-key in person, and that you checked, by means of a hard to forge
-document with a photo ID (such as a passport) that the name of the key
-owner matches the name in the user ID on the key, and finally that you
-verified (by exchange of email) that the email address on the key
-belongs to the key owner.
-
-Note that the examples given above for levels 2 and 3 are just that:
-examples. In the end, it is up to you to decide just what "casual"
-and "extensive" mean to you.
-
-This option defaults to 0.
-
-@item ---trusted-key @code{long key ID}
-Assume that the specified key (which must be given
-as a full 8 byte key ID) is as trustworthy as one of
-your own secret keys. This option is useful if you
-don't want to keep your secret keys (or one of them)
-online but still want to be able to check the validity of a given
-recipient's or signator's key. 
-
-@item ---always-trust
-Skip key validation and assume that used keys are always fully trusted.
-You won't use this unless you have installed some external validation
-scheme. This option also suppresses the "[uncertain]" tag printed
-with signature checks when there is no evidence that the user ID
-is bound to the key.
-
-@item ---keyserver @code{name}
-Use @code{name} as your keyserver. This is the server that ---recv-keys,
----send-keys, and --search-keys will communicate with to receive keys
-from, send keys to, and search for keys on. The format of the
-@code{name} is a URI: `scheme:[//]keyservername[:port]' The scheme is
-the type of keyserver: "hkp" for the Horowitz (or compatible)
-keyservers, "ldap" for the NAI LDAP keyserver, or "mailto" for the
-Horowitz email keyserver. Note that your particular installation of
-GnuPG may have other keyserver types available as well.
-
-Most keyservers synchronize with each other, so there is generally no
-need to send keys to more than one server. Using the command "host -l
-pgp.net | grep wwwkeys" gives you a list of HKP keyservers. When
-using one of the wwwkeys servers, due to load balancing using
-round-robin DNS you may notice that you get a different key server
-each time.
-
-@item ---keyserver-options @code{parameters}
-This is a space or comma delimited string that gives options for the
-keyserver. Options can be prepended with a `no-' to give the opposite
-meaning. Valid import-options or export-options may be used here as
-well to apply to importing (---recv-key) or exporting (--send-key) a
-key from a keyserver. While not all options are available for all
-keyserver types, some common options are:
-
-@table @asis
-@item include-revoked
-When searching for a key, include keys that are marked on the
-keyserver as revoked. Note that this option is always set when using
-the NAI HKP keyserver, as this keyserver does not differentiate
-between revoked and unrevoked keys. When using the LDAP keyserver,
-this applies to both searching (---search-keys) and receiving
-(---recv-keys).
-
-@item include-disabled
-When receiving or searching for a key, include keys that are marked on
-the keyserver as disabled. Note that this option is not used with HKP
-keyservers, as they do not support disabling keys.
-
-@item include-subkeys
-When receiving a key, include subkeys in the search. Note that this
-option is not used with HKP keyservers, as they do not support
-retrieving keys by subkey id.
-
-@item use-temp-files
-On most Unix-like platforms, GnuPG communicates with the keyserver
-helper program via pipes, which is the most efficient method. This
-option forces GnuPG to use temporary files to communicate. On some
-platforms (such as Win32 and RISC OS), this option is always enabled.
-
-@item keep-temp-files
-If using `use-temp-files', do not delete the temp files after using
-them. This option is useful to learn the keyserver communication
-protocol by reading the temporary files.
-
-@item verbose
-Tell the keyserver helper program to be more verbose. This option can
-be repeated multiple times to increase the verbosity level.
-
-@item honor-http-proxy
-For keyserver schemes that use HTTP (such as HKP), try to access the
-keyserver over the proxy set with the environment variable
-"http_proxy".
-
-@item auto-key-retrieve
-This option enables the automatic retrieving of keys from a keyserver
-when verifying signatures made by keys that are not on the local
-keyring.
-
-@end table
-
-@item ---import-options @code{parameters}
-This is a space or comma delimited string that gives options for
-importing keys. Options can be prepended with a `no-' to give the
-opposite meaning. The options are:
-
-@table @asis
-@item allow-local-sigs
-Allow importing key signatures marked as "local". This is not
-generally useful unless a shared keyring scheme is being used.
-Defaults to no.
-
-@item repair-hkp-subkey-bug
-During import, attempt to repair the HKP keyserver mangling multiple
-subkeys bug. Note that this cannot completely repair the damaged key
-as some crucial data is removed by the keyserver, but it does at least
-give you back one subkey. Defaults to no for regular ---import and to
-yes for keyserver ---recv-keys.
-
-@end table
-
-@item ---export-options @code{parameters}
-This is a space or comma delimited string that gives options for
-exporting keys. Options can be prepended with a `no-' to give the
-opposite meaning. The options are:
-
-@table @asis
-@item include-non-rfc
-Include non-RFC compliant keys in the export. Defaults to yes.
-
-@item include-local-sigs
-Allow exporting key signatures marked as "local". This is not
-generally useful unless a shared keyring scheme is being used.
-Defaults to no.
-
-@item include-attributes
-Include attribute user IDs (photo IDs) while exporting. This is
-useful to export keys if they are going to be used by an OpenPGP
-program that does not accept attribute user IDs. Defaults to yes.
-
-@item include-sensitive-revkeys
-Include designated revoker information that was marked as
-"sensitive". Defaults to no.
-
-@end table
-
-@item ---show-photos
-Causes ---list-keys, --list-sigs, --list-public-keys,
----list-secret-keys, and verifying a signature to also display the
-photo ID attached to the key, if any.
-See also ---photo-viewer.
-
-@item ---no-show-photos
-Resets the ---show-photos flag.
-
-@item ---photo-viewer @code{string}
-This is the command line that should be run to view a photo ID. "%i"
-will be expanded to a filename containing the photo. "%I" does the
-same, except the file will not be deleted once the viewer exits.
-Other flags are "%k" for the key ID, "%K" for the long key ID, "%f"
-for the key fingerprint, "%t" for the extension of the image type
-(e.g. "jpg"), "%T" for the MIME type of the image (e.g. "image/jpeg"),
-and "%%" for an actual percent sign. If neither %i or %I are present,
-then the photo will be supplied to the viewer on standard input.
-
-The default viewer is "xloadimage -fork -quiet -title 'KeyID 0x%k'
-stdin"
-
-@item ---exec-path @code{string}
-Sets a list of directories to search for photo viewers and keyserver
-helpers. If not provided, keyserver helpers use the compiled-in
-default directory, and photo viewers use the $PATH environment
-variable.
-
-@item ---show-keyring
-Causes ---list-keys, --list-public-keys, and --list-secret-keys to
-display the name of the keyring a given key resides on. This is only
-useful when you're listing a specific key or set of keys. It has no
-effect when listing all keys.
-
-@item ---keyring @code{file}
-Add @code{file} to the list of keyrings.
-If @code{file} begins with a tilde and a slash, these
-are replaced by the HOME directory. If the filename
-does not contain a slash, it is assumed to be in the
-home-directory ("~/.gnupg" if ---homedir is not used).
-The filename may be prefixed with a scheme:
-
-"gnupg-ring:" is the default one.
-
-It might make sense to use it together with ---no-default-keyring.
-
-@item ---secret-keyring @code{file}
-Same as ---keyring but for the secret keyrings.
-
-@item ---homedir @code{directory}
-Set the name of the home directory to @code{directory} If this
-option is not used it defaults to "~/.gnupg". It does
-not make sense to use this in a options file. This
-also overrides the environment variable "GNUPGHOME".
-
-@item ---charset @code{name}
-Set the name of the native character set. This is used
-to convert some strings to proper UTF-8 encoding. If this option is not used, the default character set is determined
-from the current locale. A verbosity level of 3 shows the used one.
-Valid values for @code{name} are:
-
-@table @asis
-@item iso-8859-1
-This is the Latin 1 set.
-
-@item iso-8859-2
-The Latin 2 set.
-
-@item iso-8859-15
-This is currently an alias for
-the Latin 1 set.
-
-@item koi8-r
-The usual Russian set (rfc1489).
-
-@item utf-8
-Bypass all translations and assume
-that the OS uses native UTF-8 encoding.
-
-@end table
-
-@item ---utf8-strings
-@itemx ---no-utf8-strings
-Assume that the arguments are already given as UTF8 strings. The default
-(---no-utf8-strings)
-is to assume that arguments are encoded in the character set as specified
-by ---charset. These options affect all following arguments. Both options may
-be used multiple times.
-
-@item ---options @code{file}
-Read options from @code{file} and do not try to read
-them from the default options file in the homedir
-(see ---homedir). This option is ignored if used
-in an options file.
-
-@item ---no-options
-Shortcut for "---options /dev/null". This option is
-detected before an attempt to open an option file.
-Using this option will also prevent the creation of a 
-"~./gnupg" homedir.
-
-@item ---load-extension @code{name}
-Load an extension module. If @code{name} does not
-contain a slash it is searched in "/usr/local/lib/gnupg"
-Extension are in gernal not useful anymore; the use of this 
-option is deprecated.
-
-@item ---debug @code{flags}
-Set debugging flags. All flags are or-ed and @code{flags} may
-be given in C syntax (e.g. 0x0042).
-
-@item ---debug-all
-Set all useful debugging flags.
-
-@item ---status-fd @code{n}
-Write special status strings to the file descriptor @code{n}.
-See the file DETAILS in the documentation for a listing of them.
-
-@item ---logger-fd @code{n}
-Write log output to file descriptor @code{n} and not to stderr.
-
-@item ---attribute-fd @code{n}
-Write attribute subpackets to the file descriptor @code{n}. This is
-most useful for use with ---status-fd, since the status messages are
-needed to separate out the various subpackets from the stream
-delivered to the file descriptor.
-
-@item ---sk-comments
-Include secret key comment packets when exporting secret keys. This
-is a GnuPG extension to the OpenPGP standard, and is off by default.
-Please note that this has nothing to do with the comments in clear
-text signatures or armor headers.
-
-@item ---no-sk-comments
-Resets the ---sk-comments option.
-
-@item ---no-comment
-See ---sk-comments. This option is deprecated and may be removed soon.
-
-@item ---comment @code{string}
-Use @code{string} as comment string in clear text signatures.
-The default is not do write a comment string.
-
-@item ---default-comment
-Force to write the standard comment string in clear
-text signatures. Use this to overwrite a ---comment
-from a config file. This option is now obsolete because there is no
-default comment string anymore.
-
-@item ---no-version
-Omit the version string in clear text signatures.
-
-@item ---emit-version
-Force to write the version string in clear text
-signatures. Use this to overwrite a previous
----no-version from a config file.
-
-@item -N, ---notation-data @code{name=value}
-Put the name value pair into the signature as notation data.
-@code{name} must consist only of alphanumeric characters, digits
-or the underscore; the first character must not be a digit.
-@code{value} may be any printable string; it will be encoded in UTF8,
-so you should check that your ---charset is set correctly.
-If you prefix @code{name} with an exclamation mark, the notation
-data will be flagged as critical (rfc2440:5.2.3.15).
-
-@item ---show-notation
-Show key signature notations in the ---list-sigs or --check-sigs
-listings.
-
-@item ---no-show-notation
-Do not show key signature notations in the ---list-sigs or --check-sigs
-listings.
-
-@item ---set-policy-url @code{string}
-Use @code{string} as Policy URL for signatures (rfc2440:5.2.3.19).
-If you prefix it with an exclamation mark, the policy URL
-packet will be flagged as critical.
-
-@item ---show-policy-url
-Show any policy URLs set in the ---list-sigs or --check-sigs listings.
-
-@item ---no-show-policy-url
-Do not show any policy URLs set in the ---list-sigs or --check-sigs
-listings.
-
-@item ---set-filename @code{string}
-Use @code{string} as the name of file which is stored in
-messages.
-
-@item ---for-your-eyes-only
-Set the `for your eyes only' flag in the message. This causes GnuPG
-to refuse to save the file unless the ---output option is given, and
-PGP to use the "secure viewer" with a Tempest-resistant font to
-display the message. This option overrides ---set-filename.
-
-@item ---no-for-your-eyes-only
-Resets the ---for-your-eyes-only flag.
-
-@item ---use-embedded-filename
-Try to create a file with a name as embedded in the data.
-This can be a dangerous option as it allows to overwrite files.
-
-@item ---completes-needed @code{n}
-Number of completely trusted users to introduce a new
-key signer (defaults to 1).
-
-@item ---marginals-needed @code{n}
-Number of marginally trusted users to introduce a new
-key signer (defaults to 3)
-
-@item ---max-cert-depth @code{n}
-Maximum depth of a certification chain (default is 5).
-
-@item ---cipher-algo @code{name}
-Use @code{name} as cipher algorithm. Running the program
-with the command ---version yields a list of supported
-algorithms. If this is not used the cipher algorithm is
-selected from the preferences stored with the key.
-
-@item ---digest-algo @code{name}
-Use @code{name} as the message digest algorithm. Running the program
-with the command ---version yields a list of supported algorithms.
-
-@item ---cert-digest-algo @code{name}
-Use @code{name} as the message digest algorithm used when signing a
-key. Running the program with the command ---version yields a list of
-supported algorithms. Be aware that if you choose an algorithm that
-GnuPG supports but other OpenPGP implementations do not, then some
-users will not be able to use the key signatures you make, or quite
-possibly your entire key.
-
-@item ---s2k-cipher-algo @code{name}
-Use @code{name} as the cipher algorithm used to protect secret keys.
-The default cipher is CAST5. This cipher is also used for
-conventional encryption if ---cipher-algo is not given.
-
-@item ---s2k-digest-algo @code{name}
-Use @code{name} as the digest algorithm used to mangle the
-passphrases. The default algorithm is RIPE-MD-160.
-This digest algorithm is also used for conventional
-encryption if ---digest-algo is not given.
-
-@item ---s2k-mode @code{n}
-Selects how passphrases are mangled. If @code{n} is 0
-a plain passphrase (which is not recommended) will be used,
-a 1 (default) adds a salt to the passphrase and
-a 3 iterates the whole process a couple of times.
-Unless ---rfc1991 is used, this mode is also used
-for conventional encryption.
-
-@item ---simple-sk-checksum
-Secret keys are integrity protected by using a SHA-1 checksum. This
-method will be part of an enhanced OpenPGP specification but GnuPG
-already uses it as a countermeasure against certain attacks. Old
-applications don't understand this new format, so this option may be
-used to switch back to the old behaviour. Using this this option
-bears a security risk. Note that using this option only takes effect
-when the secret key is encrypted - the simplest way to make this
-happen is to change the passphrase on the key (even changing it to the
-same value is acceptable).
-
-@item ---compress-algo @code{n}
-Use compression algorithm @code{n}. Default is 2 which is RFC1950
-compression. You may use 1 to use the old zlib version (RFC1951) which
-is used by PGP. 0 disables compression. The default algorithm may give
-better results because the window size is not limited to 8K. If this
-is not used the OpenPGP behavior is used, i.e. the compression
-algorithm is selected from the preferences; note, that this can't be
-done if you do not encrypt the data.
-
-@item ---disable-cipher-algo @code{name}
-Never allow the use of @code{name} as cipher algorithm.
-The given name will not be checked so that a later loaded algorithm
-will still get disabled.
-
-@item ---disable-pubkey-algo @code{name}
-Never allow the use of @code{name} as public key algorithm.
-The given name will not be checked so that a later loaded algorithm
-will still get disabled.
-
-@item ---no-sig-cache
-Do not cache the verification status of key signatures.
-Caching gives a much better performance in key listings. However, if
-you suspect that your public keyring is not save against write
-modifications, you can use this option to disable the caching. It
-probably does not make sense to disable it because all kind of damage
-can be done if someone else has write access to your public keyring.
-
-@item ---no-sig-create-check
-GnuPG normally verifies each signature right after creation to protect
-against bugs and hardware malfunctions which could leak out bits from
-the secret key. This extra verification needs some time (about 115%
-for DSA keys), and so this option can be used to disable it.
-However, due to the fact that the signature creation needs manual
-interaction, this performance penalty does not matter in most settings.
-
-@item ---auto-check-trustdb
-If GnuPG feels that its information about the Web-of-Trust has to be
-updated, it automatically runs the ---check-trustdb command 
-internally. This may be a time consuming process.
-
-@item ---no-auto-check-trustdb
-Resets the ---auto-check-trustdb option.
-
-@item ---throw-keyid
-Do not put the keyid into encrypted packets. This option
-hides the receiver of the message and is a countermeasure
-against traffic analysis. It may slow down the decryption
-process because all available secret keys are tried.
-
-@item ---not-dash-escaped
-This option changes the behavior of cleartext signatures
-so that they can be used for patch files. You should not
-send such an armored file via email because all spaces
-and line endings are hashed too. You can not use this
-option for data which has 5 dashes at the beginning of a
-line, patch files don't have this. A special armor header
-line tells GnuPG about this cleartext signature option.
-
-@item ---escape-from-lines
-Because some mailers change lines starting with "From "
-to "<From " it is good to handle such lines in a special
-way when creating cleartext signatures. All other PGP
-versions do it this way too. This option is not enabled
-by default because it would violate rfc2440.
-
-@item ---passphrase-fd @code{n}
-Read the passphrase from file descriptor @code{n}. If you use
-0 for @code{n}, the passphrase will be read from stdin. This
-can only be used if only one passphrase is supplied.
-Don't use this option if you can avoid it.
-
-@item ---command-fd @code{n}
-This is a replacement for the deprecated shared-memory IPC mode.
-If this option is enabled, user input on questions is not expected
-from the TTY but from the given file descriptor. It should be used
-together with ---status-fd. See the file doc/DETAILS in the source
-distribution for details on how to use it.
-
-@item ---use-agent
-Try to use the GnuPG-Agent. Please note that this agent is still under
-development. With this option, GnuPG first tries to connect to the
-agent before it asks for a passphrase.
-
-@item ---gpg-agent-info
-Override the value of the environment variable
-@samp{GPG_AGENT_INFO}. This is only used when ---use-agent has been given
-
-@item ---rfc1991
-Try to be more RFC1991 (PGP 2.x) compliant.
-
-@item ---pgp2
-Set up all options to be as PGP 2.x compliant as possible, and warn if
-an action is taken (e.g. encrypting to a non-RSA key) that will create
-a message that PGP 2.x will not be able to handle. Note that `PGP
-2.x' here means `MIT PGP 2.6.2'. There are other versions of PGP 2.x
-available, but the MIT release is a good common baseline.
-
-This option implies `---rfc1991 --no-openpgp --disable-mdc
----no-force-v4-certs --no-comment --escape-from-lines --force-v3-sigs
----no-ask-sig-expire --no-ask-cert-expire --cipher-algo IDEA
----digest-algo MD5 --compress-algo 1'
-
-@item ---no-pgp2
-Resets the ---pgp2 option.
-
-@item ---pgp6
-Set up all options to be as PGP 6 compliant as possible. This
-restricts you to the ciphers IDEA (if the IDEA plugin is installed),
-3DES, and CAST5, the hashes MD5, SHA1 and RIPEMD160, and the
-compression algorithms none and ZIP. This also disables making
-signatures with signing subkeys as PGP 6 does not understand
-signatures made by signing subkeys.
-
-This option implies `---disable-mdc --no-comment --escape-from-lines
----force-v3-sigs --no-ask-sig-expire --compress-algo 1'
-
-@item ---no-pgp6
-Resets the ---pgp6 option.
-
-@item ---pgp7
-Set up all options to be as PGP 7 compliant as possible. This is
-identical to ---pgp6 except that MDCs are not disabled, and the list of
-allowable ciphers is expanded to add AES128, AES192, AES256, and
-TWOFISH.
-
-@item ---no-pgp7
-Resets the ---pgp7 option.
-
-@item ---openpgp
-Reset all packet, cipher and digest options to OpenPGP behavior. Use
-this option to reset all previous options like ---rfc1991,
----force-v3-sigs, --s2k-*, --cipher-algo, --digest-algo and
----compress-algo to OpenPGP compliant values. All PGP workarounds are
-also disabled.
-
-@item ---force-v3-sigs
-OpenPGP states that an implementation should generate v4 signatures
-but PGP versions 5 and higher only recognize v4 signatures on key
-material. This option forces v3 signatures for signatures on data.
-Note that this option overrides ---ask-sig-expire, as v3 signatures
-cannot have expiration dates.
-
-@item ---no-force-v3-sigs
-Reset the ---force-v3-sigs option.
-
-@item ---force-v4-certs
-Always use v4 key signatures even on v3 keys. This option also
-changes the default hash algorithm for v3 RSA keys from MD5 to SHA-1.
-
-@item ---no-force-v4-certs
-Reset the ---force-v4-certs option.
-
-@item ---force-mdc
-Force the use of encryption with appended manipulation code. This is
-always used with the newer ciphers (those with a blocksize greater
-than 64 bit).
-
-@item ---allow-non-selfsigned-uid
-Allow the import and use of keys with user IDs which are not
-self-signed. This is not recommended, as a non self-signed user ID is
-trivial to forge.
-
-@item ---no-allow-non-selfsigned-uid
-Reset the ---allow-non-selfsigned-uid option.
-
-@item ---allow-freeform-uid
-Disable all checks on the form of the user ID while generating a new
-one. This option should only be used in very special environments as
-it does not ensure the de-facto standard format of user IDs.
-
-@item ---ignore-time-conflict
-GnuPG normally checks that the timestamps associated with keys and
-signatures have plausible values. However, sometimes a signature seems to
-be older than the key due to clock problems. This option makes these
-checks just a warning.
-
-@item ---ignore-valid-from
-GnuPG normally does not select and use subkeys created in the future. This
-option allows the use of such keys and thus exhibits the pre-1.0.7
-behaviour. You should not use this option unless you there is some
-clock problem.
-
-@item ---ignore-crc-error
-The ASCII armor used by OpenPGP is protected by a CRC checksum against
-transmission errors. Sometimes it happens that the CRC gets mangled
-somewhere on the transmission channel but the actual content (which is
-protected by the OpenPGP protocol anyway) is still okay. This option
-will let gpg ignore CRC errors.
-
-@item ---ignore-mdc-error
-This option changes a MDC integrity protection failure into a warning.
-This can be useful if a message is partially corrupt, but it is
-necessary to get as much data as possible out of the corrupt message.
-However, be aware that a MDC protection failure may also mean that the
-message was tampered with intentionally by an attacker.
-
-@item ---lock-once
-Lock the databases the first time a lock is requested
-and do not release the lock until the process
-terminates.
-
-@item ---lock-multiple
-Release the locks every time a lock is no longer
-needed. Use this to override a previous ---lock-once
-from a config file.
-
-@item ---lock-never
-Disable locking entirely. This option should be used only in very
-special environments, where it can be assured that only one process
-is accessing those files. A bootable floppy with a stand-alone
-encryption system will probably use this. Improper usage of this
-option may lead to data and key corruption.
-
-@item ---no-random-seed-file
-GnuPG uses a file to store its internal random pool over invocations.
-This makes random generation faster; however sometimes write operations
-are not desired. This option can be used to achieve that with the cost of
-slower random generation.
-
-@item ---no-verbose
-Reset verbose level to 0.
-
-@item ---no-greeting
-Suppress the initial copyright message but do not
-enter batch mode.
-
-@item ---no-secmem-warning
-Suppress the warning about "using insecure memory".
-
-@item ---no-permission-warning
-Suppress the warning about unsafe file permissions.
-
-@item ---no-mdc-warning
-Suppress the warning about missing MDC integrity protection.
-
-@item ---no-armor
-Assume the input data is not in ASCII armored format.
-
-@item ---no-default-keyring
-Do not add the default keyrings to the list of
-keyrings.
-
-@item ---skip-verify
-Skip the signature verification step. This may be
-used to make the decryption faster if the signature
-verification is not needed.
-
-@item ---with-colons
-Print key listings delimited by colons. Note, that the output will be
-encoded in UTF-8 regardless of any ---charset setting.
-
-@item ---with-key-data
-Print key listings delimited by colons (like ---with-colons) and print the public key data.
-
-@item ---with-fingerprint
-Same as the command ---fingerprint but changes only the format of the output
-and may be used together with another command.
-
-@item ---fast-list-mode
-Changes the output of the list commands to work faster; this is achieved
-by leaving some parts empty. Some applications don't need the user ID and
-the trust information given in the listings. By using this options they
-can get a faster listing. The exact behaviour of this option may change
-in future versions.
-
-@item ---fixed-list-mode
-Do not merge user ID and primary key in ---with-colon listing mode and
-print all timestamps as seconds since 1970-01-01.
-
-@item ---list-only
-Changes the behaviour of some commands. This is like ---dry-run but
-different in some cases. The semantic of this command may be extended in
-the future. Currently it only skips the actual decryption pass and
-therefore enables a fast listing of the encryption keys.
-
-@item ---no-literal
-This is not for normal use. Use the source to see for what it might be useful.
-
-@item ---set-filesize
-This is not for normal use. Use the source to see for what it might be useful.
-
-@item ---emulate-md-encode-bug
-GnuPG versions prior to 1.0.2 had a bug in the way a signature was encoded.
-This options enables a workaround by checking faulty signatures again with
-the encoding used in old versions. This may only happen for ElGamal signatures
-which are not widely used.
-
-@item ---show-session-key
-Display the session key used for one message. See ---override-session-key
-for the counterpart of this option.
-
-We think that Key-Escrow is a Bad Thing; however the user should
-have the freedom to decide whether to go to prison or to reveal the content of
-one specific message without compromising all messages ever encrypted for one
-secret key. DON'T USE IT UNLESS YOU ARE REALLY FORCED TO DO SO.
-
-@item ---override-session-key @code{string} 
-Don't use the public key but the session key @code{string}. The format of this
-string is the same as the one printed by ---show-session-key. This option
-is normally not used but comes handy in case someone forces you to reveal the
-content of an encrypted message; using this option you can do this without
-handing out the secret key.
-
-@item ---ask-sig-expire
-When making a data signature, prompt for an expiration time. If this
-option is not specified, the expiration time is "never".
-
-@item ---no-ask-sig-expire
-Resets the ---ask-sig-expire option.
-
-@item ---ask-cert-expire
-When making a key signature, prompt for an expiration time. If this
-option is not specified, the expiration time is "never".
-
-@item ---no-ask-cert-expire
-Resets the ---ask-cert-expire option.
-
-@item ---expert
-Allow the user to do certain nonsensical or "silly" things like
-signing an expired or revoked key, or certain potentially incompatible
-things like generating deprecated key types. This also disables
-certain warning messages about potentially incompatible actions. As
-the name implies, this option is for experts only. If you don't fully
-understand the implications of what it allows you to do, leave this
-off.
-
-@item ---no-expert
-Resets the ---expert option.
-
-@item ---merge-only
-Don't insert new keys into the keyrings while doing an import.
-
-@item ---allow-secret-key-import
-This is an obsolete option and is not used anywhere.
-
-@item ---try-all-secrets
-Don't look at the key ID as stored in the message but try all secret keys in
-turn to find the right decryption key. This option forces the behaviour as
-used by anonymous recipients (created by using ---throw-keyid) and might come
-handy in case where an encrypted message contains a bogus key ID.
-
-@item ---enable-special-filenames
-This options enables a mode in which filenames of the form
-@file{-&n}, where n is a non-negative decimal number,
-refer to the file descriptor n and not to a file with that name.
-
-@item ---no-expensive-trust-checks
-Experimental use only.
-
-@item ---group @code{name=value1 value2 value3 ...}
-Sets up a named group, which is similar to aliases in email programs.
-Any time the group name is a receipient (-r or ---recipient), it will
-be expanded to the values specified.
-The values are @code{key IDs} or fingerprints, but any key description
-is accepted. Note that a value with spaces in it will be treated as
-two different values. Note also there is only one level of expansion
-- you cannot make an group that points to another group.
-
-@item ---preserve-permissions
-Don't change the permissions of a secret keyring back to user
-read/write only. Use this option only if you really know what you are doing.
-
-@item ---personal-cipher-preferences @code{string}
-Set the list of personal cipher preferences to @code{string}, this list
-should be a string similar to the one printed by the command "pref" in
-the edit menu. This allows the user to factor in their own preferred
-algorithms when algorithms are chosen via recipient key preferences.
-
-@item ---personal-digest-preferences @code{string}
-Set the list of personal digest preferences to @code{string}, this list
-should be a string similar to the one printed by the command "pref" in
-the edit menu. This allows the user to factor in their own preferred
-algorithms when algorithms are chosen via recipient key preferences.
-
-@item ---personal-compress-preferences @code{string}
-Set the list of personal compression preferences to @code{string}, this
-list should be a string similar to the one printed by the command
-"pref" in the edit menu. This allows the user to factor in their own
-preferred algorithms when algorithms are chosen via recipient key
-preferences.
-
-@item ---default-preference-list @code{string}
-Set the list of default preferences to @code{string}, this list should
-be a string similar to the one printed by the command "pref" in the
-edit menu. This affects both key generation and "updpref" in the edit
-menu.
-
-@end table
-
-@majorheading How to specify a user ID
-There are different ways on how to specify a user ID to GnuPG;
-here are some examples:
-
-@table @asis
-@item 
-@item 234567C4
-@itemx 0F34E556E
-@itemx 01347A56A
-@itemx 0xAB123456
-Here the key ID is given in the usual short form.
-
-@item 234AABBCC34567C4
-@itemx 0F323456784E56EAB
-@itemx 01AB3FED1347A5612
-@itemx 0x234AABBCC34567C4
-Here the key ID is given in the long form as used by OpenPGP
-(you can get the long key ID using the option ---with-colons).
-
-@item 1234343434343434C434343434343434
-@itemx 123434343434343C3434343434343734349A3434
-@itemx 0E12343434343434343434EAB3484343434343434
-@itemx 0xE12343434343434343434EAB3484343434343434
-The best way to specify a key ID is by using the fingerprint of
-the key. This avoids any ambiguities in case that there are duplicated
-key IDs (which are really rare for the long key IDs).
-
-@item =Heinrich Heine <heinrichh@@uni-duesseldorf.de>
-Using an exact to match string. The equal sign indicates this.
-
-@item <heinrichh@@uni-duesseldorf.de>
-Using the email address part which must match exactly. The left angle bracket
-indicates this email address mode.
-
-@item +Heinrich Heine duesseldorf
-All words must match exactly (not case sensitive) but can appear in
-any order in the user ID. Words are any sequences of letters,
-digits, the underscore and all characters with bit 7 set.
-
-@item Heine
-@itemx *Heine
-By case insensitive substring matching. This is the default mode but
-applications may want to explicitly indicate this by putting the asterisk
-in front.
-
-@end table
-
-Note that you can append an exclamation mark to key IDs or
-fingerprints. This flag tells GnuPG to use exactly the given primary
-or secondary key and not to try to figure out which secondary or
-primary key to use.
-
-@majorheading RETURN VALUE
-The program returns 0 if everything was fine, 1 if at least
-a signature was bad, and other error codes for fatal errors.
-
-@majorheading EXAMPLES
-@table @asis
-@item gpg -se -r @code{Bob} @code{file}
-sign and encrypt for user Bob
-
-@item gpg ---clearsign @code{file}
-make a clear text signature
-
-@item gpg -sb @code{file}
-make a detached signature
-
-@item gpg ---list-keys @code{user_ID}
-show keys
-
-@item gpg ---fingerprint @code{user_ID}
-show fingerprint
-
-@item gpg ---verify @code{pgpfile}
-@itemx gpg ---verify @code{sigfile} @code{files}
-Verify the signature of the file but do not output the data. The second form
-is used for detached signatures, where @code{sigfile} is the detached
-signature (either ASCII armored of binary) and @code{files} are the signed
-data; if this is not given the name of the file holding the signed data is
-constructed by cutting off the extension (".asc" or ".sig") of
-@code{sigfile} or by asking the user for the filename.
-
-@end table
-
-@majorheading ENVIRONMENT
-@table @asis
-@item HOME
-Used to locate the default home directory.
-
-@item GNUPGHOME
-If set directory used instead of "~/.gnupg".
-
-@item GPG_AGENT_INFO
-Used to locate the gpg-agent; only honored when
----use-agent is set. The value consists of 3 colon delimited fields: 
-The first is the path to the Unix Domain Socket, the second the PID of
-the gpg-agent and the protocol version which should be set to 1. When
-starting the gpg-agent as described in its documentation, this
-variable is set to the correct value. The option ---gpg-agent-info can
-be used to overide it.
-
-@item http_proxy
-Only honored when the keyserver-option
-honor-http-proxy is set.
-
-@end table
-
-@majorheading FILES
-@table @asis
-@item ~/.gnupg/secring.gpg
-The secret keyring
-
-@item ~/.gnupg/secring.gpg.lock
-and the lock file
-
-@item ~/.gnupg/pubring.gpg
-The public keyring
-
-@item ~/.gnupg/pubring.gpg.lock
-and the lock file
-
-@item ~/.gnupg/trustdb.gpg
-The trust database
-
-@item ~/.gnupg/trustdb.gpg.lock
-and the lock file
-
-@item ~/.gnupg/random_seed
-used to preserve the internal random pool
-
-@item ~/.gnupg/gpg.conf
-Default configuration file
-
-@item ~/.gnupg/options
-Old style configuration file; only used when gpg.conf
-is not found
-
-@item /usr[/local]/share/gnupg/options.skel
-Skeleton options file
-
-@item /usr[/local]/lib/gnupg/
-Default location for extensions
-
-@end table
-
-@majorheading WARNINGS
-Use a *good* password for your user account and a *good* passphrase
-to protect your secret key. This passphrase is the weakest part of the
-whole system. Programs to do dictionary attacks on your secret keyring
-are very easy to write and so you should protect your "~/.gnupg/"
-directory very well.
-
-Keep in mind that, if this program is used over a network (telnet), it
-is *very* easy to spy out your passphrase!
-
-If you are going to verify detached signatures, make sure that the
-program knows about it; either be giving both filenames on the
-commandline or using @samp{-} to specify stdin.
-
-@majorheading BUGS
-On many systems this program should be installed as setuid(root). This
-is necessary to lock memory pages. Locking memory pages prevents the
-operating system from writing memory pages to disk. If you get no
-warning message about insecure memory your operating system supports
-locking without being root. The program drops root privileges as soon
-as locked memory is allocated.
-
-@bye
diff --git a/doc/gpgv.sgml b/doc/gpgv.sgml
deleted file mode 100644
index 4119b41dc..000000000
--- a/doc/gpgv.sgml
+++ /dev/null
@@ -1,225 +0,0 @@
-<!-- gpgv.sgml - the man page for GnuPG
-    Copyright (C) 2000, 2001 Free Software Foundation, Inc.
-
-    This file is part of GnuPG.
-
-    GnuPG 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.
-
-    GnuPG 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 this program; if not, write to the Free Software
-    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
--->
-<!-- This file should be processed by docbook-to-man to
-     create a manual page.  This program has currently the bug
-     not to remove leading white space. So this source file does
-     not look very pretty
-
-    FIXME: generated a file with entity (e.g. pathnames) from the
-    configure scripts and include it here
--->
-
-
-<!DOCTYPE refentry PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
-<!entity ParmDir "<parameter>directory</parameter>">
-<!entity ParmFile "<parameter>file</parameter>">
-<!entity OptParmFile "<optional>&ParmFile;</optional>">
-<!entity ParmFiles "<parameter>files</parameter>">
-<!entity OptParmFiles "<optional>&ParmFiles;</optional>">
-<!entity ParmNames "<parameter>names</parameter>">
-<!entity OptParmNames "<optional>&ParmNames;</optional>">
-<!entity ParmName  "<parameter>name</parameter>">
-<!entity OptParmName  "<optional>&ParmName;</optional>">
-<!entity ParmKeyIDs "<parameter>key IDs</parameter>">
-<!entity ParmN	    "<parameter>n</parameter>">
-<!entity ParmFlags  "<parameter>flags</parameter>">
-<!entity ParmString "<parameter>string</parameter>">
-<!entity ParmValue  "<parameter>value</parameter>">
-<!entity ParmNameValue	"<parameter>name=value</parameter>">
-]>
-
-<refentry id="gpgv">
-<refmeta>
-  <refentrytitle>gpgv</refentrytitle>
-  <manvolnum>1</manvolnum>
-  <refmiscinfo class="gnu">GNU Tools</refmiscinfo>
-</refmeta>
-<refnamediv>
-  <refname/gpgv/
-  <refpurpose>signature verification tool</>
-</refnamediv>
-<refsynopsisdiv>
-  <synopsis>
-<command>gpgv</>
- <optional><parameter/options/</optional>
- <optional><parameter/signed files/</optional>
-  </synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-    <title>DESCRIPTION</title>
-    <para>
-<command/gpgv/ is the OpenPGP signature checking tool.
-    </para>
-    <para>
-This program is a stripped down version of <command/gpg/ which is only
-able
-to check signatures.  It is somewhat smaller than the full blown
-<command/gpg/ and uses a different (and more simple way) to check that
-the public keys used to made the signature are trustworth.  There is
-no options files and only very few options are implemented.
-</para>
-<para>
-<command/gpgv/ assumes that all keys in the keyring are trustworty.
-It uses by default a keyring named <filename/trustedkeys.gpg/ which is
-assumed to be in the home directory as defined by GnuPG or set by an
-option or an environment variable.  An option may be used to specify
-another keyring or even multiple keyrings.
-</para>
-</refsect1>
-
-<refsect1>
-<title>OPTIONS</title>
-<para>
-<command/gpgv/ recognizes these options:
-</para>
-
-<variablelist>
-
-
-<varlistentry>
-<term>-v, --verbose</term>
-<listitem><para>
-Give more information during processing. If used
-twice, the input data is listed in detail.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>-q, --quiet</term>
-<listitem><para>
-Try to be as quiet as possible.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--keyring &ParmFile;</term>
-<listitem><para>
-Add &ParmFile to the list of keyrings.
-If &ParmFile begins with a tilde and a slash, these
-are replaced by the HOME directory. If the filename
-does not contain a slash, it is assumed to be in the
-home-directory ("~/.gnupg" if --homedir is not used).
-The filename may be prefixed with a scheme:</para>
-<para>"gnupg-ring:" is the default one.</para>
-<para>It might make sense to use it together with --no-default-keyring.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--homedir &ParmDir;</term>
-<listitem><para>
-Set the name of the home directory to &ParmDir; If this
-option is not used it defaults to "~/.gnupg". It does
-not make sense to use this in a options file. This
-also overrides the environment variable "GNUPGHOME".
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--status-fd &ParmN;</term>
-<listitem><para>
-Write special status strings to the file descriptor &ParmN;.
-See the file DETAILS in the documentation for a listing of them.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--logger-fd &ParmN;</term>
-<listitem><para>
-Write log output to file descriptor &ParmN; and not to stderr.
-</para></listitem></varlistentry>
-
-
-<varlistentry>
-<term>--ignore-time-conflict</term>
-<listitem><para>
-GnuPG normally checks that the timestamps associated with keys and
-signatures have plausible values.  However, sometimes a signature seems to
-be older than the key due to clock problems.  This option makes these
-checks just a warning.
-</para></listitem></varlistentry>
-
-
-</variablelist>
-</refsect1>
-
-
-<refsect1>
-    <title>RETURN VALUE</title>
-    <para>
-The program returns 0 if everything was fine, 1 if at least
-one signature was bad, and other error codes for fatal errors.
-    </para>
-</refsect1>
-
-<refsect1>
-    <title>EXAMPLES</title>
-    <variablelist>
-
-<varlistentry>
-<term>gpgv <parameter/pgpfile/</term>
-<term>gpgv <parameter/sigfile/ &OptParmFiles;</term>
-<listitem><para>
-Verify the signature of the file. The second form
-is used for detached signatures, where <parameter/sigfile/ is the detached
-signature (either ASCII armored or binary) and &OptParmFiles are the signed
-data; if this is not given the name of the file holding the signed data is
-constructed by cutting off the extension (".asc", ".sig" or ".sign") from
-<parameter/sigfile/.
-</para></listitem></varlistentry>
-
-    </variablelist>
-</refsect1>
-
-
-<refsect1>
-    <title>ENVIRONMENT</title>
-
-    <variablelist>
-<varlistentry>
-<term>HOME</term>
-<listitem><para>Used to locate the default home directory.</para></listitem>
-</varlistentry>
-<varlistentry>
-<term>GNUPGHOME</term>
-<listitem><para>If set directory used instead of "~/.gnupg".</para></listitem>
-</varlistentry>
-
-    </variablelist>
-
-</refsect1>
-
-<refsect1>
-    <title>FILES</title>
-    <variablelist>
-
-<varlistentry>
-<term>~/.gnupg/trustedkeys.gpg</term>
-<listitem><para>The default keyring with the allowed keys</para></listitem>
-</varlistentry>
-
-    </variablelist>
-</refsect1>
-
-<!-- SEE ALSO  not yet needed-->
-
-</refentry>
-
diff --git a/doc/gpgv.texi b/doc/gpgv.texi
deleted file mode 100644
index 91e2fcadf..000000000
--- a/doc/gpgv.texi
+++ /dev/null
@@ -1,119 +0,0 @@
-\input texinfo
-@c This Texinfo document has been automatically generated by
-@c docbook2texi from a DocBook documentation.  The tool used
-@c can be found at:
-@c <URL:http://shell.ipoline.com/~elmert/hacks/docbook2X/>
-@c Please send any bug reports, improvements, comments, 
-@c patches, etc. to Steve Cheng <steve@ggi-project.org>.
-
-@setfilename gpgv.info
-@dircategory GnuPG
-@direntry
-* gpgv: (gpgv).                       GnuPG signature verification tool.
-@end direntry
-
-@node top
-@top gpgv
-@menu
-@end menu
-
-@majorheading Name
-gpgv ---- signature verification tool
-
-@majorheading Synopsis
-
-@majorheading DESCRIPTION
-@code{gpgv} is the OpenPGP signature checking tool.
-
-This program is a stripped down version of @code{gpg} which is only
-able
-to check signatures. It is somewhat smaller than the full blown
-@code{gpg} and uses a different (and more simple way) to check that
-the public keys used to made the signature are trustworth. There is
-no options files and only very few options are implemented.
-
-@code{gpgv} assumes that all keys in the keyring are trustworty.
-It uses by default a keyring named @file{trustedkeys.gpg} which is
-assumed to be in the home directory as defined by GnuPG or set by an
-option or an environment variable. An option may be used to specify
-another keyring or even multiple keyrings.
-
-@majorheading OPTIONS
-@code{gpgv} recognizes these options:
-
-@table @asis
-@item -v, ---verbose
-Give more information during processing. If used
-twice, the input data is listed in detail.
-
-@item -q, ---quiet
-Try to be as quiet as possible.
-
-@item ---keyring @code{file}
-Add @code{file} to the list of keyrings.
-If @code{file} begins with a tilde and a slash, these
-are replaced by the HOME directory. If the filename
-does not contain a slash, it is assumed to be in the
-home-directory ("~/.gnupg" if ---homedir is not used).
-The filename may be prefixed with a scheme:
-
-"gnupg-ring:" is the default one.
-
-It might make sense to use it together with ---no-default-keyring.
-
-@item ---homedir @code{directory}
-Set the name of the home directory to @code{directory} If this
-option is not used it defaults to "~/.gnupg". It does
-not make sense to use this in a options file. This
-also overrides the environment variable "GNUPGHOME".
-
-@item ---status-fd @code{n}
-Write special status strings to the file descriptor @code{n}.
-See the file DETAILS in the documentation for a listing of them.
-
-@item ---logger-fd @code{n}
-Write log output to file descriptor @code{n} and not to stderr.
-
-@item ---ignore-time-conflict
-GnuPG normally checks that the timestamps associated with keys and
-signatures have plausible values. However, sometimes a signature seems to
-be older than the key due to clock problems. This option makes these
-checks just a warning.
-
-@end table
-
-@majorheading RETURN VALUE
-The program returns 0 if everything was fine, 1 if at least
-one signature was bad, and other error codes for fatal errors.
-
-@majorheading EXAMPLES
-@table @asis
-@item gpgv @code{pgpfile}
-@itemx gpgv @code{sigfile} @code{files}
-Verify the signature of the file. The second form
-is used for detached signatures, where @code{sigfile} is the detached
-signature (either ASCII armored or binary) and @code{files} are the signed
-data; if this is not given the name of the file holding the signed data is
-constructed by cutting off the extension (".asc", ".sig" or ".sign") from
-@code{sigfile}.
-
-@end table
-
-@majorheading ENVIRONMENT
-@table @asis
-@item HOME
-Used to locate the default home directory.
-
-@item GNUPGHOME
-If set directory used instead of "~/.gnupg".
-
-@end table
-
-@majorheading FILES
-@table @asis
-@item ~/.gnupg/trustedkeys.gpg
-The default keyring with the allowed keys
-
-@end table
-
-@bye
diff --git a/doc/gph/ChangeLog b/doc/gph/ChangeLog
deleted file mode 100644
index 0d42fa163..000000000
--- a/doc/gph/ChangeLog
+++ /dev/null
@@ -1,9 +0,0 @@
-Tue Sep  7 16:18:03 1999  Werner Koch  (wk@gnupg.org)
-
-	* Makefile.am: Ugly workarounds to do a VPATH build.
-
-Fri Sep  3 13:24:45 1999  Werner Koch  (wk@gnupg.org)
-
-	* Makefile.am: New
-
-
diff --git a/doc/gph/Makefile.am b/doc/gph/Makefile.am
deleted file mode 100644
index d36b0013a..000000000
--- a/doc/gph/Makefile.am
+++ /dev/null
@@ -1,54 +0,0 @@
-# GPH - GNU Privacy Handbook
-
-PARTS = manual.sgml c1.sgml c2.sgml c3.sgml c4.sgml c5.sgml c6.sgml c7.sgml \
-	signatures.fig signatures.jpg.asc
-
-EXTRA_DIST = $(PARTS) index.html
-#BUILT_SOURCES = index.html
-
-all-local: ./signatures.jpg
-
-./signatures.jpg: $(srcdir)/signatures.jpg.asc
-	../../g10/gpg --yes --dearmor \
-		      -o ./signatures.jpg $(srcdir)/signatures.jpg.asc
-	-test -d manual && cp ./signatures.jpg ./manual/signatures.jpg
-
-
-index.html: $(PARTS)
-	@set -e; \
-	   for i in $(PARTS); do \
-	     [ -f $$i ] || cat /dev/null $(srcdir)/$$i >./$$i ; \
-	   done
-	db2html manual.sgml
-	echo '<html><body>' >index.html
-	echo '<ul>'         >>index.html
-	echo '<li><a href="manual/book1.html">GnuPG User Manual</a>' >>index.html
-	echo '</ul>'          >>index.html
-	echo '</body></html>' >>index.html
-	-rm -r manual.junk
-	-rm manual/signatures.jpg
-##    (cd manual; rm -r stylesheet-images; ls | grep -v distfiles >distfiles)
-
-
-dist-hook: index.html
-
-
-%.dvi: %.sgml
-	db2dvi $<
-
-%.ps: %.dvi
-	dvips -o $@ $<
-
-%/%.html: %.sgml
-	db2html $<
-
-
-%.png: %.fig
-	fig2dev -L png $< $@
-
-%.jpg: %.fig
-	fig2dev -L jpeg $< $@
-
-%.eps: %.fig
-	fig2dev -L ps  $< $@
-
diff --git a/doc/gph/c1.sgml b/doc/gph/c1.sgml
deleted file mode 100644
index 2839f7c62..000000000
--- a/doc/gph/c1.sgml
+++ /dev/null
@@ -1,627 +0,0 @@
-<chapter id="intro" xreflabel="1">
-<docinfo>
-<date>
-$Id$
-</date>
-</docinfo>
-<title>
-Getting Started
-</title>
-
-<para>
-&Gnupg; is a tool for secure communication.
-This chapter is a quick-start guide that covers the core functionality
-of &gnupg;.
-This includes keypair creation, exchanging and verifying keys, encrypting
-and decrypting documents, and making and verifying signatures.
-It does not explain in detail the concepts behind public-key cryptography,
-encryption, and digital signatures.
-This is covered in Chapter <xref linkend="concepts">.
-It also does not explain how to use &gnupg; wisely.
-This is covered in Chapters <xref linkend="management"> and 
-<xref linkend="wise">.
-</para>
-
-<para>
-&Gnupg; uses public-key cryptography so that users may communicate securely.
-In a public-key system, each user has a public/private keypair.
-A user's private key is kept secret; it need never be revealed.
-The public key may be given to anyone with whom the user wants to
-communicate.
-&Gnupg; uses a somewhat more sophisticated scheme in which a user has
-a primary keypair and then zero or more additional subordinate keypairs.
-The primary and subordinate keypairs are bundled to facilitate key
-management and the bundle can often be considered simply as one keypair.
-</para>
-
-<sect1>
-<title>
-Generating a new keypair
-</title>
-
-<para>
-The command-line option <link linkend="gen-key"><option>--gen-key</option></link>
-is used to create a new primary keypair.
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --gen-key</userinput>
-gpg (GnuPG) 0.9.4; Copyright (C) 1999 Free Software Foundation, Inc.
-This program comes with ABSOLUTELY NO WARRANTY.
-This is free software, and you are welcome to redistribute it
-under certain conditions. See the file COPYING for details.
-
-Please select what kind of key you want:
-   (1) DSA and ElGamal (default)
-   (2) DSA (sign only)
-   (4) ElGamal (sign and encrypt)
-Your selection?
-</screen>
-
-<!--
-REWRITE
-From Thomas Zander (zander@microweb.nl):
-In GPG you can create 3 type of keypairs. A keypair is the combination
-of a publ ic key and a private key, see chapter X. A DSA keypair can
-only be used to sign a message. A ElGamal subordinate keypair can be
-used for encryption as well as s igning, but is not as compatible with
-former standards.
-
-Option 1 creates 2 keypairs; a DSA (signing) and a ElGamal (Encryption).
-Option 2 creates a DSA keypair (Signing)
-Option 4 creates a ElGemal keypair (Signing & Encryption).
-
-note: option 3 xxxx
-
-This doesn't quite work, but I agree the following paragraph is rough.
--->
-
-&Gnupg; is able to create several different types of keypairs, but a primary
-key must be capable of making signatures.
-There are therefore only three options.
-Option 1 actually creates two keypairs.
-A DSA keypair is the primary keypair usable only for making signatures.
-An ElGamal subordinate keypair is also created for encryption. 
-Option 2 is similar but creates only a DSA keypair.
-Option 4<footnote><para>Option 3 is to generate an ElGamal keypair that is
-not usable for making signatures.</para></footnote> creates a single ElGamal 
-keypair usable for both making signatures and performing encryption.
-In all cases it is possible to later add additional subkeys for encryption
-and signing.
-For most users the default option is fine.
-</para>
-
-<para>
-You must also choose a key size.
-The size of a DSA key must be between 512 and 1024 bits, and an ElGamal
-key may be of any size.
-&Gnupg;, however, requires that keys be no smaller than 768 bits.
-Therefore, if Option 1 was chosen and you choose a keysize larger than
-1024 bits, the ElGamal key will have the requested size, but the DSA
-key will be 1024 bits.
-
-<screen width="80">
-About to generate a new ELG-E keypair.
-              minimum keysize is  768 bits
-              default keysize is 1024 bits
-    highest suggested keysize is 2048 bits
-What keysize do you want? (1024)
-</screen>
-
-The longer the key the more secure it is against brute-force attacks,
-but for almost all purposes the default keysize is adequate since
-it would be cheaper to circumvent the encryption than try to break it.
-Also, encryption and decryption will be slower as the
-key size is increased, and a larger keysize may affect signature length.
-Once selected, the keysize can never be changed.
-</para>
-
-<para>
-Finally, you must choose an expiration date.
-If Option 1 was chosen, the expiration date will be used for both the
-ElGamal and DSA keypairs.
-
-<screen width="80">
-Please specify how long the key should be valid.
-         0 = key does not expire
-      &lt;n>  = key expires in n days
-      &lt;n>w = key expires in n weeks
-      &lt;n>m = key expires in n months
-      &lt;n>y = key expires in n years
-Key is valid for? (0) 
-</screen>
-
-For most users a key that does not expire is adequate.
-The expiration time should be chosen with care, however,
-since although it is possible to change the expiration date after the key
-is created, it may be difficult to communicate a change
-to users who have your public key.
-</para>
-
-<para>
-You must provide a user ID in addition to the key parameters.
-The user ID is used to associate the key being created with a real
-person.
-
-<screen width="80">
-You need a User-ID to identify your key; the software constructs the user id
-from Real Name, Comment and Email Address in this form:
-    "Heinrich Heine (Der Dichter) &lt;heinrichh@duesseldorf.de>"
-
-Real name: 
-</screen>
-
-Only one user ID is created when a key is created, but it is possible
-to create additional user IDs if you want to use the key in two or
-more contexts, &eg;, as an employee at work and a political activist
-on the side.
-A user ID should be created carefully since it cannot be edited after
-it is created.
-</para>
-
-<para>
-&Gnupg; needs a passphrase to protect the primary and subordinate 
-private keys that you keep in your possession.
-
-<screen width="80">
-You need a Passphrase to protect your private key.    
-
-Enter passphrase: 
-</screen>
-
-There is no limit on the length of a passphrase, and it should be
-carefully chosen.
-From the perspective of security, the passphrase to unlock the private
-key is one of the weakest points in &gnupg; (and other public-key 
-encryption systems as well) since it is the only protection you 
-have if another individual gets your private key.
-Ideally, the passphrase should not use words from a dictionary and
-should mix the case of alphabetic characters as well as use 
-non-alphabetic characters.
-A good passphrase is crucial to the secure use of &gnupg;.
-</para>
-
-<sect2 id="revocation">
-<title>
-Generating a revocation certificate
-</title>
-
-<para>
-After your keypair is created you should immediately generate a revocation
-certificate for the primary public key using the option
-<link linkend="gen-revoke"><option>--gen-revoke</option></link>.
-If you forget your passphrase or if your private key is compromised 
-or lost, this revocation certificate may be published to notify others
-that the public key should no longer be used.
-A revoked public key can still be used to verify signatures made
-by you in the past, but it cannot be used to encrypt future messages
-to you.
-It also does not affect your ability to decrypt messages sent to
-you in the past if you still do have access to the private key.
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --output revoke.asc --gen-revoke mykey</userinput>
-[...]
-</screen>
-
-The argument <userinput>mykey</userinput> must be a <emphasis>key
-specifier</emphasis>,
-either the key ID of your primary keypair or any part of a user ID
-that identifies your keypair.
-The generated certificate will be left in the file
-<parameter>revoke.asc</parameter>.
-If the <link linkend="output"><option>--output</option></link> option is 
-omitted, the result will be placed on standard output.
-Since the certificate is short, you may wish to print a hardcopy of
-the certificate to store somewhere safe such as your safe deposit box.
-The certificate should not be stored where others can access it since
-anybody can publish the revocation certificate and render the
-corresponding public key useless.
-</para>
-</sect2>
-</sect1>
-
-<sect1>
-<title>
-Exchanging keys
-</title>
-
-<para>
-To communicate with others you must exchange public keys.
-To list the keys on your public keyring use the command-line 
-option <link linkend="list-keys"><option>--list-keys</option></link>.
-</para>
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --list-keys</userinput>
-/users/alice/.gnupg/pubring.gpg
----------------------------------------
-pub  1024D/BB7576AC 1999-06-04 Alice (Judge) &lt;alice@cyb.org>
-sub  1024g/78E9A8FA 1999-06-04
-</screen>
-
-<sect2>
-<title>
-Exporting a public key
-</title>
-
-<para>
-To send your public key to a correspondent you must first export it.
-The command-line option <link linkend="export"><option>--export</option></link>
-is used to do this.
-It takes an additional argument identifying the public key to export.
-As with the <option>--gen-revoke</option> option, either the key ID or any part of
-the user ID may be used to identify the key to export.
-</para>
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --output alice.gpg --export alice@cyb.org</userinput>
-</screen>
-
-<para>
-The key is exported in a binary format, but this can be inconvenient
-when the key is to be sent though email or published on a web page.
-&Gnupg; therefore supports a command-line option 
-<link linkend="armor"><option>--armor</option></link><footnote>
-<para>Many
-command-line options that are frequently used can also be set in a
-<link linkend="optionsfile">configuration file</link>.
-</para>
-</footnote>
-that that 
-causes output to be generated in an ASCII-armored format similar to
-uuencoded documents.
-In general, any output from &gnupg;, &eg;, keys, encrypted documents, and
-signatures, can be ASCII-armored by adding the <option>--armor</option> option.
-</para>
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --armor --export alice@cyb.org</userinput>
------BEGIN PGP PUBLIC KEY BLOCK-----
-Version: GnuPG v0.9.7 (GNU/Linux)
-Comment: For info see http://www.gnupg.org
-
-[...]
------END PGP PUBLIC KEY BLOCK-----
-</screen>
-</sect2>
-
-<sect2>
-<title>
-Importing a public key
-</title>
-
-<para>
-A public key may be added to your public keyring with the
-<link linkend="import"><option>--import</option></link> option.
-</para>
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --import blake.gpg</userinput>
-gpg: key 9E98BC16: public key imported
-gpg: Total number processed: 1
-gpg:               imported: 1
-<prompt>alice%</prompt> <userinput>gpg --list-keys</userinput>
-/users/alice/.gnupg/pubring.gpg
----------------------------------------
-pub  1024D/BB7576AC 1999-06-04 Alice (Judge) &lt;alice@cyb.org>
-sub  1024g/78E9A8FA 1999-06-04
-
-pub  1024D/9E98BC16 1999-06-04 Blake (Executioner) &lt;blake@cyb.org>
-sub  1024g/5C8CBD41 1999-06-04
-</screen>
-
-<para>
-Once a key is imported it should be validated.
-&Gnupg; uses a powerful and flexible trust model that does not require
-you to personally validate each key you import.
-Some keys may need to be personally validated, however.
-A key is validated by verifying the key's fingerprint and then signing
-the key to certify it as a valid key.
-A key's fingerprint can be quickly viewed with the
-<link linkend="fingerprint"><option>--fingerprint</option></link>
-command-line option, but in order to certify the key you must edit it.
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --edit-key blake@cyb.org</userinput>
-
-pub  1024D/9E98BC16  created: 1999-06-04 expires: never      trust: -/q
-sub  1024g/5C8CBD41  created: 1999-06-04 expires: never     
-(1)  Blake (Executioner) &lt;blake@cyb.org>
-
-<prompt>Command></prompt> <userinput>fpr</userinput>
-pub  1024D/9E98BC16 1999-06-04 Blake (Executioner) &lt;blake@cyb.org>
-             Fingerprint: 268F 448F CCD7 AF34 183E  52D8 9BDE 1A08 9E98 BC16
-</screen>
-
-Key verification is a weak point in public-key cryptography, so you
-must be sure that the fingerprint is correct.
-The fingerprint displayed should be checked with the key's owner.
-This may be done in person or over the phone or through any other means
-as long as you can guarantee that you are communicating with the key's
-true owner.
-Once verified you may sign the key to validate it.
-</para>
-
-<screen width="80">
-<prompt>Command></prompt> <userinput>sign</userinput>
-             
-pub  1024D/9E98BC16  created: 1999-06-04 expires: never      trust: -/q
-             Fingerprint: 268F 448F CCD7 AF34 183E  52D8 9BDE 1A08 9E98 BC16
-
-     Blake (Executioner) &lt;blake@cyb.org>
-
-Are you really sure that you want to sign this key
-with your key: "Alice (Judge) &lt;alice@cyb.org>"
-
-Really sign?
-</screen>
-
-<para>
-Once signed you can check the key to list the signatures on it and
-see the signature that you have added.
-Every user ID on the key will have one or more self-signatures as well
-as a signature for each user that has validated the key.
-</para>
-
-<screen width="80">
-<prompt>Command></prompt> <userinput>check</userinput>
-uid  Blake (Executioner) &lt;blake@cyb.org>
-sig!       9E98BC16 1999-06-04   [self-signature]
-sig!       BB7576AC 1999-06-04   Alice (Judge) &lt;alice@cyb.org>
-</screen>
-</sect2>
-</sect1>
-
-<sect1>
-<title>
-Encrypting and decrypting documents
-</title>
-
-<para>
-To encrypt a document the option 
-<link linkend="encrypt"><option>--encrypt</option></link> is used.
-You must have the public keys of the intended recipients.
-The software expects the name of the document to encrypt as input or, if
-omitted, on standard input.
-The encrypted result is placed on standard output or as specified using
-the option <option>--output</option>.
-The document is compressed for additional security in addition to
-encrypting it.
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --output doc.gpg --encrypt --recipient blake@cyb.org doc</userinput>
-</screen>
-
-The <link linkend="recipient"><option>--recipient</option></link> option
-is used once for each recipient and takes an extra argument specifying
-the public key to which the document should be encrypted.
-The encrypted document can only be decrypted by someone with a private
-key that complements one of the recipients' public keys.
-In particular, you cannot decrypt a document encrypted by you unless
-you included your own public key in the recipient list.
-</para>
-
-<para>
-To decrypt a message the option 
-<link linkend="decrypt"><option>--decrypt</option></link> is used.
-You need the private key to which the message was encrypted.
-Similar to the encryption process, the document to decrypt is
-input, and the decrypted result is output.
-</para>
-
-<screen width="80">
-<prompt>blake%</prompt> <userinput>gpg --output doc --decrypt doc.gpg</userinput>
-
-You need a passphrase to unlock the secret key for
-user: "Blake (Executioner) &lt;blake@cyb.org>"
-1024-bit ELG-E key, ID 5C8CBD41, created 1999-06-04 (main key ID 9E98BC16)
-
-Enter passphrase: 
-</screen>
-
-<para>
-Documents may also be encrypted without using public-key cryptography.
-Instead, only a symmetric cipher is used to encrypt the document.
-The key used to drive the symmetric cipher is derived from a passphrase
-supplied when the document is encrypted, and for good security, it
-should not be the same passphrase that you use to protect your private key.
-Symmetric encryption is useful for securing documents when the
-passphrase does not need to be communicated to others.
-A document can be encrypted with a symmetric cipher by using the
-<link linkend="symmetric"><option>--symmetric</option></link> option.
-</para>
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --output doc.gpg --symmetric doc</userinput>
-Enter passphrase: 
-</screen>
-</sect1>
-
-<sect1>
-<title>
-Making and verifying signatures
-</title>
-
-<para>
-A digital signature certifies and timestamps a document.
-If the document is subsequently modified in any way, a verification
-of the signature will fail.
-A digital signature can serve the same purpose as a hand-written signature
-with the additional benefit of being tamper-resistant.
-The &gnupg; source distribution, for example, is signed so that users can
-verify that the source code has not been modified since it was packaged.
-</para>
-
-<para>
-Creating and verifying signatures uses the public/private keypair
-in an operation different from encryption and decryption.
-A signature is created using the private key of the signer.
-The signature is verified using the corresponding public key.
-A consequence is that it is difficult to deny that you made a digital
-signature since that would imply your private key had been compromised.
-</para>
-
-<para>
-The command-line option <link linkend="sign"><option>--sign</option></link> is
-used to make a digital signature.
-The document to sign is input, and the signed document is output.
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --output doc.sig --sign doc</userinput>
-
-You need a passphrase to unlock the private key for
-user: "Alice (Judge) &lt;alice@cyb.org>"
-1024-bit DSA key, ID BB7576AC, created 1999-06-04
-
-Enter passphrase: 
-</screen>
-
-The document is compressed before signed, and the output is in binary
-format.
-</para>
-
-<para>
-Given a signed document, you can either check the signature or
-check the signature and recover the original document.
-To check the signature use the 
-<link linkend="verify"><option>--verify</option></link> option.
-To verify the signature and extract the document use the
-<option>--decrypt</option>
-option.
-The signed document to verify and recover is input and the recovered
-document is output.
-</para>
-
-<screen width="80">
-<prompt>blake%</prompt> <userinput>gpg --output doc --decrypt doc.sig</userinput>
-gpg: Signature made Fri Jun  4 12:02:38 1999 CDT using DSA key ID BB7576AC
-gpg: Good signature from "Alice (Judge) &lt;alice@cyb.org>"
-</screen>
-
-<sect2>
-<title>
-Clearsigned documents
-</title>
-
-<para>
-A common use of digital signatures is to sign usenet postings or
-email messages.
-In such situations it is undesirable to compress the document while
-signing it.
-The option 
-<link linkend="clearsign"><option>--clearsign</option></link> 
-causes the document to be wrapped in an ASCII-armored signature but 
-otherwise does not modify the document.
-</para>
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --clearsign doc</userinput>
-
-You need a passphrase to unlock the secret key for
-user: "Alice (Judge) &lt;alice@cyb.org>"
-1024-bit DSA key, ID BB7576AC, created 1999-06-04
-
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-
-[...]
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v0.9.7 (GNU/Linux)
-Comment: For info see http://www.gnupg.org
-
-iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1
-oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k
-=y6kj
------END PGP SIGNATURE-----
-</screen>
-</sect2>
-
-<sect2>
-<title>
-Detached signatures
-</title>
-
-<para>
-A signed document has limited usefulness.
-Other users must recover the original document from the signed
-version, and even with clearsigned documents, the signed document
-must be edited to recover the original.
-Therefore, there is a third method for signing a document that
-creates a detached signature.
-A detached signature is created using the 
-<link linkend="detach-sig"><option>--detach-sig</option></link>
-option.
-</para>
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --output doc.sig --detach-sig doc</userinput>
-
-You need a passphrase to unlock the secret key for
-user: "Alice (Judge) &lt;alice@cyb.org>"
-1024-bit DSA key, ID BB7576AC, created 1999-06-04
-
-Enter passphrase: 
-</screen>
-
-<para>
-Both the document and detached signature are needed to verify
-the signature.
-The <option>--verify</option> option can be to check the 
-signature.
-</para>
-
-<screen width="80">
-<prompt>blake%</prompt> <userinput>gpg --verify doc.sig doc</userinput>
-gpg: Signature made Fri Jun  4 12:38:46 1999 CDT using DSA key ID BB7576AC
-gpg: Good signature from "Alice (Judge) &lt;alice@cyb.org>"
-</screen>
-</sect2>
-</sect1>
-</chapter>
-
-<!--
-In the "Getting Started" chapter, it would be interesting to provide
-a checklist of assumptions that the reader can consult to determine
-whether or not she fits the "most users" profile.  Perhaps put this
-at the end of the chapter (perhaps w/ forward pointer?).  You could
-include cross references for each item on the list.  For example:
-
-    23.  Your use of public key encryption has property X with attribute Y.
-         (see Section 3.4.1 for a more detailed discussion of other
-          attributes of property X)
-
-What prompted this was wondering, as I read through the generating keypair
-section, "under what circumstances would these defaults be inappropriate?"
-
-The notion of using the same key with different user IDs "as an employee at
-work and a political activist on the side" is interesting.  Knowing one,
-could you be traced to the other?  (Are they separate numeric ids, and is
-that enough?)  (seems someone could just match the public keys)
-
-It's a very nice touch that you don't cover every single prompt that the
-system throws at you, but instead treat them functionally.  For example,
-I can imagine other books going through the "Comment:" and "Email Address:"
-prompts.
--->
-
-<!--
-"Key verification is a weak point in public-key cryptography ..."
-Saying "weak point" makes it sound like a slam on public key stuff.
-Although we've talked about weaknesses of the trust model, I'm guessing
-the point here is that communication is only secure if you verify the
-identity of the key's owner.
-
-Key verification can be done through any means "as long as you can
-guarantee that you are communicating with the key's true owner".
-I suspect we'd also like to prevent leaking information that an
-interceptor could use to pose as us in a key verification step with
-another party.  I suppose the notion of bootstrapping may not be widely
-appreciated as an analogy.
-
-I'm almost inclined to want to see a section in the Getting Started
-guide called "Why you should read the rest of this book".  Failing
-that, or perhaps better yet, maybe it would work to have some margin
-notes that point to other sections of the book for more information
-("a discussion of trust models begins on p. 95").
--->
-
diff --git a/doc/gph/c2.sgml b/doc/gph/c2.sgml
deleted file mode 100644
index b045ed4ee..000000000
--- a/doc/gph/c2.sgml
+++ /dev/null
@@ -1,345 +0,0 @@
-<chapter id="concepts" xreflabel="2">
-<docinfo>
-<date>
-$Id$
-</date>
-</docinfo>
-<title>
-Concepts
-</title>
-
-<para>
-&Gnupg; makes uses of several cryptographic concepts including 
-<firstterm>symmetric ciphers</firstterm>, 
-<firstterm>public-key ciphers</firstterm>, and 
-<firstterm>one-way hashing</firstterm>.
-You can make basic use &gnupg; without fully understanding these concepts,
-but in order to use it wisely some understanding of them is necessary.
-</para>
-
-<para>
-This chapter introduces the basic cryptographic concepts used in GnuPG.
-Other books cover these topics in much more detail.
-A good book with which to pursue further study is 
-<ulink url="http://www.counterpane.com/schneier.html">Bruce 
-Schneier</ulink>'s
-<ulink url="http://www.counterpane.com/applied.html">"Applied 
-Cryptography"</ulink>.
-</para>
-
-<sect1>
-<title>
-Symmetric ciphers
-</title>
-
-<para>
-A symmetric cipher is a cipher that uses the same key for both encryption
-and decryption.
-Two parties communicating using a symmetric cipher must agree on the
-key beforehand.
-Once they agree, the sender encrypts a message using the key, sends it
-to the receiver, and the receiver decrypts the message using the key.
-As an example, the German Enigma is a symmetric cipher, and daily keys
-were distributed as code books.
-Each day, a sending or receiving radio operator would consult his copy
-of the code book to find the day's key.
-Radio traffic for that day was then encrypted and decrypted using the
-day's key.
-Modern examples of symmetric ciphers include 3DES, Blowfish, and IDEA.
-</para>
-
-<para>
-A good cipher puts all the security in the key and none in the algorithm.
-In other words, it should be no help to an attacker if he knows which
-cipher is being used.
-Only if he obtains the key would knowledge of the algorithm be needed.
-The ciphers used in &gnupg; have this property.
-</para>
-
-<para>
-Since all the security is in the key, then it is important that it be
-very difficult to guess the key.
-In other words, the set of possible keys, &ie;, the <emphasis>key
-space</emphasis>, needs
-to be large.
-While at Los Alamos, Richard Feynman was famous for his ability to
-crack safes.
-To encourage the mystique he even carried around a set of tools
-including an old stethoscope.
-In reality, he used a variety of tricks to reduce the number of
-combinations he had to try to a small number and then simply guessed
-until he found the right combination.
-In other words, he reduced the size of the key space.
-</para>
-
-<para>
-Britain used machines to guess keys during World War 2.
-The German Enigma had a very large key space, but the British built
-speciailzed computing engines, the Bombes, to mechanically try 
-keys until the day's key was found.
-This meant that sometimes they found the day's key within hours of
-the new key's use, but it also meant that on some days they never
-did find the right key.
-The Bombes were not general-purpose computers but were precursors
-to modern-day computers.
-</para>
-
-<para>
-Today, computers can guess keys very quickly, and this is why key
-size is important in modern cryptosystems.
-The cipher DES uses a 56-bit key, which means that there are
-<!-- inlineequation -->
-2<superscript>56</superscript> possible keys.
-<!-- inlineequation -->
-2<superscript>56</superscript> is 72,057,594,037,927,936 keys.
-This is a lot of keys, but a general-purpose computer can check the
-entire key space in a matter of days.
-A specialized computer can check it in hours.
-On the other hand, more recently designed ciphers such as 3DES, 
-Blowfish, and IDEA
-<!-- inlineequation -->
-all use 128-bit keys, which means there are 2<superscript>128</superscript> 
-possible keys.
-This is many, many more keys, and even if all the computers on the
-planet cooperated, it could still take more time than the age of
-the universe to find the key.
-</para>
-</sect1>
-
-<sect1>
-<title>
-Public-key ciphers
-</title>
-
-<para>
-The primary problem with symmetric ciphers is not their security but
-with key exchange.
-Once the sender and receiver have exchanged keys, that key can be
-used to securely communicate, but what secure communication channel
-was used to communicate the key itself?
-In particular, it would probably be much easier for an attacker to work
-to intercept the key than it is to try all the keys in the key space.
-Another problem is the number of keys needed.
-<!-- inlineequation -->
-If there are <emphasis>n</emphasis> people who need to communicate, then 
-<!-- inlineequation -->
-<emphasis>n(n-1)/2</emphasis> keys
-are needed for each pair of people to communicate privately.
-This may be ok for a small number of people but quickly becomes unwieldly
-for large groups of people.
-</para>
-
-<para>
-Public-key ciphers were invented to avoid the key-exchange problem
-entirely.
-A public-key cipher uses a pair of keys for sending messages.
-The two keys belong to the person receiving the message.
-One key is a <emphasis>public key</emphasis> and may be given to anybody.
-The other key is a <emphasis>private key</emphasis> and is kept 
-secret by the owner.
-A sender encrypts a message using the public key and once encrypted,
-only the private key may be used to decrypt it.
-</para>
-
-<para>
-This protocol solves the key-exchange problem inherent with symmetric
-ciphers.
-There is no need for the sender and receiver to agree
-upon a key.
-All that is required is that some time before secret communication the
-sender gets a copy of the receiver's public key.
-Furthermore, the one public key can be used by anybody wishing to
-communicate with the receiver.
-<!-- inlineequation -->
-So only <emphasis>n</emphasis> keypairs are needed for <emphasis>n</emphasis> 
-people to communicate secretly
-with one another,
-</para>
-
-<para>
-Public-key ciphers are based on one-way trapdoor functions.
-A one-way function is a function that is easy to compute,
-but the inverse is hard to compute.
-For example, it is easy to multiply two prime numbers together to get
-a composite, but it is difficult to factor a composite into its prime
-components.a
-A one-way trapdoor function is similar, but it has a trapdoor.
-That is, if some piece of information is known, it becomes easy
-to compute the inverse.
-For example, if you have a number made of two prime factors, then knowing
-one of the factors makes it easy to compute the second.
-Given a public-key cipher based on prime factorization, the public
-key contains a composite number made from two large prime factors, and
-the encryption algorithm uses that composite to encrypt the
-message.
-The algorithm to decrypt the message requires knowing the prime factors,
-so decryption is easy if you have the private key containing one of the
-factors but extremely difficult if you do not have it.
-</para>
-
-<para>
-As with good symmetric ciphers, with a good public-key cipher all of the
-security rests with the key.
-Therefore, key size is a measure of the system's security, but
-one cannot compare the size of a symmetric cipher key and a public-key
-cipher key as a measure of their relative security.
-In a brute-force attack on a symmetric cipher with a key size of 80 bits,
-<!-- inlineequation -->
-the attacker must enumerate up to 2<superscript>81</superscript>-1 keys to 
-find the right key.
-In a brute-force attack on a public-key cipher with a key size of 512 bits,
-the attacker must factor a composite number encoded in 512 bits (up to
-155 decimal digits).
-The workload for the attacker is fundamentally different depending on
-the cipher he is attacking.
-While 128 bits is sufficient for symmetric ciphers, given today's factoring
-technology public keys with 1024 bits are recommended for most purposes.
-</para>
-</sect1>
-
-<sect1>
-<title>
-Hybrid ciphers
-</title>
-
-<para>
-Public-key ciphers are no panacea.
-Many symmetric ciphers are stronger from a security standpoint,
-and public-key encryption and decryption are more expensive than the
-corresponding operations in symmetric systems.
-Public-key ciphers are nevertheless an effective tool for distributing
-symmetric cipher keys, and that is how they are used in hybrid cipher
-systems.
-</para>
-
-<para>
-A hybrid cipher uses both a symmetric cipher and a public-key cipher.
-It works by using a public-key cipher to share a key for the symmetric
-cipher.
-The actual message being sent is then encrypted using the key and sent
-to the recipient.
-Since symmetric key sharing is secure, the symmetric key used is different
-for each message sent.
-Hence it is sometimes called a session key.
-</para>
-
-<para>
-Both PGP and &gnupg; use hybrid ciphers.
-The session key, encrypted using the public-key cipher, and the message
-being sent, encrypted with the symmetric cipher, are automatically
-combined in one package.
-The recipient uses his private-key to decrypt the session key and the
-session key is then used to decrypt the message.
-</para>
-
-<para>
-A hybrid cipher is no stronger than the public-key cipher or symmetric
-cipher it uses, whichever is weaker.
-In PGP and &gnupg;, the public-key cipher is probably the weaker of
-the pair.
-Fortunately, however, if an attacker could decrypt a session key it
-would only be useful for reading the one message encrypted with that
-session key.
-The attacker would have to start over and decrypt another session
-key in order to read any other message.
-</para>
-</sect1>
-
-<sect1>
-<title>
-Digital signatures
-</title>
-
-<para>
-A hash function is a many-to-one function that maps its input to a
-value in a finite set.
-Typically this set is a range of natural numbers.
-<!-- inlineequation -->
-A simple ehash function is <emphasis>f</emphasis>(<emphasis>x</emphasis>) = 0 
-for all integers <emphasis>x</emphasis>.
-A more interesting hash function is 
-<emphasis>f</emphasis>(<emphasis>x</emphasis>) = <emphasis>x</emphasis> 
-<emphasis>mod</emphasis> 37, which
-maps <emphasis>x</emphasis> to the remainder of dividing <emphasis>x</emphasis> by 37.
-</para>
-
-<para>
-A document's digital signature is the result of applying a hash
-function to the document.
-To be useful, however, the hash function needs to satisfy two
-important properties.
-First, it should be hard to find two documents that hash to the
-same value.
-Second, given a hash value it should be hard to recover the document
-that produced that value.
-</para>
-
-<para>
-Some public-key ciphers<footnote><para>
-The cipher must have the property that the actual public key or private
-key could be used by the encryption algorithm as the public key.
-RSA is an example of such an algorithm while ElGamal is not an example.
-</para>
-</footnote> could be used to sign documents.
-The signer encrypts the document with his <emphasis>private</emphasis> key.
-Anybody wishing to check the signature and see the document simply
-uses the signer's public key to decrypt the document.
-This algorithm does satisfy the two properties needed from a good hash
-function, but in practice, this algorithm is too slow to be useful.
-</para>
-
-<para>
-An alternative is to use hash functions designed to satisfy these
-two important properties.
-SHA and MD5 are examples of such algorithms.
-Using such an algorithm, a document is signed by hashing it, and
-the hash value is the signature.
-Another person can check the signature by also hashing their copy of the
-document and comparing the hash value they get with the hash value of
-the original document.
-If they match, it is almost certain that the documents are identical.
-</para>
-
-<para>
-Of course, the problem now is using a hash function for digital
-signatures without permitting an attacker to interfere with signature
-checking.
-If the document and signature are sent unencrypted, an attacker could
-modify the document and generate a corresponding signature without the
-recipient's knowledge.
-If only the document is encrypted, an attacker could tamper with the
-signature and cause a signature check to fail.
-A third option is to use a hybrid public-key encryption to encrypt both
-the signature and document.
-The signer uses his private key, and anybody can use his public key
-to check the signature and document.
-This sounds good but is actually nonsense.
-If this algorithm truly secured the document it would also
-secure it from tampering and there would be no need for the signature.
-The more serious problem, however, is that this does not protect either
-the signature or document from tampering.
-With this algorithm, only the session key for the symmetric cipher
-is encrypted using the signer's private key.
-Anybody can use the public key to recover the session key.
-Therefore, it is straightforward for an attacker to recover the session
-key and use it to encrypt substitute documents and signatures to send
-to others in the sender's name.
-</para>
-
-<para>
-An algorithm that does work is to use a public key algorithm to
-encrypt only the signature.
-In particular, the hash value is encrypted using the signer's private
-key, and anbody can check the signature using the public key.
-The signed document can be sent using any other encryption algorithm
-including none if it is a public document.
-If the document is modified the signature check will fail, but this
-is precisely what the signature check is supposed to catch.
-The Digital Signature Standard (DSA) is a public key signature 
-algorithm that works as just described.
-DSA is the primary signing algorithm used in &Gnupg;.
-</para>
-
-</sect1>
-</chapter>
-
diff --git a/doc/gph/c3.sgml b/doc/gph/c3.sgml
deleted file mode 100644
index 541cf6c9d..000000000
--- a/doc/gph/c3.sgml
+++ /dev/null
@@ -1,885 +0,0 @@
-<chapter id="management" xreflabel="3">
-<docinfo>
-<date>
-$Id$
-</date>
-</docinfo>
-<title>
-Key Management
-</title>
-
-<para>
-Key tampering is a major security weakness with public-key cryptography.
-An eavesdropper may tamper with a user's keyrings or forge a
-user's public key and post it for others to download and use.
-For example, suppose Chloe wants to monitor the messages that Alice
-sends to Blake.
-She could mount what is called a <firstterm>man in the 
-middle</firstterm> attack.
-In this attack, Chloe creates a new public/private keypair.
-She replaces Alice's copy of Blake's public key with the new public key.
-She then intercepts the messages that Alice sends to Blake.
-For each intercept, she decrypts it using the new private key, reencrypts
-it using Blake's true public key, and forwards the reencrypted
-message to Blake.
-All messages sent from Alice to Blake can now be read by Chloe.
-</para>
-
-<para>
-Good key management is crucial in order to ensure not just the integrity
-of your keyrings but the integrity of other users' keyrings as well.
-The core of key management in &gnupg; is the notion of signing keys.
-Key signing has two main purposes: it permits you to detect tampering
-on your keyring, and it allows you to certify that a key truly belongs
-to the person named by a user ID on the key.
-Key signatures are also used in a scheme known as the <firstterm>web of 
-trust</firstterm> to extend certification to keys not directly signed by you 
-but signed by others you trust.
-Responsible users who practice good key management can defeat key
-tampering as a practical attack on secure communication with &gnupg;.
-</para>
-
-<sect1>
-<title>
-Managing your own keypair
-</title>
-
-<para>
-A keypair has a public key and a private key.
-A public key consists of 
-the public portion of the master signing key,
-the public portions of the subordinate signing and encryption subkeys, and 
-a set of user IDs used to associate the public key with a real person.
-Each piece has data about itself.
-For a key, this data includes its ID, when it was created, when it
-will expire, etc.
-For a user ID, this data includes the name of the real person it identifies,
-an optional comment, and an email address.
-The structure of the private key is similar, except that it contains only
-the private portions of the keys, and there is no user ID information.
-</para>
-
-<para>
-The command-line option 
-<link linkend="edit-key"><option>--edit-key</option></link>
-may be used to view a keypair.
-For example,
-
-<screen width="80">
-<prompt>chloe%</prompt> <userinput>gpg --edit-key chloe@cyb.org</userinput>
-Secret key is available.
-
-pub  1024D/26B6AAE1  created: 1999-06-15 expires: never      trust: -/u
-sub  2048g/0CF8CB7A  created: 1999-06-15 expires: never     
-sub  1792G/08224617  created: 1999-06-15 expires: 2002-06-14
-sub   960D/B1F423E7  created: 1999-06-15 expires: 2002-06-14
-(1)  Chloe (Jester) &lt;chloe@cyb.org>
-(2)  Chloe (Plebian) &lt;chloe@tel.net>
-<prompt>Command></prompt>
-</screen>
-
-The public key is displayed along with an indication of whether
-or not the private key is available.
-Information about each component of the public key is then listed.
-The first column indicates the type of the key.
-The keyword <literal>pub</literal> identifies the public master signing key,
-and the keyword <literal>sub</literal> identifies a public subordinate key.
-The second column indicates the key's bit length, type, and ID.
-The type is <literal>D</literal> for a DSA key, <literal>g</literal> for an 
-encryption-only
-ElGamal key, and <literal>G</literal> for an ElGamal key that may be used for
-both encryption and signing.
-The creation date and expiration date are given in columns three and four.
-The user IDs are listed following the keys.
-</para>
-
-<para>
-More information about the key can be obtained with interactive commands.
-The command <link linkend="toggle"><command>toggle</command></link> 
-switches between the public and private
-components of a keypair if indeed both components are available.
-
-<screen width="80">
-<prompt>Command></prompt> <userinput>toggle</userinput>
-               
-sec  1024D/26B6AAE1  created: 1999-06-15 expires: never     
-sbb  2048g/0CF8CB7A  created: 1999-06-15 expires: never     
-sbb  1792G/08224617  created: 1999-06-15 expires: 2002-06-14
-sbb   960D/B1F423E7  created: 1999-06-15 expires: 2002-06-14
-(1)  Chloe (Jester) &lt;chloe@cyb.org>
-(2)  Chloe (Plebian) &lt;chloe@tel.net>
-</screen>
-
-The information provided is similar to the listing for the public-key
-component.
-The keyword <literal>sec</literal> identifies the private master signing key,
-and the keyword <literal>sbb</literal> identifies the private subordinates keys.
-The user IDs from the public key are also listed for convenience.
-</para>
-
-<sect2>
-<title id="integrity">
-Key integrity
-</title>
-
-<para>
-When you distribute your public key, you are distributing the public
-components of your master and subordinate keys as well as the user IDs.
-Distributing this material alone, however, is a security risk since
-it is possible for an attacker to tamper with the key.
-The public key can be modified by adding or substituting keys, or by
-adding or changing user IDs.
-By tampering with a user ID, the attacker could change the user ID's email
-address to have email redirected to himself.
-By changing one of the encryption keys, the attacker would
-also be able to decrypt the messages redirected to him.
-</para>
-
-<para>
-Using digital signatures is a solution to this problem.
-When data is signed by a private key, the corresponding public key
-is bound to the signed data.
-In other words, only the corresponding public key can be used to
-verify the signature and ensure that the data has not been modified.
-A public key can be protected from tampering by using its corresponding
-private master key to sign the public key components and user IDs, thus
-binding the components to the public master key.
-Signing public key components with the corresponding private master
-signing key is called <firstterm>self-signing</firstterm>, and a public key that has
-self-signed user IDs bound to it is called a <firstterm>certificate</firstterm>.
-</para>
-
-<!--
-%\begin{figure}
-%Blank
-%\caption{This should depict how self-signatures bind information to
-%a public key.}\label{fig:selfsignedkey}
-%\end{figure}
-%
-%As an example, Figure~\ref{fig:selfsignedkey} illustrates Chloe's public
-%key, which has been self-signed to bind the user IDs and public subkeys
-%to the public master key.
-%The signatures on the user IDs can be checked with the \texttt{check}
-%command from the key edit menu.
--->
-
-<para>
-As an example, Chloe has two user IDs and three subkeys.
-The signatures on the user IDs can be checked with the command
-<link linkend="check"><command>check</command></link> from the key edit menu.
-
-<screen width="80">
-<prompt>chloe%</prompt> <userinput>gpg --edit-key chloe</userinput>
-Secret key is available.
-
-pub  1024D/26B6AAE1  created: 1999-06-15 expires: never      trust: -/u
-sub  2048g/0CF8CB7A  created: 1999-06-15 expires: never     
-sub  1792G/08224617  created: 1999-06-15 expires: 2002-06-14
-sub   960D/B1F423E7  created: 1999-06-15 expires: 2002-06-14
-(1)  Chloe (Jester) &lt;chloe@cyb.org>
-(2)  Chloe (Plebian) &lt;chloe@tel.net>
-
-<prompt>Command></prompt> <userinput>check</userinput>
-uid  Chloe (Jester) &lt;chloe@cyb.org>
-sig!       26B6AAE1 1999-06-15   [self-signature]
-uid  Chloe (Plebian) &lt;chloe@tel.net>
-sig!       26B6AAE1 1999-06-15   [self-signature]
-</screen>
-
-As expected, the signing key for each signature is the master signing
-key with key ID <literal>0x26B6AAE1</literal>.
-The self-signatures on the subkeys are present in the public key, but
-they are not shown by the &gnupg; interface.
-</para>
-</sect2>
-
-<sect2>
-<title>
-Adding and deleting key components
-</title>
-
-<para>
-Both new subkeys and new user IDs may be added to your keypair after
-it has been created.
-A user ID is added using the command 
-<link linkend="adduid"><command>adduid</command></link>.
-You are prompted for a real name, email address, and comment just
-as when you create an initial keypair.
-A subkey is added using the command 
-<link linkend="addkey"><command>addkey</command></link>.
-The interface is similar to the interface used when creating an initial
-keypair.
-The subkey may be a DSA signing key, and encrypt-only ElGamal
-key, or a sign-and-encrypt ElGamal key.
-When a subkey or user ID is generated it is self-signed using your 
-master signing key, which is why you must supply your passphrase
-when the key is generated.
-</para>
-
-<para>
-Additional user IDs are useful when you need multiple identities.
-For example, you may have an identity for your job and an identity
-for your work as a political activist.
-Coworkers will know you by your work user ID.
-Coactivists will know you by your activist user ID.
-Since those groups of people may not overlap, though, each group
-may not trust the other user ID.
-Both user IDs are therefore necessary.
-</para>
-
-<para>
-Additional subkeys are also useful.
-The user IDs associated with your public master key are validated by
-the people with whom you
-communicate, and changing the master key therefore requires recertification.
-This may be difficult and time consuming if you communicate with
-many people.
-On the other hand, it is good to periodically change encryption subkeys.
-If a key is broken, all the data encrypted with that key will be
-vulnerable.
-By changing keys, however, only the data encrypted with the one broken
-key will be revealed.
-</para>
-
-<para>
-Subkeys and user IDs may also be deleted.
-To delete a subkey or user ID you must first select it using the
-<link linkend="key"><command>key</command></link> or 
-<link linkend="uid"><command>uid</command></link> commands respectively.
-These commands are toggles.
-For example, the command <command>key <parameter>2</parameter></command> 
-selects the second subkey,
-and invoking <command>key <parameter>2</parameter></command> again 
-deselects it.
-If no extra argument is given, all subkeys or user IDs are deselected.
-Once the user IDs to be deleted are selected, the command
-<link linkend="deluid"><command>deluid</command></link>
-actually deletes the user IDs from your key.
-Similarly, the command <link linkend="delkey"><command>delkey</command></link>
-deletes all selected subkeys from both your public and private keys.
-</para>
-
-<para>
-For local keyring management, deleting key components is a good way
-to trim other people's public keys of unnecessary material.
-Deleting user IDs and subkeys on your own key, however, is not always
-wise since it complicates key distribution.
-By default, when a user imports your updated public key it will be merged
-with the old copy of your public key on his ring if it exists.
-The components from both keys are combined in the merge, and this
-effectively restores any components you deleted.
-To properly update the key, the user must first delete the old version
-of your key and then import the new version.
-This puts an extra burden on the people with whom you communicate.
-Furthermore, if you send your key to a keyserver, the merge will
-happen regardless, and anybody who downloads your key from a keyserver
-will never see your key with components deleted.
-Consequently, for updating your own key it is better to revoke key
-components instead of deleting them.
-</para>
-</sect2>
-
-<sect2>
-<title>
-Revoking key components
-</title>
-
-<para>
-To revoke a subkey it must be selected.
-Once selected it may be revoked with the 
-<link linkend="revkey"><command>revkey</command></link> command.
-The key is revoked by adding a revocation self-signature to the key.
-Unlike the command-line option <option>--gen-revoke</option>, the effect of
-revoking a subkey is immediate.
-</para>
-
-<screen width="80">
-<prompt>Command></prompt> <userinput>revkey</userinput>
-Do you really want to revoke this key? y
-                                        
-You need a passphrase to unlock the secret key for
-user: "Chloe (Jester) &lt;chloe@cyb.org>"
-1024-bit DSA key, ID B87DBA93, created 1999-06-28
-
-                  
-pub  1024D/B87DBA93  created: 1999-06-28 expires: never      trust: -/u
-sub  2048g/B7934539  created: 1999-06-28 expires: never     
-sub  1792G/4E3160AD  created: 1999-06-29 expires: 2000-06-28
-rev! subkey has been revoked: 1999-06-29
-sub   960D/E1F56448  created: 1999-06-29 expires: 2000-06-28
-(1)  Chloe (Jester) &lt;chloe@cyb.org>
-(2)  Chloe (Plebian) &lt;chloe@tel.net>
-</screen>
-
-<para>
-A user ID is revoked differently.
-Normally, a user ID collects signatures that attest that the user ID
-describes the person who actually owns the associated key.
-In theory, a user ID describes a person forever, since that person will
-never change.
-In practice, though, elements of the user ID such as the email address
-and comment may change over time, thus invalidating the user ID.
-</para>
-
-<para>
-The OpenPGP
-<comment>First reference to OpenPGP</comment>
-specification does not support user ID revocation, but
-a user ID can effectively be revoked by revoking the self-signature
-on the user ID.
-For the security reasons described 
-<link linkend="integrity">previously</link>,
-correspondents will not trust a user ID with no valid self-signature.
-</para>
-
-<para>
-A signature is revoked by using the command 
-<link linkend="revsig"><command>revsig</command></link>.
-Since you may have signed any number of user IDs, the user interface
-prompts you to decide for each signature whether or not to revoke it.
-</para>
-
-<screen width="80">
-<prompt>Command></prompt> <userinput>revsig</userinput>
-You have signed these user IDs:
-     Chloe (Jester) &lt;chloe@cyb.org>
-   signed by B87DBA93 at 1999-06-28
-     Chloe (Plebian) &lt;chloe@tel.net>
-   signed by B87DBA93 at 1999-06-28
-user ID: "Chloe (Jester) &lt;chloe@cyb.org>"
-signed with your key B87DBA93 at 1999-06-28
-Create a revocation certificate for this signature? (y/N)n
-user ID: "Chloe (Plebian) &lt;chloe@tel.net>"                
-signed with your key B87DBA93 at 1999-06-28
-Create a revocation certificate for this signature? (y/N)y
-You are about to revoke these signatures:                 
-     Chloe (Plebian) &lt;chloe@tel.net>
-   signed by B87DBA93 at 1999-06-28
-Really create the revocation certificates? (y/N)y
-                                                 
-You need a passphrase to unlock the secret key for
-user: "Chloe (Jester) &lt;chloe@cyb.org>"
-1024-bit DSA key, ID B87DBA93, created 1999-06-28
-
-                  
-pub  1024D/B87DBA93  created: 1999-06-28 expires: never      trust: -/u
-sub  2048g/B7934539  created: 1999-06-28 expires: never     
-sub  1792G/4E3160AD  created: 1999-06-29 expires: 2000-06-28
-rev! subkey has been revoked: 1999-06-29
-sub   960D/E1F56448  created: 1999-06-29 expires: 2000-06-28
-(1)  Chloe (Jester) &lt;chloe@cyb.org>
-(2)  Chloe (Plebian) &lt;chloe@tel.net>
-</screen>
-
-<para>
-A revoked user ID is indicated by the revocation signature on 
-the ID when the signatures on the key's user IDs are listed.
-</para>
-
-<screen width="80">
-<prompt>Command></prompt> <userinput>check</userinput>
-uid  Chloe (Jester) &lt;chloe@cyb.org>
-sig!       B87DBA93 1999-06-28   [self-signature]
-uid  Chloe (Plebian) &lt;chloe@tel.net>
-rev!       B87DBA93 1999-06-29   [revocation]
-sig!       B87DBA93 1999-06-28   [self-signature]
-</screen>
-
-<para>
-Revoking both subkeys and self-signatures on user IDs adds revocation
-self-signatures to the key.
-Since signatures are being added and no material is deleted, a 
-revocation will always be visible to others when your updated public
-key is distributed and merged with older copies of it.
-Revocation therefore guarantees that everybody has a consistent
-copy of your public key.
-</para>
-</sect2>
-
-<sect2>
-<title>
-Updating a key's expiration time
-</title>
-
-<para>
-The expiration time of a key may be updated with the command
-<link linkend="expire"><command>expire</command></link> from the key edit menu.
-If no key is selected the expiration time of the primary key
-is updated.
-Otherwise the expiration time of the selected subordinate key
-is updated.
-</para>
-
-<para>
-A key's expiration time is associated with the key's self-signature.
-The expiration time is updated by deleting the old self-signature
-and adding a new self-signature.
-Since correspondents will not have deleted the old self-signature, they
-will see an additional self-signature on the key when they update
-their copy of your key.
-The latest self-signature takes precedence, however, so all correspondents
-will unambiguously know the expiration times of your keys.
-</para>
-</sect2>
-</sect1>
-
-<sect1>
-<title>
-Validating other keys on your public keyring
-</title>
-
-<para>
-In Chapter <xref linkend="intro"> a procedure was given to validate your
-correspondents' public keys: a correspondent's key is validated by
-personally checking his key's fingerprint and then signing his public
-key with your private key.
-By personally checking the fingerprint you can be sure that the
-key really does belong to him, and since you have signed they key, you
-can be sure to detect any tampering with it in the future.
-Unfortunately, this procedure is awkward when either you must validate
-a large number of keys or communicate with people whom you do not
-know personally.
-</para>
-
-<para>
-&Gnupg; addresses this problem with a mechanism popularly known
-as the <firstterm>web of trust</firstterm>.
-In the web of trust model, responsibility for validating public
-keys is delegated to people you trust.
-For example, suppose
-<itemizedlist spacing="compact">
-<listitem>
-<para>
-Alice has signed Blake's key, and
-</para>
-</listitem>
-<listitem>
-<para>
-Blake has signed Chloe's key and Dharma's key.
-</para>
-</listitem>
-</itemizedlist>
-
-If Alice trusts Blake to properly validate keys that he signs, then
-Alice can infer that Chloe's and Dharma's keys are valid without 
-having to personally check them.
-She simply uses her validated copy of Blake's public key to
-check that Blake's signatures on Chloe's and Dharma's are good.
-In general, assuming that Alice fully trusts everybody to properly
-validate keys they sign, then any key signed by a valid key is also
-considered valid.
-The root is Alice's key, which is axiomatically assumed to be valid.
-</para>
-
-<sect2>
-<title>
-Trust in a key's owner
-</title>
-
-<para>
-In practice trust is subjective.
-For example, Blake's key is valid to Alice since she signed it, but she
-may not trust Blake to properly validate keys that he signs.
-In that case, she would not take Chloe's and Dharma's key as valid
-based on Blake's signatures alone.
-The web of trust model accounts for this by associating with each
-public key on your keyring an indication of how much you trust the
-key's owner.
-There are four trust levels.
-
-<variablelist>
-<varlistentry>
-<term>
-unknown
-</term>
-<listitem>
-<para>
-Nothing is known about the owner's judgement in key signing.
-Keys on your public keyring that you do not own initially have
-this trust level.
-</para>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>
-none
-</term>
-<listitem>
-<para>
-The owner is known to improperly sign other keys.
-</para>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>
-marginal
-</term>
-<listitem>
-<para>
-The owner understands the implications of key signing and 
-properly validates keys before signing them.
-</para>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>
-full
-</term>
-<listitem>
-<para>
-The owner has an excellent understanding of key signing,
-and his signature on a key would be as good as your own.
-</para>
-</listitem>
-</varlistentry>
-</variablelist>
-
-A key's trust level is something that you alone assign to the
-key, and it is considered private information.
-It is not packaged with the key when it is exported; it is even
-stored separately from your keyrings in a separate database.
-</para>
-
-<para>
-The &gnupg; key editor may be used to adjust your trust in a key's owner.
-The command is <link linkend="trust"><command>trust</command></link>.
-In this example Alice edits her trust in Blake and then updates
-the trust database to recompute which keys are valid based on her new
-trust in Blake.
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --edit-key blake</userinput>
-
-pub  1024D/8B927C8A  created: 1999-07-02 expires: never      trust: q/f
-sub  1024g/C19EA233  created: 1999-07-02 expires: never     
-(1)  Blake (Executioner) &lt;blake@cyb.org>
-
-<prompt>Command></prompt> <userinput>trust</userinput>
-pub  1024D/8B927C8A  created: 1999-07-02 expires: never      trust: q/f
-sub  1024g/C19EA233  created: 1999-07-02 expires: never     
-(1)  Blake (Executioner) &lt;blake@cyb.org>
-
-Please decide how far you trust this user to correctly
-verify other users' keys (by looking at passports,
-checking fingerprints from different sources...)?
-
- 1 = Don't know
- 2 = I do NOT trust
- 3 = I trust marginally
- 4 = I trust fully
- s = please show me more information
- m = back to the main menu
-
-<prompt>Your decision?</prompt> <userinput>3</userinput>
-                
-pub  1024D/8B927C8A  created: 1999-07-02 expires: never      trust: m/f
-sub  1024g/C19EA233  created: 1999-07-02 expires: never     
-(1)  Blake (Executioner) &lt;blake@cyb.org>
-
-<prompt>Command></prompt> <userinput>quit</userinput>
-[...]
-</screen>
-
-Trust in the key's owner and the key's validity are indicated to the
-right when the key is displayed.
-Trust in the owner is displayed first and the key's validity is 
-<!-- HERE, need to fix quotation marks -->
-second<footnote>
-<para>
-&Gnupg; overloads the word "trust" by using it to mean
-trust in an owner and trust in a key.
-This can be confusing.
-Sometimes trust in an owner is referred to as
-<firstterm>owner-trust</firstterm> to
-distinguish it from trust in a key.
-<!-- HERE, need to fix quotation marks -->
-Throughout this manual, however, "trust" is used to 
-mean trust in a key's
-<!-- HERE, need to fix quotation marks -->
-owner, and "validity" is used to mean trust that a key 
-belongs to the human associated with the key ID.
-</para>
-</footnote>.
-The four trust/validity levels are abbreviated: unknown (<literal>q</literal>),
-none (<literal>n</literal>), marginal (<literal>m</literal>), and 
-full (<literal>f</literal>).
-In this case, Blake's key is fully valid since Alice signed it herself.
-She initially has an unknown trust in Blake to properly sign other keys
-but decides to trust him marginally.
-</para>
-</sect2>
-
-<sect2>
-<title>
-Using trust to validate keys
-</title>
-
-<para>
-The web of trust allows a more elaborate algorithm to be used to
-validate a key.
-Formerly, a key was considered valid only if you signed it personally.
-<!-- HERE, math -->
-A more flexible algorithm can now be used: a key <emphasis>K</emphasis> is considered valid
-if it meets two conditions:
-<orderedlist spacing="compact">
-<listitem>
-<para>
-it is signed by enough valid keys, meaning
-<itemizedlist spacing="compact">
-<listitem>
-<para>
-you have signed it personally, 
-</para>
-</listitem>
-<listitem>
-<para>
-it has been signed by one fully trusted key, or
-</para>
-</listitem>
-<listitem>
-<para>
-it has been signed by three marginally trusted keys; and
-</para>
-</listitem>
-</itemizedlist>
-</para>
-</listitem>
-<listitem>
-<para>
-<!-- HERE, math -->
-the path of signed keys leading from <emphasis>K</emphasis> back 
-to your own key is five steps or shorter.
-</para>
-</listitem>
-</orderedlist>
-
-The path length, number of marginally trusted keys required, and number
-of fully trusted keys required may be adjusted.
-The numbers given above are the default values used by &gnupg;.
-</para>
-
-<para>
-<xref linkend="wot-examples"> shows a web of trust rooted at Alice.
-The graph illustrates who has signed who's keys.
-The table shows which keys Alice considers valid based on her
-trust in the other members of the web.
-<comment>Potential bug: <option>--completes-needed</option> on command 
-line seems to be ignored when combined with <option>--update-trustdb</option>.
-Value is taken correctly if put in options file, however.</comment>
-This example assumes that two marginally-trusted keys or one
-fully-trusted key is needed to validate another key.
-The maximum path length is three.
-</para>
-
-<para>
-When computing valid keys in the example, Blake and Dharma's are
-always considered fully valid since they were signed directly
-by Alice.
-The validity of the other keys depends on trust.
-In the first case, Dharma is trusted fully, which implies 
-that Chloe's and Francis's keys will be considered valid.
-In the second example, Blake and Dharma are trusted marginally.
-Since two marginally trusted keys are needed to fully validate a
-key, Chloe's key will be considered fully valid, but Francis's 
-key will be considered only marginally valid.
-In the case where Chloe and Dharma are marginally trusted,
-Chloe's key will be marginally valid since Dharma's key is
-fully valid.
-Francis's key, however, will also be considered marginally
-valid since only a fully valid key can be used to validate
-other keys, and Dharma's key is the only fully valid key
-that has been used to sign Francis's key.
-When marginal trust in Blake is added, Chloe's key becomes
-fully valid and can then be used to fully validate Francis's
-key and marginally validate Elena's key.
-Lastly, when Blake, Chloe, and Elena are fully trusted, this is
-still insufficient to validate Geoff's key since the maximum
-certification path is three, but the path length from Geoff
-back to Alice is four.
-</para>
-
-<para>
-The web of trust model is a flexible approach to the problem of safe
-public key exchange.
-It permits you to tune &gnupg; to reflect how you use it.
-At one extreme you may insist on multiple, short paths from your
-<!-- HERE, math -->
-key to another key <emphasis>K</emphasis> in order to trust it.
-On the other hand, you may be satisfied with longer paths and
-<!-- HERE, math -->
-perhaps as little as one path from your key to the other 
-key <emphasis>K</emphasis>.
-<!-- HERE, math -->
-Requiring multiple, short paths is a strong guarantee 
-that <emphasis>K</emphasis> belongs to whom your think it does.
-The price, of course, is that it is more difficult to validate keys
-since you must personally sign more keys than if you accepted fewer
-and longer paths.
-</para>
-
-<figure id="wot-examples" float=1>
-<title>
-A hypothetical web of trust
-</title>
-<!--
-The graph indicates who has signed who's keys.
-The table, in which names have been abbreviated, shows which keys are 
-valid depending on how Alice trusts other members in the web.
-Alice considers different keys valid depending on how she trusts
-the members of the web.
--->
-
-<graphic fileref="signatures.jpg"></graphic>
-
-<informaltable frame="all">
-<tgroup cols="4" rowsep="1" colsep="1">
-<colspec colname="one" colnum="1">
-<colspec colname="two" colnum="2">
-<colspec colname="three" colnum="3">
-<colspec colname="four" colnum="4">
-<spanspec spanname="lefthalf" namest="one" nameend="two" align="center">
-<spanspec spanname="righthalf" namest="three" nameend="four" align="center">
-
-<thead>
-<colspec
-<row>
-<entry spanname="lefthalf">trust</entry>
-<entry spanname="righthalf">validity</entry>
-</row>
-<row>
-<entry align="center">marginal</entry>
-<entry align="center">full</entry>
-<entry align="center">marginal</entry>
-<entry align="center">full</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry></entry>
-<entry>Dharma</entry>
-<entry></entry>
-<entry>Blake, Chloe, Dharma, Francis</entry>
-</row>
-
-<row>
-<entry>Blake, Dharma</entry>
-<entry></entry>
-<entry>Francis</entry>
-<entry>Blake, Chloe, Dharma</entry>
-</row>
-
-<row>
-<entry>Chloe, Dharma</entry>
-<entry></entry>
-<entry>Chloe, Francis</entry>
-<entry>Blake, Dharma</entry>
-</row>
-
-<row>
-<entry>Blake, Chloe, Dharma</entry>
-<entry></entry>
-<entry>Elena</entry>
-<entry>Blake, Chloe, Dharma, Francis</entry>
-</row>
-
-<row>
-<entry></entry>
-<entry>Blake, Chloe, Elena</entry>
-<entry></entry>
-<entry>Blake, Chloe, Elena, Francis</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</figure>
-</sect2>
-</sect1>
-
-<sect1>
-<title>
-Distributing keys
-</title>
-
-<para>
-Ideally, you distribute your key by personally giving it to your
-correspondents.
-In practice, however, keys are often distributed by email or some
-other electronic communication medium.
-Distribution by email is good practice when you have only a few
-correspondents, and even if you have many correspondents, you can use
-an alternative means such as posting your public key on your World Wide
-Web homepage.
-This is unacceptable, however, if people who need your public key do
-not know where to find it on the Web.
-</para>
-
-<para>
-To solve this problem public key servers are used to collect
-and distribute public keys.
-A public key received by the server is either added to the server's
-database or merged with the existing key if already present.
-When a key request comes to the server, the server consults its
-database and returns the requested public key if found.
-</para>
-
-<para>
-A keyserver is also valuable when many people are frequently signing other
-people's keys.
-Without a keyserver, when Blake sign's Alice's key then Blake would send
-Alice a copy of her public key signed by him so that Alice could
-add the updated key to her ring as well as distribute it to all of her
-correspondents.
-Going through this effort fulfills Alice's and Blake's responsibility 
-to the community at large in building tight webs of trust and thus
-improving the security of PGP.
-It is nevertheless a nuisance if key signing is frequent.
-</para>
-
-<para>
-Using a keyserver makes the process somewhat easier.
-When Blake signs Alice's key he sends the signed key to the key server.
-The key server adds Blake's signature to its copy of Alice's key.
-Individuals interested in updating their copy of Alice's key then consult
-the keyserver on their own initiative to retrieve the updated key.
-Alice need never be involved with distribution and can retrieve signatures
-on her key simply by querying a keyserver.
-<comment><option>--keyserver</option> must come before
-<option>--send-key</option> or <option>--recv-key</option>.  
-This appears to be a bug.</comment>
-</para>
-
-<para>
-One or more keys may be sent to a keyserver using the command-line
-option <link linkend="send-keys"><option>--send-keys</option></link>.
-The option takes one or more key specifiers and sends the specified
-keys to the key server.
-The key server to which to send the keys is specified with the
-command-line option <link linkend="keyserver"><option>--keyserver</option></link>.
-Similarly, the option 
-<link linkend="recv-keys"><option>--recv-keys</option></link> is used 
-to retrieve keys from a keyserver, but the option <option>--recv-keys</option>
-requires a key ID be used to specify the key.
-In the following example Alice sends her public key to the keyserver
-<parameter>certserver.pgp.com</parameter> and then updates her copy 
-of Blake's key from the same keyserver.
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC</userinput>
-gpg: requesting key BB7576AC from certserver.pgp.com ...
-gpg: key BB7576AC: 1 new signature
-
-gpg: Total number processed: 1
-gpg:         new signatures: 1
-<prompt>alice%</prompt> <userinput>gpg --keyserver certserver.pgp.com --send-key blake@cyb.org</userinput>
-gpg: success sending to 'certserver.pgp.com' (status=200)
-</screen>
-
-There are several popular keyservers in use around the world.
-The major keyservers synchronize themselves, so it is fine to
-pick a keyserver close to you on the Internet and then use it
-regularly for sending and receiving keys.
-</para>
-</sect1>
-
-</chapter>
-
diff --git a/doc/gph/c4.sgml b/doc/gph/c4.sgml
deleted file mode 100644
index 1932da7ae..000000000
--- a/doc/gph/c4.sgml
+++ /dev/null
@@ -1,433 +0,0 @@
-<chapter id="wise" xreflabel="4">
-<docinfo>
-<date>
-$Id$
-</date>
-</docinfo>
-<title>
-Daily use of &Gnupg;
-</title>
-
-<para>
-&Gnupg; is a complex tool with technical, social, and legal issues
-surrounding it.
-Technically, it has been designed to be used in situations having
-drastically different security needs.
-This complicates key management.
-Socially, using &gnupg; is not strictly a personal decision.
-To use &gnupg effectively both parties communicating must use it.
-Finally, as of 1999, laws regarding digital encryption, and in particular
-whether or not using &gnupg; is legal, vary from country to country and 
-is currently being debated by many national governments.
-</para>
-
-<para>
-This chapter addresses these issues.
-It gives practical advice on how to use &gnupg; to meet your security needs.
-It also suggests ways to promote the use of &gnupg; for secure
-communication between yourself and your colleagues when your colleagues
-are not currently using &gnupg;.
-Finally, the legal status of &gnupg; is outlined given the current status
-of encryption laws in the world.
-</para>
-
-<sect1>
-<title>
-Defining your security needs
-</title>
-
-<para>
-&Gnupg; is a tool you use to protect your privacy.
-Your privacy is protected if you can correspond with others without
-eavesdroppers reading those messages.
-</para>
-
-<para>
-How you should use &gnupg; depends on the determination and resourcefulness
-of those who might want to read your encrypted messages.
-An eavesdropper may be an unscrupulous system administrator casually
-scanning your mail, it might be an industrial spy trying to collect
-your company's secrets, or it might be a law enforcement agency trying
-to prosecute you.
-Using &gnupg; to protect against casual eavesdropping is going to be
-different than using &gnupg; to protect against a determined adversary.
-Your goal, ultimately, is to make it more expensive to recover the
-unencrypted data than that data is worth.
-</para>
-
-<para>
-Customizing your use of &gnupg; revolves around three issues:
-<itemizedlist spacing="compact">
-<listitem>
-<para>
-the key size of your public/private keypair,
-</para>
-</listitem>
-
-<listitem>
-<para>
-protecting your private key, and
-</para>
-</listitem>
-
-<listitem>
-<para>
-managing your web of trust.
-</para>
-</listitem>
-</itemizedlist>
-
-A well-chosen key size protects you against brute-force attacks on
-encrypted messages.
-Protecting your private key prevents an attacker from simply using your
-private key to decrypt encrypted messages and sign messages in your name.
-Correctly managing your web of trust prevents attackers from masquarading
-as people with whom you communicate.
-Ultimately, addressing these issues with respect to your own security
-needs is how you balance the extra work required to use &gnupg; with
-the privacy it gives you.
-</para>
-
-<sect2>
-<title>
-Choosing a key size
-</title>
-
-<para>
-Selecting a key size depends on the key.
-In OpenPGP, a public/private keypair usually has multiple keys.
-At the least it has a master signing key, and it probably has one or
-more additional subkeys for encryption.
-Using default key generation parameters with &gnupg;, the master
-key will be a DSA key, and the subkeys will be ElGamal keys.
-</para>
-
-<para>
-DSA allows a key size up to 1024 bits.
-This is not especially good given today's factoring technology, but
-that is what the standard specifies.
-Without question, you should use 1024 bit DSA keys.
-</para>
-
-<para>
-ElGamal keys, on the other hand, may be of any size.
-Since &gnupg; is a hybrid public-key system, the public key is used
-to encrypt a 128-bit session key, and the private key is used to
-decrypt it.
-Key size nevertheless affects encryption and decryption speed
-since the cost of these algorithms is exponential in the size of
-the key.
-Larger keys also take more time to generate and take more space
-to store.
-Ultimately, there are diminishing returns on the extra security
-a large key provides you.
-After all, if the key is large enough to resist a brute-force
-attack, an eavesdropper will merely switch to some other method for
-obtaining your plaintext data.
-Examples of other methods include robbing your home or office
-and mugging you.
-1024 bits is thus the recommended key size.
-If you genuinely need a larger key size then you probably already
-know this and should be consulting an expert in data security.
-</para>
-</sect2>
-
-<sect2>
-<title>
-Protecting your private key
-</title>
-
-<para>
-Protecting your private key is the most important job you have to
-use &gnupg; correctly.
-If someone obtains your private key, then all data encrypted to
-the private key can be decrypted and signatures can be made in your name.
-If you lose your private key, then you will no longer be able to 
-decrypt documents encrypted to you in the future or in the past,
-and you will not be able to make signatures.
-Losing sole possession of your private key is catastrophic.
-</para>
-
-<para>
-Regardless of how you use &gnupg; you should store the public
-key's <link linkend="revocation">revocation certificate</link> 
-and a backup of your private key on write-protected media in a safe place.
-For example, you could burn them on a CD-ROM and store them in your
-safe deposit box at the bank in a sealed envelope.
-Alternatively, you could store them on a floppy and hide it in your
-house.
-Whatever you do, they should be put on media that is safe to store
-for as long as you expect to keep the key, and you should store
-them more carefully than the copy of your private key you use daily.
-</para>
-
-<para>
-To help safeguard your key, &Gnupg; does not store your raw
-private key on disk.
-Instead it encrypts it using a symmetric encryption algorithm.
-That is why you need a passphrase to access the key.
-Thus there are two barriers an attacker must cross to access your private
-key: (1) he must actually acquire the key, and (2) he must get past
-the encryption.
-</para>
-
-<para>
-Safely storing your private key is important, but there is a cost.
-Ideally, you would keep the private key on a removable, write-protected disk
-such as a floppy disk, and you would use it on a single-user machine 
-not connected to a network.
-This may be inconvenient or impossible for you to do.
-For example, you may not own your own machine and must use a computer 
-at work or school, or it may mean you have to physically disconnect
-your computer from your cable modem every time you want to use &gnupg;
-</para>
-
-<para>
-This does not mean you cannot or should not use &gnupg;.
-It means only that you have decided that the data you are protecting is
-important enough to encrypt but not so important as to take extra
-steps to make the first barrier stronger.
-It is your choice.
-</para>
-
-<para>
-A good passphrase is absolutely critical when using &gnupg;.
-Any attacker who gains access to your private key must bypass the 
-encryption on the private key.
-Instead of brute-force guessing the key, an attacker will almost
-certainly instead try to guess the passphrase.
-</para>
-
-<para>
-The motivation for trying passphrases is that most people choose
-a passphrase that is easier to guess than a random 128-bit key.
-If the passphrase is a word, it is much cheaper to try all the
-words in the dictionaries of the world's languages.
-Even if the word is permuted, &eg, k3wldood, it is still easier
-to try dictionary words with a catalog of permutations.
-The same problem applies to quotations.
-In general, passphrases based on natural-language utterances
-are poor passphrases since there is little randomness and lots
-of redundancy in natural language.
-You should avoid natural language passphrases if you can.
-</para>
-
-<para>
-A good passphrase is one that you can remember but is hard for
-someone to guess.
-It should include characters from the whole range of printable characters
-on your keyboard.
-This includes uppercase alphabetics characters, numbers, and special
-characters such as <literal>}</literal> and <literal>|</literal>.
-Be creative and spend a little time considering your passphrase; a
-good choice is important to ensure your privacy.
-</para>
-</sect2>
-
-<!--
-<sect2>
-<title>
-Reacting to a compromised private key
-</title>
-
-<para>
-Despite your precautions you may lose sole access to your private key.
-For example, you may forget the passphrase, or someone who you think 
-can bypass the encryption gets access to it.
-In that case then you need to spread the word that your key is no 
-longer valid.
-To do that you use the key revocation certificate you should have generated
-when you created the key.
-Importing it onto your public keyring will revoke the public key
-of the keypair you no longer wish to use.
-It is then up to you to distribute the revoked public key to all 
-those who may encrypt documents to you.
-</para>
-
-<para>
-A revoked public key only prevents future use of the private key.
-Others will neither be able to encrypt documents to the key nor will
-they be able to check signatures made with the private key.
-Documents signed in the past can still be checked, however, and
-documents encrypted in the past can still be decrypted.
-</para>
-
-<para>
-It is important that you protect the revocation certificate carefully.
-Anybody can add the certificate to your public key and distribute it,
-and there is no way to revoke a revocation certificate.
-Therefore, you should store the revocation certificate in a safe
-place such as with the backup of your private key.
-</para>
-</sect2>
--->
-
-<sect2>
-<title>
-Managing your web of trust
-</title>
-
-<para>
-As with protecting your private key, managing your web of trust is
-another aspect of using &gnupg; that requires balancing security against
-ease of use.
-If you are using &gnupg; to protect against casual eavesdropping and
-forgeries then you can afford to be relatively trusting of other
-people's signatures.
-On the other hand, if you are concerned that there may be a determined
-attacker interested in invading your privacy, then
-you should be much less trusting of other signatures and spend more time 
-personally verifying signatures.
-</para>
-
-<para>
-Regardless of your own security needs, through, you should 
-<emphasis>always be careful</emphasis> when signing other keys.
-It is selfish to sign a key with just enough confidence in the key's
-validity to satisfy your own security needs.
-Others, with more stringent security needs, may want to depend on 
-your signature.
-If they cannot depend on you then that weakens the web of trust
-and makes it more difficult for all &gnupg; users to communicate.
-Use the same care in signing keys that you would like others to use when
-you depend on their signatures.
-</para>
-
-<para>
-In practice, managing your web of trust reduces to assigning trust to 
-others and tuning the options 
-<link linkend="marginals-needed"><option>--marginals-needed</option></link>
-and 
-<link linkend="completes-needed"><option>--completes-needed</option></link>.
-Any key you personally sign will be considered valid, but except for small
-groups, it will not be practical to personally sign the key of every person
-with whom you communicate.
-You will therefore have to assign trust to others.
-</para>
-
-<para>
-It is probably wise to be accurate when assigning trust and then
-use the options to tune how careful &gnupg; is with key validation.
-As a concrete example, you may fully trust a few close friends that
-you know are careful with key signing and then marginally
-trust all others on your keyring.
-From there, you may set <option>--completes-needed</option> to
-<literal>1</literal> and <option>--marginals-needed</option> to
-<literal>2</literal>.
-If you are more concerned with security you might choose values of
-<literal>1</literal> and <literal>3</literal> or <literal>2</literal>
-and <literal>3</literal> respectively.
-If you are less concerned with privacy attacks and just want some
-reasonable confidence about validity, set the values to <literal>1</literal>
-and <literal>1</literal>.
-In general, higher numbers for these options imply that more people
-would be needed to conspire against you in order to have a key validated
-that does not actually belong to the person whom you think it does.
-</para>
-</sect2>
-</sect1>
-
-<sect1>
-<title>
-Building your web of trust
-</title>
-
-<para>
-Wanting to use &gnupg; yourself is not enough.
-In order to use to communicate securely with others you must have
-a web of trust.
-At first glance, however, building a web of trust is a daunting task.
-The people with whom you communicate need to use 
-&gnupg;<footnote><para>In this section, &gnupg; refers to the 
-&gnupg; implementation of OpenPGP as well as other implementations 
-such as NAI's PGP product.</para></footnote>, and there needs to be enough 
-key signing so that keys can be considered valid.
-These are not technical problems; they are social problems.
-Nevertheless, you must overcome these problems if you want to 
-use &gnupg;.
-</para>
-
-<para>
-When getting started using &gnupg; it is important to realize that you
-need not securely communicate with every one of your correspondents.
-Start with a small circle of people, perhaps just yourself and
-one or two others who also want to exercise their right
-to privacy.
-Generate your keys and sign each other's public keys.
-This is your initial web of trust.
-By doing this you will appreciate the value of a small, robust
-web of trust and will be more cautious as you grow your web
-in the future.
-</para>
-
-<para>
-In addition to those in your initial web of trust, you may want to
-communicate securely with others who are also using &gnupg;.
-Doing so, however, can be awkward for two reasons:
-(1) you do not always know when someone uses or is willing to use
-&gnupg;, and (2) if you do know of someone who uses it, you may still have
-trouble validating their key.
-The first reason occurs because people do not always advertise that
-they use &gnupg;.
-The way to change this behavior is to set the example and advertise 
-that you use &gnupg;.
-There are at least three ways to do this: you can sign messages you mail
-to others or post to message boards, you can put your public key on your
-web page, or, if you put your key on a keyserver, you can put your key
-ID in your email signature.
-If you advertise your key then you make it that much more acceptable
-for others to advertise their keys.
-Furthermore, you make it easier for others to start communicating
-with you securely since you have taken the initiative and made it clear
-that you use &gnupg;.
-</para>
-
-<para>
-Key validation is more difficult.
-If you do not personally know the person whose key you want to sign,
-then it is not possible to sign the key yourself.
-You must rely on the signatures of others and hope to find a chain
-of signatures leading from the key in question back to your own.
-To have any chance of finding a chain, you must take the intitive
-and get your key signed by others outside of your intitial web of trust.
-An effective way to accomplish this is to participate in key
-signing parties.
-If you are going to a conference look ahead of time for a key
-signing party, and if you do not see one being held, offer to 
-<ulink url="http://www.herrons.com/kb2nsx/keysign.html">hold one</ulink>.
-You can also be more passive and carry your fingerprint with you
-for impromptu key exchanges.
-In such a situation the person to whom you gave the fingerprint
-would verify it and sign your public key once he returned home.
-</para>
-
-<para>
-Keep in mind, though, that this is optional.
-You have no obligation to either publically advertise your key or
-sign other people's keys.
-The power of &gnupg; is that it is flexible enough to adapt to your
-security needs whatever they may be.
-The social reality, however, is that you will need to take the initiative
-if you want to grow your web of trust and use &gnupg; for as much of 
-your communication as possible.
-</para>
-</sect1>
-
-<sect1>
-<title>
-Using &Gnupg; legally
-</title>
-
-<para>
-The legal status of encryption software varies from country to country,
-and law regarding encryption software is rapidly evolving.
-<ulink url="http://cwis.kub.nl/~frw/people/koops/bertjaap.htm">Bert-Japp 
-Koops</ulink> has an excellent 
-<ulink url="http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm">Crypto
-Law Survey</ulink> to which you should refer for the legal status of
-encryption software in your country.
-</para>
-
-</sect1>
-</chapter>
-
diff --git a/doc/gph/c5.sgml b/doc/gph/c5.sgml
deleted file mode 100644
index b847e5853..000000000
--- a/doc/gph/c5.sgml
+++ /dev/null
@@ -1,38 +0,0 @@
-<chapter id="Modules" xreflabel="5">
-<docinfo>
-<date>
-$Id$
-</date>
-</docinfo>
-<title>
-Programming with &Gnupg;
-</title>
-
-<para>...</para>
-
-<sect1>
-<title>
-Using &gpg in batch mode
-</title>
-
-<para>...</para>
-
-<sect2>
-<title>
-Invoking &gpg from mail clients
-</title>
-
-<para>...</para>
-</sect2>
-</sect1>
-
-<sect1>
-<title>
-Writing extension modules
-</title>
-
-<para>...</para>
-</sect1>
-
-</chapter>
-
diff --git a/doc/gph/c6.sgml b/doc/gph/c6.sgml
deleted file mode 100644
index 1b82a8c9a..000000000
--- a/doc/gph/c6.sgml
+++ /dev/null
@@ -1,804 +0,0 @@
-<reference>
-<docinfo>
-<date>
-$Id$
-</date>
-</docinfo>
-<title>
-Command Reference
-</title>
-
-<partintro>
-<sect1>
-<title>
-Key specifiers
-</title>
-
-<para>
-Many commands and options require a <firstterm>key specifier</firstterm>.
-A key specifier is the key ID or any portion of ther user ID of
-a key.
-Consider the following example.
-
-<screen width="80">
-<prompt>alice%</prompt> <userinput>gpg --list-keys chloe</userinput>
-pub  1024D/B87DBA93 1999-06-28 Chloe (Jester) &lt;chloe@cyb.org>
-uid                            Chloe (Plebian) &lt;chloe@tel.net>
-sub  2048g/B7934539 1999-06-28
-</screen>
-
-For this key, <literal>0xB87DBA93</literal>,
-<literal>Chloe</literal>,
-<literal>Plebian</literal>, and
-<literal>oe@tel</literal>
-are all examples of key specifiers that match the above key.
-</para>
-</sect1>
-</partintro>
-
-<refentry id="send-keys">
-<refnamediv>
-<refname>
-send-keys
-</refname>
-<refpurpose>
-send keys to a key server
-</refpurpose>
-
-
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-send-keys <replaceable class="parameter">key</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command sends a public key to a keyserver.  
-The parameter <replaceable class="parameter">key</replaceable> specifies 
-the public key that should be uploaded.
-The command requires the option
-<link linkend="keyserver"><option>keyserver</option></link> to specify
-to which keyserver &gpg; should send the keys.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="recv-keys">
-<refnamediv>
-<refname>
-recv-keys
-</refname>
-<refpurpose>
-retrieve keys from a key server
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>recv-keys</option> <replaceable class="parameter">key-id key-id ...</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command downloads one or more public keys from a keyserver.  
-Each <replaceable class="parameter">key-id</replaceable> is a key ID.
-The command requires the option
-<link linkend="keyserver"><option>keyserver</option></link> to 
-specify from which keyserver &gpg; should download the keys.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="encrypt">
-<refnamediv>
-<refname>
-encrypt
-</refname>
-<refpurpose>
-encrypt a document
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>encrypt</option> <replaceable class="parameter">filename</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command encrypts the document 
-<replaceable class="parameter">filename</replaceable> to
-recipients specified using the 
-option <link linkend="recipient"><option>recipient</option></link>.
-If the parameter <replaceable class="parameter">filename</replaceable>
-is omitted, then the document to encrypt is taken from standard input.
-If the option <option>recipient</option> is omitted,
-&gpg; will prompt for a recipient.
-If the option <link linkend="output"><option>output</option></link> is used,
-&gpg; will output the encrypted information to the specified file.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="decrypt">
-<refnamediv>
-<refname>
-decrypt
-</refname>
-<refpurpose>
-decrypt an encrypted document
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>decrypt</option> <replaceable class="parameter">filename</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command decrypts <replaceable class="parameter">filename</replaceable>
-and puts the result on standard output.
-If the parameter <replaceable class="parameter">filename</replaceable>
-is omitted, then the document to decrypt is taken from standard input.
-Use the option <link linkend="output"><option>output</option></link>
-to output the decrypted message to a file instead.
-</para>
-</refsect1>
-</refentry>
-
-
-<refentry id="clearsign">
-<refnamediv>
-<refname>
-clearsign
-</refname>
-<refpurpose>
-make a cleartext signature
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>clearsign</option> <replaceable class="parameter">filename</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command signs a message that can be verified to ensure that the 
-original message has not been changed.
-Verification of the signed message is done using the command
-<link linkend="verify"><option>verify</option></link>.
-
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="fingerprint">
-<refnamediv>
-<refname>
-fingerprint
-</refname>
-<refpurpose>
-display key fingerprints
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>fingerprint</option> <replaceable class="parameter">name ...</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command prints the fingerprints of the specified public keys.
-The parameter <replaceable class="parameter">name</replaceable> is a
-key specifier.
-If no parameter <replaceable class="parameter">name</replaceable> is
-provided, &gpg; will print the fingerprints of all the keys on 
-your public keyring.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="detach-sig">
-<refnamediv>
-<refname>
-detach-sig
-</refname>
-<refpurpose>
-make a detached signature
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>detach-sig</option> <replaceable class="parameter">filename</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command creates a signature file that can be used 
-to verify that the orginal file 
-<replaceable class="parameter">filename</replaceable> has not
-been changed.  
-Verification of the file using a detached signature is done using the 
-command <link linkend="verify"><option>verify</option></link>.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="gen-key">
-<refnamediv>
-<refname>
-gen-key
-</refname>
-<refpurpose>
-generate a new keypair
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>gen-key</option>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command generates a private/public key pair for use in encrypting, 
-decrypting, and signing of messages.
-You will br prompted for the kind of key you wish to create, the key 
-size, and the key's expiration date.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="symmetric">
-<refnamediv>
-<refname>
-symmetric
-</refname>
-<refpurpose>
-encrypt a document using only a symmetric encryption algorithm
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>symmetric</option> <replaceable class="parameter">filename</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command encrypts a document using a symmetric algorithm with
-a key derived from a passphrase supplied by you during execution.
-The key should be selected to make it difficult to randomly guess the key.
-To decrypt a document encrypted in this manner use the command.
-<link linkend="decrypt"><option>decrypt</option></link>.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="list-keys">
-<refnamediv>
-<refname>
-list-keys
-</refname>
-<refpurpose>
-list information about the specified keys
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>list-keys</option> <replaceable class="parameter">key ...</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command lists the public key specified by the key specifiers on the
-command line.
-If no key specifier is given, &gpg; will print all of the keys on the 
-public keyring.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="import">
-<refnamediv>
-<refname>
-import
-</refname>
-<refpurpose>
-import keys to a local keyring
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>import</option> <replaceable class="parameter">filename</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command imports one or more public keys onto the user's public 
-keyring from the file <replaceable class="parameter">filename</replaceable>.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="verify">
-<refnamediv>
-<refname>
-verify
-</refname>
-<refpurpose>
-verify a signed document
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>verify</option> <replaceable class="parameter">signature document</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command verifies a document against a signature
-to ensure that the document has not been altered since the signature
-was created.
-If <replaceable class="parameter">signature</replaceable> is omitted,
-&gpg; will look in <replaceable class="parameter">document</replaceable>
-for a clearsign signature.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="gen-revoke">
-<refnamediv>
-<refname>
-gen-revoke
-</refname>
-<refpurpose>
-generate a revocation certificate for a public/private keypair
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>gen-revoke</option> <replaceable class="parameter">key</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command generates a revocation certificate for a public/private 
-key pair.  
-The parameter <replaceable class="parameter">key</replaceable> is 
-a key specifier.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="export">
-<refnamediv>
-<refname>
-export
-</refname>
-<refpurpose>
-export keys from a local keyring
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>export</option> <replaceable class="parameter">key key ...</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command exports the public keys components of the keys specified
-by the key specifiers <replaceable class="parameter">key key ...</replaceable>.
-The export command by default sends its output to standard output.  
-This key file can later be imported into another keyring using the command
-<link linkend="import"><option>import</option></link>.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="edit-key">
-<refnamediv>
-<refname>
-edit-key
-</refname>
-<refpurpose>
-presents a menu for operating on keys
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>edit-key</option> <replaceable class="parameter">key</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This command presents a menu which enables you to perform
-key-related taskes.
-The key specifier <replaceable class="parameter">key</replaceable>
-specifies the key pair to be edited.
-If the specifier matches more than one key pair, &gpg; issues
-an error and exits.
-</para>
-
-<para>
-Key listings displayed during key editing show the key with its
-secondary keys and all user ids.
-Selected keys or user ids are indicated by an asterisk.
-The trust and validity values are displayed with the primary key: 
-the first is the assigned trust and the second is the
-calculated validity.
-Letters are used for the values:
-
-<informaltable>
-<tgroup cols="2" rowsep="1" colsep="1">
-<thead>
-<row>
-<entry>Letter</entry>
-<entry>Meaning</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry>
--
-</entry>
-<entry>
-No ownertrust assigned / not yet calculated.
-</entry>
-</row>
-<row>
-<entry>
-e
-</entry>
-<entry>
-Trust calculation has failed.
-</entry>
-</row>
-
-<row>
-<entry>
-q
-</entry>
-<entry>
-Not enough information for calculation.
-</entry>
-</row>
-
-<row>
-<entry>
-n
-</entry>
-<entry>
-Never trust this key.
-</entry>
-</row>
-
-<row>
-<entry>
-m
-</entry>
-<entry>
-Marginally trusted.
-</entry>
-</row>
-
-<row>
-<entry>
-f
-</entry>
-<entry>
-Fully trusted.
-</entry>
-</row>
-
-<row>
-<entry>
-u
-</entry>
-<entry>
-Ultimately trusted.
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</para>
-
-<para>
-The following lists each key editing command and a description
-of its behavior.
-</para>
-
-<refsect2 id="sign">
-<title>
-sign
-</title>
-
-<para>
-Makes a signature on the current key.
-If th  key is not yet signed by the default user or the user 
-given with the option
-<link linkend="local-user"><option>local-user</option></link>, 
-the program displays the information of the key again, together with
-its  fingerprint and asks whether it should be signed.
-This question is repeated for all users specified with the option
-<option>local-user</option>.
-</para>
-</refsect2>
-
-<refsect2 id="lsign">
-<title>
-lsign
-</title>
-
-<para>
-Same as <link linkend="sign">sign</link>, but the signature is
-marked as non-exportable and will therefore never be used by others.
-This may be used to make keys valid only in the local environment.
-</para>
-</refsect2>
-
-<refsect2 id="revsig">
-<title>
-revsig
-</title>
-
-<para>
-Revoke a signature.
-Asks for each signature makde by a one of the private keys whether
-a revocation certificate should be generated.
-</para>
-</refsect2>
-
-<refsect2 id="trust">
-<title>
-trust
-</title>
-
-<para>
-Change the owner trust value.
-This updates the trust database immediately and no save is required.
-</para>
-</refsect2>
-
-<refsect2 id="disable">
-<title>
-disable
-</title>
-
-<para>
-Disable the key.
-A disabled key cannot normally be used for encryption.
-</para>
-</refsect2>
-
-<refsect2 id="enable">
-<title>
-enable
-</title>
-
-<para>
-Enable a key that has been previously
-<link linkend="disable">disabled</link>.
-</para>
-</refsect2>
-
-<refsect2 id="adduid">
-<title>
-adduid
-</title>
-
-<para>
-Add a new user id to the current key.
-</para>
-</refsect2>
-
-<refsect2 id="deluid">
-<title>
-deluid
-</title>
-
-<para>
-Delete a user id from the current key.
-</para>
-</refsect2>
-
-<refsect2 id="addkey">
-<title>
-addkey
-</title>
-
-<para>
-Add a new subkey to the current key.
-</para>
-</refsect2>
-
-<refsect2 id="delkey">
-<title>
-delkey
-</title>
-
-<para>
-Delete a subkey from the current key.
-</para>
-</refsect2>
-
-<refsect2 id="revkey">
-<title>
-revkey
-</title>
-
-<para>
-Revoke a subkey of the current key.
-</para>
-</refsect2>
-
-<refsect2 id="expire">
-<title>
-expire
-</title>
-
-<para>
-Change a key expiration time.
-If a subkey is selected, the time of that key will be changed.
-With no selection the expiration time of the current primary key is changed.
-</para>
-</refsect2>
-
-<refsect2 id="key">
-<title>
-key n
-</title>
-
-<para>
-Toggle selection of subkey with index n.
-Use 0 to deselect all.
-</para>
-</refsect2>
-
-<refsect2 id="uid">
-<title>
-uid n
-</title>
-
-<para>
-Toggle selection of user id with index n.
-Use 0 to deselect all.
-</para>
-</refsect2>
-
-<refsect2 id="passwd">
-<title>
-toggle
-</title>
-
-<para>
-Change the passphrase of the private key of the selected key pair.
-</para>
-</refsect2>
-
-<refsect2 id="toggle">
-<title>
-toggle
-</title>
-
-<para>
-Toggle between public and private key listings.
-</para>
-</refsect2>
-
-<refsect2 id="check">
-<title>
-check
-</title>
-
-<para>
-Check all selected user ids.
-</para>
-</refsect2>
-
-<refsect2 id="pref">
-<title>
-pref
-</title>
-
-<para>
-List preferences.
-</para>
-</refsect2>
-
-<refsect2 id="save">
-<title>
-save
-</title>
-
-<para>
-Save all changes to the current key and quit.
-</para>
-</refsect2>
-
-<refsect2 id="quit">
-<title>
-save
-</title>
-
-<para>
-Quit without updating the current key.
-</para>
-</refsect2>
-
-</refsect1>
-</refentry>
-</reference>
diff --git a/doc/gph/c7.sgml b/doc/gph/c7.sgml
deleted file mode 100644
index 17f3186f1..000000000
--- a/doc/gph/c7.sgml
+++ /dev/null
@@ -1,251 +0,0 @@
-<reference>
-<docinfo>
-<date>
-$Id$
-</date>
-</docinfo>
-<title>
-Options Reference
-</title>
-
-<partintro>
-<sect1 id="optionsfile">
-<title>
-Setting options
-</title>
-
-<para>
-Options may be specified on the command line or in an options file.
-The default location of the options file is
-<literal>~/.gnupg/options</literal>.
-When specifying options in the options file, omit the leading two
-dashes and instead use simply the option name followed by any
-arguments.
-Lines in the file with a hash (<literal>#</literal>) as the 
-first non-white-space character are ignored.
-</para>
-</sect1>
-</partintro>
-
-<refentry id="keyserver">
-<refnamediv>
-<refname>
-keyserver
-</refname>
-<refpurpose>
-specify the keyserver to use to locate keys
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>keyserver</option> <replaceable class="parameter">server-name</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This option is used in conjunction with either 
-<link linkend="recv-keys"><option>recv-keys</option></link> or 
-<link linkend="send-keys"><option>send-keys</option></link> to specify a
-keyserver to manage public key distribution.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="output">
-<refnamediv>
-<refname>
-output
-</refname>
-<refpurpose>
-specify the file in which to place output
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>output</option> <replaceable class="parameter">file-name</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This is a description.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="recipient">
-<refnamediv>
-<refname>
-recipient
-</refname>
-<refpurpose>
-specify the recipient of a public-key encrypted document
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This is a description.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="armor">
-<refnamediv>
-<refname>
-armor
-</refname>
-<refpurpose>
-ASCII-armor encrypted or signed output
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This is a description.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="no-greeting">
-<refnamediv>
-<refname>
-no-greeting
-</refname>
-<refpurpose>
-suppress the opening copyright notice but do not enter batch mode
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-This is a description.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="local-user">
-<refnamediv>
-<refname>
-local-user
-</refname>
-<refpurpose>
-specifies a user id to use for signing
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>localuser</option> <replaceable class="parameter">name</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-Use <replaceable class="parameter">name</replaceable> as the user ID to sign.
-This option is silently ignored for the list commands, so that it can be 
-used in an options file.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="completes-needed">
-<refnamediv>
-<refname>
-completes-needed
-</refname>
-<refpurpose>
-specifies the number of fully-trusted people needed to validate a new key.
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>completes-needed</option> <replaceable class="parameter">n</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-A public key on your keyring is validated using those signatures on
-the key that were made by other valid keys on your keyring.
-The option specifies the number of signatures needed if you fully
-trust the owners of the keys that made the signatures.
-Your trust in a key's owner is set with the command 
-<link linkend="edit-key"><option>edit-key</option></link>.
-</para>
-</refsect1>
-</refentry>
-
-<refentry id="marginals-needed">
-<refnamediv>
-<refname>
-marginals-needed
-</refname>
-<refpurpose>
-specifies the number of marginally-trusted people needed to validate
-a new key.
-</refpurpose>
-</refnamediv>
-<refsynopsisdiv>
-<synopsis>
-<option>marginals-needed</option> <replaceable class="parameter">n</replaceable>
-</synopsis>
-</refsynopsisdiv>
-
-<refsect1>
-<title>
-Description
-</title>
-
-<para>
-A public key on your keyring is validated using those signatures on
-the key that were made by other valid keys on your keyring.
-The option specifies the number of signatures needed if you marginally
-trust the owners of the keys that made the signatures.
-Your trust in a key's owner is set with the command 
-<link linkend="edit-key"><option>edit-key</option></link>.
-</para>
-</refsect1>
-</refentry>
-</reference>
-
diff --git a/doc/gph/manual.sgml b/doc/gph/manual.sgml
deleted file mode 100644
index f573bfd4f..000000000
--- a/doc/gph/manual.sgml
+++ /dev/null
@@ -1,71 +0,0 @@
-<!--
-  ToDo
-  - acknowledge Joergen Grahn for his xfig version of Figure 3.1
-  - 'inlineequation' marks places where formatting is ok now but not
-    semantically correct.
-  - need some story for formatting math
-       From Tom Goulet (tomg@iaw.on.ca):
-       > and the <SUP> tag doesn't seem to do much under Lynx, consider just
-       > using a ^ to show powers.
- -->
-
-<!DOCTYPE BOOK PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
-<!--ArborText, Inc., 1988-1995, v.4001-->
-<!NOTATION drw SYSTEM "DRW">
-<!ENTITY gpg "<application>gpg</application>">
-<!ENTITY gnupg "GnuPG">
-<!ENTITY Gnupg "GnuPG">
-<!ENTITY eg "e.g.">
-<!ENTITY ie "i.e.">
-<!ENTITY chapter1 SYSTEM "c1.sgml">
-<!ENTITY chapter2 SYSTEM "c2.sgml">
-<!ENTITY chapter3 SYSTEM "c3.sgml">
-<!ENTITY chapter4 SYSTEM "c4.sgml">
-<!ENTITY chapter5 SYSTEM "c5.sgml">
-<!ENTITY chapter6 SYSTEM "c6.sgml">
-<!ENTITY chapter7 SYSTEM "c7.sgml">
-]>
-<book>
-<bookinfo>
-<title>The GNU Privacy Handbook</title>
-<date>
-August 25, 1999
-</date>
-<copyright>
-<year>1999</year>
-<holder>Free Software Foundation</holder>
-</copyright>
-<abstract>
-<para>
-Please direct questions, bug reports, or suggesstions concerning
-this manual to the maintainer, Mike Ashley (<email>jashley@acm.org</email>).
-Contributors to this manual also include Matthew Copeland and
-Joergen Grahn.
-</para>
-
-<para>
-This manual may be redistributed under the terms of the
-<ulink url="http://www.gnu.org/copyleft/gpl.html">GNU General Public
-License</ulink>.
-</para>
-<para> <!-- I have added this note (wk 06.09.99) -->
-PLEASE NOTE, THAT THIS IS A DRAFT VERSION OF THE MANUAL AND NOT A COMPLETE
-AND CORRECT MANUAL.  CONSIDER IT AS WORK IN PROGRESS.  The latest draft of
-the manual should be available online;
-<ulink url="http://www.gnupg.org/docs.html">www.gnupg.org</ulink> has a link
-to it.
-</para>
-</abstract>
-</bookinfo>
-
-<toc></toc>
-
-&chapter1
-&chapter2
-&chapter3
-&chapter4
-&chapter5
-&chapter6
-&chapter7
-</book>
-
diff --git a/doc/gph/signatures.fig b/doc/gph/signatures.fig
deleted file mode 100644
index 57fdfe6f6..000000000
--- a/doc/gph/signatures.fig
+++ /dev/null
@@ -1,44 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
--2
-1200 2
-6 600 300 9450 2625
-6 1500 300 9450 2625
-2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
-	1 1 3.00 90.00 180.00
-	 1575 1050 2475 1950
-2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
-	1 1 3.00 90.00 180.00
-	 3675 1950 4575 1050
-2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
-	1 1 3.00 90.00 180.00
-	 5775 1050 6675 1050
-2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
-	1 1 3.00 90.00 180.00
-	 7875 1050 8475 1050
-2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
-	1 1 3.00 90.00 180.00
-	 3600 525 4500 1050
-2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
-	1 1 3.00 90.00 180.00
-	 3675 1950 5100 2550
-2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
-	1 1 3.00 90.00 180.00
-	 5175 1200 5625 2325
-4 0 0 100 0 14 18 0.0000 4 180 825 6825 1125 Elena\001
-4 0 0 100 0 14 18 0.0000 4 180 825 8625 1125 Geoff\001
-4 0 0 100 0 14 18 0.0000 4 180 825 4725 1125 Chloe\001
-4 0 0 100 0 14 18 0.0000 4 180 825 2625 525 Blake\001
-4 0 0 100 0 14 18 0.0000 4 180 990 2550 2025 Dharma\001
-4 0 0 100 0 14 18 0.0000 4 180 1155 5175 2625 Francis\001
--6
-2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
-	1 1 3.00 90.00 180.00
-	 1575 1050 2475 450
-4 0 0 100 0 14 18 0.0000 4 180 825 600 1125 Alice\001
--6
diff --git a/doc/gph/signatures.jpg.asc b/doc/gph/signatures.jpg.asc
deleted file mode 100644
index 99f04e394..000000000
--- a/doc/gph/signatures.jpg.asc
+++ /dev/null
@@ -1,232 +0,0 @@
------BEGIN PGP ARMORED FILE-----
-Version: GnuPG v0.9.11 (GNU/Linux)
-Comment: For info see http://www.gnupg.org
-Comment: Use "gpg --dearmor" for unpacking
-
-/9j/4AAQSkZJRgABAQEAUABQAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkS
-Ew8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJ
-CQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
-MjIyMjIyMjIyMjIyMjL/wAARCACxAogDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEA
-AAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIh
-MUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6
-Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ
-mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx
-8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
-AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV
-YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp
-anN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPE
-xcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3
-+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiub8Z+MrbwRpaan
-f6bqV1Zl9kktlGjiEnG3fudSAScA8jPBwSM5+i/Emx1bxBa6LcaH4g0i7vEka1/t
-Sx8lZig3MqnceQvPpx1yQCAdpRXH6V4y1G7+Id74U1HQPsHk2kl7b3X2xZftEIlE
-atsC/Lu5OCcjGMV0Gp67o+ieV/a2q2Nh52fL+13CRb8YzjcRnGR09RQBoUVyfi7x
-NfWfgO78Q+EhpuqmBDN5jT7ovKQnzGUqcOQFPG4dDySNpuaF4x0fW7XTF/tCxh1O
-+tIrn+zvtaNMm+ISbdvDHCnOcDjmgDoKKy9S8S6Do1wtvqmt6bYzsgdY7q6SJiuS
-MgMQcZBGfY1qUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
-FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
-FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
-FFABRRRQAVz/AIk8ceGvCPljXNXgtJJMFYcNJIQc4bYgLbflI3YxkYzmjxZ400Lw
-Vpy3mtXflebuEEKKXkmZRkhVH4DJwoJGSMivnTxl4Z8X/EB5/Htr4TktLS6SDZbw
-ytNPOu3YJQnUj5V6KvylSAw3PQB29/8AHy+1zVLPSfAnh2S5vLhwoOoDlj82VCI2
-AAMNvL4ADZAAzXsmh2+o2mh2UGr3v23UliX7TOAoDyHltoVVG0HIHAOAM85Ncn8M
-/hnY+ANLLuY7nWrhALq7A4A6+XHnkID36sRk9AF7ygDzf41zXlx4EuNDsNF1XUbr
-Utux7G1MyReXLG58wjlcjOODnBrj/B2j6jL8XNI1a1s/GUlnFaTR3lx4qtlLxLtb
-b5Up9WYDaoDD5uSrNj3iigDxf/hMLz/haf8AwlH/AAg/jL7D/Yn9n+X/AGSfM8zz
-/MzjdjbjvnOe1SfFZtc1PWdHNrpF3Popsmljnh8ORalOJmYZR45sGIbQh6Kc5BBx
-8vslFAHgfhNtS0n4UeNtKufDfiD7Xe3E4tUXRmiM32iLYpEacIF2EsB8qgqASSBR
-4A0G58I+ILCDxD4Ru9bfUreyuLbVhYPLJpr4VRDJv4iEeOqkEBVyDwE98ooA+ZNZ
-8JeKbbVNYg16DWdQnvLiVhfWvhi21EzxH5FcSl90JwvEYI2DGMZr2/4aWs1j8PNI
-tJ21IvCkiD+0rcwThRIwUNGWbaAuAoyflA6dB1lFAGXrniPSPDVvbXGs30dnBcXC
-20ckgO3zGBIBIGFGFJ3HAGOSK0IJ4bq3iuLeWOaCVA8ckbBldSMggjggjnNU9Z0P
-S/EOnPYavYQXtq2TsmTO0kEblPVWwThhgjPBryufwV43+G1vLd+BdZk1bSYULtou
-oqZGAA/5Z7cZO5nchPLJwB854oA9korh/B3xS0Lxdef2UVn0zXU3LLpt4hVwyAbw
-p6Ng7hg4b5WJUAV3FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
-FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
-FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVz/izx
-poXgrTlvNau/K83cIIUUvJMyjJCqPwGThQSMkZFAHQV5P4i+LFxq2oyeGvhxZ/2z
-q7xSFr1SBDalTgsC4Cv3wxITJTBfO2stNN8afGZEm1dpPDfg6ZIporOMrJLd4bOS
-2AcHkgsNv+rIRvvV6xoHhzSPC2lrpui2MdpaBy+xSWLMepZmJLHoMkngAdAKAOL8
-J/Ce307WG8S+Kbz+3fEskq3H2iQERwOFxhFzhsHoSBgKm1UxXpFFFABRRRQAUUUU
-AFFFFABRRRQAUUUUAFFFFAHJ+M/hz4c8dIjavbSLdxJsivLd9kqLuBxnBDDrwwON
-zYwTmuHGpeP/AIWXDrrC3fi/wuqKft0Y/wBItuS0jMCWYgAN94lcbPnTla9kooAw
-/C/i7RfGOlpf6PexzAorSwFgJYCcjbImcqcq3scZBI5rcrzPxR8G9IvnfVfC0knh
-3Xo0YwTWMhhiLbQuGVfuAqCMpj7xJDdDn2fxQ1rwdqkGi/EzTo7QSI/kazaAvFOE
-wMlFBOSQScYI3plFBzQB65RXPt458LLqOmWA16xkuNT3fYxFKHWXBK/eXKjLAqMk
-ZYEDJGK6CgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
-KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
-KKKKACiiigAqnqt+2maXcXyWN3fGBN/2e0VWlcd9oYgE45xnJxgZOAblcf8AE7Vd
-Y0vwNe/2BYX15qd1/osP2KF5Hh3A7pPkIZcKGww6MVoAj8D/ABP0Hx9cXlvpcd3B
-PaortHdhFZ1JIyoV2JAIAJ7bl9aku/GWo2PxH07wxc6BssdS837JqX2xT5nlw+Y/
-7oLkYJ28kZ6ivLLHTPEfw88S+FdYtLfWdetH0z7Pc2dtoP2d7W1Y71Rtu5TLvZnI
-yGymGbDZro/FfiW8k+Jnh3UYfB3iua10CW+iuJItMLCbzEEatEQcMuRnJxwRQB6Z
-4h1y28PaNPf3E1ojqjCCO6ukt1nl2krGHc4BbHXtye1WNJvW1LRrG/eKOJ7m3jma
-OOZZlUsoOA68OBn7w4PUVwfxB1q31fwCsR8H65qU2p2k5tov7JLvYzhCqtKrcxsC
-5wwBzhiCRgk8J6pf618PG8MW+k65omr2uiLaxXOoWclvGZRF5e5JBnGGwezYOQDg
-4AOsn8aeFbW4lt7jxLo0M8TlJI5L+JWRgcEEFsgg8Yq5qeu6Ponlf2tqtjYedny/
-tdwkW/GM43EZxkdPUV4fYabo48IW3hnUPhLrjazFshluILJAk8ySA5N4eVjcj5mH
-CqxCnABpnjbw34ph8eavqF/FqWo2d26iwmt/DttqoWJRny9jtmEKX25wPMIZjzQB
-7/BPDdW8VxbyxzQSoHjkjYMrqRkEEcEEc5qSvO/gxpk2j+CprKX+2Qkd7IYk1axN
-o6KVQ4RN7/JuLHIIyS3Hc7nxC8LXHjPwXfaJa332Oaba6sygpIVIYI/BIUkDleRg
-HkZUgHH+IvixcatqMnhr4cWf9s6u8Uha9UgQ2pU4LAuAr98MSEyUwXztrQ8J/Ce3
-07WG8S+Kbz+3fEskq3H2iQERwOFxhFzhsHoSBgKm1UxWX8G/EVjptvJ4C1DS49E8
-Q2DsZID/AMvhxkyAknc+3BIyQVAK/LwvrlABRRRQAUUUUAFFFFABRRRQAUUUUAFF
-FFABRRRQAUUUUAFFFFABVe+sLPU7OSzv7SC7tZMb4Z4xIjYIIyp4OCAfwqxRQB8c
-eMPh54p0u8uNRfwdPpmmvvkSG1lN2lvGgGd8gZiOOSzYB5wABger/B74w/2r9n8M
-+Jrn/iYcR2V9I3/Hz6RyH/np6N/F0Pzff9wrj/H9h4G/sd9R8aWlj9n+SAXMsZ87
-725URk/edcnC9t2eM0AdhRXl/gXx1qnjrxGBotlPZeEdNiCvc3i+ZPdS7MCIuXOM
-bg5I3N8g3MPMxXqFAHn9/wDFjTv9JXw9oeueJPJ3x/aNMsmktvOGf3Zl/wC+TuUM
-MMCM1n3/AMVrhYPCev2OnQJ4V1i7NpdXN9MI5oH3sgJAJVVGxnzlsgEHZwTn+Dtc
-134caDB4V1rwVrl59i3mC90eIXcdwrSyMScbdnUYBO4jkheMx+Pr6bVPD/hC2XwR
-rPkQ6nDfzabDpxmWKzjLosbhRsDshB8r+HkNjjIB6xpurabrNu1xpeoWl9ArlGkt
-ZllUNgHBKkjOCDj3Fc34N8Zaj4j1jW9J1bQP7GvtJ8jzIvti3G7zVZhyqgDgA8E9
-e2K5PwncL4a+IfjloPCWs2mmzpG1kttpTLFKbaNw6ptG3LnJToGz1BIBr+G/FlzZ
-fEPxPrF14N8XRWetPZLC50hyYRFGUdpACTjJz8u44HTPFAHqmp67o+ieV/a2q2Nh
-52fL+13CRb8YzjcRnGR09RVj7fZ/2d/aP2uD7D5Xn/afMHl+Xjdv3dNuOc9MV5P4
-j07+yfihqes+IPBl94p0y/tIo9Pe0tvtv2PYAHjMTfKu5stu+uM7nxzk/gnxoPhl
-ZpaW93aWJ1iTUG0JQt08FmQrorJKR5hRkY+TzvMgLAMCAAe56Zruj635v9k6rY3/
-AJOPM+yXCS7M5xnaTjOD19DWhXz/APDvRL23+Jmm6lJbeI7X91LDIH8Lx6bbOmxy
-BI0Um372CMqckKOwx9AUAFFZ+t6V/bejz6d9vvrDztv+k2E3lTJhg3ytg4zjB9ia
-4/8A4VZ/1Pvjn/wcf/YUAegUV5//AMKs/wCp98c/+Dj/AOwo/wCFWf8AU++Of/Bx
-/wDYUAegUV5//wAKs/6n3xz/AODj/wCwo/4VZ/1Pvjn/AMHH/wBhQBqJ8TfBbazd
-6S/iC0t7y0d0mW63QKrI21gHcBSc9gTnkjgV1EE8N1bxXFvLHNBKgeOSNgyupGQQ
-RwQRzmvli6+CfjTVvFWofZ7WQWD3twI9R1O5XdIquwDuBlyWxnOzncD0Oa7fwl8A
-dS0a4ivbvxhd2M7IyXEejFomK54AmJBxkISCnbHoaAPdK5vxn4ytvBGlpqd/pupX
-VmX2SS2UaOIScbd+51IBJwDyM8HBIzsaVYNpml29i99d3xgTZ9ou2VpXHbcVABOO
-M4ycZOTkng/jXNeXHgS40Ow0XVdRutS27HsbUzJF5csbnzCOVyM44OcGgC5ofxV0
-3XPEFhow0LxBYT3zzJBJf2ixRs0IYyDO8nKlSpABweDirmleMtRu/iHe+FNR0D7B
-5NpJe2919sWX7RCJRGrbAvy7uTgnIxjFcH8OJtS0fxPa6XaeH/ED2d9e3t1eapr2
-lNFPErxoVQShyCWaEb2IG47eAak/4TC8/wCFp/8ACUf8IP4y+w/2J/Z/l/2SfM8z
-z/MzjdjbjvnOe1AHrmpatpujW63GqahaWMDOEWS6mWJS2CcAsQM4BOPY1H/buj/2
-P/a/9q2P9mf8/v2hPJ+9t+/nb97jr14rxv4l6J4kv/GMOuompX2gy2SLaRRaFDft
-au2CyG2mYFSdm4yFQRkIelUPD+lzaX8PvHFpNpHie9Opoot7G48PG3UXDiTDxRI7
-qApCMSAoXYgGTtFAHt+m+JdB1m4a30vW9Nvp1Qu0drdJKwXIGSFJOMkDPuKjvvFn
-hvTLySzv/EGlWl1HjfDPexxuuQCMqTkZBB/GvH9Esv7P8R/DK6tPBGq2cltaSRap
-PHpXlkyOn2cNKw9GVnJbkI4bqSKyPHlh4n1PxH4k+1aDfGR5ZIrQ2XhSC7SaEIFi
-Y3RPmKxGMkZKdsEbQAfR9Fc38P3mb4faAlxZXdlPBZR28kF3EY5FaMeWSVPIBK5H
-qCDXSUAFFcfrfgD+29Yn1H/hLfFdh523/RrDUvKhTChflXacZxk+5NZ//CrP+p98
-c/8Ag4/+woA9Ark0+JvgttZu9JfxBaW95aO6TLdboFVkbawDuApOewJzyRwKy/8A
-hVn/AFPvjn/wcf8A2FeKXXwT8aat4q1D7PayCwe9uBHqOp3K7pFV2AdwMuS2M52c
-7gehzQB9TwTw3VvFcW8sc0EqB45I2DK6kZBBHBBHOakrwvwl8AdS0a4ivbvxhd2M
-7IyXEejFomK54AmJBxkISCnbHoa9o0qwbTNLt7F767vjAmz7RdsrSuO24qACccZx
-k4ycnJIBl+K/GOl+D7O3lv8Az57i6lENrZWieZPcOSBhEyM4yM89wOpAOHpHxPh1
-PxZZaDceGfEGlvfoxtZtRtRCJGRWeQYJ6BQuCM5LcgYBJ48sNXi8T+FfFOm6ZJqc
-Givdfa7WBwJzHLGFLRqeHICn5Qck7QOpI5PTtV+IfiTxp9msr7xHpekT/aZXfUfD
-9vbizXB8lVZt3m4YqCOGIBPqVAPVJvEug22qDS59b02LUC6oLR7pFlLNjaNhOcnI
-wMc5FWNS1bTdGt1uNU1C0sYGcIsl1MsSlsE4BYgZwCcexr5gn8H+IVsJdM17TPEB
-vHcvcy2nha3vmZmffkXgkDuTkZOeMlegr0PXNKvLfWPCGv614d1XxTo0OiJaSWrQ
-GW5guiu4zS2zEgswwrZJwRycqmQD1yHVtNudLOqQahaS6eEZzdpMrRBVzuO8HGBg
-5OeMGvN/DnxfvPFOs2drpvhu0NpdXBRHk123W4WIMQ0ht/v5CgttGeBwSOar+DdK
-Wx0vxjrGo+E7u28N6hcRzWXh17Vp5SUyGb7NghS7bCB0XaOQiq1U/hAlnplno2lX
-/gHVbTXY/P36xPo4jRcmRhmY/MMoQnTvjpQB0njP4pxeGfEqaDYafaaheLb/AGi4
-NxqsNkkIJAVd0nBcj5tvBwVIyCcdh4c1O71nw/Z6je2MdjPcIX8iO6S5ULk7SJE+
-Vgy4bI9a8j1yPS7b4v3upS/DrVdU0kae1tJ5Gg+Yk12Zt7TAMAG4JXf1PbIIJ9k0
-l4ZNGsXt7KSxga3jMdpJEImgXaMIUHClRxjtjFAFyiiigAooooAKKKKACiiigAoo
-ooAKKKKACiiigAooooA4f4ifDu38a2cV3aTfYPENjh7G/QlSpB3BGI5255BHKnkd
-w2f8O/iJcaveS+FPFcP2DxZY5SSNwFF2AM71xxuxyQOCPmX5chfSK4f4ifDu38a2
-cV3aTfYPENjh7G/QlSpB3BGI5255BHKnkdwwB3FFeb/Dv4iXGr3kvhTxXD9g8WWO
-UkjcBRdgDO9ccbsckDgj5l+XIX0igAooooAKKKKACiiigAooooAKKKKACiiigAoo
-ooAKKKKACiio554bW3luLiWOGCJC8kkjBVRQMkkngADnNAEd/N9n065n+0wWvlxO
-/n3AzHFgE7nGV+UdTyOB1HWviTUrvWvF3ipYrjUZNY1C5uBbQSs5CyFnO0JvC7EL
-NkDCgZ6Cvc76+1T4465JpWlST2HgWxlAu7wLte9cYIVQfwIU/d4dhnYg9csPDei6
-Xb6dBZ6XaRJpqMlmfKBaAMMNtY8gt/Ec5bvmgCn4L8J2fgrwva6LZv5vlZeacoEa
-aRjlmIH4AZyQoUZOM10FFFABRRRQAVy/j/xZceCfC765BpX9pRwyok6faBD5aMcB
-8kHPzFRgD+LPQGuoqnq2mw6zo19pdw0iwXtvJbyNGQGCupUkZBGcH0NAElhfW+p6
-dbX9nJ5lrdRJNC+0jcjAFTg8jII61Yryv4H6lNDomreD7tYzd+G72S3aSEHY6s7n
-IJOSd6ydhxt75r1SgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
-gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
-gAooooAKKKKACiiigAooooAKKKKAOH+Inw7t/GtnFd2k32DxDY4exv0JUqQdwRiO
-dueQRyp5HcNn/Dv4iXGr3kvhTxXD9g8WWOUkjcBRdgDO9ccbsckDgj5l+XIX0iuH
-+Inw7t/GtnFd2k32DxDY4exv0JUqQdwRiOdueQRyp5HcMAdxRXm/w7+Ilxq95L4U
-8Vw/YPFljlJI3AUXYAzvXHG7HJA4I+ZflyF9IoAKKKKACiiigAooooAKKKKACiii
-gAooooAKKKjnnhtbeW4uJY4YIkLySSMFVFAySSeAAOc0AE88Nrby3FxLHDBEheSS
-RgqooGSSTwABzmvE76+1T4465JpWlST2HgWxlAu7wLte9cYIVQfwIU/d4dhnYgL6
-+1T4465JpWlST2HgWxlAu7wLte9cYIVQfwIU/d4dhnYg9k0rSrHQ9Lt9M0y2jtrO
-3TZFEnRR/MknJJPJJJOSaADStKsdD0u30zTLaO2s7dNkUSdFH8ySckk8kkk5Jq5R
-RQAUUUUAFFFFABRRRQB4/wCLv+KI+NuieLW/caRrMX9n6jMOQJMYUuz/ACxrxCcg
-g4ic4659gri/ir4XXxZ8PtRtFjke7tkN5aCNGdjLGCQoUEbiylk7/ezgkCrHw28U
-N4v8B6bqs8kbXmww3e11J81DtJYAAKWAD7cDAcdsGgDrKKKKACiiigAooooAKKKK
-ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
-ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4f4i
-fDu38a2cV3aTfYPENjh7G/QlSpB3BGI5255BHKnkdw2f8O/iJcaveS+FPFcP2DxZ
-Y5SSNwFF2AM71xxuxyQOCPmX5chfSK8H/aH0XVNR+wXtl4b8+1tIi0+qw/PIo+Ym
-NlU5EahSxZgQC3BXncAe4WN/Z6nZx3lhdwXdrJnZNBIJEbBIOGHBwQR+FWK+aPgD
-46TR9Yk8K3xxa6nL5lrIWVVjn24IOcE7wqqOT8yqAPmJH0vQAUUVX+32f9o/2d9r
-g+3eV5/2bzB5nl5279vXbnjPTNAFiiiigAooooAKKKKACiio554bW3luLiWOGCJC
-8kkjBVRQMkkngADnNABPPDa28txcSxwwRIXkkkYKqKBkkk8AAc5rxO+vtU+OOuSa
-VpUk9h4FsZQLu8C7XvXGCFUH8CFP3eHYZ2IC+vtU+OOuSaVpUk9h4FsZQLu8C7Xv
-XGCFUH8CFP3eHYZ2IPZNK0qx0PS7fTNMto7azt02RRJ0UfzJJySTySSTkmgA0rSr
-HQ9Lt9M0y2jtrO3TZFEnRR/MknJJPJJJOSauUUUAFFFFABRRRQAUUUUAFFFFABXj
-/gr/AIoX4w6/4Qn+Sx1r/iZaWqfLGv3iyLGuQvAZcnbkQDjlQPYK8n+NtjcaXZ6P
-460mPbqeh3aCSQMFDQOcbXxhmXeVXaD0lfjkkAHrFFV7C+t9T062v7OTzLW6iSaF
-9pG5GAKnB5GQR1qxQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
-QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
-QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5X4z+CWkaw6al4YaPw/rEL+aj26lYn
-ZVGz5VI8shlU7kHGWJDEjHcaXbavf+DlsdekktdUe3e2ubizmG4sMp50bBQFLACQ
-cDbuAxxW5Ve/tft2nXNn9ont/PieLzrd9kke4EbkbswzkHsaAPC/D+ja1ffB/wD4
-TZPHHiePVre3uLxY5L4y25MEj/KY26grHjkkZPII4NzXEv7/AMY/DXxPoVnpUHib
-WdPmlne5EiwSEWyH5gpLcK7gHr90EkAY6SD4JaLDYRaY/iHxPPpKOGbTZNQAt3Af
-ftKKg4Lc8YOeQQea3L/4d2F/4o0rXf7V1W2bSdgsbK1ljitoEUAFFQJnawGG55HG
-cAAAGfonjq/ufA3iTUtaOlWGpaJd3VjJNuk+yNLGBtbH39pZlXAyx7ckKOb8FfFz
-VNd8b6doV3ceH9QgvkmHmaXFdRNAyIXBbz1AYEKRgfXIxg9JZfCPR7XR9a0mbWNc
-vbHWPnuoru5Rv324MJgQgIkyAckkNgbg2BgtvhPZwa5purzeKvFd7dadL5tv9r1A
-SAZxuXlM7WAwwBGRxQBl6r4t+I1t4/uPC2naV4fvHlt/tlpLvkQQW5n2B5ssNxCg
-5VBnLAjOCpk1nxJ8R9M1zw1oaR+FGv8AV4rjc5W4MSyRbnODnIUxmPHBO7d0GK0L
-/wCE9nfeIbnXP+Eq8V299PvXfb6gE8uNnL+Uh2ZEYJ4XOBWpqfgK21bxLomvXWta
-z9s0hFWERzoiSEHLs6hMZcfK+3aCABgCgDg/Cvxe1vUrG+l1xNDslbRJdUsrkeas
-cZSZoAsq5YtucDAQ5xgDJbAk8FfFzVNd8b6doV3ceH9QgvkmHmaXFdRNAyIXBbz1
-AYEKRgfXIxg6i/Arw35EdvLquuS28Vo9msRuI0Xy2dpADsjBbEjeYNxI3BcggYrQ
-tvhPZwa5purzeKvFd7dadL5tv9r1ASAZxuXlM7WAwwBGRxQB6BXz/wDEfxV/wlHx
-FHgXWtT/AOEc8O2sqfapHOXvGO1lyVyqqdwI3EKv3m5AQfQFZ+s6HpfiHTnsNXsI
-L21bJ2TJnaSCNynqrYJwwwRng0AGh2Ol6dodla6JHBHpiRKbYQNuQoeQwbndnOd2
-TnOcnNaFeT3Pwj1Tw9uufh74rvtKk815fsF5J5toxbC9MHGFzyyuTheQRmo4Pit4
-j8L3EUHxH8KyadBO4Eeo2A8yBNxwFYBmGQFkY4YtgDCd6APXKKx/D3irQvFdmbrQ
-9TgvY1++EJDx5JA3IcMudpxkDOMjitigAooooAKKKKACiiigAooooAKp6tpsOs6N
-faXcNIsF7byW8jRkBgrqVJGQRnB9DVyigDyv4H6lNDomreD7tYzd+G72S3aSEHY6
-s7nIJOSd6ydhxt75r1SvF/G99b/D3426N4rnk8jTNYtHtdQMamR2KADcVPRRm3Py
-c/u24Ofm9Y0TW9O8R6PBq2k3H2ixn3eXLsZN21ip4YAjkEcigDQooooAKKKKACii
-igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
-igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
-igAooooAKKKKACiiigAooooAKKKKACiiigAooooA871v4N+HL6//ALU0WS78Oaoi
-OI7jSpPKUMU2glBwAB1CFN25snnNYf8AaHxa8C/ubrToPGGkQdLmAlbtk+4ikD5i
-wwrMdkn3jlz1HsFFAHD+GPi34O8VSw21rqf2W+m4W0vV8pyd20KDyjMSRhVYk56c
-HHcVzfivwH4c8Z25TWdOjknCbY7uP5J4+GxhxyQCxO05XPJBrh5vBfj/AMDuJ/BP
-iCTWtPRFQaPrD7iqqoVQjEgADczYUx8Ko+bpQB65RXlem/Gi00+4bS/HmlXfhzVI
-kJZmieSCbBC7k2gtgsHxgMuF++a9Msb+z1OzjvLC7gu7WTOyaCQSI2CQcMODggj8
-KALFFFFABRRRQAUUUUAfP/7QPgD/AJnTTo/7sephpf8AdSJ1U/gpwf7px941ufs3
-zwt4F1O3WWMzpqbO8YYblVoowpI6gEqwB77T6V7BPBDdW8tvcRRzQSoUkjkUMrqR
-ggg8EEcYrzf4deCz4E8a+KbCJJDp9+kF1YusMmxIw0oMTOcjeu5RgsSwIb1AAPTK
-KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
-KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
-KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAr
-31hZ6nZyWd/aQXdrJjfDPGJEbBBGVPBwQD+FeZ3nwaXSXnvvAniDUvD94zpILfz2
-ktZCinarg/MQW5JYuACw2kHFeqUUAeP/APCxPHPgj/kffDH2nTE/d/2rpWG+78u9
-1ztG9imM+V1OAfuiSP8AaC8LnxZNp0qSLo4TMWrLvYM20HDRbA6jO5cjPIHGDkeu
-V88az+zjrEu+6s/FMF/fTSl5jfQPFuzksxcM5LZx1HOSc+oB9BwTw3VvFcW8sc0E
-qB45I2DK6kZBBHBBHOakrw/wj4S+KPw22/ZvsPiHTGzG2lR37J5edzB0aVVVPmPO
-M7t3I6MvsF9Zf25oclrM99p7XMQyYJ/KngY4PDoSAwPoSpxjkHkA0KK+YPAq+JPG
-9wNLi8WeK7O/fTxeLdT6jIIDtuvLkKJ1kXyyMfMv7xGBODx6n408W+OtA8Z2OlaP
-pWjalb6qkw0+Eu6T7o4gzGRmYIAGbOB1UYyCc0AemUVwer+I/EvhbwHe6l4kvvDF
-pqwuFS1dRcNaspK8MoBkZ8eYcKDwAegNY/w2+J2oeLfFV3ot7Jo12iWX2uO60tLi
-NVIcIUZZgCT8wORgDHfPAB6pRXibfEn4g2Wia1r15Z+GJdP0PUzp97DD9oSWVldE
-byySQAd4wT7/AC9j2ninxT4gj8W2XhTwpY2MupyWhv7i51JmEEUAYoOEO4sXAHHT
-I4OSVAO4org9Kv8A4lXNv4gtb2x8Pw6haPAmn3AWcWs5YBpc5O8hVIAIAG7I5wcS
-fCC4iu/hbo08NlBZRt5+IIC5RMTyDguzNz15J6+nFAHcUV4f4q+LnivRvEOo2EVr
-odj5V2YLK01OG5Sa5j37BMJPlhEbHccllAAPJxk+4UAFFFFABRRRQAUUUUAFFFFA
-BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
-BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
-BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVn63pX9t6PPp32++sPO2/6TYTe
-VMmGDfK2DjOMH2JrQooA5PwZ4CtvA6PBp+tazc2bJtWzvZ0kijO4tuQBAVOS2cHB
-zyCQCKfiH4ZWfiPxGNcm8R+I7S6j/wCPdLO+EaW2UCN5QKEpuA+bB5ya7iigDl9V
-8D2et+F7LRNR1TVZmsZY57fUftAW7SRCdr7woBYAkZKk9/vfNWXpfwuttK8QLrie
-KfE9xqCW72yy3d6k3yMDwd0fIVjvAORuAJBrvKKAPN/+FM6O2h6hpEniDxHJa6hd
-peXO+8QmSRd2SfkwdxYFsgklEOflrY1r4c6XrkWkyS3+q22p6ZEIYdWtbnZeOm0q
-Q8mDuzkk8dScY3MD2FFAHDp8M7ePTprdfFPisXU0sbyah/aZ+0siBwsW7bjywZHb
-GOp68CpPCXw4tvBlxE2neIfEEtpGjILC6uke3wxycJsG07ucrg5z2JB7SigDzf8A
-4UtoXkfYf7b8R/2N5vmf2R/aJ+ybd+/Zt2525993fOea9IoooAKKKKACiiigAooo
-oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
-oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
-oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
-oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
-oAKKKKACiiigAooooAKKKKACiiigAooooA//2Q==
-=ao7I
------END PGP ARMORED FILE-----
diff --git a/doc/samplekeys.asc b/doc/samplekeys.asc
deleted file mode 100644
index 04599e895..000000000
--- a/doc/samplekeys.asc
+++ /dev/null
@@ -1,624 +0,0 @@
-
-  pub  1024D/621CC013 1998-07-07 Werner Koch <wk@gnupg.org>
-  uid                            Werner Koch <werner.koch@guug.de>
-  sub  1536g/ADF6A6E1 1999-02-20  [expires: 2002-11-01]
-
-  pub  1024D/5B0358A2 1999-03-15 Werner Koch <wk@gnupg.org>
-
-  pub  4096R/99242560 2002-01-28 David M. Shaw <dshaw@jabberwocky.com>
-  sub  2048g/1643B926 2002-01-28  [expires: 2012-01-26]
-
-  pub  1024D/B2D7795E 2001-01-04 
-  uid                            Philip R. Zimmermann <prz@mit.edu>
-  uid                            Philip R. Zimmermann <prz@acm.org>
-  uid                            [image of size 3457]
-  sub  3072g/A8E92834 2001-01-04 
-
-  pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
-  
-
------BEGIN PGP PUBLIC KEY BLOCK-----
-Version: GnuPG v1.0.6e-cvs (GNU/Linux)
-
-mQGiBDWiIPMRBAC2D3tFzbD48fop00PiM8+du2SZ6HOgYVopP+Gtm2WBDUjkFwDC
-kw0DL9pS3iNIunHgfeuzDbm4R3lXTXjlmBxUjNVBkX4ZmRESEoaN26fsFWb1RvBg
-VcKcN+DyY4GFP9LQ8JyWifAc1+o9HnE0k40D52lBLXSf7v4JhvY9NtfE8wCg4oXT
-aCiRFPSClIko3RqJkrnpv1cEAKx32rnEog5mPPs8mW1Sy5yulCTKrbCL9S7wINtM
-cF6FJNm2PB97Vy+FGfGHKEl2KM8AC6t3CKOVGSdKvTn+9ZiPFiytohUmFaZaU19F
-jApQHZBrdx4FW+8bToRrdZhCnkUIzWdi7XlEK0Qw/TE0Pl8XLxDdCKQI+JASXvW0
-eh8wA/4nnAphsEpR1GWa4Kls7+/KO/V8Q3XLi3ZeItny+5MBDn/Y7A3u4RrNu8q3
-SRJgBvUBfUzhfSyRZhNQqpIFvhKSsbGNNVo5tARSQdUe4j1GlLRUWcWKn4F2q5j4
-6pdogYvnFYy8xrvuAUqI1QD4D/4YXJyKMH+DOHnT4iAjD9RlY7QaV2VybmVyIEtv
-Y2ggPHdrQGdudXBnLm9yZz6IRgQQEQIABgUCOdeQqgAKCRBd4kmWWwNYouphAKDJ
-YHGt9SdQTwe0FODk/1aOJap13QCdF/Y83Ku5blk0l7p9H8cicg+JPySIVwQTEQIA
-FwUCOhpQtgULBwoDBAMVAwIDFgIBAheAAAoJEGx+4bhiHMATm7kAoMBBag8scWbt
-Xcs7lhrjQOIzd2onAJ4oIuIPWnArE+6EOQBk8vceoMb/lbQhV2VybmVyIEtvY2gg
-PHdlcm5lci5rb2NoQGd1dWcuZGU+iQFfAwUQNaInDgNvEbj/PqoLEAMH3AUfSLqa
-afqtZgoV6kmFfKETjBapE8kCe9+iJZSe0OnhohDKzqU5GKBVchajiThIr8Ufn1if
-MXvnvyqtNlb9FwDRsiomrOpqqw51NgQVrj1wKO8ucFbg55smUtNSz+eeZTQVYpbw
-7DAv6kK7x3t8tJKeCAGytRDBt6m7DRwmhy0U8DPlPWdAmJ5ApWwdoI3AvZ27Rd58
-6AXm6MHWMrWrenhTKwX2ERwFH2W0TdMev6K/iO1leYLU/hq31bksVaxi7CvRTfIl
-xopIqnS//AYRZ7Yn+AVBnSEHX7flGsJk+CJawS/zsIdobpe1D7ceGKsEImxiGY6K
-RUqgRqfo+FRVHWqVcTK2kC3fz1MGe/Jx4BfyFwc4Td2K4a8gsSBh6zeDDezlmYzt
-tRfeObYGtfxZyF7FQVRAi4pbZwvfv0wVdHxNvGlXGuxFgT/iMdkFiQB1AwUQNaN3
-FB0Z9MEMmFelAQE98wL/RzGj7jFhUCmUU7SchjKNCA/sPw7S5/M+wjAXeS9vtvkU
-02N+n4MCE3obQc4iCQvcaxa0J8flQdqWL6a00UgoOlO2v4X+U+lk/c4/POwtlLiF
-hOqYyzU78AKrxrEqACKViEYEEBECAAYFAjvjfbkACgkQH+0kqpJl+vsaiQCdF17S
-Tq6vDmL904W0mD0m3m66ZOkAnjXUF+7U4s14zHRn+oR/DTG+yKI8iEYEEBECAAYF
-AjnPUbEACgkQNfZhfFE679kjigCfcLUFU4HwC2iqbCUxcIHoCg2xFPcAn2x8nlUi
-2uXjwgT2OA5sifc3XQq2iEYEEBECAAYFAjlqZ8EACgkQRxYpGYKVe2ahiACdHELx
-vEtYuKiUAuP7N2p6PB+s6R8AniXxK1c1qIsyN8S3D4hv5ygXQApOiEYEEBECAAYF
-Ajiy8lYACgkQSBf5O8XogRIOMACgpDCmckpZHGgzyzgdGb/q+YrAtPEAnjDbzLSt
-tKJxIQDqVQwZf/qZOF9HiEYEEBECAAYFAjbtTgsACgkQXeJJllsDWKJ8mgCgsSwb
-LXqFX8J+YOS7oPUIFQjFe+kAn0YECl0L/c5eKDuwGtUJY5vcxDNwiD8DBRA3blnc
-ZKpl/bHMA6oRAulaAJ9dQ/nN1j/mr7DdbZiVjg70OC1cSwCgsn1NrNKqoCoCU3TP
-mcjvDFxoWS+IWwQTEQIAGwUCNs8JNwUJCCCxRAMLCgMDFQMCAxYCAQIXgAAKCRBs
-fuG4YhzAE2kgAJ92JKU+YcYHoRhX51+4s3fnPIyNEgCfaiWeoyb15xgdO6etGiD2
-MYCWy5m5AY0ENs8HCBAGAPc1hCpuXmaTDAUbIqS9CFHkihMnilIwAV+L2Dbq5eOP
-toemPKx5+6xtZfzzY9/VCVwZCxY9Y5PEN9r/twUA478L/FOXv5E4BpX+4R91klt/
-EZGcNfDl2Ar56FpGJ3iLg4+vxx9m1TV5k2nNOUZAVD1L+MoapWhaZFXLMChrhDUc
-bo7/1Fr1Rfv9j/LkkIJJhqf3G8HzE5AvCQVSywUayYZdbmqdiY2bklZJVFAXs1X9
-zSTGoFc8eOxz6i1ZeMq+GwADBgX/T7o5R+SOTlJ72ac/g121f1kFX1dbRkQq2pCI
-95qTehp1AxdSwG3ur2slFCfi8ZDNUqkFXJrsv5mh1yfqq7zS5T6lGT5lOXCDZbAO
-2wqNZY1VKeeCdcvD2VMeh8XxJfy8y1ZK/iE1p8qnokYpA3nFH+JIsdrXk5ceiN3n
-Kk+aDamUkV1sJzeEm5F7QHe60oBKbVGIUF4EhGq6daVyeCeK4KhWuPYyiEgyaq5/
-xJZbR3uRcdW6X5AiGJWJOOQoGvWziEwEGBECAAwFAjbPBwgFCQbzyQAACgkQbH7h
-uGIcwBN5FQCggakIOYzLX3lNq2WWgcAkSNm7kpoAnA69b3z2E5vxyD3bhggVUDX7
-j8hrmQGiBDbtSOkRBACURhKnGIFyXIeX61GAY9hJA5FgG4UalV55ohdz4whBgDzD
-GLE3XYlO8HCn4ggKilll6MOwY0yZeg6PEU9Y3SqTzpQSV6qj2M7MgcS8xOpi6bNC
-u0iyZUik0KklUXMdI8e/CVmBpQJT9CofbD1dsP6z4dC6z3jil0+5Wbfw6yIXzwCg
-y/7Fagq5mN0H760/JEiiXILS1n0D/3H26lTaxo1vGput9Td1FQN7Vn6YDP0/To5i
-psOODROV3zyUwF5QleY+8zTFJA3qD5KxRfA726WELOF1mB6Mw44UdkPniOoGdMH5
-oSx6qnNnlVZBBu3U+e1qfQwLQjHu0WX4Z2q00DKpWLThGv7Loh5NKi6OfTbMhfHo
-evCAzQnmA/wKc6J8GqthENThKXxZaei3Ep0t+PlBmbUzuAYCXZhI6/0KyD6emyQ7
-LYIaPv9qEfMkMLhxicG0v/AAwOCBRKS3bkqc6wAYaO0bjUHJvem3HkWPux82t83+
-6YPyRnVjm/mwt0uEyKSvt7Md2DVrO3lEcKRkRHiYuf0nonPhl5Rs5bQaV2VybmVy
-IEtvY2ggPHdrQGdudXBnLm9yZz6IWwQTEQIAGwUCNxrPkAUJDMl8gAMLCgMDFQMC
-AxYCAQIXgAAKCRBd4kmWWwNYol3CAJ47+zjeQIsMwiwcJvYfcsLn1yULlQCfUTKu
-paT6pw5culAis/pBrdBKZciIRgQQEQIABgUCNxrRPQAKCRBsfuG4YhzAE4X0AJ43
-A7wbYbR6LTfPSD+fdBkimNvO8QCdFoSpfY+4FsKVagg/qH3KtGUARtSJAHUDBRA3
-GtFjHRn0wQyYV6UBAdGuAv9AM0o9XkmBbOLLNse8Qp9MjD8TC/oSXYxp1W9AjyRs
-83iqQ+vaZlbA/O5z2ud4I9DV4vwA50Lz5nLFbPHa+yuT8VxTl2icw5u9rZy3iSok
-3rGXzGOzENMmEFIVFqIEmPGIRgQQEQIABgUCNxrRowAKCRBot6uJV1SNzS34AKCE
-rfsfa9Nh5deJ40nxpmSI8lK17gCfRYcU6i1B1Nbg2Zkkr5SqTnBtaWCIRgQQEQIA
-BgUCN08fXQAKCRD27t8gGEvE2S2+AJ4udDl47EAnP4K+RvsWcv8qjqpzlgCeOFZZ
-blzWjeie8oQfYl7bBBrxPqKIRgQQEQIABgUCN6cm/gAKCRCYNGXbIUOUIn7JAJ9L
-LXMt+0R8u4gdmxQeKz1TQyWoswCfYQh/tMjUzk4rKxBy4UtELnwJ9x+IRQQQEQIA
-BgUCN+FBMwAKCRA2Z2DxfS7XiHnnAJ93k5kJXcvwCGLhBb8mhdRT5kHQzQCY97a7
-DtZgMs7O/jwfvq2bpzL3nohGBBARAgAGBQI4KmIPAAoJEOPyWFQSjw55Gx0An0Ue
-6lGJsE8ba3/hcOoX7GIwsv/wAJ9XkXZJHQhMTiT8L6xxLWcnUplQNYhGBBARAgAG
-BQI4PoQFAAoJEDy4klAvo7wt7aQAn0CBYasE7gZZZ7lDpIDGuq7pV/v2AKCpZLWB
-dON2nqkq1MOIkvxNo+I8BIhGBBARAgAGBQI46dJKAAoJEE3WcVrMxTeC+m8AoMKb
-rmutaoALaWkjmB1+31rex+O5AKCp/Ki0pDcTZBmCDd3jd9cE6u0qjIhGBBARAgAG
-BQI5Kja7AAoJEIG908QOH5t5ZekAn2uNClagsId37o8FesrYI0S8x+gNAJ93DOXd
-KR8kjoD7ft0rs04pj9rlE4hGBBARAgAGBQI5KnG3AAoJED4gT8kqkIcsTW8AoNSH
-nitUbZpwTUzEHSxC+nfZRvIGAJ9bPJqRoloYIvsBZWiN5Log3A4zH4hGBBARAgAG
-BQI5LjG8AAoJED2K8bIJrApqqE0AoL3BDQMJ3/ZQwwQq3I4qZvlGOFYcAJwNEQDy
-LsZGAt3GHJeBpJGwAxm+v4g/AwUQOS4q0J6y5PNpFshzEQLgTACgilmE66iRYTSJ
-nkJZPl+W9cXNaGsAmgM6Uf8sn9EnYbnThlMHgGx5E6KfiEYEEBECAAYFAjksKEYA
-CgkQs+2ENZ0bx8g7MwCfX/8HTK842/fulLtfElcW0RW9a8wAn18MUa7KTA79a6EV
-Krqa3qNLt2v1iQEcBBABAQAGBQI5Kv6BAAoJEAWcfuLwhsu1Iz8H/3KXi/WE7Oe1
-Huw2h0A1JGyl+zKI23po+RenuSKC1NX821NRyrIN1U6CKzyBdMKeiWd4/bNaD9vQ
-Ft3SKK4CgjRqs694TV1ue1c5+iY3TtjTSR2vAyxACScl6csIm4TAJXuSMDSeuE17
-1QsXSJa5CEXBSnHTOPd5B+47hAr+0G16fgWFH9WLjZNA8s3JBZNg69hQSDiZC1FI
-oP0SuBUJk47hmZpjIzNGKGRxWzfK82tAk3eS1smnq+V1LvDLWJXkG/XVJeX5SsT6
-WyIBcXsq9eMk/t8mDyVxE5SbCFu7TNIMEL8f49bEQk77xf+t/5nzDOY1iA/q2H1l
-o/0ncauofCyJARUDBRA5Lpn1EcKB1QApK4EBARqvB/9Nk6Edg2z5stFyag8CqlOc
-iVURGdZpH/kR/OtlZkIHva4fgF9chC2F/wd2rMfoG/Begl1jvt4aOAR2Eq/qECHl
-kWeMIMr4yWVJqhYg7WT+dir2MsZOcS5FRpzMyVDuauY/KmBQKE7Eg1J7mVI9CgRZ
-TvkkQusDh85pUhOla7b2n4QLCrbicLpC/MBlHE1nfcxDEiYxwA+rJSTnLg8wI+7q
-OX6fqjd3zV3LgKd9HwFZ7ws8Hgaog35HJpIFfev/cOpcFMOl42cQxZII45wcQT4j
-I32lwSjAOMWYMbAUSIEjDs1Sfowkcu0cvtTZTDly0UvTJjQ+OjDe0+oJOofrmKuf
-iQCVAwUQOUX4pCt4HizjmvPpAQE86gP/Yf56qY6Qe5nCOa1ex73/ZMPvOELl7yKT
-ohPZRxPWHsy63Ff/CyC6A6dPZfNiUdfxYO4BsitGh76unRmeFjf/awwWjfOqvx62
-bYpWMb7E4QQt2KesNjgK/yNaVHPGtsKa4E2gWo/+rWQHgfq14igx8w+KOoyqRhUZ
-N019GyLMN+qJAJUDBRA5LpoJe390GVLRyrEBAUxgA/0dWRrv3KBVNJXHtYjDlHH1
-zBh+x7i8TI2aAPEN2bz3zWI9XWiknNudVm7xtsp61iMJ/xXvlD0Jasxhk8/JHRPa
-wNO8kWR3UfKYsnIR7WBxrlNNBic3MTMrUCyRszLqGA2d8nJqHQ5HBNkhT3sZJFzm
-0EshmypsmN5bbkTquvTYiYhGBBARAgAGBQI5Mb/DAAoJEL1YtpICkSxThskAoKv3
-X28MpPW09UhfjuQ9rexmubuRAJ9EJLu2mUpM7BdXKi10HmC0ui4m/ohMBBARAgAM
-BQI5Ln4fBQMJZ1MAAAoJENeMvOVmp0sxywsAoLtChkYFfkT2YJGGmfrW24orSShr
-AJ97CvRlJ3C5VFlnME/r3feAmv4Di4hGBBARAgAGBQI5So3XAAoJEFy3t/Kgqlwe
-CicAoO+D5CGVRJIto2n33aXYU1yuxhiEAKC++kE+wyq5BAbi8YX0BAUxfRXtmokA
-lQMFEDljXQjvbYJB8IEZXQEB1d0D/iNMwOG2MJMrziMiIokV6UvbgqtG3AEltb5E
-8CGTS3wO8cbqrx+yIv3ZKLn3HAR8vt5KRkQe7qxi/hFaIpPuMXky85TrbXyZGvib
-Y0siHFyrAem/jP/EVU04Bl59nLbBRF3vU6nQP8MRn6v49p66oDtAAPNRQcmFjz+s
-XGMZfFBAiEYEEBECAAYFAjlqA18ACgkQh9ag3dpKERaGCQCguc0ldTZL7+j6Avlp
-5VIV1Cn+DC0AoI6PBkWkwmfFeNbWPgRZxOuQ+uZoiEYEEBECAAYFAjnKOwoACgkQ
-K7tDpvCerwpRBACdF1rqU4MpphmY3GWtamI9yWKCEs0An2weHB1LSl/xnAeK+Lfs
-mOobg2vKiEYEEBECAAYFAjnL/fEACgkQMsNbgEe6k1dzowCfQuX1VDigeNBsCcxK
-vdmPU54QyhwAoKqychYr/hLHqQgfVU2sETcOY/YTiEYEEBECAAYFAjnKnW8ACgkQ
-NfZhfFE679nDAQCcD20GISMXSvMu1f95S7nZipLmUbEAn3LITRjm7w/b3uqAgmgj
-KeAQqH9OiEYEEBECAAYFAjnLMiYACgkQUaz2rXW+gJep8gCgvcTvQjtCjp2vPCQ+
-9LvriWkgryYAoLWJ/1lhi6jPLY6Nlm4NVrFG+WzviEYEEBECAAYFAjnM3EcACgkQ
-3nqvbpTAnH+xDgCfU3V2BpK9VFMI8d0P/RQ7qDPU5a0AniMxEJFV0F7OySIez+aX
-KlFLHYIFiEYEEBECAAYFAjnPDvUACgkQC2MP3CMjttIBqACfc9B562R+9fgL+PV+
-VGjASJzP85MAn1rJQVVVQSLrP6SdHHbxtbPr41HGiEYEEBECAAYFAjnPykwACgkQ
-E9QuGvaKeLzbXQCgokt9SjQxh7tIOg9oJ+LckPQ6ua0An0cbFCxj+1YPvMXEG2Sb
-wMe7XmeuiEYEEBECAAYFAjnKizMACgkQF6ZBbfeUj9otwQCfUxI+VUJNs6D4216e
-mqnxhvYn3N4AoJFV214unHmOO+IieX463D7tMG0niQEVAwUQOcqYWBpPhku+30gx
-AQEmKQgAmnTtDlJoTHIJVpMR3WXl5aiRmy+FOlUvrXjrtWhYM9YZS91t4QIgnMB2
-AptITQYBcQ4FJ7jYRbpk8zig0i0GyYDjD3lmrE2+XgluhxO9qSAGuXsOUQsuq6/f
-Q0WqbnBtUQZ/CJW0CydpFfE5x8uA1TC8wrGCfPRcmfVrc8e93UtKSwWWgo4xOkiJ
-QXT0s5V/iR09pUduScTpgjLjZonAzR2NKojay2Php27GHBO/HU6Rb2ZGOVZfIsdd
-Fj9M9YNwO8L/qjnUNv48igA1yxYxybO/iDaK/6M0LjKWckPOJhUI2bDU12jpe7jA
-ui2/FwdRBLCZK9L86AcKigUfSSGXiohGBBARAgAGBQI5zFCsAAoJECDmcbCsS9oo
-iBoAmweFLJPySJaIGv2aMspXbPlppl2aAJ9faAb7oaICLW2zdvqraYpRo+09BohG
-BBARAgAGBQI50N/bAAoJEG8ji8JP2loMxJMAnRXmIq/pekWpI5w7hJg9NU6yUCrg
-AJ0XyfLgd6v6nGyRwQpx6Aza7iuIfIhGBBARAgAGBQI50gqvAAoJEL/hIGVrIUia
-opoAnjLR00eLkd2TWTNleRoUY6qQTgRsAKCQoNcdBZYYtsfF+uGIjkNwuDXQhYhG
-BBARAgAGBQI5zndTAAoJEOFd2FexXDfRWIIAn2Jx1qya4qH5U6r8drlhAPhXAOh3
-AJ9i0WYu9oGWjEAcmN7qVtzqamIKOohGBBARAgAGBQI5yjg1AAoJEPC/nJckksmN
-3fcAn07g5lMJoyO8DmpDm8oTuasN5YZCAJ0UnrVLSJw4GM71RFkRKixzIObuj4hG
-BBARAgAGBQI51EpUAAoJECnvS20UZCjxm9wAn24zywUnORPNEQlnivNU4un91BQW
-AJ4u7ej3KRtOXR6QfKTeN5ZY4Cm4lYhGBBARAgAGBQI51EpaAAoJEH6Lq0fkCp16
-ShoAnj9kolr8EMCMutP7vkv8MS/wsiH7AKCzbC4C1+igyQ0Lm3I9FyCl0VVbxYhG
-BBARAgAGBQI51EpYAAoJEPz0IFPX+kUSTLcAoIGt9RQkhVgz3lEUA1zn5D9W0cYt
-AJ9iyirYXCX63tNY3cqMg6gWQA0+cYhGBBARAgAGBQI54GWRAAoJEJ/Oxj5lCIC0
-w4IAnjVo0u/3WFb53v2pVwetMugjH9qeAJ4u1VsvgSUTtkS/8o6+Bx7sDjs5dohG
-BBARAgAGBQI5z6dKAAoJEJFazEWo9ML9kc4AniStFstXJoQolnooDIMzDzS+ADr3
-AKCkE4tq6WjxfLSV0MHIFLvXg7If2YhGBBARAgAGBQI52lYiAAoJECYzIbZBaZVr
-nfEAoPSPjJ2qNNhaTN5bz2omXssehuDrAJ4x3M0HsV3vg3YI6xToTg8bTiuBBohG
-BBARAgAGBQI5zvUmAAoJEHMKa4Nqhe7d53MAoLQ4MuRp2VN91lOciN2/oIppP/P4
-AKDDSwJvp04Dml0S4+9D/xcBwqKVY4kAlQMFEDnQ+N2248PGUGh5LQEBw1cD/0XW
-PC0AvGn5xQpjCUFSYvpx4EuUnnOMukKEYnqzFs2wtKCO8Pbb3IyHJ6VGUftYCemM
-L1OL8NQgw6AdiHqWm/lKXhbe1vbO+3+EoHbDyIdne4RFK4mulRBUFx/yovwkg9z5
-EWJVsrzS/fUuAg5kX/c+hdRtdDi8QYQjPSIwLWrkiEYEEBECAAYFAjgUDgoACgkQ
-YAeQgHPH80+3bgCfWl/hh0/ZW4u4OEW1KtIOiU7OjosAnRIisuZdS0ht51jdjrbI
-Uq7lRXDhiEYEEBECAAYFAjrBCNIACgkQt1anjIgqbEvnSACbBze4BqULiimEcIUM
-4lkErCnDocwAn18tJqdhoZgyD0B0ouLbfgJCJplKiEYEEBECAAYFAjrB0SMACgkQ
-0vCiU5+ISsi/SgCfar7RT9JPw/V1MO0rREx2SfDSIfoAoNcgtmpLWgU3kbf8wb4A
-ESQIu30xiQEVAwUQOS2iwwFVuuKglNolAQH1NggAjNw4Cg/0z+6FqCv5b/opI0E3
-oc2Z1wh+ovL6jsA9hKiq2MiQ0bdd2GmjgiojVNE5wYYm1DYjAnLVUMgKuMNQDCSn
-pFe7jghGHJZgnyT3CG2X0TdiN1FNGt1MQwyetIUH/KSIHWPf70OHQvw9BRvkHZa0
-9bk9N+WTrDzyhKuZmbLBN2O+wC19O4s64bk39+SsZZ8iDUuMONCg8HTJ2JF1aRH2
-i1wpXoWpQ6UXnVPXIWmA31PdzsJ6j/mDgnlVbH0rL24po9kB3ig2IA16rKrMC8H5
-mKnM9lvA2VDBr/0WX7LGlscRKD9NXlNjoL7a+CSO7TxLnAdq3+Yi+sQJPINro4kB
-GQQQAQEABgUCOS2T2gAKCRCVYGGm3ZNBOfDAB+MGwzHvzV0zSoFSWevq9l+prNU0
-yHKdv39AAONHvo8e/AsNTltPk3LKiXdkKxkGl6e7UkHawJoOgd+8DCmUStVv3Srd
-POSovqqce6KC9UfsmbLOf18mx7bP5OYpeTleF1fvBMvFhW9jrmTKFpO22uLScpmo
-qXmz0J4/dOnrPmPP71gi4Y04AZE8DYtnARVUScEYiZCiLP00+QocjtkIJRLhNTYM
-NW91oAW4KYz5Sz1wxyczyfSq03mLBBan9vr3G9WGzUCWpBDic45dpoX2osgImPjn
-bRf/yQJ6+GKRT7UlMRFI5rWbK3JSBXOGvjNZlKQcG5uA5OM8zEpW0xbwiEYEEBEC
-AAYFAjr1eYkACgkQ7A6vcTZ3gCW+HQCeM7uVjDTOpJequ0Z3BVeKA9V3OFcAnRZV
-ML+f+ZmH5tx+BV1TgSlXOA2TiEYEEBECAAYFAjr1mvgACgkQLBigKrTF83/VqACe
-M0Aik+REDgVsgu0cyR+2oXw808EAoJM0ojjxIgtWFWsCJUh/nyHQsleJiEYEEBEC
-AAYFAjssp/UACgkQlTDIHyPR99S8oQCfdIzgvLTu4E2h5iZ6eSzt99ASFP4AnieH
-MW2mdukyzJuddTiu1II1NksPiQEVAwUQO0HCUNImKUTOasbBAQFLZwgAkgMC/xim
-skOjL/CxghgdkSWkDFdpEr3XYhzUdLesWgN4AM28mGZZKA9la7dXXRrKYkxhX8mp
-L4C3Q9LnrafP+Zn1c8mTuNIxX86j7iZAIksoZ4D2csN8NSMYT9pKK6jZP1IOckCF
-BBI0W/yMGUGulDitWj4TwIArf2xQkV73zMKYJFhW5mSjWDx//F1zrn+x1B0pNoZW
-CPQ0gDLdEtnWO2x/aiocqkEorHwNfkWusHvEmx4MkarXPDZuLqumEWOpW6v4xOl4
-49Z9au384FST6xf9c6QjXngaSQAc3VcwC6AuTjbmiQ6+H6WGwjss5GzRNRg/LD8L
-uqaKb12tkfrZmIhGBBARAgAGBQI7RW00AAoJEOd14yTbQbOHdAsAmwXs1mCo2SJL
-911EsKPE7/sgZJw4AJwO96IG44Gh+XlQnsqM0J2GnD8qp4hGBBARAgAGBQI7SxcH
-AAoJEA6nVrUUSEP1OCcAn3HchOcEeuCeLzCYi1U7JwjsC9iEAKCoelaC999gohQn
-O/x50vgUsskGJ4hGBBARAgAGBQI7Rdj9AAoJECP6tfsIFswbylQAnR3Ea24SlXoM
-JbSnEOamFTuesu+CAJ0XOHaDol1jnHssyX917HZ8bZ94NohGBBARAgAGBQI7RfEO
-AAoJECeGwkR/ikAX5soAn1tP8xYpXSQTPrTrcwaXK3m7wqLZAJ9G3yh6wapy2NZL
-D5ZgeEPwDrGggohGBBARAgAGBQI7ScGaAAoJEFCP02O8k2g5qqQAnjyt7fxDX7sa
-l/ppjksajqFlOCmBAKDHqKC5h3R0jNUR95ZhwwVrynKFJYhGBBARAgAGBQI7TBe1
-AAoJENcNX1hgPNB4c0wAn0/S027VD6x7S2FBGyiD3GP4FC+iAJwNtcPDbyiugiNn
-SDQnSmSxSBbubYhGBBARAgAGBQI7SCdaAAoJENdZXTdLcpYlWi8AnRLlddW/rueL
-z6igUbjJq5ATAX1kAJ4l9Ej4Mw3WpASDoEQS8SNMpaj1AYhGBBARAgAGBQI7ShVN
-AAoJEJYkg+FWYsc0dG4AnRx0d9Ti17jNFMLeigC/MCr+QSviAJ9kb2IuGhw1bUi1
-KINM8q2bQQAaqohGBBARAgAGBQI7UblhAAoJEOQ7FTzLRn4nHrgAn2fkDVwZqjcN
-olNGNE5LjdblbNXEAJ9Vy61tZ/s0H/l7mZOigbreJDIhGYhGBBARAgAGBQI7V0Jb
-AAoJEHkWLzb39qrZbrEAoKFjjHUPomPUu1gAnuk2qqm1p3CZAKDtB/PvqBb2C0rV
-mmfpg1pXj/nU2IhGBBARAgAGBQI7ZzpQAAoJEMALDTYh5T69uBEAnjTka8BHWuhK
-MmPW52PQJ7cmJ9tUAJ9zGIqA/3/nk1ZS0pgyLfnKPJvRQYhGBBARAgAGBQI7SZO8
-AAoJEHgz7PG1REgVUUkAn35FdEAplXfFwa+ENMPRNagzdA8LAKCFTXbGeSjirdjM
-21dFNIToh8S7NYkAlQMFEDwGr3MXPHHnE9mHPQEBv60D/iZt13tGPf3PqtZDQqqB
-Ej7TlHtqmRWJ41qETo5ix0CHCw0OsDF1Y1kzjwfax5Fte49YLGVlcfYhldAQ+D3q
-ha0MceKQPtVFg0rcBij72QcMznYXSDtEYD7TAlNtcAPCr/VjHQBziBN6dAok2Tt8
-sztsdcwJfk+9LANB2vX2qaJNiEYEEBECAAYFAjxw4+EACgkQGM0lpSLzivOYuACe
-IyfkTvjVxQnVP21FOVKscS3n/Q0Ani/K4IFki5Uqe9zk5MYN3TI8mj2jiEYEEBEC
-AAYFAjwlvGUACgkQLbySPj3b3eohlACfXuiyTRw8ObbNLCLAPQrAJGVjclQAn20M
-uHHrNq77H1SgBw/Xn7fadKKwiEYEEBECAAYFAjtSxDgACgkQO/YJxouvzb1SXgCe
-IKzHXwuDNHmz56JZApYo2QOFFUoAoLDQT7AFQT/vlXq1GkO+hKtzeuXfiEYEEBEC
-AAYFAjwjtU4ACgkQRHJT9Ar9DKjy/QCffSBJW6EJF7eqTae4LxD8zPet6iEAoIWI
-REsh6zjEbITlfWWGhWSrs5yYiQCVAwUQO4Hbo1Ks6y7TpCxhAQFTLwP/ZOBttIDu
-MJPRxSNnJvNoSlstaYxqH42+33XtwxvUai2LCVIKHC8kgavSqn5psK+j9sVLqibn
-PebK2QN8Xwid9ZG6FGF6c46T1STOhrhJyYcj4la7WBg1ggd70Q1gOn9OmzWtmYDu
-7VoxTYhwG51IGrasgEOFzJrvb0hV5bzGc6iIRgQQEQIABgUCOomB3AAKCRBiiATb
-IPxs9iv7AKCaonJLi5A4q952Lf1IAZSWbvaV6wCgpq1Iw+gUkhgr2UX/7dKrBA/2
-hseIRgQQEQIABgUCPAgRzwAKCRBqWILfhEBGApEcAJ9RIFv5APNz7Z0xfXWl/fVH
-PnUyrACfamdeFPVrHL101BILgIFOEUNbGXyIRgQQEQIABgUCPA6XmgAKCRCLup94
-YAy/5zEQAJ9W0yasRJlv6ClDJffKiJfQMyFQlgCeI1wR3sdVisKpHVpclKui+3cK
-SECIRgQQEQIABgUCO5hEjgAKCRCQLb2RjDipCsToAJ0YYpBpdCpAuxlvsOCVqJFD
-ha2mjgCeIVf0M4eRHrZSjzUNPegY0c31fOCIRgQQEQIABgUCPAui2wAKCRCqz7OG
-IRtu7wv+AJwOBT2jCTvg4DmCK6ia3Ch+4RAwIgCghK9NjNrz+yqCYR0BBtLmrFwU
-cHGIRgQQEQIABgUCPAf7VwAKCRDa0rBdXzwxhQUdAKCzI6mRsmewgoxBtCiMO2yw
-DI0X/QCgqJLsS94ezwllI7uvWix2qO1qt0CIRgQQEQIABgUCPF2rOgAKCRDu8Ns0
-syEmAwy4AJ48w1kK9bn3eclkd3PEJ6DuHJsDTwCeNEq79cwbEEzUGX1mySe4QuPq
-qwOIRgQQEQIABgUCPHFBegAKCRA6GqY1kJpUBuDEAJ4wQq/nnv52HnpLeS/Y/g0w
-cp6+zQCdH5DVjozROk45axTNDiJrI+sTpZyIRgQQEQIABgUCPHN4gQAKCRCj4LnS
-ejT63p/YAKCc9dxuOjoejjPjv4/bJBfE9Bb3AACeLS91AYIJCSvYhT7BI/FsNpim
-WEyJARwEEAEBAAYFAjyFr5YACgkQEq14jk8L6rswwAgAmYoP9jbj4yzxZiLRwaT0
-v1di1Zz5ip862ETNkr8JQGu0F57+aSlECj3BPnc/A93AnEHvw12Xryb1bAZxgKNS
-t5GowTTKCm0zUvwY+6HQ+T7R3VIOGzfkzV867tt7pO2QsS+4yYwvo9gVHczV9PSF
-OeCGjme1Q3yoEp1/r6VvH0fi1JgkYoKFLw0UBuu+gv2XdeXY9FWXKHm/u88nsBSc
-8PJ+B6I3u0/E7B2Pu29u8apY4VCtY4BUwoALBBjUYLFzEh/xJTi7qPD5NLZQSFog
-6Z3aju+0MqYsrBiQpZpSiWBgPqxQwz/DZdUH0Y/wMNU19gsjkpy2+L6uAEQYfSIW
-0IhGBBARAgAGBQI8tzrnAAoJEGNFXT5qgEC9YbsAoPZcSYh+baeE+o46yDhhBV5W
-4VynAKCiJAby2fHjNyOANqOs+AbJ366jhYhGBBARAgAGBQI8f3SNAAoJEG3yVZ9B
-pWcPTCAAoNRGmdH4SpTKSGMu22mHq5O5B4PMAJ9q8l/Td+8yLzQZKJV7DCD2o4+F
-rIhGBBARAgAGBQI8lzY1AAoJEINou1lm+8GMz1UAn1e3vrSf7b0HHMO3NgHD4Zfx
-2vbiAJ0bg3QKT2sa2j6RDsQ2SOjirPZunYhGBBARAgAGBQI8foHxAAoJEI47c57d
-K8ydixoAnjC8sjBGNb/0bckMNegrZUgNFBXXAJsHnBic+JYFJxX5cAM0d3YVEM4Y
-LIhGBBARAgAGBQI8lzQ5AAoJEKHoAnDadDOW1DQAn3Pb1VX9+0CLtOOHaAQX3weS
-BT2cAJ4+TXEmmOpYYGzgT8pXZsjGyw42fIhGBBARAgAGBQI8gGO+AAoJENeDa2wM
-2SDnmrUAn0WufO0MQO/wKk0PMZsgz3gq3GkjAKDGHpOyOl0Sr5L6UwmufJHmsTju
-dokAlQMFEDyCLHLlFSglMxzaXQEBOCoD/1duqEnfsCjE+0B2pzKh9h3/IPi4dIaC
-qlCTjDZ/tWU4xVGmaMfU1I6TVRDUtPBOt9XW4xdew+ntJNHd8E7g2fVjRSyQYLwZ
-EQ/jG2jjowfAEUMJzQSPm2C6E8uIxuvD4gP4N3/mj4l1WHp8aexGhbeSqF9BbHYu
-7ri93Tz3TdJ0iEYEExECAAYFAjyvU4gACgkQ6pxm6rn41tlvcACgjPRZmULJnaVf
-apXamMzoPhtFAIkAnAuIhaMOKBqsiGzpWxkAkCUh1qJ+iEYEEBECAAYFAjyxOCwA
-CgkQJXt5TsZsoD0UnACePAR8wWLkY8ZdEVwJyHOztnk91oMAnA1OZbHhmMwN+bYj
-mazn9dYOddvqiEYEEBECAAYFAjyxjiwACgkQocWSfM5dzg6zaACfQky2IN8wQyZA
-DGCZ384YlBgRzDEAn1Ivzmi/vBUfmlAUrk91d9q1EgUxiEYEEBECAAYFAjyxgtgA
-CgkQeuuK7Uc6ScmBaQCfZ9ogU30ZhDBB0JZzo7dJBqq1pu0An2aNVIoZ9KKjEiLD
-+HaKMha1Q8bPiEYEEBECAAYFAjyyhzcACgkQVlEzpFDUq7kRIACg3C8msuOW4fDW
-M7McRIFT5AY/084AoKUUviYD6wezVBn4NUIOKMxM6Ay4iEYEEBECAAYFAjyz7a8A
-CgkQJltdGckHlEx4bgCgzog5Mv7LJUDZziSGgv+hzyvkCR0Anic4FduBfWg/zuyB
-kgOhT8QzyUmCmQILBDxUyXkBEACgg6vxNPigg9FQz14CkPtR/dEq3sCjK1r4+2oy
-eoRno+pqZ6Z7ZfphgA/q5woweFAGOg17KD2WXegoQ5pXbFvP+w9j9zm3g59XzTRS
-zZgScelTibPnKy6g8r8GDAY6IQraR6pxe4297/NznqvRvKpTt5g1XP5LyjVBsEv9
-HAYJE1vyy10qSQRtEz3QunUzfELNC4kiYNMZOnmgaFeW4APIIhWDtrrxqW3Ofjp1
-K4DAhqcnayrfvYbOtqh0sxJ246kvVc3Bc9pH6wDw/yub2deuPq6BZBLBJwrtu/20
-qD0nsZ9is/5j0aL1MZuVmr7xKYqeehyzJ1WdpJK52qng9natYedS+GefKDIw1Jq7
-ppQNWfVduTNITFTF0JswggjQuPqKT8Td5GCywQWN/kGHbp6EdybiUXZ+9fp4eek0
-UB5M+srSwbkF4hQ0mBrqlsaoji4CuXjc0c+Zx1D0pGfqqBCmvEV1tLul3U8h0TzR
-4opUA8mLKegQp5cjh/dHz7zTPDxVgSr3blJ9FxI1Z69th/+jJj3q6joo3uW/5y8q
-QCrzdSCzs+TDEWwucZtJIuIhTct8AMPY/Ayt+Pf9jXfI+xSQgz3r7Eu5o+rEu02/
-cthaOc4b3KYDtNkjLKszgiext1BYOq06R+Yyh2qgsg9azzkfudvvpwhCpJ7EOxcd
-aP3bxwAGKbQlRGF2aWQgTS4gU2hhdyA8ZHNoYXdAamFiYmVyd29ja3kuY29tPokC
-NAQTAQIAHgUCPFTJeQIbAwYLBwoDBAIDFQMCAxYCAQIeAQIXgAAKCRDbaY1xmSQl
-YH7aD/wMq9ksbvAf9drjVP2u4rjZhLkHyc1zCp7rMXc5CdNgDNVyhl7+co/qMeQB
-wk8SYEVedrZZ5Q7qjygjkKWp3qrLlw5PSydwCHaf5mlVg5E+5gt+RTkOi6FXdE/5
-c0IrIB+MNI3jt3IeOqEhITWcnjDk4gIxm4z43tvXvf/fY33ohrQknApN9uYISoEl
-zYGgnEZqX6P3p/8FB2+27A3t/Eshr6lLvVNEMgOlBY8te9TFvMJTMeSJXIQVpvbz
-/LMF8uEboWVzRC77y7RcD8p+JP9V97qZGsiOYB+2MPGEvAhEPHxQZAbaBF+eBFLz
-ev+xmI36fHlFnAFiWikp0tYVLROgBhVGJUOJlDK+olfpxUqF+N8MfjeS01aHLy+Y
-6rkzC26AC/9j+Adka9mBXEiiA1vQcBfO4U45QhgDAl00yUW1gV4oNGZ9YqslOhS/
-VHB61CjWwjnV3Jwkhscxux3rjj6TAwn5QmoO9kr3CqH1rzQXxTVruCJuwyuI6aNe
-ywINoubgDhqhOCPfqyzgdxfp5UAhy54ge9dqjfgHI2Q3WxxhD3mCdYgN89GZNpuH
-2lJkJZrRl7BimjqDeTlKYscZ1anrRgRpSoFDdUcMncySzW6cB1WSImj1aNWpq58F
-xoJWcTy6lNesINeRjZ/r1eJBeN55P8+7DKGIsGkpftsqgXAqVYhGBBARAgAGBQI8
-WhCrAAoJEM3PhoWgyT97OYoAnRFHu9zcFMaNxojhWfZSlc32F8P3AJ4wp9uyTSnJ
-pCDW7b4lcyUEX+fMiYkBFQMFEDxaMf7/7ryp5VOhtwEBMsMH/1O0rOOp5nFiivB6
-9+IbPSc0lxeLjPfmb/wQArJXWXZsWDbBuby3yL5+wwwMFyLLDGV/kPiC6qPHfC21
-oI7sui/TgBe5XblSkx19wAUgyuHrAw/YJTgqhXKmaZFgkcVKhFcc81HU1w7HiGvM
-oWA+4VMFHdqKmGsqYkegvfroYWsxbDxbQ1OQ4GHVwJ8pHYVdfWX5xKTRjuKTC1GH
-esfA4lorrs/zC/clQuJHMV/TrE9OyvP39vq5zBbG5iOerU/VO4w96yxiHoA2J4YD
-SSmEZaCTqjleH1u6Jt/YrL41RaRBayNOoyF/AM6rrmai7agTlutY5kjMjWyZ4YNp
-za3E4Q+IRgQQEQIABgUCPF2uXwAKCRC98g3l6mjvU3yBAJ92Uc/XTOt69hteH6JT
-CvcFJE3NEACdG1gNdn1xkCU4cIjx4NZJty4vFF+IRgQQEQIABgUCPFyBgwAKCRDq
-vxOyCxdw2+H+AJ4/oSxuFQVqj1SS3Z6nufW+4UKpxgCfUFd5h+48RyHC4prnHd2X
-wTwDFYaIRgQQEQIABgUCPF7gdAAKCRCc69apC10naM32AKCypWJPQ+Y7y8odeJfa
-MsjZgrN+XgCff6aipzB501CUUc/PlaKhL3KanVWIRgQQEQIABgUCPGBsXgAKCRDa
-2nnNeIo/TL/wAJ9fXFgw4gF89C0G22XZBFgddadIJACeP8RBT6kShayJrX1TK6SG
-o3aw3GaIRgQQEQIABgUCPH0qxgAKCRDWFJDobGH8qhA3AJ9QBuhppkcU1dO+qUDE
-FDmeKGlJeQCeNIHejRJbsqRlsJjWKhU0xDW6TKaIRgQQEQIABgUCPJfc9wAKCRAH
-lNKuLBMRcSkdAKCKG/h17odvnPFMdJD2/MofAmLt/wCePQBItnFwcWsaoECtHVhA
-Xkor806IRgQQEQIABgUCPJ9y1AAKCRCDaLtZZvvBjN43AKCazWmPGOA8Q0oUrjF4
-QvOUFM/bDACdHDw6m42VYtjIGqZGudhZiam3PBuIRgQQEQIABgUCPL9PngAKCRBE
-slvUW9U99zyHAJ45DoDcb7HPXjgOAv00OHNIvDheMwCgsd3fo9m9BHyyxWz8QrCT
-0aLAcv2IRgQQEQIABgUCPF4i7wAKCRAIBXUxEzAHMTr/AJ44sNlp+qn9bVY56sXE
-3/iTZ+bTIgCeM16g9RACeNezFD2z+1EzCg852Oq5Ag0EPFTLBBAIAO5SrjR8+omG
-/tqQGW8a46eQB1fOqW7VSUAVqRlpBixERm+sNoWEy/GF6+yYLXgZstWv/peWWI52
-RUPOtN3mUQtYPv5K67lpn4icRPx7R1XFUg1MVzSYhOuw6UnRj3/InCMd3PdV5Lov
-Yn0t1TEo9Xs1i5ufzmBdbrU0OUIsK7807mgrPI1g1M8SO+xXM0GEBC7g5h3r3XuC
-nuujHlgiWm7PTkOoutb7qya49VkEPab1zs3G3aEBbQBf7xivNq569KeXA8nrN0uZ
-QiguJyIb6JB6LQn+t2FFOmnxvTi6fwEpXKdodtb5rQ6e8UoOg+yL5+XB7R5wbwoR
-ur40PSDuYHcAAwUIAJzRe8+VXFdNC22EMTdb1++4isCdWhGVUmDKyZ77YbSTzOWp
-QLDkEUXvOaYGbAX3dsYCmw2RbEGj3ovp+fZzD08ZevGLK2DlmgXvSEZxCgWCB0lc
-AwBrBHccjioKYTTu3ECnKUVnXqovRUNdXFlS2a0qgoZk/WermBiw2mysAIWJek6x
-ENifTszOfOiwEWR2/JtjDnBq5Wvl2WWp54xFX2nouaJ/CLoTi2pcf78e+Atai4vQ
-dXyPycgrCZTELo5A66c/NIcCMmr7rSwfU3UGZ/E7jai/5u3KVNWDGzSGv9TsNgoq
-O864a/xb01+CoDGhqurpMe6lgw2zBPegReeyDLSJAiIEGAECAAwFAjxUywQFCRLM
-AwAACgkQ22mNcZkkJWDxrA/+NILMckL+DPARXz4JzxDmJUhAcKYm6/l0Xau6vfJ9
-xfWZV4yR6u+EYV+mqLS9dMKXjG+n3BSoZmjLvDYceD1D/foddSOxMJjHi59qaxv7
-Em7IAmOLbBFtPDWw83F3Y+vir3pKROpWJjmuDkUExDg8fNXfUfA8XKlAmB2J/omD
-GxA5wWZh4D3OYZBrwTY9hfnRrOJ9Igb8RUgaE0sx2/V5LBt/3KvA3VufTHCcNf50
-8jdpCyLxozaknlftj9qHoeTUSQB7PV+VvmWq/rKr5Rw2tXtI6tkqzIVnTg9aoE19
-wcxcroVltyCS3XMhRKejbAvy9niXZFsHJU9cYRL5vCxLAdtZ3RNlDaSIzlHHRbxJ
-2GvOA4vGaSLxL54BuqvbZuSteA12WEHM7Dfq6zl4E2H8WxLgs6RQoNQ2WkUJlpF3
-MsM6OxdmFIMNZxXvU5SKyyYF2XI4PoaN1DZqrla/qjVdSM2ApBOiO9Cf0N37lzn1
-XTNldCUE2lnwTlBaMMFTcsyOV0pfE08LJbBjfK6BABgUd9ycIQcuk5XYRK50daby
-DlbdJJBl2xKiCGDjb37HXdiyBWVH8noIfKBQiTQ5ijmyp7lcmR+d0N24E59Og+U3
-QWgivbrFalHviWdSuFS8vttJEogami5Hpd+Ne6Pm6naS91LvIF8tW7DocqPZu/bo
-PKKZAaIEOlToJxEEAMJP+0akG7QQemN3cbXVC2RNZieKFkMF16eNhXYS+i2BFkCP
-mHh7CmurW7/OrMYFimJgv/2P7lcMVyhYXbhvOxSYdexsNKK/5cTJA0PUZR3HjBVw
-Rjms2OQCtfTpe5nM5u9cVc6+pGPouyR4+3DfEt/m6PyM83Q1/pgqeF8YgdFZAKD/
-RQCveEwrrNwD96C9ZEayb10l5wP/XxdZ6TO3kkl4rd95sk7/czB7jc7pU07GYykZ
-Y5hOuGK/I5v9kuAt52pf4x5ccZ0augBFn6TFir9r3LmM1yK8P4TI34iI0M8PriuX
-TQU1mSzHt2KMPz09shQsMK1SmmzYnSCTmKdH7LOKd/6MPIWeflQQcjas8UtRtdYc
-lclynRQEAIGTMN16w+MRVdl1NFMuTSx+JYR1wEz/kak2zAyUrgDsDqKomhI0nik7
-lCro9g7AMWoaKvX1YR+hPIdbSTGKmdVu+rira8CFIgo6o0QkbGDgNMQp5x/fEJ0n
-SRbx1VKiAcMf9z5Dj5EVCr/fVp6/ccPLbRhrLEAT3gFYiwqSFozKiGEEHxECACEF
-AjpU8FsCBwAXDIARP8cyBB0j6epm3bUAnJ28Id903GEACgkQx0Y2ObLXeV5XuACg
-odXarRcQ/wYmTKnT9XmWBvAGYEwAn1O1V/DaSGhpncs1Xa0g1KOPQCWntCJQaGls
-aXAgUi4gWmltbWVybWFubiA8cHJ6QG1pdC5lZHU+iFUEEBECABUFAjpU6CcFCwkI
-BwMCGQEFGwMAAAAACgkQx0Y2ObLXeV5WUQCfWWfTDHzSezrDawgN2Z4Qb7dHKooA
-oJyVnm61utdRsdLr2e6QnV5Z0yjjiEYEEBECAAYFAjpU6RIACgkQY8tpHfrr1fwk
-9wCeKbj4dzSi15Bms1R64xK6Ks1VSvsAoLVZckjuDAyrQCDPTuFCz7484kEyiEYE
-EBECAAYFAjpXKG0ACgkQ14y85WanSzFQbQCg2uVT3G+jVR+rVXhAyVL/rQY6eqAA
-ni6DbX27Nq7yZICgx1hCA5iXYMthiD8DBRA6WP4Y8CBzV/QUlSsRAkmdAKC3TfkS
-Seh+poPFnMfW+LRuQJm8hgCdGacEslDd1xCQSYyYcSVbJEVFo0qIRgQQEQIABgUC
-OlrmsgAKCRBnkE+tCnkWEPSUAKDpWL9v2omScHt8go1AkjlpBG0ZawCdE0H8UBXf
-KW4QVCZHAoM8Ms1J4tiIRgQQEQIABgUCOleFogAKCRCsuxZLz3PsTI1gAJ0ZT2DR
-scaui0RLxHsTRdhjQED8xgCgpx/V/+LCiztzXI1f0hGVIROAKV+IRgQQEQIABgUC
-Oz6yWAAKCRAToEwwnJOdb4xJAJ91WRvsYFJrpNYIIRIUxvzJrTghPgCdHazYP0SQ
-h4c5PNtAW1YHA5RkOPqIRgQQEQIABgUCO9lQJgAKCRAn/j6KBbyBDt7xAJ9IFWcl
-fzF6xnhv1GpDKMCKeI4CQQCeLd0VBn/44vdt3H/8zzgKy5JlRS6IRgQQEQIABgUC
-PFnfQQAKCRAqK7rFw91p1ajHAJ9w3XdBtInEbKaiJhIqe3lW1jNNVwCfevWYQ7j0
-B2t2N617SBsbbGkDg2+JARwEEAEBAAYFAjwuoDwACgkQLRPpBcN2PZPEKQf/R58v
-HmZBgp7V8mgEKCJfX8TCOqJrNYJ8Xt81IH0bXv1k4gGXVwIaavHLHPcf31Hau2sQ
-/hJm9KI71budHSBbWt4tnwNMFapI55xWWKPirM2TKnfoj+4kOOK4WuDjsTsjY0m4
-v9RE8XmocZHR53YkSyryPy2b/Ti3nQKsloUpC/kezmU8XBtP3cQfaZEEbnWKHQ+Y
-mkc3nrbIraEINULNu5kP2T4scMRPe7D97vQR+6K2Vc5o20n942Pzb8u7BAgN43Bw
-GAVS1KcoXT+lZrch5bLgF1u5liSsn6FsHLTpOL3SecqF88tiiM+4V+bklXjZuXbr
-DU4Dl6gz/M4jF8TRiohGBBARAgAGBQI8O2hdAAoJEC27dr+t1MkzaFIAnRrW4uU4
-nwxzc2VHICu7nanqvIAAAJ9G4MFHT4y6ZR3prjQWjpWeQX3YYohGBBARAgAGBQI7
-hGqgAAoJEDDVfYbZ1NUsLgcAn1JmhZaKQYAe7Ah59k6xNPUpZRnvAJ4/uM3HHFiR
-VhArbe1vx2BjqadO/ohKBBARAgAKBQI7ty0LAwUIeAAKCRA2ttlJOTQkckVDAJ9s
-mqnAjJE/VqWMhmvWVcFKdeG0cACg29PJ3V37M+lx6Z1NWsUBaC5qhZmIRgQQEQIA
-BgUCPCu1uQAKCRA/sA/yl51MG59IAJsGzjndfoJFTA2uzbQCMcWeLUFnWQCgtXP+
-MIuRVK6bCGdbN1WVg0wlGHSIRgQQEQIABgUCO7+BdwAKCRA/zigQ4zaxBsdMAJ9n
-/toag3d/RKUMBrkYM5CahuSHwQCdEDx8+v9R85EdIXWIua+NAIxDJkSIRgQQEQIA
-BgUCPCIDJwAKCRBH07jLEUv/CMmjAKDFe/lsmnnnNQzsAg732GEGBOkgxwCfdcvt
-9mtxU64JWSdB7GGOGDyMSiyIRgQQEQIABgUCO8Nu2gAKCRBI1eMI/ua3cshMAJ9f
-LUz4VSTpfEhJsNulV4FxsCWnkACgtKDn6Br3ncYiMCv0I1wKohwY9ciIRgQQEQIA
-BgUCPESMCgAKCRBU3b7cPKNJbJ+fAJ9ith4zBy4mGX8PN2OSBxuHMBBYpwCeJSc1
-wP6OgatNXzZfgERyC5tG1JGIRgQQEQIABgUCPJq0qgAKCRBh+N6vwPlo3JqPAKCj
-J+WVShKpcHEv42g7TIFRx19DJgCeJaEC5PHJEpAEpJ1R135pcuMUNoSIRgQQEQIA
-BgUCO6bRVAAKCRBiGZ/lFRHt+Bj5AKCx28nM8btX06i1M+M0sl7rE1g30ACfbv5n
-ZYUnvB/ltVlq4Upd+suWX+uIRgQQEQIABgUCO8vVQgAKCRBj+Xyfj9I1PDMIAJ4j
-6Ysm4A7vidqast/lbQ82WEy68gCeN6Edwm8GttOsqHbI98LYMQ9aIAOIRgQQEQIA
-BgUCO7EVnwAKCRBn2bOMCRwxhzkeAJ0aRutcMPoywIRtM+cSDgBFtpyP7ACgz/Q7
-VDZq9tNtnUVODuzQ9BbNFZGIRgQQEQIABgUCO/Hq/wAKCRBojqAxWqujDBYMAJ9e
-4nWFjVYSK3NXt+XYG5ByewNKPACePp/Yd8ui91ViuNSbhHiwCAyYli6IRgQQEQIA
-BgUCPB8wXQAKCRBqRzoxcSFero3PAKDzhIRGCfFfnuvcPTJs63q2rTiYmgCfS6Ct
-YOMQyaYbjsCA2uNKod1h8wmIRgQQEQIABgUCO/MZBgAKCRB8MVegZEc1dpe6AJ9o
-nHdaU9zxdk10LVzDS8iQfJIl3wCgkQ3PHxJACbWq550Nuu6GLcyB6JOIRgQQEQIA
-BgUCPHSv2gAKCRCMnNnnGBSTGUrmAJwOG7kZGIUFwcEnd3RtUE6QXy/eUwCgluH6
-J77g/pyyki767QxcWkSEXOmIRgQQEQIABgUCOyiObQAKCRCPrQIss6QEWVYBAKDO
-++09sRU/5u3rlpMuUo9F4bzKbgCePw6JPtErRjAt8zfk8maUM0inwheIRgQQEQIA
-BgUCPC6hGwAKCRCQ3qzudismmon3AJ0RJDe8fCYq0Sv4Q+23UZqFBkSwRgCgx/Mc
-nOoHqTP5NdOWpZiekDuO2kKJASAEEAEBAAoFAjqkA6MDBQF4AAoJEJ7v5Ejutjqx
-+WYH/RIGqKU1KjIonGFv6l6f+YLuiP83imKXSOHVd5r/Wu1fOhodGOkbIvCPhwgq
-+xwnjNsbFNTC8KshWIaTjtz77Sgu4qp0aQzQt5ebmJliB6YN45Tq/7SdZZKP1OTk
-GUFcyl2GafjRp71uHvD+eqtXTxTKfee5Dlh6vi+ha6ouBybMdB9B0OYzhU2Xi0Dm
-GqtcnDDavGostWCvtzFtKEtg4yzu2tR8nUgV5kMCz3osglgr7d8WQ+aZxgMOblFf
-gcCRELeBWh4zjEh9wrH/7KMcr6REiXgp0YTpm18JH+UKbvsL05sJgvnJEoDncP8P
-G4IkMR0JN8KRcYhZ8E2SNV6Rn/mISgQQEQIACgUCO8+CVwMFAXgACgkQp22qG2je
-6vanXQCg+p5+GfFkymKzjUML9zip1f2dVEUAni4ysdlyH3A3oxKV7RWyXj1PgCGO
-iEUEEBECAAYFAjtUcBcACgkQp4aCct/T12ngEACXYfv/a7NuPFA3zpRUc0QpWCv3
-LQCfd/aNbpLY3QNAGdWIrLsKTKF9IEmIRQQQEQIABgUCOt/u9QAKCRCsdttzJR81
-wWSNAKDFrGzAtuKoODKe6DDKx+sOoBL/MgCYi3X66YcHE5oExf+99xwTmzMsEIhG
-BBARAgAGBQI8C8rhAAoJELSC37AZpFlD+bUAoPXlGhIUXF6mARtpxetRaG7fO8Vm
-AJ96IIXSJfps2fO3AUS38An/8PdmLIhGBBARAgAGBQI7zcfhAAoJEL01r7GgoJ3c
-vXkAoN5CbbjJXjI5byD1iis9G+H0cCMFAJ9Mqk1scRTGFajVipyjoC61eLoEJ4hG
-BBARAgAGBQI7FfJNAAoJEMR6qYKMZW0Ott4An1qoDfLV3fUHFeDlpP9OtxYLXV2c
-AKCNMkaY04vqNNIvJy0c/nnsrog7GIhGBBARAgAGBQI7ztdAAAoJEMS3xe6ePjec
-bb8AnA6N6qCXWvfqxZTWW8i31bnm5gMYAJwLDIRUW00lahMf3L/84nrZmHx5HIhG
-BBARAgAGBQI7wo3iAAoJEMZN/hnNBj2mK0MAoONXqgCWmOwY1kuCKmMYcpXHCjgw
-AKC0hG5DBo0EcCSQ9xuXN2OySrGyGYhMBBARAgAMBQI7yJIHBQMB4TOAAAoJEMtT
-PRy1z8BdctkAoKLJRxjLZ02ddy73NoMS3PwTU8HEAJ9xPD9OTf3NctADtorKsf0y
-dCyvcYhGBBARAgAGBQI76umKAAoJENDQZPuFwYBQPikAoMzuIMloKscZ6GTuEx83
-WSozA7KIAKCDgWXCiaxSEhsJOvOLdu1C525f6IhGBBARAgAGBQI8BunhAAoJENEG
-RJeBUhtCpPEAnRqnpqhWbQUGExxxlJqawSqPqA1cAJ4pRGh/F+3ALSFrH3SYv84u
-MmcuHIicBBABAQAGBQI6ektkAAoJENEdYC5Hk8UppFYEAJI0VWk6aMSh4r1vT4sQ
-ZZNnszlsPiXq9HFts1o0GK0BBNgN7PRcVxQYXroDajSlUGhr3pBmx8LzIS1VQcIk
-GS5aMHed+UifhhdIbWDrPz4driXOQnAcB+isMeRfw1tf+5Quyp1BhrYyzSerwN3D
-wZC80Uq066Bhok9bQw/Onwr2iEYEEBECAAYFAjuzGgEACgkQ1LqD795zV/I43ACg
-xwwecFuPr1I4wAawRXPTvz+2iLcAnjqju6l6jGS42flmgIQhYR8IbbpOiEYEEBEC
-AAYFAjuzZNQACgkQ5hUbwVnPhdbNIwCgiR88Ff9WiqZu03JUD8xg1eABomMAoMrm
-WytXRamVMAgfKd/hIFBY76DEiEYEEBECAAYFAjqqoAMACgkQ7tDfcL9n0utnlACe
-IB7BHKg9ajYIyf61OCLETHioqAsAmwXzodEuj1Vmkanes5VwctoPzUM7iEYEEBEC
-AAYFAjvaGf0ACgkQ+8k1yjhw7+0uAgCaAztlqJo9gtpS9BfZnuQb/bK5IKUAnjLo
-TJE+INlQq0PbMPFGvhS1aGn0tCJQaGlsaXAgUi4gWmltbWVybWFubiA8cHJ6QGFj
-bS5vcmc+iEYEEBECAAYFAjpU6LcACgkQx0Y2ObLXeV4TyQCg5ii9gHqOjlsHGSsq
-kliw+Ha0MX4AoLie5O1xLkK/rS9J3aIp9EUkE5AhiEYEEBECAAYFAjpU6WkACgkQ
-Y8tpHfrr1fykfgCeLP0tqVZ8D9lU2EVrKZkdauwst50AoIQsSo6PBhfNwwb5zDLK
-O/PGftGhiEYEEBECAAYFAjpXKUkACgkQ14y85WanSzGqnQCePrJJrLngH0MDYrDU
-qrK1ju2/BHUAnieEItKJUoN9FXzacVsEFW1D0UwQiD8DBRA6WP4q8CBzV/QUlSsR
-Ap0RAJwPSxTAIb6M1TM8LSNgnvYigYZXwwCfZzVNckHKo7WtpZ1lWN+4W80eKJyI
-RgQQEQIABgUCOlrmuwAKCRBnkE+tCnkWEOpjAKDeibXDKCIMiNZafH0nzDD/CRU+
-pACglr+BhEKX68HeW4QnooPxoFwlviKIRgQQEQIABgUCOleFogAKCRCsuxZLz3Ps
-TDo9AJ97srZSNDeiQUHoiGsETRMKG6Uf+ACgwsiJIzN2rVgvAgCfq89g/efv8hTR
-zNf/AAANkgEQAAEBAAAAAAAAAAAAAAAA/9j/4AAQSkZJRgABAQAAAQABAAD/2wBD
-AAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEEx
-NDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7
-Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAHUD
-ASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
-AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAk
-M2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlq
-c3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
-x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEB
-AQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
-BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5
-OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaX
-mJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq
-8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiiigAooooAKyNb8S6boUZN1Lulx8sS/
-eP8Ah+NZXjbxcdCt/sdjh7+UdcjES+p968fvLyW6leaa4mmlY5kkL4AP1qXLsaQh
-fVnc6l8TdSncrYRRW6Zx03t/L+lYsvjjXnA8zUZY8nI2kr/QVzlu0b8+S2R/HvJN
-WFgAYuwDFuvJ/lzms2/M2UbdDrLPxlrETK51CRxn7sm1gfzrs9F8b2d8ix3v+jyn
-+Ij5T/hXkQj8gZX5hnlCMZq9YShm8vzDt7HuDQm0KUUz3ZHWRQ6MGU9CDkGnV5VZ
-6xf6FJ5qTlY8/Mh5Vh9K77QNfi1uEkJskUZI7EeorRSuYyjY16KKKogKKKKACiii
-gArO17VU0XR575sFkXCKf4mPQVo1wHxXvfJ0yztw+N8hdh3IHA/nSew4q7PNdT1G
-a9vpLi4kaaaRyWY8KDRYWCXkuG5Qc+gzWe8mWAUYz19TW9pbGJAScZ6msJuyO2nG
-7NOPTrcxhAMdOmOKp3eg36OWsw0qY4x2rVgkynIyfrite0bKDBrBNo3aOOtvDWr3
-dwPPjEKDOS1dJbeFJYY/3UqKxGC5TJ/Wt+Fdx4HNaMUSlM9yK1TbMJ2RwWo+GtXe
-MiaZLlByCo2mpvCOpTaDrKpdEmA/KxIwVz612rR4PPWue13T4RcwXBUBWYI5A6Z6
-GmpNMmyasejghgCDkHkGlrD8J3ck+lfZ5m3SWreXu/vL/Cfy/lW5XQnc5GrMKKKK
-YgooooAK8j+LF4ZNchtmACQQjGDySefy6V6jqeowaVp099cnEcK7j7+grwXxjq1x
-r2ovqYRUV8DaCTtA7VMmtjWnBv3jMgjM0wAUnFbcCtHGFHOevtUek2RisUmkwS3O
-4HIqeWTaP3e0HPzMemfwrmk7s7oWSuatk7BQG71v28OFUpjHt2rj7XWreH91NLGW
-PQ7W/qK6bTdYs5IgFuI8njGajlsPmubtrmMGVuAo5q7GxWMcZBH51nmVDaIqMpEr
-DJB7VcWf98Y+wXg9jVowlqTtIpGP6Vj+KNv/AAj1y4xuUAr9cjFajHnHWsvxG6DS
-ij8h3H6c0yUW/Aju/n7xg7Rn6gkV2Fc14Lg22MszD53IBPf1rpa6I7HNLcKKKKok
-KKKKAOQ+JchHhuOIMR5twufoATXkjOkjqqAHLYAzxXq3xLikl0uzKAkCYg49SvFe
-YR2htbqKJyN3JODnNc837zO6l/DSNOLeijyuy7cEZzVG50jUbsmWKTamTny1GRzV
-4TAPtUZ+la2nyJbBWmZogScBhgfnWN7G9jmrfR7/AM7ZJdq8GDw8Suf6VRtXubfU
-FjMZR8jATjP0r0jfbMM7ULHvgVyl3BFPreICruTglTwvPr60+buKK1NeKe5S3W5l
-iaNmHBTgKfU//WpJ/E13bYVJxM+MnEYyK25LKNtPtkPCK4U/TNYF94IinuWfcUVj
-uDxnBBpITa7GppvitLnalxZzRseN6pkE/TtUviOVbmC0jhdSGk+b26VlGz1PSpkE
-Vz9sthgGN/vr7hq6PT7Qajq9os4ZI0BfYB1AOcH/AD3rSOrsYzVlc6bQrZrXR4Ed
-drldzD3P+RWjRRXUcQUUUUAFFFFAGN4r06bU9Blhtl3TIQ6qOrY7D8K8fvraW31J
-VmR0ZQPlYYI/Cvea8q+IVi0PiFrgnImjBUY/P+VZTj1OijP7JyP2n/SMnPB9eldX
-pV/5kIRsbfQ9K4yTMbhmyMnvUg1FoGYyI4THAXoPT+dYONztckkb2v69ZwSJa29q
-gLf6ybYPlHt7+9Q6JdWA1NWgYBMdBXOzTf2id0aFg3anW+l3Fkv2tmcL1A/wo5VY
-Sl9x6+ghnswgcEOOcdvemWs7zQHgSMjFGK+oNcZpd/Kl5Ct1JMIVAOA+M/WtGzu1
-0nXHWObdbXZ8xCT3PVTSuRyHTymN1QeUSwYcba1dHt1W5Z2xvVOg9z/9YVmC583G
-OM9BWtoTectzN/CZNi+4H/661p2uc9S6ia1FFFdBzBRRRQAUUVi6x4v0HQwft2ox
-K4/5ZodzfkOn40AbVcX8SrHdo6akg+e2ba2P7p/+v/OsDVvjhYws0elaZLO3Z5m2
-g/gM/wA6525+I+t+IQ+n3ywQ290rDy0jwQMZHJOetS9jSKdzm7i+USAlhkZ56Dr1
-rd0vy5o9r4cuvzcg54rjLzNvcFMY55xW3od8FKx4GR8zMemazlG6N4zfMap02KC6
-bEcTJ6Nx+tbumPYyRrb/AL+Jc/dBEig+wYcU20FtqSguuMcZ7mtCx8PrDMZGkJVG
-yB/Kuf1Oly7Ej6XcyebgQ3IZTtdl2OD26cViw2lxeSrayYTyzklTnbg9veun1LUU
-021IDb5Dwi+vvXOaVfIJZJN4LF8YHuadmTzHTqZEt/3eTIFwg7lu1dnpdn9g06K3
-7gZb6nrXn0mvWujeVqOoI8ltG6/LHyS3b/Gu20TxRo3iCMNp16kj4yYm+Vx/wE10
-U1ZHJWd3oa9FFFamAUUUUAeF+KPijqurI0Fq32K3PaJvmP1avPbi5kuZCWJOTyfW
-mzOzNinwxBRuPXtSNCe3hSIBiMv/ACp1vcbdThkbp5gz9KYzEL9agcE7vXND1Hex
-s6raecSVA3jkZ71nWdy1qWjkG3sQRWlBdi8tQ+cuvyuPcVFMsc3yyrz2P/16yi2t
-GdE4p+8jWsfEMNsU3H7vf+92rdt/FyiI4Zcnt6GvPmsyv3HB46k4zUiQTRKF3gAH
-Od3ehwi9SVOSVrHT6nrjzSYMgJUjknOKgsZnS4MrMVRerY/zk1mafAly2W3SAclg
-NoNWPNaW+kUDbFF8qovQHufr/hVqFkTzXNG+v3v5T5oxGq4WM9AKxlMlheCS1leN
-kO5CrYI59a0XOPvAfX1rN1OPPIB5TB+lUSekeF/ipNEqWutKbhBwJ1Hzj6jv/nrX
-pWnaxp2rRCSxu4pwRnCtyPqOor5ht5G3Dca2bW+mtXEkEzxsDkMuQaCeVM+kqK8W
-sPiPr1rB5bXImx0MqbiPxoouTyM80jh8xyxHyg1KVx1qxEEeNfK5FI6euKZViq5I
-FJDGZA+Occ0sik9BVaYMqZUkFecjjFIksQtJZT7+iEjcPSt63W1mUNIRjFc9ZXhu
-D5FwQSwwre/oa3raW3+xlGwWPr1FRUj1RtSl0GmW1jdlWCNz2Y/40yCBNQZijq0a
-NtKp/X/P51nXk4RJdqYBPJJHJq74a2x6XM4I3NJyM46f5NaQgkyZVG9DRv7hNPsW
-8pQP4VA7k/8A66g06Hy7dcnJbkk9yetU9TZpr+KHnKfO2fXoK0LYqYh1x6ZqpPUm
-JKy45z+XaqV8AUQ89x06VeccHA6896rXSbrZj3Ug1JRjYKsQfXrVxX+Xg+4qCVQQ
-D0NOhJYcdTSEtGWVkIyFU/gtFJGEywbA568c0UFmUomil/dAtk9B3q/nzBjHTqKW
-BVjIPU45NMPDn3pkLQY6jBwRxTIoxJIE7HjmpW4/OmQcXC+maBdTG2FHdckFDxWp
-p7yyyu+eMcD/AGj3qpdLsvpAMdTWxpkQjsVfpn5j+NVFXZCIL6N5YhG5GeWA6laT
-w/c+TJLYy4Al5TI/iHb8v5VYlwblAW6qMZ9c1mztgSleCzAKR26c1T0dwL1sDNPN
-Oed7HafYcCr8MnlSAZwrdSfWobSLZCij0xRLlXHHDVBojSLZGSTz29KYFDK6nncM
-VHbTCSMqx+739RUJvWz+5A4/jbp+VIZSnGFOAOKbC3zZzjr0pbjvnkk9qihyZAB3
-4oFfU0IEO05BH9f0oq1hIkXIySKKBn//2YhGBBARAgAGBQI8ZiQyAAoJEMdGNjmy
-13leJSIAoIx0Ql/m4Gf4ZZeFQ1Of+zq6499DAKCHBzmIEtE740kuUl5HGNvCJ4Qb
-MIhGBBARAgAGBQI8ZiXuAAoJEGPLaR3669X8OzwAoKHGtOZfI1nc4NEGzRLorYzu
-HN2YAKC6koYnTdhlsiEOJxiaUxTGi+Vv4rkDDQQ6VOgnEAwAzB13VyQ4SuLE8OiO
-E2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ngw+Po1gr9oSgmC66p
-rrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkItAjbBJstoXp18mAkK
-jX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF6PlTETlPtvFuuUs4
-INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ+PVZX9x2Uk89PY3b
-zpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarTW56NoKVyOtQa8L9G
-AFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPwpVsYjY67
-VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6ypUM
-2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpTDJvAAICDACNUV4K2PS6
-h574Z3NaBsIQe5jkVO48MSohjC6s29CjPhlU79cQIYWmBpuNfwroZ6zltyz6Y2Fm
-65V0IfvVicR7zvFFCOhahMuk1cr+Qp936OMEq9sLZGxTjClgwrHGS7YpMSZrEC7b
-pOmERjo4F/n5YmCHJCH8QzCOc9+80gjVEsHiJVABrC8yykjKL5x1V/PSArE4QtML
-bkBPGmQYOw8bx6jCHoO43QjUzbqRfBMHZqWVJyoIIZCp+n13XM4+NO/cDVsZ8bjc
-h0LIOyMrT85n24yfXRlP0s7BFjLm59Jjhf4djuJWikJawWETlypAy86OYRRuwCbI
-yNauBeTKy+avZvF2oLvpwH4UnudpC06/O0jkj2lQpn9EEUw11RwO6sq9zYTwAUyK
-erN00cbCfyiZl01CIo0btcTO6hQK3c67PaloJ9lVH8/mH7LuqkMLDH5ugkpzmed/
-8SorfqVkakne6b4mRySFCBXaVZoKmDHzcH2oSSMhM9exyh6dzi1bGu6ITAQYEQIA
-DAUCOlToJwUbDAAAAAAKCRDHRjY5std5XuVtAKD4358jdvOoX358HnQnmwUdUczu
-FgCfT70B8OXmdyevgPtF4wOVighnBFGZAaIENaIeHhEEAP6XSuDmn2tbgzewq+Z7
-LOGzaYPGFEoNNVVSdPCkwhHaQgD2lPjc2j9yg9qMO+FlNoMz+9LPbkhkNlYnuAS7
-zpGmgR22v94rwa4NyCxa8Wzn5ikIPBYbZ3Hf0wTsM35JG8QTXFSbgT0bY2d3ZQ20
-uCDzbCCL9krgiH0JgPKjRr1rAKCKyfdG9n8xEQmZCrX5KMmAPH5zawQA4SfEZiKy
-ogpw5N085NOJ7ujvH6d6ba5pzu45brw37BFbGEY8jGw5254whrtT3haD9h2fh/Za
-eAmkG8o1odiZbyPVDnO9ldekhZFdK/JNHrjUFx4Yc11iJH8+IMEmwZDdpzufunCF
-Xip7HchWJEMlbPkPOvzzH46O7rcq3Fi6tQgEAKLt3WtSUeviiTuIFGVYdhdTaGlQ
-hDwL5Q4TVddP4cHuZktJE41CdYzJeepsABb4RRRfbGlvngJ68CDh46KW3R6zwZky
-ZTpzTB1SycxZao4ocEUWUMi/Ijbtpn2q5/TK9vLreQUJqdApzRCeoZdArO5dsWoF
-hbZRCtiCNeOLyt3xtCdXZXJuZXIgS29jaCAoZ251cGcgc2lnKSA8ZGQ5am5AZ251
-Lm9yZz6IXQQTEQIAHQUCNlWgpgUJCG0MiAMLBAMFFQMCBgEDFgIBAheAAAoJEGi3
-q4lXVI3NLj4AoId15gcyYpBX2YLtEQTlXPp3mtEGAJ9UxzJE/t3EHCHK2bAIOkBw
-IW8ItIkBXwMFEDWiHkMDbxG4/z6qCxADYzIFHR6I9Si9gzPQNRcFs2znrTp5pV5M
-k6f1aqRgZxL3E4qUZ3xePQhwAo3fSy3kCwLmFGqvzautSMHn8K5V1u+T5CSHqLFY
-Kqj5FGtuB/xwoKDXH6UOP0+l5IP8H1RTjme3Fhqahec+zPG3NT57vc2Ru2t6PmuA
-wry2BMuSFMBs7wzXkyC3DbI54MV+IKPjHMORivK8uI8jmna9hdNVyBifCk1GcxkH
-BSCFvU8xJePsA/Q//zCelvrnrIiMfY4CQTmKzke9MSzbAZQIRddgrGAsiX1tE8Z3
-YMd8lDpuujHLVEdWZo6s54OJuynHrtFFObdapu0uIrT+dEXSASMUbEuNCLL3aCnr
-EtGJCwxB2TPQvCCvR2BKzol6MGWxA+nmddeQib2r+GXoKXLdnHcpsAjA7lkXk3IF
-yJ7MLFK6uDrjGbGJs2FKSduUjS/Ib4hGBBARAgAGBQI1oic8AAoJEGx+4bhiHMAT
-ftYAn1fOaKDUOt+dS38rB+CJ2Q+iElWJAKDRPpp8q5GylbM8DPlMpClWN3TYqYhG
-BBARAgAGBQI27U5sAAoJEF3iSZZbA1iiarYAn35qU3ZOlVECELE/3V6q98Q30eAa
-AKCtO+lacH0Qq1E6v4BP/9y6MoLIhohGBBARAgAGBQI5TM2WAAoJEAJx6COq/B+4
-jTYAnjOMlKc5tuqspHgAUgAVmBda5XNGAKCIqZ3Fu33suLyRABGZ+tN3tJ1QZ4hG
-BBARAgAGBQI1pysWAAoJEAQ1xdJF3KZpeMoAmwZEvOS95jEKj/HnbFBDDp5C4dw0
-AJ4nsZgDnGDAG7FCEJI6+LoIIUit44hGBBARAgAGBQI26PrdAAoJEAcDKpaJBMji
-EpgAoM3IisrN7XXdhnP9lmx0UJKE7SsFAJwMWIBnGK93ojuWXh9YgDRySZKZqIhG
-BBARAgAGBQI7JUB0AAoJEB3TgN9DaBQASVsAn28snlWv8ljqxPsS2e7xqJxzND3G
-AKCsObLMGdGyED2YKlu0sSa4E7cE+4hGBBARAgAGBQI6xKZNAAoJECAsPjFYbhLl
-DsgAn0tfgJSaxWUd5s0ZGmKob7b84onEAKC15V+DRTrE1tArKxy/itSNiMtQG4hG
-BDARAgAGBQI4no7wAAoJECShvswraT6/w8oAn0XLPn0F4s9wQ4pGXNPCm7MJ6E5z
-AJ9CbanRlaKAXoD1LP5bmADGkRBqfYhGBBARAgAGBQI4vt9pAAoJEC5ArMtkcKsm
-HDkAoL3TIizomIuEKO6vwHMFcFndsaAaAKCJAkq+I2mjYimFE7ajlaL0jyecGohM
-BBARAgAMBQI6IYGCBQMD7eiAAAoJEDJKcxqmfO/9aXgAoOumahVFuBTuZsv5ma2x
-G3dVPZczAKC1viEIhAakthEb+Pi0SRyeK7cqqYhGBBARAgAGBQI5zA88AAoJEDLD
-W4BHupNX9vwAn1ZRUYyIWV5XoRUIq7Epz1id+hDVAKDMZSo15h9vfGAjrytpxOs5
-clW+G4hGBBARAgAGBQI5bedgAAoJEDLGkzuo7SAfxjMAn2I7CSRyEz8mkaD3emaM
-1WYxvbb5AKCFOlNjoxNmu3SSWfgrW1EESYPQY4hGBBARAgAGBQI4q/0WAAoJEDW6
-YX9GCEVakzQAmgNaF00/D/eOgHmtLEjE0IH1H2yUAJ9EKs47I9s8U7IYJOGoQRy7
-LD1JRYhGBBARAgAGBQI7ScU3AAoJEDeckqFodBLoiG0AoItVFw4742i3VVL75rHp
-S/iRTyXXAJ46OJxgMvJ9knQ0l4so5JiBotS/8IkAdQMFMDifLTk7IqtjPG8o8QEB
-gOEDAJEaFnJ11GJlMpSIkxT4kU1DpXJGc+w5vhX8xjqjTlkbCS1AeryM2FGz/wPK
-DjHtG97Ybptmeigrx5ZZ9O/wp96sTYpKiKk93YRyzPOtJ4GhahMR48LBu6YnHppJ
-nxCyg4hGBBARAgAGBQI4XUq+AAoJEEPM0G/dqdt2qekAoN1HvYZQ6AxvNVLx3M06
-s/ytk21NAKDNn0RgGyCBiyQeLuV3Gkuqxke7kIhGBBARAgAGBQI5Zs0MAAoJEEcW
-KRmClXtmuPEAoJe7siEXNYVflP+Glf71M2xvkSa3AKCerd0dwvhmi4Ao4ujBnuZI
-4YUIhIkBFQMFEDfZA2RNwxExOP7mwwEByhEH/2zbTPiXuaff02Xj7QqSIwjo0O47
-sgxNHbuUMJB7pvD0q8g/T+jX0ux6Ci16m42aOUjp254G33RN679BdjiHG47DOric
-TvdLq9uWtqg+irQosJen+e0pIsFTfmj1zA1G8rrbADqVCEz4SpibDLB5wXDhVdqa
-R3sAteIAZti1xoTiFc12KrarkLn+BaWUtvBbi93bsD+ySTE/kIeeCGLW9IEHok8d
-id1QMWXNM2VuzSdKSoxaiuJOkuZ2Aui0HAdEycY5fhOqIo4B/rtxGpdBXBBCxNi+
-VRaq0CWn13BiII2BvNOmCn879R89qMxuj10X3RnRQIHgj4mg/X7zni684FOIRgQQ
-EQIABgUCOQ0ojwAKCRBS/u9nIH5xmceVAJ9VIlMfbC6Gni3jLXZs7VEX5NWQCQCg
-id47hulygTIy5ePkpgjOO1ZDP/aIRgQQEQIABgUCO1X9UgAKCRBW05T8JNULxIz6
-AJ9tUSb17Etq+1C6V7YiiHCt//vY2ACgt6hl1q6z2ZhSgJLBV6N6wss0GWGIRgQQ
-EQIABgUCOJj9UAAKCRBl3EK31OWAJovMAJ4oWYv+ThvQp8zMdVCnbQQL77eLdgCf
-ZV/ownqDt0xfEMpHTF0hSHQxy96IRgQQEQIABgUCOpP0TgAKCRBpwYMr+Tra7NWk
-AKDQEafW/9gKnUNFINJqEkYUXsYlLgCZAcGWOePrrM7PEOz/h03kqllYt86IRgQQ
-EQIABgUCOFjPGgAKCRBxLQsX0D2KT22cAJ0a+519NvXqtRND7/RcEK4LN2bvpwCe
-LNuUSotPPf2r7FVap5vO3oAMwdmIRgQQEQIABgUCOGDD6AAKCRBxRvDjMHApSKW9
-AJ9R/bMcCRef9myi9B2bC1zuN2qtbACfc+1NHDhmDSK0TaR5Seu2TyV9LceIRgQQ
-EQIABgUCOUbNKQAKCRB/4u1e9RQ7Ki5KAJ4r4dNSN7kLq1nOW52+309RiDpn8gCc
-DhPygqyVfPUZKOtVwvttHZcysxqIRgQQEQIABgUCOPN6JwAKCRCEP1fXrLWNT4SW
-AJ9IRICEmPNdhoYWUc7hP7HOUVhHfgCfUsR4bR9KCTaynBmKvAKA/ciTBh6IRgQQ
-EQIABgUCNacrcQAKCRCE5PiUAeWZaBjoAJ41XKqKVxMjGBGXxffEkyprrSj4igCf
-cR5sWVtyrVUk0X/yE0jUrP9IApSIRgQQEQIABgUCOnNH4AAKCRCI98SPIjWV9R3S
-AJwLoPyJ8dzW1f2ubzYBEkkHN41p9QCeKbvAZQNRcsMKTJCAuhlwFnh7KGqJARUD
-BRA21moYjl8DByup3WkBAZ0tB/9v5kOKdh7rwDaPHFLxvG7flsD8XOvMM/LH0uAx
-smUebXYwIRWDziZqDmFHpnzTt5LM7nyaPJjggfSCmlLKtx5ZgIgXM9D7WrwPRgcX
-g3SHbuKbXTeiSQRP8goMeADlQFd+sX8l40mwKF9klQXR7/02CT+LM5A/KnXM4mqQ
-1cjFLiCwhx2G+Rsx4PEDTDoBL3W6ME/pxIzn0NJuhp9oDVvKuWmKtwKPWSHRj8CR
-56OBxeZG+sPK3UySM/ZEdEL0iEZvgYRwpf/t8vnS8/Li/M6pem6FnwLalQwv/vMF
-FQvBiHJqRJ1VxsdHVDMbap1LO7A2QGghPkeDnAN4jyCsqXVtiEYEEBECAAYFAjt4
-2yAACgkQj8C3jQmzMQbrmgCfeBACKTFlOsTcbhhlvIjZJ9ZUT10An0NHUHnoktA4
-GMdxW5vR+t1uhGcWiEYEEBECAAYFAjbWagEACgkQkrJ6leQEE6q4FwCg2WMRtIdc
-wsfnj8ngeK0CyIjXxqYAoOsMufELOYL7yb85M27iZlqZ48/eiEYEEBECAAYFAjnK
-lgsACgkQnznd8F4pxsIVuACfc+MHLblJgJcI5Z42D4d5ufs+LsYAoMq1/GdeKCtx
-028BGZm1Yc0zO8cwiEYEEBECAAYFAjnPNIIACgkQpll1bT9NtmnSywCfWpns8kIg
-d/oStQbXXVzltaMJtbcAoL/cJ/9k1kraYpk6Z8IJGf2wEGVFiEYEEBECAAYFAjqW
-fQEACgkQq79czSEmG4giGACg/qNL4huhd12Jyya3qTJeFYFgMm0AoOWNXs1CepYM
-GZ1HNhbcJiH+G8/IiEYEEBECAAYFAjoZ9rYACgkQvhpT6zI73uZHuQCeNJfhA/uB
-HrHUFhMILz27aBJcBC0An2dF4AKA1T8P5MuqKaUxL1OqdPJkiEYEEBECAAYFAjmS
-plwACgkQx+D2lKJNi05V5QCgxOAE1SMP4BhATMhTXNiSJbU2BmEAoNbcbOwM+rOz
-ecX6aQyeCBg8WcSeiEYEEBECAAYFAjfZA0MACgkQzTbgIX48jquOOQCgqjyYGNri
-U4Zb6aKW4GHcuJNoM0kAoNCupziSR9pBxWVeMNVhVp6XvigmiEYEEBECAAYFAjm0
-32EACgkQ0Y4PDnuqkPpwSQCgubij+epzZINnZ4qvmFgNNR9YGUIAn2Dwom8wzr7/
-W0Q9qiUz+FVYoHHqiEYEEBECAAYFAjgmg+4ACgkQ1eiHQ5R2ErMIAwCdF+TWZ/T7
-KJR0y5IQ2EoxfLKxnawAoK8xJ0QSYaiZYKCxB8tYzMItHv7liEYEEBECAAYFAjfX
-jLIACgkQ1rb6S4yOnyPYrACgr35M5uneN/5PCc9Uh9caSYdJtwwAoOjzOz6KwrKd
-c4wXaDnRJNnBpZMdiEYEEBECAAYFAjpCNWEACgkQ30kDp8mywsCuGACgw405ZqhW
-MrgNewU0gPllz+S9V68AoLer9gdEcr3aHhxZxmZpjsRy4w/tiEYEEBECAAYFAjrO
-IywACgkQ4HkONspwutzZoQCdHVZOvgnh2kW4229FOwRdtVybZGUAoOhlsIEL0j5W
-4YJCGQrhd7vxuo0viEYEEBECAAYFAjnzJCIACgkQ5jU8OLhSiwGGrwCg304/n0hg
-n41Bgmal2jI8WAmK098Ani2W7uoOHSWlBQEkoisKMbSh3jIhiEYEEBECAAYFAjqQ
-EYkACgkQ86QzvnxWxe/4rwCfSXD8N6MhMzfKqZ6b6X/kag/dS/QAn2QM9U4dCrUl
-8kOTdZbP+NC+Hcx0iEYEEBECAAYFAjnND5cACgkQ93111w6M5IHPxgCfZrmMKTTn
-ZT5+uv6wVFDUyoqavEoAn0nvU51E1kt5+QPuKEnZiZyjwayniEYEEBECAAYFAjqe
-VPUACgkQ+qVJWkKzL8lzvACfXa4hgEv1Z+GZLZKHQ76Yg7aPnzQAn2cm8G7PirTu
-WSANQVUlCWu4PUh8
-=9VIS
------END PGP PUBLIC KEY BLOCK-----