Update head to match stable 1.0

20 files changed, 6221 insertions, 532 deletions

diff --git a/doc/ChangeLog b/doc/ChangeLog
index b83adc839..1832da00a 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,27 +1,365 @@
-Tue Oct 26 14:10:21 CEST 1999  Werner Koch  <wk@gnupg.de>
+2002-06-21  David Shaw  <dshaw@jabberwocky.com>
 
-	* Makefile.am (SUBDIRS): Removed gph from this development series
+	* 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>
@@ -30,7 +368,20 @@ Mon May 31 19:41:10 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
 
 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
index a06b5888e..9170d5b93 100644
--- a/doc/DETAILS
+++ b/doc/DETAILS
@@ -1,23 +1,47 @@
 
-Format of "---with-colons" listings
-===================================
+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.
 
-sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
-ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
 
  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
@@ -33,21 +57,51 @@ ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
 		       17 = DSA (sometimes called DH, sign only)
 		       20 = ElGamal (sign and encrypt)
 	    (for other id's see include/cipher.h)
- 5. Field:  KeyID
+ 5. Field:  KeyID either of 
  6. Field:  Creation Date (in UTC)
  7. Field:  Key expiration date or empty if none.
- 8. Field:  Local ID: record number of the dir record in the trustdb.
-	    This value is only valid as long as the trustdb is not
-	    deleted. You can use "#<local-id> as the user id when
-	    specifying a key. This is needed because keyids may not be
-	    unique - a program may use this number to access keys later.
+ 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").
-
-More fields may be added later.
+            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:
@@ -55,7 +109,7 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB:
     !  !------ 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
 ==================================
@@ -66,10 +120,26 @@ more arguments in future versions.
 
 
     GOODSIG	<long keyid>  <username>
-	The signature with the keyid is good.
+	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>
@@ -80,11 +150,14 @@ more arguments in future versions.
 	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 ere emitted for a good signature.
+	status lines are emitted for a good signature.
 	sig-timestamp is the signature creation time in seconds after
-	the epoch.
+	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
@@ -107,34 +180,51 @@ more arguments in future versions.
 	    3 - Invalid packet found, this may indicate a non OpenPGP message.
 	You may see more than one of these status lines.
 
-    TRUST_UNDEFINED
-    TRUST_NEVER
+    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.  No arguments yet.
+	to indicate how trustworthy the signature is.  The error token
+        values are currently only emiited by gpgsm.
 
     SIGEXPIRED
-	The signature key has expired.	No arguments yet.
+	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 his owner.  No arguments yet.
+	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 RSA or IDEA algorithms has been used in the data.  A
+	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.
+	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
 
-    NEED_PASSPHRASE <long keyid>  <keytype>  <keylength>
+    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
@@ -149,7 +239,7 @@ more arguments in future versions.
 	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
-	PAD_PASSPHRASE.
+	BAD_PASSPHRASE.
 
     BAD_PASSPHRASE <long keyid>
 	The supplied passphrase was wrong or not given.  In the latter case
@@ -177,7 +267,7 @@ more arguments in future versions.
     IMPORTED   <long keyid>  <username>
 	The keyid and name of the signature just imported
 
-    IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
+    IMPORT_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
 	<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
 	Final statistics on import process (this is one long line)
 
@@ -185,11 +275,108 @@ more arguments in future versions.
 	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
+
+    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>
+        A key has been created
+            type: 'B' = primary and subkey
+                  'P' = primary
+                  'S' = subkey
+
+    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"
+
+    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
 ==============
@@ -222,6 +409,121 @@ Key generation
     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 -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 Tester (with stupid passphrase) <joe@foo.bar>
+ssb  1024g/8F70E2C0 2000-03-09
+
+
 
 Layout of the TrustDB
 =====================
@@ -230,6 +532,8 @@ 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.
@@ -259,7 +563,7 @@ the DB is always of type 1 and this is the only record of this type.
      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.
-     4 bytes reserved for version extension record
+     1 u32  record number of the trusthashtbale
 
 
   Record type 2: (directory record)
@@ -316,7 +620,7 @@ the DB is always of type 1 and this is the only record of this type.
 
   Record type 5: (pref record)
   --------------
-    Informations about preferences
+    This record type is not anymore used.
 
      1 byte value 5
      1 byte   reserved
@@ -339,16 +643,16 @@ the DB is always of type 1 and this is the only record of this type.
      1 u32    next   next sigrec of this uid or 0 to indicate the
 		     last sigrec.
      6 times
-	1 u32  Local_id of signators dir or shadow dir record
+	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 my be revoked)
+			 1 = valid is set (but may be revoked)
 
 
 
   Record type 8: (shadow directory record)
   --------------
-    This record is used to reserved a LID for a public key.  We
+    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
@@ -477,7 +781,7 @@ There is one enhancement used with the old style packet headers:
 +  future extensions. These length markers must be inserted into the data
 +  stream just before writing the data out.
 +
-+  This 2 byte filed is large enough, because the application must buffer
++  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
@@ -485,10 +789,19 @@ There is one enhancement used with the old style packet headers:
 +  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 it's fingerprint, other records
-    are used for secondary keys.  fingerprints are always 20 bytes
+    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.
@@ -508,6 +821,41 @@ Usage of gdbm files for keyrings
 
 
 
+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
 ===========
@@ -596,11 +944,11 @@ The keyserver also recognizes http-POSTs to /pks/add. Use this to upload
 keys.
 
 
-A better way to to this would be a request like:
+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.
+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/FAQ b/doc/FAQ
deleted file mode 100644
index 788b85751..000000000
--- a/doc/FAQ
+++ /dev/null
@@ -1,352 +0,0 @@
-	    GNU Privacy Guard -- Frequently Asked Questions
-	   =================================================
-
-  This FAQ is partly compiled from messages of the developers mailing list.
-
-  Many thanks to Kirk Fort, Brian Warner, ...
-
-
-  Q: How does this whole thing work?
-  A: To generate a secret/public keypair, run
-
-      gpg --gen-key
-
-  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 be very careful with this
-  secret keyring: 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
-
-      gpg --fingerprint user-id
-
-  over phone (if you really know the voice of the other person) or 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: What is the recommended key size?
- A: 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 keysize is larger
-    than 1024 bits.  Encryption keys may have greater sizes,
-    but you should than check the fingerprint of this key:
-    "gpg --fingerprint --fingerprint <user ID>".
-
- Q: Why are some signatures with an ELG-E key valid?
- A: These are ElGamal Key generated by GnuPG in v3 (rfc1991)
-    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 accept 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: Why is PGP 5.x not able to encrypt messages with some keys?
- A: 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 an 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?
- A: PGP 5.x does not accept V4 signatures for data material but
-    OpenPGP requires generation of V4 signatures for all kind of
-    data.  Use the option "--force-v3-sigs" to generate V3 signatures
-    for data.
-
- Q: I can't delete an user id because it is already deleted on my
-    public keyring?
- A: 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 it 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: How can I encrypt a message so that pgp 2.x is able to decrypt it?
- A: You can't do that because pgp 2.x normally uses IDEA which is not
-    supported by GnuPG because it is patented, but if you have a modified
-    version of PGP you can try this:
-
-       gpg --rfc1991 --cipher-algo 3des ...
-
-    Please don't pipe the data to encrypt to gpg but give it as a filename;
-    other wise, pgp 2 will not be able to handle it.
-
- Q: How can I conventional encrypt a message, so that PGP can decrypt it?
- A: You can't do this for PGP 2.  For PGP 5 you should use this:
-
-       gpg -c --cipher-algo 3des --compress-algo 1 myfile
-
-    You may replace "3des" by "cast5". "blowfish" does not work with
-    all versions of pgp5.  You may also want to put
-       compress-algo 1
-    into your ~/.gnupg/options file - this does not affect normal
-    gnupg operation.
-
-
-  Q: Why does it sometimes take so long to create keys?
-  A: 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 it's price. What I do
-  is to hit several times on the shift, control, alternate, and capslock
-  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/[u]random).
-
-  Q: And it really takes long when I work on a remote system. Why?
-  A: 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 keyring (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: How does the whole trust thing work?
-  A: 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.
-
-      gpg --list-keys --with-colons
-
-  If the first field is "pub" or "uid", the second field shows you the trust:
-
-     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
-
-  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)
-
-      gpg --list-ownertrust
-
-  The first field is the fingerprint of the primary key, the second field
-  is the assigned value:
-
-      - = 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.
-
-  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 trust-DB so it is okay
-  to give a gpg keyring away (but we have a --export command too).
-
-
-  Q: What is the difference between options and commands?
-  A: 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 *must* pick exactly one command (**with one exception, see below). You
-  *may* 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:
-
-   gpg [--option something] [--option2] [--option3 something] --command file
-
-  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
-
-   gpg -r alice -o secret.txt -e test.txt
-
-  If you write the options out in full, it is easier to read
-
-   gpg --recipient alice --output secret.txt --encrypt test.txt
-
-  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.
-
-   gpg --armor --recipient alice --output secret.txt --encrypt test.txt
-
-  If you imagine square brackets around the optional parts, it becomes a bit
-  clearer:
-
-   gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
-
-  The optional parts can be rearranged any way you want.
-
-   gpg --output secret.txt --recipient alice --armor --encrypt test.txt
-
-  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".
-
-  ** the exception: signing and encrypting at the same time. Use
-
-   gpg [--options] --sign --encrypt foo.txt
-
-
-  Q: What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
-  A: This is the internal representation of an 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: What is trust, validity and ownertrust?
-  A: "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 interpret some of the informational outputs?
-  A: While checking the validity of a key, GnuPG sometimes prints
-     some information which is prefixed with information about
-     the checked item.
-	"key 12345678.3456"
-     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.
-	"uid 12345678.3456/ACDE"
-     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.
-	"sig 12345678.3456/ACDE/9A8B7C6D"
-     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: How do I sign a patch file?
-  A: 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 of lines starting with a
-     dash and these are then quoted and that is not good for 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?
-  A: Use "--encrypt-to your_keyid".  You can use more than one
-     of these options. To temporary override the use of this additional
-     keys, you can use the option "--no-encrypt-to".
-
-
-  Q: How can I get rid of the Version and Comment headers in
-     armored messages?
-  A: 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?
-  A: 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
-     "iso-8859-1" is the most used one, so this is the default.  You can
-     change the charset with the option "--charset".  It is important that
-     you 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 do I transfer owner trust values from PGP to GnuPG?
-  A: There is a script in the tools directory to help you:
-     After you have imported the PGP keyring you can give this command:
-	$ lspgpot pgpkeyring | gpg --import-ownertrust
-     where pgpkeyring is the original keyring and not the GnuPG one you
-     might have created in the first step.
-
-  Q: Are the headerlines of a cleartext signater part of the signed
-     material?
-  A: 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 modern signatures, to tell the parser which
-     hash algorithm to use.
-
-
diff --git a/doc/HACKING b/doc/HACKING
index 6f4c9ffd8..811179e53 100644
--- a/doc/HACKING
+++ b/doc/HACKING
@@ -10,12 +10,13 @@ CVS Access
 ==========
 Anonymous read-only CVS access is available:
 
-  cvs -z6 -d :pserver:anonymous@ftp.guug.de:/home/koch/cvs login
+  cvs -z3 -d :pserver:anoncvs@cvs.gnupg.org:/cvs/gnupg login
 
-use the password "anonymous".  To check out the the complete
+use the password "anoncvs".  To check out the the complete
 archive use:
 
-  cvs -z6 -d :pserver:anonymous@ftp.guug.de:/home/koch/cvs checkout gnupg
+  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
@@ -112,6 +113,74 @@ Directory Layout
   ./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
 
 
 
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 209032141..ca4941411 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1,42 +1,77 @@
-## Process this file with automake to create Makefile.in
-
-BUILT_SOURCES = version.sgml
+# Copyright (C) 1998, 1999, 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
 
+## Process this file with automake to create Makefile.in
 
-#EXTRA_DIST = DETAILS gpg.sgml gpg.1 FAQ HACKING OpenPGP \
-#	     version.sgml.in $(BUILT_SOURCES)
-EXTRA_DIST = DETAILS HACKING OpenPGP FAQ
+AUTOMAKE_OPTIONS = no-texinfo.tex
 
-#man_MANS = gpg.1
+EXTRA_DIST = DETAILS gpg.sgml gpg.1 gpgv.sgml gpgv.1 faq.raw FAQ faq.html \
+             HACKING OpenPGP README.W32 samplekeys.asc
 
-### pkgdata_DATA = gcryptref.html gcryptref.ps
+man_MANS = gpg.1 gpgv.1
 
+info_TEXINFOS = gpg.texi gpgv.texi
 
-# gcryptref.sgml : version.sgml
+# Need this to avoid building of dvis with automake 1.4
+DVIS =
 
+pkgdata_DATA = FAQ faq.html
 
-if HAVE_DB2MAN
-%.1 : %.sgml
-	$(DB2MAN) $<  >$@
-endif
+BUILT_SOURCES = FAQ faq.html 
+# we can't add gpg.texi gpgv.texi here because automake does not like them to
+# be built files. 
 
-if HAVE_DB2TEX
-%.ps : %.dvi
-	dvips -o $@ $<
+CLEANFILES = faq.raw.xref gpg.xml gpgv.xml
 
-%.tex : %.sgml
-	$(DB2TEX) -V generate-book-toc $< > $@
 
-%.dvi : %.tex
-	$(JADETEX) $<
+%.texi : %.xml
+if HAVE_DOCBOOK_TO_TEXI
+	docbook2texi $< | sed 's,--,---,' >$@
+else
+	: Warning: missing docbook to texinfo tools, cannot make $@
+	touch $@
 endif
 
-if HAVE_DB2HTML
-%.html : %.sgml
-	$(DB2HTML) --nosplit $<
+%.xml : %.sgml
+if HAVE_DOCBOOK_TO_TEXI
+	sgml2xml -x lower $< >$@
+else
+	: Warning: missing docbook to texinfo tools, cannot make $@
+	touch $@
 endif
 
 
+%.1 : %.sgml
+if HAVE_DOCBOOK_TO_MAN
+	docbook-to-man $<  >$@
+else
+	: Warning: missing docbook-to-man, cannot make $@
+	echo ".TH $< 1"   >$@
+	echo "No man page due to missing docbook-to-man" >>$@
+endif
+
 
+FAQ : faq.raw
+	$(FAQPROG) -f $<  $@ || $(FAQPROG) -f $< $@
 
+faq.html : faq.raw
+	$(FAQPROG) -h -f $< $@ 2>&1 || $(FAQPROG) -h -f $< $@
 
+dist-hook:
+	@if test "`wc -c < gpg.1`" -lt 200; then \
+	    echo 'ERROR: dummy man page'; false; fi
diff --git a/doc/OpenPGP b/doc/OpenPGP
index c73eee4f8..a511ad7fd 100644
--- a/doc/OpenPGP
+++ b/doc/OpenPGP
@@ -8,11 +8,7 @@
 
   Compatibility Notes
   ===================
-   GnuPG (>0.4.5) is in compliance with RFC2440 despite these exceptions:
-
-    * (9.1) states that RSA SHOULD be implemented.  This is not done
-      (except with an extension, usable outside the U.S.) due to
-      patent problems.
+   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.
@@ -21,7 +17,7 @@
    All MAY features are implemented with this exception:
 
     * multi-part armored messages are not supported.
-      MIME should be used instead.
+      MIME (rfc2015) should be used instead.
 
    Most of the OPTIONAL stuff is implemented.
 
@@ -33,6 +29,15 @@
    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:
   ==========================================
diff --git a/doc/README.W32 b/doc/README.W32
new file mode 100644
index 000000000..05e41e3e2
--- /dev/null
+++ b/doc/README.W32
@@ -0,0 +1,95 @@
+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" 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\HomeDir
+    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\MODir
+     (Example entry: "c:/gnu/locale/fr")
+  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.0.n.tar.gz
+
+or for snapshots (with a letter appended to the version number)
+
+  ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.nx.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/faq.raw b/doc/faq.raw
new file mode 100644
index 000000000..eac856bd3
--- /dev/null
+++ b/doc/faq.raw
@@ -0,0 +1,932 @@
+[$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=Douglas Calvert, <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]
+
+
+Version: 1.5.6[H p]
+Last-Modified: Sep 14, 2001[H p]
+Maintained-by: [$maintainer]
+
+
+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. 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 questions <Rcompat>ff. 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] [H a href=[$hGPG]/docs.html]<[$hGPG]/docs.html>[H/a] is the
+    documentation page. 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.: 
+    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], 
+    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 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
+    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] 
+    how 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
+    avoided. 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 version 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:
+    "gpg --fingerprint <user ID>".
+
+    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, 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/[u]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 it
+    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 we GnuPG implements a special way to do
+    deal with it: Simply use the long keyid which you can figure out
+    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 of lines starting with a dash and
+    these are then quoted and that is not good for 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 temporary override the use of this additional keys, 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 "iso-8859-1" is the most used one, so this is the default.
+    You can change the charset with the option "--charset".  It is
+    important that you 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] Cd to this directory.  [H LI] gpg --homedir
+    . --edit foo and use "passwd" to remove the pass-phrase 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 a 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 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, the trustdb, 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 
+
+    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
+
+    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", "blowfish" does not
+    work with all versions of pgp5.  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 an 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 one 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 a too serious 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 the some informations are 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 files, 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 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 on Windows 1.0.2 or older. 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
+    key. Because of security fixes, you should keep your gpg
+    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
+    currectly.  You may want to apply this patch if you can't upgrade:
+       http://www.gnupg.org/developer/gpg-woody-fix.txt 
+
+
+
+<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 be very careful
+    with this secret keyring: 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
+    [H pre]
+        gpg --fingerprint user-id
+    [H/pre]
+    over phone (if you really know the voice of the other person) or 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 Key generated by GnuPG in v3 (rfc1991) 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
+    accept 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)
+  
+    [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 trust-DB 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?
+
+    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 are not changes 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-signatures is increaded by one second when running this
+    command.
+
+
+<S> ACKNOWLEDGEMENTS
+
+    Many thanks to Nils Ellmenreich for maintaining this FAQ file for
+    a long time and to all posters to gnupg-users and gnupg-devel. They
+    all provided most of the answers.
+
+    Also thanks to Casper Dik for providing me 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
new file mode 100644
index 000000000..167093dcc
--- /dev/null
+++ b/doc/fr/ChangeLog
@@ -0,0 +1,17 @@
+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
new file mode 100644
index 000000000..5c7246c9d
--- /dev/null
+++ b/doc/fr/DETAILS
@@ -0,0 +1,945 @@
+
+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
new file mode 100644
index 000000000..48c28ae76
--- /dev/null
+++ b/doc/fr/FAQ
@@ -0,0 +1,1111 @@
+
+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
new file mode 100644
index 000000000..3a5d8485e
--- /dev/null
+++ b/doc/fr/README.fr
@@ -0,0 +1,10 @@
+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
new file mode 100644
index 000000000..7a6e346a8
--- /dev/null
+++ b/doc/gnupg-w32.reg
@@ -0,0 +1,8 @@
+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/gpg.sgml b/doc/gpg.sgml
index 44220a16e..145ad7c52 100644
--- a/doc/gpg.sgml
+++ b/doc/gpg.sgml
@@ -1,5 +1,5 @@
 <!-- gpg.sgml - the man page for GnuPG
-    Copyright (C) 1998, 1999 Free Software Foundation, Inc.
+    Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
 
     This file is part of GnuPG.
 
@@ -27,7 +27,7 @@
 -->
 
 
-<!DOCTYPE RefEntry PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
+<!DOCTYPE refentry PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
 <!entity ParmDir "<parameter>directory</parameter>">
 <!entity ParmFile "<parameter>file</parameter>">
 <!entity OptParmFile "<optional>&ParmFile;</optional>">
@@ -71,6 +71,16 @@
     <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>
@@ -113,7 +123,7 @@ Encrypt data. This option may be combined with --sign.
 <varlistentry>
 <term>-c, --symmetric</term>
 <listitem><para>
-Encrypt with symmetric cipher only
+Encrypt with symmetric cipher only.
 This command asks for a passphrase.
 </para></listitem></varlistentry>
 
@@ -144,16 +154,42 @@ message.
 <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 (it may be a
-detached signature when not used in batch mode). If
+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 (if such a file does
-not exist it is expected at stdin; use a single dash ("-") as
-filename to force a read from stdin). With more than
+".sig" or ".asc" extension. 
+With more than
 1 argument, the first should be a detached signature
-and the remaining files are the signed stuff.
+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>
 
 <!--
@@ -202,7 +238,6 @@ Same as --list-keys, but the signatures are listed too.
 Same as --list-sigs, but the signatures are verified.
 </para></listitem></varlistentry>
 
-
 <varlistentry>
 <term>--fingerprint &OptParmNames;</term>
 <listitem><para>
@@ -226,8 +261,13 @@ useful for debugging.
 <varlistentry>
 <term>--gen-key</term>
 <listitem><para>
-Generate a new key pair. This command can only be
-used interactive.
+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>
 
 
@@ -257,6 +297,17 @@ 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.  GnuPG asks for every
@@ -279,9 +330,13 @@ for encryption.</para></listitem></varlistentry>
     <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 an user id.</para></listitem></varlistentry>
+Delete a user id.</para></listitem></varlistentry>
     <varlistentry>
     <term>addkey</term>
     <listitem><para>
@@ -291,6 +346,10 @@ Add a subkey to this key.</para></listitem></varlistentry>
     <listitem><para>
 Remove a subkey.</para></listitem></varlistentry>
     <varlistentry>
+    <term>addrevoker</term>
+    <listitem><para>
+Add a designated revoker.</para></listitem></varlistentry>
+    <varlistentry>
     <term>revkey</term>
     <listitem><para>
 Revoke a subkey.</para></listitem></varlistentry>
@@ -306,6 +365,16 @@ primary key is changed.</para></listitem></varlistentry>
     <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;.
@@ -320,10 +389,36 @@ Use 0 to deselect all.</para></listitem></varlistentry>
     <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.</para></listitem></varlistentry>
     <varlistentry>
+    <term>showpref</term>
+    <listitem><para>
+More verbose preferences listing.</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.  Only available algorithms are allowed.  This
+command just initializes an internal list and does not change anything
+unless another command 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 fill be advanced by one second.
+</para></listitem></varlistentry>
+    <varlistentry>
     <term>toggle</term>
     <listitem><para>
 Toggle between public and secret key listing.</para></listitem></varlistentry>
@@ -346,7 +441,8 @@ 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.</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>
@@ -358,15 +454,23 @@ trust value.  Letters are used for the values:</para>
 <varlistentry>
 <term>--sign-key &ParmName;</term>
 <listitem><para>
-Sign a public key with you secret key.	This is a shortcut version
-of the subcommand "sign" from --edit.
+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>
-Sign a public key with you secret key but mark it as non-exportable.
-This is a shortcut version of the subcommand "lsign" from --edit.
+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>
@@ -382,12 +486,25 @@ Remove key from the secret and public keyring
 </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.
+</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>
@@ -415,16 +532,24 @@ or changed by you.
 <varlistentry>
 <term>--export-all &OptParmNames;</term>
 <listitem><para>
-Same as --export, but does also export keys which
-are not compatible to OpenPGP.
+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 does export the secret keys.
+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>
 
 
@@ -433,29 +558,67 @@ This is normally not very useful and a security risk.
 <term>--fast-import &OptParmFiles;</term>
 <listitem><para>
 Import/merge keys. This adds the given keys to the
-keyring.
-The fast version does not build
-the trustdb; this can be done at any time with the
-command --update-trustdb.
+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 HKP
-keyserver. Option --keyserver must be used to
-give the name of this keyserver.
+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>--export-ownertrust</term>
+<term>--update-trustdb</term>
 <listitem><para>
-List the assigned ownertrust values in ASCII format
-for backup purposes
+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>
@@ -468,10 +631,11 @@ values will be overwritten.
 
 <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 of stdin.
-If "*" is used for the algorithm, digests for all available algorithms
-are printed.
+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>
 
 
@@ -481,7 +645,7 @@ are printed.
 <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
+PLEASE, don't use this command unless you know what you are doing; it may
 remove precious entropy from the system!
 </para></listitem></varlistentry>
 
@@ -512,8 +676,8 @@ Print warranty information.
 <varlistentry>
 <term>-h, --help</term>
 <listitem><para>
-Print usage information.  This is a really long list even it does list
-not all options.
+Print usage information.  This is a really long list even though it doesn't list
+all options.
 </para></listitem></varlistentry>
 
 
@@ -581,7 +745,7 @@ specified, GnuPG asks for the user-id unless --default-recipient is given
 <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 a non empty.
+don't ask if this is a valid one. &ParmName; must be non-empty.
 </para></listitem></varlistentry>
 
 <varlistentry>
@@ -602,9 +766,9 @@ Reset --default-recipient and --default-recipient-self.
 <varlistentry>
 <term>--encrypt-to &ParmName;</term>
 <listitem><para>
-Same as --recipient but this one is intended for
-in the options file and may be used together with
-an own user-id as an "encrypt-to-self".  These keys
+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
@@ -635,7 +799,7 @@ Try to be as quiet as possible.
 
 
 <varlistentry>
-<term>-z &ParmN;</term>
+<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
@@ -676,6 +840,14 @@ 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>
@@ -699,30 +871,189 @@ Assume "yes" 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.
+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 to lookup keys which are not yet in
-your keyring.  This is only done while verifying
-messages with signatures.  The option is also
-required for the command --send-keys to
-specify the keyserver to where the keys should
-be send.  All keyservers synchronize with each
-other - so there is no need to send keys to more
-than one server.  Using the command
-"host -l pgp.net | grep wwwkeys" gives you a
-list of keyservers.  Because there is load
-balancing using round-robin DNS you may notice
-that you get different key servers.
+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.
+</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.  While not all options are available for all keyserver types,
+some common options are:
+<variablelist>
+
+<varlistentry>
+<term>include-revoked</term>
+<listitem><para>
+When receiving or 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.
+</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>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>--show-photos</term>
+<listitem><para>
+Causes --list-keys, --list-sigs, --list-public-keys, and
+--list-secret-keys to also display the photo ID attached to a 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>--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>
@@ -734,7 +1065,6 @@ 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>"gnupg-gdbm:" may be used for a GDBM ring.</para>
 <para>It might make sense to use it together with --no-default-keyring.
 </para></listitem></varlistentry>
 
@@ -772,6 +1102,10 @@ Valid values for &ParmName; are:</para>
 <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>
 
@@ -783,8 +1117,8 @@ Valid values for &ParmName; are:</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 effects all following arguments.  Both options may
-used multiple times.
+by --charset. These options affect all following arguments.  Both options may
+be used multiple times.
 </para></listitem></varlistentry>
 
 
@@ -803,6 +1137,8 @@ in an options file.
 <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>
 
 
@@ -846,11 +1182,34 @@ Write log output to file descriptor &ParmN; and not to stderr.
 
 
 <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>
-Do not write comment packets.  This option affects only
-the generation of secret keys.	Output of option packets
-is disabled since version 0.4.2.
+See --sk-comments.  This option is deprecated and may be removed soon.
 </para></listitem></varlistentry>
 
 
@@ -858,6 +1217,7 @@ is disabled since version 0.4.2.
 <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>
 
 
@@ -866,7 +1226,8 @@ Use &ParmString; as comment string in clear text signatures.
 <listitem><para>
 Force to write the standard comment string in clear
 text signatures.  Use this to overwrite a --comment
-from a config file.
+from a config file.  This option is now obsolete because there is no
+default comment string anymore.
 </para></listitem></varlistentry>
 
 
@@ -890,14 +1251,27 @@ signatures.  Use this to overwrite a previous
 <term>-N, --notation-data &ParmNameValue;</term>
 <listitem><para>
 Put the name value pair into the signature as notation data.
-&ParmName; must consists only of alphanumeric characters, digits
+&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 encoded in UTF8,
-so sou should have check that your --charset is set right.
+&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>
@@ -907,6 +1281,18 @@ 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>
@@ -916,6 +1302,21 @@ 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.
@@ -956,25 +1357,32 @@ selected from the preferences stored with the key.
 </para></listitem></varlistentry>
 
 
-
 <varlistentry>
 <term>--digest-algo &ParmName;</term>
 <listitem><para>
-Use  &ParmName; as message digest algorithm. Running the
-program with the command --version yields a list of
-supported algorithms.  Please note that using this
-option may violate the OpenPGP requirement, that a
-160 bit hash is to be used for DSA.
+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 BLOWFISH.	This cipher is
-also used for conventional encryption if --cipher-algo
-is not given.
+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>
 
 
@@ -1001,16 +1409,27 @@ for conventional encryption.
 
 
 <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.
+</para></listitem></varlistentry>
+
+
+<varlistentry>
 <term>--compress-algo &ParmN;</term>
 <listitem><para>
-Use compress algorithm	&ParmN;. Default is 2 which is
-RFC1950 compression. You may use 1 to use the old zlib
-version which is used by PGP. 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.
+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>
 
 
@@ -1031,6 +1450,42 @@ 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
@@ -1074,6 +1529,31 @@ can only be used if only one passphrase is supplied.
 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>
@@ -1081,46 +1561,160 @@ Don't use this option if you can avoid it.
 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'
+</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 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.
+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 5.x recognizes v4 signatures only
-on key material.  This options forces v3 signatures for
-signatures on data.
+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 cipher (those
-with a blocksize greater than 64 bit).
-This option might not be implemented yet.
+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 of keys with user IDs which are not self-signed.
-This is only allows the import - key validation will fail and you
-have to check the validity of the key my other means.  This hack is
-needed for some German keys generated with pgp 2.6.3in. You should really
-avoid using it, because OpenPGP has better mechanics to do separate signing
-and encryption keys.
+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 OpenPG 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 anyway protected by
+the OpenPGP protocol) is still okay.  This option will let gpg ignore
+CRC errors.
 </para></listitem></varlistentry>
 
 
@@ -1141,6 +1735,25 @@ 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>
@@ -1162,6 +1775,12 @@ enter batch mode.
 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-armor</term>
@@ -1190,14 +1809,15 @@ verification is not needed.
 <varlistentry>
 <term>--with-colons</term>
 <listitem><para>
-Print key listings delimited by colons.
+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 and print the public key data.
+Print key listings delimited by colons (like --with-colons) and print the public key data.
 </para></listitem></varlistentry>
 
 <varlistentry>
@@ -1208,6 +1828,32 @@ 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.
@@ -1220,16 +1866,266 @@ This is not for normal use.  Use the source to see for what it might be useful.
 </para></listitem></varlistentry>
 
 <varlistentry>
-<term>--entropy-dll-name &ParmFile;</term>
+<term>--emulate-md-encode-bug</term>
 <listitem><para>
-This option is only used for the Win32 version of GnuPG and changes the
-default location (c:/gnupg/entropy.dll) of the Winseed DLL to &ParmFile;.
+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 &ParmNameValue;</term>
+<listitem><para>
+Sets up a name 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.  Note 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>
@@ -1295,6 +2191,20 @@ constructed by cutting off the extension (".asc" or ".sig") of
 <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 overide it.</para></listitem>
+</varlistentry>
+<varlistentry>
+<term>http_proxy</term>
+<listitem><para>Only honored when the option --honor-http-proxy is set.</para></listitem>
+</varlistentry>
     </variablelist>
 
 </refsect1>
@@ -1334,6 +2244,11 @@ constructed by cutting off the extension (".asc" or ".sig") of
 </varlistentry>
 
 <varlistentry>
+<term>~/.gnupg/random_seed</term>
+<listitem><para>used to preserve the internal random pool</para></listitem>
+</varlistentry>
+
+<varlistentry>
 <term>~/.gnupg/options</term>
 <listitem><para>May contain options</para></listitem>
 </varlistentry>
@@ -1366,6 +2281,11 @@ 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!
 </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
+commandline or using <literal>-</literal> to specify stdin.
+</para>
 </refsect1>
 
 
diff --git a/doc/gpgv.sgml b/doc/gpgv.sgml
new file mode 100644
index 000000000..4119b41dc
--- /dev/null
+++ b/doc/gpgv.sgml
@@ -0,0 +1,225 @@
+<!-- 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
new file mode 100644
index 000000000..cc83e6a2d
--- /dev/null
+++ b/doc/gpgv.texi
@@ -0,0 +1,115 @@
+\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
+
+@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/Makefile.am b/doc/gph/Makefile.am
index 732c3e3e6..d36b0013a 100644
--- a/doc/gph/Makefile.am
+++ b/doc/gph/Makefile.am
@@ -11,7 +11,7 @@ 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
+	-test -d manual && cp ./signatures.jpg ./manual/signatures.jpg
 
 
 index.html: $(PARTS)
@@ -27,7 +27,7 @@ index.html: $(PARTS)
 	echo '</body></html>' >>index.html
 	-rm -r manual.junk
 	-rm manual/signatures.jpg
-	(cd manual; rm -r stylesheet-images; ls | grep -v distfiles >distfiles)
+##    (cd manual; rm -r stylesheet-images; ls | grep -v distfiles >distfiles)
 
 
 dist-hook: index.html
diff --git a/doc/gph/signatures.jpg.asc b/doc/gph/signatures.jpg.asc
new file mode 100644
index 000000000..99f04e394
--- /dev/null
+++ b/doc/gph/signatures.jpg.asc
@@ -0,0 +1,232 @@
+-----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
new file mode 100644
index 000000000..04599e895
--- /dev/null
+++ b/doc/samplekeys.asc
@@ -0,0 +1,624 @@
+
+  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-----
diff --git a/doc/version.sgml.in b/doc/version.sgml.in
deleted file mode 100644
index d78bda934..000000000
--- a/doc/version.sgml.in
+++ /dev/null
@@ -1 +0,0 @@
-@VERSION@