summaryrefslogtreecommitdiff
path: root/docs/_static/DETAILS.html
diff options
context:
space:
mode:
authorKali Kaneko <kali@futeisha.org>2015-06-08 17:00:40 -0400
committerKali Kaneko <kali@futeisha.org>2015-06-08 17:00:40 -0400
commit28ec72ebe2aac0829b11e016ab21ec52308c0854 (patch)
tree1ddeb46cbc0af8ba57ec29c81c43ae39b52d953f /docs/_static/DETAILS.html
parent3408b93ee630e01b0905b9bfa849d611bdc52c0a (diff)
parent18b6361d66518b5c413c5b893676b87503545274 (diff)
Merge branch 'release-2.0.2'
Diffstat (limited to 'docs/_static/DETAILS.html')
-rw-r--r--docs/_static/DETAILS.html2677
1 files changed, 0 insertions, 2677 deletions
diff --git a/docs/_static/DETAILS.html b/docs/_static/DETAILS.html
deleted file mode 100644
index 7b0b9f8..0000000
--- a/docs/_static/DETAILS.html
+++ /dev/null
@@ -1,2677 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
-<head>
-<title>GnuPG Details</title>
-<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
-<meta name="title" content="GnuPG Details"/>
-<meta name="generator" content="Org-mode"/>
-<meta name="generated" content="2013-07-03T09:52+0000"/>
-<meta name="author" content="isis"/>
-<meta name="description" content=""/>
-<meta name="keywords" content=""/>
-<style type="text/css">
- <!--/*--><![CDATA[/*><!--*/
- html { font-family: Times, serif; font-size: 12pt; }
- .title { text-align: center; }
- .todo { color: red; }
- .done { color: green; }
- .tag { background-color: #add8e6; font-weight:normal }
- .target { }
- .timestamp { color: #bebebe; }
- .timestamp-kwd { color: #5f9ea0; }
- .right {margin-left:auto; margin-right:0px; text-align:right;}
- .left {margin-left:0px; margin-right:auto; text-align:left;}
- .center {margin-left:auto; margin-right:auto; text-align:center;}
- p.verse { margin-left: 3% }
- pre {
- border: 1pt solid #AEBDCC;
- background-color: #F3F5F7;
- padding: 5pt;
- font-family: courier, monospace;
- font-size: 90%;
- overflow:auto;
- }
- table { border-collapse: collapse; }
- td, th { vertical-align: top; }
- th.right { text-align:center; }
- th.left { text-align:center; }
- th.center { text-align:center; }
- td.right { text-align:right; }
- td.left { text-align:left; }
- td.center { text-align:center; }
- dt { font-weight: bold; }
- div.figure { padding: 0.5em; }
- div.figure p { text-align: center; }
- div.inlinetask {
- padding:10px;
- border:2px solid gray;
- margin:10px;
- background: #ffffcc;
- }
- textarea { overflow-x: auto; }
- .linenr { font-size:smaller }
- .code-highlighted {background-color:#ffff00;}
- .org-info-js_info-navigation { border-style:none; }
- #org-info-js_console-label { font-size:10px; font-weight:bold;
- white-space:nowrap; }
- .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
- font-weight:bold; }
- /*]]>*/-->
-</style>
-<script type="text/javascript">
-/*
-@licstart The following is the entire license notice for the
-JavaScript code in this tag.
-
-Copyright (C) 2012 Free Software Foundation, Inc.
-
-The JavaScript code in this tag is free software: you can
-redistribute it and/or modify it under the terms of the GNU
-General Public License (GNU GPL) as published by the Free Software
-Foundation, either version 3 of the License, or (at your option)
-any later version. The code is distributed WITHOUT ANY WARRANTY;
-without even the implied warranty of MERCHANTABILITY or FITNESS
-FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
-
-As additional permission under GNU GPL version 3 section 7, you
-may distribute non-source (e.g., minimized or compacted) forms of
-that code without the copy of the GNU GPL normally required by
-section 4, provided you include this license notice and a URL
-through which recipients can access the Corresponding Source.
-
-
-@licend The above is the entire license notice
-for the JavaScript code in this tag.
-*/
-<!--/*--><![CDATA[/*><!--*/
- function CodeHighlightOn(elem, id)
- {
- var target = document.getElementById(id);
- if(null != target) {
- elem.cacheClassElem = elem.className;
- elem.cacheClassTarget = target.className;
- target.className = "code-highlighted";
- elem.className = "code-highlighted";
- }
- }
- function CodeHighlightOff(elem, id)
- {
- var target = document.getElementById(id);
- if(elem.cacheClassElem)
- elem.className = elem.cacheClassElem;
- if(elem.cacheClassTarget)
- target.className = elem.cacheClassTarget;
- }
-/*]]>*///-->
-</script>
-<script type="text/css" href="./agogo.css" />
-</head>
-<body>
-
-<div id="preamble">
-
-</div>
-
-<div id="content">
-<h1 class="title">GnuPG Details</h1>
-
-
-<p>
-This is the DETAILS file for GnuPG which specifies some internals and
-parts of the external API for GPG and GPGSM.
-</p>
-
-<div id="table-of-contents">
-<h2>Table of Contents</h2>
-<div id="text-table-of-contents">
-<ul>
-<li><a href="#sec-1">1 Format of the colon listings</a>
-<ul>
-<li><a href="#sec-1-1">1.1 Description of the fields</a>
-<ul>
-<li><a href="#sec-1-1-1">1.1.1 Field 1 - Type of record</a></li>
-<li><a href="#sec-1-1-2">1.1.2 Field 2 - Validity</a></li>
-<li><a href="#sec-1-1-3">1.1.3 Field 3 - Key length</a></li>
-<li><a href="#sec-1-1-4">1.1.4 Field 4 - Public key algorithm</a></li>
-<li><a href="#sec-1-1-5">1.1.5 Field 5 - KeyID</a></li>
-<li><a href="#sec-1-1-6">1.1.6 Field 6 - Creation date</a></li>
-<li><a href="#sec-1-1-7">1.1.7 Field 7 - Expiration date</a></li>
-<li><a href="#sec-1-1-8">1.1.8 Field 8 - Certificate S/N, UID hash, trust signature info</a></li>
-<li><a href="#sec-1-1-9">1.1.9 Field 9 - Ownertrust</a></li>
-<li><a href="#sec-1-1-10">1.1.10 Field 10 - User-ID</a></li>
-<li><a href="#sec-1-1-11">1.1.11 Field 11 - Signature class</a></li>
-<li><a href="#sec-1-1-12">1.1.12 Field 12 - Key capabilities</a></li>
-<li><a href="#sec-1-1-13">1.1.13 Field 13 - Issuer certificate fingerprint or other info</a></li>
-<li><a href="#sec-1-1-14">1.1.14 Field 14 - Flag field</a></li>
-<li><a href="#sec-1-1-15">1.1.15 Field 15 - S/N of a token</a></li>
-<li><a href="#sec-1-1-16">1.1.16 Field 16 - Hash algorithm</a></li>
-</ul>
-</li>
-<li><a href="#sec-1-2">1.2 Special fields</a>
-<ul>
-<li><a href="#sec-1-2-1">1.2.1 PKD - Public key data</a></li>
-<li><a href="#sec-1-2-2">1.2.2 TRU - Trust database information</a></li>
-<li><a href="#sec-1-2-3">1.2.3 SPK - Signature subpacket records</a></li>
-<li><a href="#sec-1-2-4">1.2.4 CFG - Configuration data</a></li>
-</ul></li>
-</ul>
-</li>
-<li><a href="#sec-2">2 Format of the &ndash;status-fd output</a>
-<ul>
-<li><a href="#sec-2-1">2.1 General status codes</a>
-<ul>
-<li><a href="#sec-2-1-1">2.1.1 NEWSIG</a></li>
-<li><a href="#sec-2-1-2">2.1.2 GOODSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</a></li>
-<li><a href="#sec-2-1-3">2.1.3 EXPSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</a></li>
-<li><a href="#sec-2-1-4">2.1.4 EXPKEYSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</a></li>
-<li><a href="#sec-2-1-5">2.1.5 REVKEYSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</a></li>
-<li><a href="#sec-2-1-6">2.1.6 BADSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</a></li>
-<li><a href="#sec-2-1-7">2.1.7 ERRSIG &lt;keyid&gt; &lt;pkalgo&gt; &lt;hashalgo&gt; &lt;sig_class&gt; &lt;time&gt; &lt;rc&gt;</a></li>
-<li><a href="#sec-2-1-8">2.1.8 VALIDSIG &lt;args&gt;</a></li>
-<li><a href="#sec-2-1-9">2.1.9 SIG_ID &lt;radix64_string&gt; &lt;sig_creation_date&gt; &lt;sig-timestamp&gt;</a></li>
-<li><a href="#sec-2-1-10">2.1.10 ENC_TO &lt;long_keyid&gt; &lt;keytype&gt; &lt;keylength&gt;</a></li>
-<li><a href="#sec-2-1-11">2.1.11 BEGIN_DECRYPTION</a></li>
-<li><a href="#sec-2-1-12">2.1.12 END_DECRYPTION</a></li>
-<li><a href="#sec-2-1-13">2.1.13 DECRYPTION_INFO &lt;mdc_method&gt; &lt;sym_algo&gt;</a></li>
-<li><a href="#sec-2-1-14">2.1.14 DECRYPTION_FAILED</a></li>
-<li><a href="#sec-2-1-15">2.1.15 DECRYPTION_OKAY</a></li>
-<li><a href="#sec-2-1-16">2.1.16 SESSION_KEY &lt;algo&gt;:&lt;hexdigits&gt;</a></li>
-<li><a href="#sec-2-1-17">2.1.17 BEGIN_ENCRYPTION &lt;mdc_method&gt; &lt;sym_algo&gt;</a></li>
-<li><a href="#sec-2-1-18">2.1.18 END_ENCRYPTION</a></li>
-<li><a href="#sec-2-1-19">2.1.19 FILE_START &lt;what&gt; &lt;filename&gt;</a></li>
-<li><a href="#sec-2-1-20">2.1.20 FILE_DONE</a></li>
-<li><a href="#sec-2-1-21">2.1.21 BEGIN_SIGNING</a></li>
-<li><a href="#sec-2-1-22">2.1.22 ALREADY_SIGNED &lt;long-keyid&gt;</a></li>
-<li><a href="#sec-2-1-23">2.1.23 SIG_CREATED &lt;type&gt; &lt;pk_algo&gt; &lt;hash_algo&gt; &lt;class&gt; &lt;timestamp&gt; &lt;keyfpr&gt;</a></li>
-<li><a href="#sec-2-1-24">2.1.24 NOTATION_</a></li>
-<li><a href="#sec-2-1-25">2.1.25 POLICY_URL &lt;string&gt;</a></li>
-<li><a href="#sec-2-1-26">2.1.26 PLAINTEXT &lt;format&gt; &lt;timestamp&gt; &lt;filename&gt;</a></li>
-<li><a href="#sec-2-1-27">2.1.27 PLAINTEXT_LENGTH &lt;length&gt;</a></li>
-<li><a href="#sec-2-1-28">2.1.28 ATTRIBUTE &lt;arguments&gt;</a></li>
-<li><a href="#sec-2-1-29">2.1.29 SIG_SUBPACKET &lt;type&gt; &lt;flags&gt; &lt;len&gt; &lt;data&gt;</a></li>
-</ul>
-</li>
-<li><a href="#sec-2-2">2.2 Key related</a>
-<ul>
-<li><a href="#sec-2-2-1">2.2.1 INV_RECP, INV_SGNR</a></li>
-<li><a href="#sec-2-2-2">2.2.2 NO_RECP &lt;reserved&gt;</a></li>
-<li><a href="#sec-2-2-3">2.2.3 NO_SGNR &lt;reserved&gt;</a></li>
-<li><a href="#sec-2-2-4">2.2.4 KEYEXPIRED &lt;expire-timestamp&gt;</a></li>
-<li><a href="#sec-2-2-5">2.2.5 KEYREVOKED</a></li>
-<li><a href="#sec-2-2-6">2.2.6 NO_PUBKEY &lt;long keyid&gt;</a></li>
-<li><a href="#sec-2-2-7">2.2.7 NO_SECKEY &lt;long keyid&gt;</a></li>
-<li><a href="#sec-2-2-8">2.2.8 KEY_CREATED &lt;type&gt; &lt;fingerprint&gt; [&lt;handle&gt;]</a></li>
-<li><a href="#sec-2-2-9">2.2.9 KEY_NOT_CREATED [&lt;handle&gt;]</a></li>
-<li><a href="#sec-2-2-10">2.2.10 TRUST_</a></li>
-<li><a href="#sec-2-2-11">2.2.11 PKA_TRUST_</a></li>
-</ul>
-</li>
-<li><a href="#sec-2-3">2.3 Remote control</a>
-<ul>
-<li><a href="#sec-2-3-1">2.3.1 GET_BOOL, GET_LINE, GET_HIDDEN, GOT_IT</a></li>
-<li><a href="#sec-2-3-2">2.3.2 USERID_HINT &lt;long main keyid&gt; &lt;string&gt;</a></li>
-<li><a href="#sec-2-3-3">2.3.3 NEED_PASSPHRASE &lt;long keyid&gt; &lt;long main keyid&gt; &lt;keytype&gt; &lt;keylength&gt;</a></li>
-<li><a href="#sec-2-3-4">2.3.4 NEED_PASSPHRASE_SYM &lt;cipher_algo&gt; &lt;s2k_mode&gt; &lt;s2k_hash&gt;</a></li>
-<li><a href="#sec-2-3-5">2.3.5 NEED_PASSPHRASE_PIN &lt;card_type&gt; &lt;chvno&gt; [&lt;serialno&gt;]</a></li>
-<li><a href="#sec-2-3-6">2.3.6 MISSING_PASSPHRASE</a></li>
-<li><a href="#sec-2-3-7">2.3.7 BAD_PASSPHRASE &lt;long keyid&gt;</a></li>
-<li><a href="#sec-2-3-8">2.3.8 GOOD_PASSPHRASE</a></li>
-</ul>
-</li>
-<li><a href="#sec-2-4">2.4 Import/Export</a>
-<ul>
-<li><a href="#sec-2-4-1">2.4.1 IMPORT_CHECK &lt;long keyid&gt; &lt;fingerprint&gt; &lt;user ID&gt;</a></li>
-<li><a href="#sec-2-4-2">2.4.2 IMPORTED &lt;long keyid&gt; &lt;username&gt;</a></li>
-<li><a href="#sec-2-4-3">2.4.3 IMPORT_OK &lt;reason&gt; [&lt;fingerprint&gt;]</a></li>
-<li><a href="#sec-2-4-4">2.4.4 IMPORT_PROBLEM &lt;reason&gt; [&lt;fingerprint&gt;]</a></li>
-<li><a href="#sec-2-4-5">2.4.5 IMPORT_RES &lt;args&gt;</a></li>
-</ul>
-</li>
-<li><a href="#sec-2-5">2.5 Smartcard related</a>
-<ul>
-<li><a href="#sec-2-5-1">2.5.1 CARDCTRL &lt;what&gt; [&lt;serialno&gt;]</a></li>
-<li><a href="#sec-2-5-2">2.5.2 SC_OP_FAILURE [&lt;code&gt;]</a></li>
-<li><a href="#sec-2-5-3">2.5.3 SC_OP_SUCCESS</a></li>
-</ul>
-</li>
-<li><a href="#sec-2-6">2.6 Miscellaneous status codes</a>
-<ul>
-<li><a href="#sec-2-6-1">2.6.1 NODATA &lt;what&gt;</a></li>
-<li><a href="#sec-2-6-2">2.6.2 UNEXPECTED &lt;what&gt;</a></li>
-<li><a href="#sec-2-6-3">2.6.3 TRUNCATED &lt;maxno&gt;</a></li>
-<li><a href="#sec-2-6-4">2.6.4 ERROR &lt;error location&gt; &lt;error code&gt; [&lt;more&gt;]</a></li>
-<li><a href="#sec-2-6-5">2.6.5 SUCCESS [&lt;location&gt;]</a></li>
-<li><a href="#sec-2-6-6">2.6.6 BADARMOR</a></li>
-<li><a href="#sec-2-6-7">2.6.7 DELETE_PROBLEM &lt;reason_code&gt;</a></li>
-<li><a href="#sec-2-6-8">2.6.8 PROGRESS &lt;what&gt; &lt;char&gt; &lt;cur&gt; &lt;total&gt;</a></li>
-<li><a href="#sec-2-6-9">2.6.9 BACKUP_KEY_CREATED &lt;fingerprint&gt; &lt;fname&gt;</a></li>
-<li><a href="#sec-2-6-10">2.6.10 MOUNTPOINT &lt;name&gt;</a></li>
-<li><a href="#sec-2-6-11">2.6.11 PINENTRY_LAUNCHED &lt;pid&gt;</a></li>
-</ul>
-</li>
-<li><a href="#sec-2-7">2.7 Obsolete status codes</a>
-<ul>
-<li><a href="#sec-2-7-1">2.7.1 SIGEXPIRED</a></li>
-<li><a href="#sec-2-7-2">2.7.2 RSA_OR_IDEA</a></li>
-<li><a href="#sec-2-7-3">2.7.3 SHM_INFO, SHM_GET, SHM_GET_BOOL, SHM_GET_HIDDEN</a></li>
-<li><a href="#sec-2-7-4">2.7.4 BEGIN_STREAM, END_STREAM</a></li>
-</ul></li>
-</ul>
-</li>
-<li><a href="#sec-3">3 Format of the &ndash;attribute-fd output</a></li>
-<li><a href="#sec-4">4 Unattended key generation</a></li>
-<li><a href="#sec-5">5 Layout of the TrustDB</a></li>
-<li><a href="#sec-6">6 GNU extensions to the S2K algorithm</a></li>
-<li><a href="#sec-7">7 Keyserver helper message format</a></li>
-<li><a href="#sec-8">8 Object identifiers</a></li>
-<li><a href="#sec-9">9 Miscellaneous notes</a>
-<ul>
-<li><a href="#sec-9-1">9.1 v3 fingerprints</a></li>
-<li><a href="#sec-9-2">9.2 Simplified revocation certificates</a></li>
-<li><a href="#sec-9-3">9.3 Documentation on HKP (the http keyserver protocol):</a></li>
-</ul>
-</li>
-</ul>
-</div>
-</div>
-
-<div id="outline-container-1" class="outline-2">
-<h2 id="sec-1"><span class="section-number-2">1</span> Format of the colon listings</h2>
-<div class="outline-text-2" id="text-1">
-
-<p> The format is a based on colon separated record, each recods starts
- with a tag string and extends to the end of the line. Here is an
- example:
-</p>
-
-
-<pre class="example">$ gpg --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 &lt;wk@g10code.com&gt;:
-uid:f::::::::Werner Koch &lt;wk@gnupg.org&gt;:
-sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e:
-fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1:
-sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc:
-fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4:
-</pre>
-
-
-<p>
-The double <code>--with-fingerprint</code> prints the fingerprint for the subkeys
-too. Old versions of gpg used a lighly different format and required
-the use of the option <code>--fixed-list-mode</code> to conform to format
-described here.
-</p>
-
-</div>
-
-<div id="outline-container-1-1" class="outline-3">
-<h3 id="sec-1-1"><span class="section-number-3">1.1</span> Description of the fields</h3>
-<div class="outline-text-3" id="text-1-1">
-
-
-</div>
-
-<div id="outline-container-1-1-1" class="outline-4">
-<h4 id="sec-1-1-1"><span class="section-number-4">1.1.1</span> Field 1 - Type of record</h4>
-<div class="outline-text-4" id="text-1-1-1">
-
-
-<dl>
-<dt>pub</dt><dd>Public key
-</dd>
-<dt>crt</dt><dd>X.509 certificate
-</dd>
-<dt>crs</dt><dd>X.509 certificate and private key available
-</dd>
-<dt>sub</dt><dd>Subkey (secondary key)
-</dd>
-<dt>sec</dt><dd>Secret key
-</dd>
-<dt>ssb</dt><dd>Secret subkey (secondary key)
-</dd>
-<dt>uid</dt><dd>User id (only field 10 is used).
-</dd>
-<dt>uat</dt><dd>User attribute (same as user id except for field 10).
-</dd>
-<dt>sig</dt><dd>Signature
-</dd>
-<dt>rev</dt><dd>Revocation signature
-</dd>
-<dt>fpr</dt><dd>Fingerprint (fingerprint is in field 10)
-</dd>
-<dt>pkd</dt><dd>Public key data [*]
-</dd>
-<dt>grp</dt><dd>Keygrip
-</dd>
-<dt>rvk</dt><dd>Revocation key
-</dd>
-<dt>tru</dt><dd>Trust database information [*]
-</dd>
-<dt>spk</dt><dd>Signature subpacket [*]
-</dd>
-<dt>cfg</dt><dd>Configuration data [*]
-</dd>
-</dl>
-
-
-<p>
- Records marked with an asterisk are described at <a href="#Special-field-formats">*Special fields</a>.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-2" class="outline-4">
-<h4 id="sec-1-1-2"><span class="section-number-4">1.1.2</span> Field 2 - Validity</h4>
-<div class="outline-text-4" id="text-1-1-2">
-
-
-<p>
- This is a letter describing the computed validity of a key.
- Currently this is a single letter, but be prepared that additional
- information may follow in some future versions. Note that GnuPG &lt;
- 2.1 does not set this field for secret key listings.
-</p>
-<dl>
-<dt>o</dt><dd>Unknown (this key is new to the system)
-</dd>
-<dt>i</dt><dd>The key is invalid (e.g. due to a missing self-signature)
-</dd>
-<dt>d</dt><dd>The key has been disabled
- (deprecated - use the 'D' in field 12 instead)
-</dd>
-<dt>r</dt><dd>The key has been revoked
-</dd>
-<dt>e</dt><dd>The key has expired
-</dd>
-<dt>-</dt><dd>Unknown validity (i.e. no value assigned)
-</dd>
-<dt>q</dt><dd>Undefined validity. '-' and 'q' may safely be treated as
- the same value for most purposes
-</dd>
-<dt>n</dt><dd>The key is not valid
-</dd>
-<dt>m</dt><dd>The key is marginal valid.
-</dd>
-<dt>f</dt><dd>The key is fully valid
-</dd>
-<dt>u</dt><dd>The key is ultimately valid. This often means that the
- secret key is available, but any key may be marked as
- ultimately valid.
-</dd>
-<dt>w</dt><dd>The key has a well known private part.
-</dd>
-<dt>s</dt><dd>The key has special validity. This means that it might be
- self-signed and expected to be used in the STEED sytem.
-</dd>
-</dl>
-
-
-<p>
- If the validity information is given for a UID or UAT record, it
- describes the validity calculated based on this user ID. If given
- for a key record it describes the validity taken from the best
- rated user ID.
-</p>
-<p>
- For X.509 certificates a 'u' is used for a trusted root
- certificate (i.e. for the trust anchor) and an 'f' for all other
- valid certificates.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-3" class="outline-4">
-<h4 id="sec-1-1-3"><span class="section-number-4">1.1.3</span> Field 3 - Key length</h4>
-<div class="outline-text-4" id="text-1-1-3">
-
-
-<p>
- The length of key in bits.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-4" class="outline-4">
-<h4 id="sec-1-1-4"><span class="section-number-4">1.1.4</span> Field 4 - Public key algorithm</h4>
-<div class="outline-text-4" id="text-1-1-4">
-
-
-<p>
- The values here are those from the OpenPGP specs or if they are
- greather than 255 the algorithm ids as used by Libgcrypt.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-5" class="outline-4">
-<h4 id="sec-1-1-5"><span class="section-number-4">1.1.5</span> Field 5 - KeyID</h4>
-<div class="outline-text-4" id="text-1-1-5">
-
-
-<p>
- This is the 64 bit keyid as specified by OpenPGP and the last 64
- bit of the SHA-1 fingerprint of an X.509 certifciate.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-6" class="outline-4">
-<h4 id="sec-1-1-6"><span class="section-number-4">1.1.6</span> Field 6 - Creation date</h4>
-<div class="outline-text-4" id="text-1-1-6">
-
-
-<p>
- The creation date of the key is given in UTC. For UID and UAT
- records, this is used for the self-signature date. Note that the
- date is usally printed in seconds since epoch, however, we are
- migrating to an ISO 8601 format (e.g. "19660205T091500"). This is
- currently only relevant for X.509. A simple way to detect the new
- format is to scan for the 'T'. Note that old versions of gpg
- without using the <code>--fixed-list-mode</code> option used a "yyyy-mm-tt"
- format.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-7" class="outline-4">
-<h4 id="sec-1-1-7"><span class="section-number-4">1.1.7</span> Field 7 - Expiration date</h4>
-<div class="outline-text-4" id="text-1-1-7">
-
-
-<p>
- Key or UID/UAT expiration date or empty if it does not expire.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-8" class="outline-4">
-<h4 id="sec-1-1-8"><span class="section-number-4">1.1.8</span> Field 8 - Certificate S/N, UID hash, trust signature info</h4>
-<div class="outline-text-4" id="text-1-1-8">
-
-
-<p>
- Used for serial number in crt records. For UID and UAT records,
- this is a hash of the user ID contents used to represent that
- exact user ID. For trust signatures, this is the trust depth
- seperated by the trust value by a space.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-9" class="outline-4">
-<h4 id="sec-1-1-9"><span class="section-number-4">1.1.9</span> Field 9 - Ownertrust</h4>
-<div class="outline-text-4" id="text-1-1-9">
-
-
-<p>
- This is only used on primary keys. This is a single letter, but
- be prepared that additional information may follow in future
- versions. For trust signatures with a regular expression, this is
- the regular expression value, quoted as in field 10.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-10" class="outline-4">
-<h4 id="sec-1-1-10"><span class="section-number-4">1.1.10</span> Field 10 - User-ID</h4>
-<div class="outline-text-4" id="text-1-1-10">
-
-<p> The value is quoted like a C string to avoid control characters
- (the colon is quoted <code>\x3a</code>). For a "pub" record this field is
- not used on &ndash;fixed-list-mode. 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. A FPR
- record stores the fingerprint here. The fingerprint of a
- revocation key is stored here.
-</p></div>
-
-</div>
-
-<div id="outline-container-1-1-11" class="outline-4">
-<h4 id="sec-1-1-11"><span class="section-number-4">1.1.11</span> Field 11 - Signature class</h4>
-<div class="outline-text-4" id="text-1-1-11">
-
-
-<p>
- Signature class as per RFC-4880. 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' is used the same
- way. This field if not used for X.509.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-12" class="outline-4">
-<h4 id="sec-1-1-12"><span class="section-number-4">1.1.12</span> Field 12 - Key capabilities</h4>
-<div class="outline-text-4" id="text-1-1-12">
-
-
-<p>
- The defined capabilities are:
-</p>
-<dl>
-<dt>e</dt><dd>Encrypt
-</dd>
-<dt>s</dt><dd>Sign
-</dd>
-<dt>c</dt><dd>Certify
-</dd>
-<dt>a</dt><dd>Authentication
-</dd>
-<dt>?</dt><dd>Unknown capability
-</dd>
-</dl>
-
-
-<p>
- A key may have any combination of them in any order. In addition
- to these letters, the primary key has uppercase versions of the
- letters to denote the <span style="text-decoration:underline;">usable</span> capabilities of the entire key, and
- a potential letter 'D' to indicate a disabled key.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-13" class="outline-4">
-<h4 id="sec-1-1-13"><span class="section-number-4">1.1.13</span> Field 13 - Issuer certificate fingerprint or other info</h4>
-<div class="outline-text-4" id="text-1-1-13">
-
-
-<p>
- 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 key database it is
- only filled if the issuer certificate is available. The root has
- been reached if this is the same string as the fingerprint. The
- advantage of using this value is that it is guaranteed to have
- been been build by the same lookup algorithm as gpgsm uses.
-</p>
-<p>
- For "uid" records this field lists the preferences in the same way
- gpg's &ndash;edit-key menu does.
-</p>
-<p>
- For "sig" records, this is the fingerprint of the key that issued
- the signature. Note that this is only filled in if the signature
- verified correctly. Note also that for various technical reasons,
- this fingerprint is only available if &ndash;no-sig-cache is used.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-14" class="outline-4">
-<h4 id="sec-1-1-14"><span class="section-number-4">1.1.14</span> Field 14 - Flag field</h4>
-<div class="outline-text-4" id="text-1-1-14">
-
-
-<p>
- Flag field used in the &ndash;edit menu output
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-15" class="outline-4">
-<h4 id="sec-1-1-15"><span class="section-number-4">1.1.15</span> Field 15 - S/N of a token</h4>
-<div class="outline-text-4" id="text-1-1-15">
-
-
-<p>
- Used in sec/sbb to print the serial number of a token (internal
- protect mode 1002) or a '#' if that key is a simple stub (internal
- protect mode 1001)
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-1-1-16" class="outline-4">
-<h4 id="sec-1-1-16"><span class="section-number-4">1.1.16</span> Field 16 - Hash algorithm</h4>
-<div class="outline-text-4" id="text-1-1-16">
-
-
-<p>
- For sig records, this is the used hash algorithm. For example:
- 2 = SHA-1, 8 = SHA-256.
-</p>
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-1-2" class="outline-3">
-<h3 id="sec-1-2"><span class="section-number-3">1.2</span> Special fields</h3>
-<div class="outline-text-3" id="text-1-2">
-
-
-
-</div>
-
-<div id="outline-container-1-2-1" class="outline-4">
-<h4 id="sec-1-2-1"><span class="section-number-4">1.2.1</span> PKD - Public key data</h4>
-<div class="outline-text-4" id="text-1-2-1">
-
-
-<p>
- If field 1 has the tag "pkd", a listing looks like this:
-</p>
-
-
-<pre class="example">pkd:0:1024:B665B1435F4C2 .... FF26ABB:
- ! ! !-- the value
- ! !------ for information number of bits in the value
- !--------- index (eg. DSA goes from 0 to 3: p,q,g,y)
-</pre>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-1-2-2" class="outline-4">
-<h4 id="sec-1-2-2"><span class="section-number-4">1.2.2</span> TRU - Trust database information</h4>
-<div class="outline-text-4" id="text-1-2-2">
-
-<p> Example for a "tru" trust base record:
-</p>
-
-
-<pre class="example">tru:o:0:1166697654:1:3:1:5
-</pre>
-
-
-<dl>
-<dt>Field 2</dt><dd>Reason for staleness of trust. If this field is
- empty, then the trustdb is not stale. This field may
- have multiple flags in it:
-
-<dl>
-<dt>o</dt><dd>Trustdb is old
-</dd>
-<dt>t</dt><dd>Trustdb was built with a different trust model
- than the one we are using now.
-
-</dd>
-</dl>
-
-</dd>
-<dt>Field 3</dt><dd>Trust model
-
-<dl>
-<dt>0</dt><dd>Classic trust model, as used in PGP 2.x.
-</dd>
-<dt>1</dt><dd>PGP trust model, as used in PGP 6 and later.
- This is the same as the classic trust model,
- except for the addition of trust signatures.
-
-</dd>
-</dl>
-
-<p> GnuPG before version 1.4 used the classic trust model
- by default. GnuPG 1.4 and later uses the PGP trust
- model by default.
-</p>
-</dd>
-<dt>Field 4</dt><dd>Date trustdb was created in seconds since Epoch.
-</dd>
-<dt>Field 5</dt><dd>Date trustdb will expire in seconds since Epoch.
-</dd>
-<dt>Field 6</dt><dd>Number of marginally trusted users to introduce a new
- key signer (gpg's option &ndash;marginals-needed).
-</dd>
-<dt>Field 7</dt><dd>Number of completely trusted users to introduce a new
- key signer. (gpg's option &ndash;completes-needed)
-
-</dd>
-<dt>Field 8</dt><dd>Maximum depth of a certification chain. (gpg's option
- &ndash;max-cert-depth)
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-1-2-3" class="outline-4">
-<h4 id="sec-1-2-3"><span class="section-number-4">1.2.3</span> SPK - Signature subpacket records</h4>
-<div class="outline-text-4" id="text-1-2-3">
-
-
-<dl>
-<dt>Field 2</dt><dd>Subpacket number as per RFC-4880 and later.
-</dd>
-<dt>Field 3</dt><dd>Flags in hex. Currently the only two bits assigned
- are 1, to indicate that the subpacket came from the
- hashed part of the signature, and 2, to indicate the
- subpacket was marked critical.
-</dd>
-<dt>Field 4</dt><dd>Length of the subpacket. Note that this is the
- length of the subpacket, and not the length of field
- 5 below. Due to the need for %-encoding, the length
- of field 5 may be up to 3x this value.
-</dd>
-<dt>Field 5</dt><dd>The subpacket data. Printable ASCII is shown as
- ASCII, but other values are rendered as %XX where XX
- is the hex value for the byte.
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-1-2-4" class="outline-4">
-<h4 id="sec-1-2-4"><span class="section-number-4">1.2.4</span> CFG - Configuration data</h4>
-<div class="outline-text-4" id="text-1-2-4">
-
-
-<p>
- &ndash;list-config outputs information about the GnuPG configuration
- for the benefit of frontends or other programs that call GnuPG.
- There are several list-config items, all colon delimited like the
- rest of the &ndash;with-colons output. The first field is always "cfg"
- to indicate configuration information. The second field is one of
- (with examples):
-</p>
-<dl>
-<dt>version</dt><dd>The third field contains the version of GnuPG.
-
-<pre class="example">
-cfg:version:1.3.5
-</pre>
-
-
-</dd>
-<dt>pubkey</dt><dd>The third field contains the public key algorithms
- this version of GnuPG supports, separated by
- semicolons. The algorithm numbers are as specified in
- RFC-4880. Note that in contrast to the &ndash;status-fd
- interface these are <span style="text-decoration:underline;">not</span> the Libgcrypt identifiers.
-
-<pre class="example">
-cfg:pubkey:1;2;3;16;17
-</pre>
-
-
-</dd>
-<dt>cipher</dt><dd>The third field contains the symmetric ciphers this
- version of GnuPG supports, separated by semicolons.
- The cipher numbers are as specified in RFC-4880.
-
-<pre class="example">
-cfg:cipher:2;3;4;7;8;9;10
-</pre>
-
-
-</dd>
-<dt>digest</dt><dd>The third field contains the digest (hash) algorithms
- this version of GnuPG supports, separated by
- semicolons. The digest numbers are as specified in
- RFC-4880.
-
-<pre class="example">
-cfg:digest:1;2;3;8;9;10
-</pre>
-
-
-</dd>
-<dt>compress</dt><dd>The third field contains the compression algorithms
- this version of GnuPG supports, separated by
- semicolons. The algorithm numbers are as specified
- in RFC-4880.
-
-<pre class="example">
-cfg:compress:0;1;2;3
-</pre>
-
-
-</dd>
-<dt>group</dt><dd>The third field contains the name of the group, and the
- fourth field contains the values that the group expands
- to, separated by semicolons.
-
-<p>
- For example, a group of:
-</p><pre class="example">
-group mynames = paige 0x12345678 joe patti
-</pre>
-
-<p> would result in:
-</p><pre class="example">
-cfg:group:mynames:patti;joe;0x12345678;paige
-</pre>
-
-</dd>
-</dl>
-
-
-
-</div>
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-2" class="outline-2">
-<h2 id="sec-2"><span class="section-number-2">2</span> Format of the &ndash;status-fd output</h2>
-<div class="outline-text-2" id="text-2">
-
-
-<p>
- Every line is prefixed with "[GNUPG:] ", followed by a keyword with
- the type of the status line and some arguments depending on the type
- (maybe none); an application should always be prepared to see more
- arguments in future versions.
-</p>
-
-</div>
-
-<div id="outline-container-2-1" class="outline-3">
-<h3 id="sec-2-1"><span class="section-number-3">2.1</span> General status codes</h3>
-<div class="outline-text-3" id="text-2-1">
-
-
-</div>
-
-<div id="outline-container-2-1-1" class="outline-4">
-<h4 id="sec-2-1-1"><span class="section-number-4">2.1.1</span> NEWSIG</h4>
-<div class="outline-text-4" id="text-2-1-1">
-
-<p> May be issued right before a signature verification starts. This
- is useful to define a context for parsing ERROR status messages.
- No arguments are currently defined.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-2" class="outline-4">
-<h4 id="sec-2-1-2"><span class="section-number-4">2.1.2</span> GOODSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</h4>
-<div class="outline-text-4" id="text-2-1-2">
-
-<p> The signature with the keyid is good. For each signature only one
- of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or
- ERRSIG will be emitted. In the past they were used as a marker
- for a new signature; new code should use the NEWSIG status
- instead. The username is the primary one encoded in UTF-8 and %XX
- escaped. The fingerprint may be used instead of the long keyid if
- it is available. This is the case with CMS and might eventually
- also be available for OpenPGP.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-3" class="outline-4">
-<h4 id="sec-2-1-3"><span class="section-number-4">2.1.3</span> EXPSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</h4>
-<div class="outline-text-4" id="text-2-1-3">
-
-<p> 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. The fingerprint may be used instead of the long keyid if
- it is available. This is the case with CMS and might eventually
- also be available for OpenPGP.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-4" class="outline-4">
-<h4 id="sec-2-1-4"><span class="section-number-4">2.1.4</span> EXPKEYSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</h4>
-<div class="outline-text-4" id="text-2-1-4">
-
-<p> 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. The fingerprint may be used instead of the
- long keyid if it is available. This is the case with CMS and
- might eventually also be available for OpenPGP.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-5" class="outline-4">
-<h4 id="sec-2-1-5"><span class="section-number-4">2.1.5</span> REVKEYSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</h4>
-<div class="outline-text-4" id="text-2-1-5">
-
-<p> The signature with the keyid is good, but the signature was made
- by a revoked key. The username is the primary one encoded in UTF-8
- and %XX escaped. The fingerprint may be used instead of the long
- keyid if it is available. This is the case with CMS and might
- eventually also beñ available for OpenPGP.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-6" class="outline-4">
-<h4 id="sec-2-1-6"><span class="section-number-4">2.1.6</span> BADSIG &lt;long_keyid_or_fpr&gt; &lt;username&gt;</h4>
-<div class="outline-text-4" id="text-2-1-6">
-
-<p> The signature with the keyid has not been verified okay. The
- username is the primary one encoded in UTF-8 and %XX escaped. The
- fingerprint may be used instead of the long keyid if it is
- available. This is the case with CMS and might eventually also be
- available for OpenPGP.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-7" class="outline-4">
-<h4 id="sec-2-1-7"><span class="section-number-4">2.1.7</span> ERRSIG &lt;keyid&gt; &lt;pkalgo&gt; &lt;hashalgo&gt; &lt;sig_class&gt; &lt;time&gt; &lt;rc&gt;</h4>
-<div class="outline-text-4" id="text-2-1-7">
-
-<p> It was not possible to check the signature. This may be caused by
- a missing public key or an unsupported algorithm. A RC of 4
- indicates unknown algorithm, a 9 indicates a missing public
- key. The other fields give more information about this signature.
- sig_class is a 2 byte hex-value. The fingerprint may be used
- instead of the keyid if it is available. This is the case with
- gpgsm and might eventually also be available for OpenPGP.
-</p>
-<p>
- Note, that TIME may either be the number of seconds since Epoch or
- the letter 'T'.
- an ISO 8601 string. The latter can be detected by the presence of
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-8" class="outline-4">
-<h4 id="sec-2-1-8"><span class="section-number-4">2.1.8</span> VALIDSIG &lt;args&gt;</h4>
-<div class="outline-text-4" id="text-2-1-8">
-
-
-<p>
- The args are:
-</p>
-<ul>
-<li>&lt;fingerprint_in_hex&gt;
-</li>
-<li>&lt;sig_creation_date&gt;
-</li>
-<li>&lt;sig-timestamp&gt;
-</li>
-<li>&lt;expire-timestamp&gt;
-</li>
-<li>&lt;sig-version&gt;
-</li>
-<li>&lt;reserved&gt;
-</li>
-<li>&lt;pubkey-algo&gt;
-</li>
-<li>&lt;hash-algo&gt;
-</li>
-<li>&lt;sig-class&gt;
-</li>
-<li>[ &lt;primary-key-fpr&gt; ]
-</li>
-</ul>
-
-
-<p>
- This status indicates that the signature is good. This is the same
- as GOODSIG but has the fingerprint as the argument. Both status
- lines are emitted for a good signature. All arguments here are on
- one long line. sig-timestamp is the signature creation time in
- seconds after the epoch. expire-timestamp is the signature
- expiration time in seconds after the epoch (zero means "does not
- expire"). sig-version, pubkey-algo, hash-algo, and sig-class (a
- 2-byte hex value) are all straight from the signature packet.
- PRIMARY-KEY-FPR is the fingerprint of the primary key or identical
- to the first argument. This is useful to get back to the primary
- key without running gpg again for this purpose.
-</p>
-<p>
- The primary-key-fpr parameter is used for OpenPGP and not
- class is not defined for CMS and currently set to 0 and 00.
- available for CMS signatures. The sig-version as well as the sig
-</p>
-<p>
- Note, that *-TIMESTAMP may either be a number of seconds since
- Epoch or an ISO 8601 string which can be detected by the presence
- of the letter 'T'.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-9" class="outline-4">
-<h4 id="sec-2-1-9"><span class="section-number-4">2.1.9</span> SIG_ID &lt;radix64_string&gt; &lt;sig_creation_date&gt; &lt;sig-timestamp&gt;</h4>
-<div class="outline-text-4" id="text-2-1-9">
-
-<p> This is emitted only for signatures of class 0 or 1 which have
- been verified okay. The string is a signature id and may be used
- in applications to detect replay attacks of signed messages. Note
- that only DLP algorithms give unique ids - others may yield
- duplicated ones when they have been created in the same second.
-</p>
-<p>
- Note, that SIG-TIMESTAMP may either be a number of seconds since
- Epoch or an ISO 8601 string which can be detected by the presence
- of the letter 'T'.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-10" class="outline-4">
-<h4 id="sec-2-1-10"><span class="section-number-4">2.1.10</span> ENC_TO &lt;long_keyid&gt; &lt;keytype&gt; &lt;keylength&gt;</h4>
-<div class="outline-text-4" id="text-2-1-10">
-
-<p> The message is encrypted to this LONG_KEYID. KEYTYPE is the
- numerical value of the public key algorithm or 0 if it is not
- known, KEYLENGTH is the length of the key or 0 if it is not known
- (which is currently always the case). Gpg prints this line
- always; Gpgsm only if it knows the certificate.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-11" class="outline-4">
-<h4 id="sec-2-1-11"><span class="section-number-4">2.1.11</span> BEGIN_DECRYPTION</h4>
-<div class="outline-text-4" id="text-2-1-11">
-
-<p> Mark the start of the actual decryption process. This is also
- emitted when in &ndash;list-only mode.
-</p></div>
-
-</div>
-
-<div id="outline-container-2-1-12" class="outline-4">
-<h4 id="sec-2-1-12"><span class="section-number-4">2.1.12</span> END_DECRYPTION</h4>
-<div class="outline-text-4" id="text-2-1-12">
-
-<p> Mark the end of the actual decryption process. This are also
- emitted when in &ndash;list-only mode.
-</p></div>
-
-</div>
-
-<div id="outline-container-2-1-13" class="outline-4">
-<h4 id="sec-2-1-13"><span class="section-number-4">2.1.13</span> DECRYPTION_INFO &lt;mdc_method&gt; &lt;sym_algo&gt;</h4>
-<div class="outline-text-4" id="text-2-1-13">
-
-<p> Print information about the symmetric encryption algorithm and the
- MDC method. This will be emitted even if the decryption fails.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-14" class="outline-4">
-<h4 id="sec-2-1-14"><span class="section-number-4">2.1.14</span> DECRYPTION_FAILED</h4>
-<div class="outline-text-4" id="text-2-1-14">
-
-<p> The symmetric decryption failed - one reason could be a wrong
- passphrase for a symmetrical encrypted message.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-15" class="outline-4">
-<h4 id="sec-2-1-15"><span class="section-number-4">2.1.15</span> DECRYPTION_OKAY</h4>
-<div class="outline-text-4" id="text-2-1-15">
-
-<p> The decryption process succeeded. This means, that either the
- correct secret key has been used or the correct passphrase for a
- conventional encrypted message was given. The program itself may
- return an errorcode because it may not be possible to verify a
- signature for some reasons.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-16" class="outline-4">
-<h4 id="sec-2-1-16"><span class="section-number-4">2.1.16</span> SESSION_KEY &lt;algo&gt;:&lt;hexdigits&gt;</h4>
-<div class="outline-text-4" id="text-2-1-16">
-
-<p> The session key used to decrypt the message. This message will
- only be emitted when the special option &ndash;show-session-key is
- used. The format is suitable to be passed to the option
- &ndash;override-session-key
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-17" class="outline-4">
-<h4 id="sec-2-1-17"><span class="section-number-4">2.1.17</span> BEGIN_ENCRYPTION &lt;mdc_method&gt; &lt;sym_algo&gt;</h4>
-<div class="outline-text-4" id="text-2-1-17">
-
-<p> Mark the start of the actual encryption process.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-18" class="outline-4">
-<h4 id="sec-2-1-18"><span class="section-number-4">2.1.18</span> END_ENCRYPTION</h4>
-<div class="outline-text-4" id="text-2-1-18">
-
-<p> Mark the end of the actual encryption process.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-19" class="outline-4">
-<h4 id="sec-2-1-19"><span class="section-number-4">2.1.19</span> FILE_START &lt;what&gt; &lt;filename&gt;</h4>
-<div class="outline-text-4" id="text-2-1-19">
-
-<p> Start processing a file &lt;filename&gt;. &lt;what&gt; indicates the performed
- operation:
-</p><dl>
-<dt>1</dt><dd>verify
-</dd>
-<dt>2</dt><dd>encrypt
-</dd>
-<dt>3</dt><dd>decrypt
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-2-1-20" class="outline-4">
-<h4 id="sec-2-1-20"><span class="section-number-4">2.1.20</span> FILE_DONE</h4>
-<div class="outline-text-4" id="text-2-1-20">
-
-<p> Marks the end of a file processing which has been started
- by FILE_START.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-21" class="outline-4">
-<h4 id="sec-2-1-21"><span class="section-number-4">2.1.21</span> BEGIN_SIGNING</h4>
-<div class="outline-text-4" id="text-2-1-21">
-
-<p> Mark the start of the actual signing process. This may be used as
- an indication that all requested secret keys are ready for use.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-22" class="outline-4">
-<h4 id="sec-2-1-22"><span class="section-number-4">2.1.22</span> ALREADY_SIGNED &lt;long-keyid&gt;</h4>
-<div class="outline-text-4" id="text-2-1-22">
-
-<p> Warning: This is experimental and might be removed at any time.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-23" class="outline-4">
-<h4 id="sec-2-1-23"><span class="section-number-4">2.1.23</span> SIG_CREATED &lt;type&gt; &lt;pk_algo&gt; &lt;hash_algo&gt; &lt;class&gt; &lt;timestamp&gt; &lt;keyfpr&gt;</h4>
-<div class="outline-text-4" id="text-2-1-23">
-
-<p> A signature has been created using these parameters.
- Values for type &lt;type&gt; are:
-</p><dl>
-<dt>D</dt><dd>detached
-</dd>
-<dt>C</dt><dd>cleartext
-</dd>
-<dt>S</dt><dd>standard
-</dd>
-</dl>
-
-<p> (only the first character should be checked)
-</p>
-<p>
- &lt;class&gt; are 2 hex digits with the OpenPGP signature class.
-</p>
-<p>
- Note, that TIMESTAMP may either be a number of seconds since Epoch
- or an ISO 8601 string which can be detected by the presence of the
- letter 'T'.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-24" class="outline-4">
-<h4 id="sec-2-1-24"><span class="section-number-4">2.1.24</span> NOTATION_</h4>
-<div class="outline-text-4" id="text-2-1-24">
-
-<p> There are actually two related status codes to convey notation
- data:
-</p>
-<ul>
-<li>NOTATION_NAME &lt;name&gt;
-</li>
-<li>NOTATION_DATA &lt;string&gt;
-</li>
-</ul>
-
-
-<p>
- &lt;name&gt; and &lt;string&gt; are %XX escaped; the data may be split among
- several NOTATION_DATA lines.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-25" class="outline-4">
-<h4 id="sec-2-1-25"><span class="section-number-4">2.1.25</span> POLICY_URL &lt;string&gt;</h4>
-<div class="outline-text-4" id="text-2-1-25">
-
-<p> Note that URL in &lt;string&gt; is %XX escaped.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-26" class="outline-4">
-<h4 id="sec-2-1-26"><span class="section-number-4">2.1.26</span> PLAINTEXT &lt;format&gt; &lt;timestamp&gt; &lt;filename&gt;</h4>
-<div class="outline-text-4" id="text-2-1-26">
-
-<p> This indicates the format of the plaintext that is about to be
- written. The format is a 1 byte hex code that shows the format of
- the plaintext: 62 ('b') is binary data, 74 ('t') is text data with
- no character set specified, and 75 ('u') is text data encoded in
- the UTF-8 character set. The timestamp is in seconds since the
- epoch. If a filename is available it gets printed as the third
- argument, percent-escaped as usual.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-27" class="outline-4">
-<h4 id="sec-2-1-27"><span class="section-number-4">2.1.27</span> PLAINTEXT_LENGTH &lt;length&gt;</h4>
-<div class="outline-text-4" id="text-2-1-27">
-
-<p> This indicates the length of the plaintext that is about to be
- written. Note that if the plaintext packet has partial length
- encoding it is not possible to know the length ahead of time. In
- that case, this status tag does not appear.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-1-28" class="outline-4">
-<h4 id="sec-2-1-28"><span class="section-number-4">2.1.28</span> ATTRIBUTE &lt;arguments&gt;</h4>
-<div class="outline-text-4" id="text-2-1-28">
-
-<p> The list or argemnts are:
-</p><ul>
-<li>&lt;fpr&gt;
-</li>
-<li>&lt;octets&gt;
-</li>
-<li>&lt;type&gt;
-</li>
-<li>&lt;index&gt;
-</li>
-<li>&lt;count&gt;
-</li>
-<li>&lt;timestamp&gt;
-</li>
-<li>&lt;expiredate&gt;
-</li>
-<li>&lt;flags&gt;
-</li>
-</ul>
-
-
-<p>
- This is one long line issued for each attribute subpacket when an
- attribute packet is seen during key listing. &lt;fpr&gt; is the
- fingerprint of the key. &lt;octets&gt; is the length of the attribute
- subpacket. &lt;type&gt; is the attribute type (e.g. 1 for an image).
- &lt;index&gt; and &lt;count&gt; indicate that this is the N-th indexed
- subpacket of count total subpackets in this attribute packet.
- &lt;timestamp&gt; and &lt;expiredate&gt; 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. &lt;flags&gt; are a bitwise OR
- of:
-</p><dl>
-<dt>0x01</dt><dd>this attribute packet is a primary uid
-</dd>
-<dt>0x02</dt><dd>this attribute packet is revoked
-</dd>
-<dt>0x04</dt><dd>this attribute packet is expired
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-2-1-29" class="outline-4">
-<h4 id="sec-2-1-29"><span class="section-number-4">2.1.29</span> SIG_SUBPACKET &lt;type&gt; &lt;flags&gt; &lt;len&gt; &lt;data&gt;</h4>
-<div class="outline-text-4" id="text-2-1-29">
-
-<p> This indicates that a signature subpacket was seen. The format is
- the same as the "spk" record above.
-</p>
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-2-2" class="outline-3">
-<h3 id="sec-2-2"><span class="section-number-3">2.2</span> Key related</h3>
-<div class="outline-text-3" id="text-2-2">
-
-
-</div>
-
-<div id="outline-container-2-2-1" class="outline-4">
-<h4 id="sec-2-2-1"><span class="section-number-4">2.2.1</span> INV_RECP, INV_SGNR</h4>
-<div class="outline-text-4" id="text-2-2-1">
-
-<p> The two similar status codes:
-</p>
-<ul>
-<li>INV_RECP &lt;reason&gt; &lt;requested_recipient&gt;
-</li>
-<li>INV_SGNR &lt;reason&gt; &lt;requested_sender&gt;
-</li>
-</ul>
-
-
-<p>
- are issued for each unusable recipient/sender. The reasons codes
- currently in use are:
-</p>
-<dl>
-<dt>0</dt><dd>No specific reason given
-</dd>
-<dt>1</dt><dd>Not Found
-</dd>
-<dt>2</dt><dd>Ambigious specification
-</dd>
-<dt>3</dt><dd>Wrong key usage
-</dd>
-<dt>4</dt><dd>Key revoked
-</dd>
-<dt>5</dt><dd>Key expired
-</dd>
-<dt>6</dt><dd>No CRL known
-</dd>
-<dt>7</dt><dd>CRL too old
-</dd>
-<dt>8</dt><dd>Policy mismatch
-</dd>
-<dt>9</dt><dd>Not a secret key
-</dd>
-<dt>10</dt><dd>Key not trusted
-</dd>
-<dt>11</dt><dd>Missing certificate
-</dd>
-<dt>12</dt><dd>Missing issuer certificate
-</dd>
-</dl>
-
-
-<p>
- Note that for historical reasons the INV_RECP status is also used
- for gpgsm's SIGNER command where it relates to signer's of course.
- Newer GnuPG versions are using INV_SGNR; applications should
- ignore the INV_RECP during the sender's command processing once
- they have seen an INV_SGNR. Different codes are used so that they
- can be distinguish while doing an encrypt+sign operation.
-</p></div>
-
-</div>
-
-<div id="outline-container-2-2-2" class="outline-4">
-<h4 id="sec-2-2-2"><span class="section-number-4">2.2.2</span> NO_RECP &lt;reserved&gt;</h4>
-<div class="outline-text-4" id="text-2-2-2">
-
-<p> Issued if no recipients are usable.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-3" class="outline-4">
-<h4 id="sec-2-2-3"><span class="section-number-4">2.2.3</span> NO_SGNR &lt;reserved&gt;</h4>
-<div class="outline-text-4" id="text-2-2-3">
-
-<p> Issued if no senders are usable.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-4" class="outline-4">
-<h4 id="sec-2-2-4"><span class="section-number-4">2.2.4</span> KEYEXPIRED &lt;expire-timestamp&gt;</h4>
-<div class="outline-text-4" id="text-2-2-4">
-
-<p> The key has expired. expire-timestamp is the expiration time in
- seconds since Epoch. This status line is not very useful because
- it will also be emitted for expired subkeys even if this subkey is
- not used. To check whether a key used to sign a message has
- expired, the EXPKEYSIG status line is to be used.
-</p>
-<p>
- Note, that the TIMESTAMP may either be a number of seconds since
- Epoch or an ISO 8601 string which can be detected by the presence
- of the letter 'T'.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-5" class="outline-4">
-<h4 id="sec-2-2-5"><span class="section-number-4">2.2.5</span> KEYREVOKED</h4>
-<div class="outline-text-4" id="text-2-2-5">
-
-<p> The used key has been revoked by its owner. No arguments yet.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-6" class="outline-4">
-<h4 id="sec-2-2-6"><span class="section-number-4">2.2.6</span> NO_PUBKEY &lt;long keyid&gt;</h4>
-<div class="outline-text-4" id="text-2-2-6">
-
-<p> The public key is not available
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-7" class="outline-4">
-<h4 id="sec-2-2-7"><span class="section-number-4">2.2.7</span> NO_SECKEY &lt;long keyid&gt;</h4>
-<div class="outline-text-4" id="text-2-2-7">
-
-<p> The secret key is not available
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-8" class="outline-4">
-<h4 id="sec-2-2-8"><span class="section-number-4">2.2.8</span> KEY_CREATED &lt;type&gt; &lt;fingerprint&gt; [&lt;handle&gt;]</h4>
-<div class="outline-text-4" id="text-2-2-8">
-
-<p> A key has been created. Values for &lt;type&gt; are:
-</p><dl>
-<dt>B</dt><dd>primary and subkey
-</dd>
-<dt>P</dt><dd>primary
-</dd>
-<dt>S</dt><dd>subkey
-</dd>
-</dl>
-
-<p> The fingerprint is one of the primary key for type B and P and the
- one of the subkey for S. Handle is an arbitrary non-whitespace
- string used to match key parameters from batch key creation run.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-9" class="outline-4">
-<h4 id="sec-2-2-9"><span class="section-number-4">2.2.9</span> KEY_NOT_CREATED [&lt;handle&gt;]</h4>
-<div class="outline-text-4" id="text-2-2-9">
-
-<p> The key from batch run has not been created due to errors.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-10" class="outline-4">
-<h4 id="sec-2-2-10"><span class="section-number-4">2.2.10</span> TRUST_</h4>
-<div class="outline-text-4" id="text-2-2-10">
-
-<p> These are several similar status codes:
-</p>
-<ul>
-<li>TRUST_UNDEFINED &lt;error_token&gt;
-</li>
-<li>TRUST_NEVER &lt;error_token&gt;
-</li>
-<li>TRUST_MARGINAL [0 [&lt;validation_model&gt;]]
-</li>
-<li>TRUST_FULLY [0 [&lt;validation_model&gt;]]
-</li>
-<li>TRUST_ULTIMATE [0 [&lt;validation_model&gt;]]
-</li>
-</ul>
-
-
-<p>
- For good signatures one of these status lines are emitted to
- indicate the validity of the key used to create the signature.
- The error token values are currently only emitted by gpgsm.
-</p>
-<p>
- VALIDATION_MODEL describes the algorithm used to check the
- validity of the key. The defaults are the standard Web of Trust
- model for gpg and the the standard X.509 model for gpgsm. The
- defined values are
-</p>
-<dl>
-<dt>pgp </dt><dd>The standard PGP WoT.
-</dd>
-<dt>shell</dt><dd>The standard X.509 model.
-</dd>
-<dt>chain</dt><dd>The chain model.
-</dd>
-<dt>steed</dt><dd>The STEED model.
-</dd>
-</dl>
-
-
-<p>
- Note that the term <code>TRUST_</code> in the status names is used for
- historic reasons; we now speak of validity.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-2-11" class="outline-4">
-<h4 id="sec-2-2-11"><span class="section-number-4">2.2.11</span> PKA_TRUST_</h4>
-<div class="outline-text-4" id="text-2-2-11">
-
-<p> This is is one:
-</p>
-<ul>
-<li>PKA_TRUST_GOOD &lt;mailbox&gt;
-</li>
-<li>PKA_TRUST_BAD &lt;mailbox&gt;
-</li>
-</ul>
-
-
-<p>
- Depending on the outcome of the PKA check one of the above status
- codes is emitted in addition to a <code>TRUST_*</code> status.
-</p>
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-2-3" class="outline-3">
-<h3 id="sec-2-3"><span class="section-number-3">2.3</span> Remote control</h3>
-<div class="outline-text-3" id="text-2-3">
-
-
-</div>
-
-<div id="outline-container-2-3-1" class="outline-4">
-<h4 id="sec-2-3-1"><span class="section-number-4">2.3.1</span> GET_BOOL, GET_LINE, GET_HIDDEN, GOT_IT</h4>
-<div class="outline-text-4" id="text-2-3-1">
-
-
-<p>
- These status line are used with &ndash;command-fd for interactive
- control of the process.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-3-2" class="outline-4">
-<h4 id="sec-2-3-2"><span class="section-number-4">2.3.2</span> USERID_HINT &lt;long main keyid&gt; &lt;string&gt;</h4>
-<div class="outline-text-4" id="text-2-3-2">
-
-<p> Give a hint about the user ID for a certain keyID.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-3-3" class="outline-4">
-<h4 id="sec-2-3-3"><span class="section-number-4">2.3.3</span> NEED_PASSPHRASE &lt;long keyid&gt; &lt;long main keyid&gt; &lt;keytype&gt; &lt;keylength&gt;</h4>
-<div class="outline-text-4" id="text-2-3-3">
-
-<p> Issued whenever a passphrase is needed. KEYTYPE is the numerical
- value of the public key algorithm or 0 if this is not applicable,
- KEYLENGTH is the length of the key or 0 if it is not known (this
- is currently always the case).
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-3-4" class="outline-4">
-<h4 id="sec-2-3-4"><span class="section-number-4">2.3.4</span> NEED_PASSPHRASE_SYM &lt;cipher_algo&gt; &lt;s2k_mode&gt; &lt;s2k_hash&gt;</h4>
-<div class="outline-text-4" id="text-2-3-4">
-
-<p> Issued whenever a passphrase for symmetric encryption is needed.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-3-5" class="outline-4">
-<h4 id="sec-2-3-5"><span class="section-number-4">2.3.5</span> NEED_PASSPHRASE_PIN &lt;card_type&gt; &lt;chvno&gt; [&lt;serialno&gt;]</h4>
-<div class="outline-text-4" id="text-2-3-5">
-
-<p> Issued whenever a PIN is requested to unlock a card.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-3-6" class="outline-4">
-<h4 id="sec-2-3-6"><span class="section-number-4">2.3.6</span> MISSING_PASSPHRASE</h4>
-<div class="outline-text-4" id="text-2-3-6">
-
-<p> No passphrase was supplied. An application which encounters this
- message may want to stop parsing immediately because the next
- message will probably be a BAD_PASSPHRASE. However, if the
- application is a wrapper around the key edit menu functionality it
- might not make sense to stop parsing but simply ignoring the
- following BAD_PASSPHRASE.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-3-7" class="outline-4">
-<h4 id="sec-2-3-7"><span class="section-number-4">2.3.7</span> BAD_PASSPHRASE &lt;long keyid&gt;</h4>
-<div class="outline-text-4" id="text-2-3-7">
-
-<p> The supplied passphrase was wrong or not given. In the latter
- case you may have seen a MISSING_PASSPHRASE.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-3-8" class="outline-4">
-<h4 id="sec-2-3-8"><span class="section-number-4">2.3.8</span> GOOD_PASSPHRASE</h4>
-<div class="outline-text-4" id="text-2-3-8">
-
-<p> The supplied passphrase was good and the secret key material
- is therefore usable.
-</p>
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-2-4" class="outline-3">
-<h3 id="sec-2-4"><span class="section-number-3">2.4</span> Import/Export</h3>
-<div class="outline-text-3" id="text-2-4">
-
-
-</div>
-
-<div id="outline-container-2-4-1" class="outline-4">
-<h4 id="sec-2-4-1"><span class="section-number-4">2.4.1</span> IMPORT_CHECK &lt;long keyid&gt; &lt;fingerprint&gt; &lt;user ID&gt;</h4>
-<div class="outline-text-4" id="text-2-4-1">
-
-<p> This status is emitted in interactive mode right before
- the "import.okay" prompt.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-4-2" class="outline-4">
-<h4 id="sec-2-4-2"><span class="section-number-4">2.4.2</span> IMPORTED &lt;long keyid&gt; &lt;username&gt;</h4>
-<div class="outline-text-4" id="text-2-4-2">
-
-<p> The keyid and name of the signature just imported
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-4-3" class="outline-4">
-<h4 id="sec-2-4-3"><span class="section-number-4">2.4.3</span> IMPORT_OK &lt;reason&gt; [&lt;fingerprint&gt;]</h4>
-<div class="outline-text-4" id="text-2-4-3">
-
-<p> The key with the primary key's FINGERPRINT has been imported.
- REASON flags are:
-</p>
-<dl>
-<dt>0</dt><dd>Not actually changed
-</dd>
-<dt>1</dt><dd>Entirely new key.
-</dd>
-<dt>2</dt><dd>New user IDs
-</dd>
-<dt>4</dt><dd>New signatures
-</dd>
-<dt>8</dt><dd>New subkeys
-</dd>
-<dt>16</dt><dd>Contains private key.
-</dd>
-</dl>
-
-
-<p>
- The flags may be ORed.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-4-4" class="outline-4">
-<h4 id="sec-2-4-4"><span class="section-number-4">2.4.4</span> IMPORT_PROBLEM &lt;reason&gt; [&lt;fingerprint&gt;]</h4>
-<div class="outline-text-4" id="text-2-4-4">
-
-<p> Issued for each import failure. Reason codes are:
-</p>
-<dl>
-<dt>0</dt><dd>No specific reason given.
-</dd>
-<dt>1</dt><dd>Invalid Certificate.
-</dd>
-<dt>2</dt><dd>Issuer Certificate missing.
-</dd>
-<dt>3</dt><dd>Certificate Chain too long.
-</dd>
-<dt>4</dt><dd>Error storing certificate.
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-2-4-5" class="outline-4">
-<h4 id="sec-2-4-5"><span class="section-number-4">2.4.5</span> IMPORT_RES &lt;args&gt;</h4>
-<div class="outline-text-4" id="text-2-4-5">
-
-<p> Final statistics on import process (this is one long line). The
- args are a list of unsigned numbers separated by white space:
-</p>
-<ul>
-<li>&lt;count&gt;
-</li>
-<li>&lt;no_user_id&gt;
-</li>
-<li>&lt;imported&gt;
-</li>
-<li>&lt;imported_rsa&gt;
-</li>
-<li>&lt;unchanged&gt;
-</li>
-<li>&lt;n_uids&gt;
-</li>
-<li>&lt;n_subk&gt;
-</li>
-<li>&lt;n_sigs&gt;
-</li>
-<li>&lt;n_revoc&gt;
-</li>
-<li>&lt;sec_read&gt;
-</li>
-<li>&lt;sec_imported&gt;
-</li>
-<li>&lt;sec_dups&gt;
-</li>
-<li>&lt;skipped_new_keys&gt;
-</li>
-<li>&lt;not_imported&gt;
-</li>
-</ul>
-
-
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-2-5" class="outline-3">
-<h3 id="sec-2-5"><span class="section-number-3">2.5</span> Smartcard related</h3>
-<div class="outline-text-3" id="text-2-5">
-
-
-</div>
-
-<div id="outline-container-2-5-1" class="outline-4">
-<h4 id="sec-2-5-1"><span class="section-number-4">2.5.1</span> CARDCTRL &lt;what&gt; [&lt;serialno&gt;]</h4>
-<div class="outline-text-4" id="text-2-5-1">
-
-<p> This is used to control smartcard operations. Defined values for
- WHAT are:
-</p>
-<dl>
-<dt>1</dt><dd>Request insertion of a card. Serialnumber may be given
- to request a specific card. Used by gpg 1.4 w/o
- scdaemon
-</dd>
-<dt>2</dt><dd>Request removal of a card. Used by gpg 1.4 w/o scdaemon.
-</dd>
-<dt>3</dt><dd>Card with serialnumber detected
-</dd>
-<dt>4</dt><dd>No card available
-</dd>
-<dt>5</dt><dd>No card reader available
-</dd>
-<dt>6</dt><dd>No card support available
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-2-5-2" class="outline-4">
-<h4 id="sec-2-5-2"><span class="section-number-4">2.5.2</span> SC_OP_FAILURE [&lt;code&gt;]</h4>
-<div class="outline-text-4" id="text-2-5-2">
-
-<p> An operation on a smartcard definitely failed. Currently there is
- no indication of the actual error code, but application should be
- prepared to later accept more arguments. Defined values for
- &lt;code&gt; are:
-</p>
-<dl>
-<dt>0</dt><dd>unspecified error (identically to a missing CODE)
-</dd>
-<dt>1</dt><dd>canceled
-</dd>
-<dt>2</dt><dd>bad PIN
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-2-5-3" class="outline-4">
-<h4 id="sec-2-5-3"><span class="section-number-4">2.5.3</span> SC_OP_SUCCESS</h4>
-<div class="outline-text-4" id="text-2-5-3">
-
-<p> A smart card operaion succeeded. This status is only printed for
- certain operation and is mostly useful to check whether a PIN
- change really worked.
-</p>
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-2-6" class="outline-3">
-<h3 id="sec-2-6"><span class="section-number-3">2.6</span> Miscellaneous status codes</h3>
-<div class="outline-text-3" id="text-2-6">
-
-
-</div>
-
-<div id="outline-container-2-6-1" class="outline-4">
-<h4 id="sec-2-6-1"><span class="section-number-4">2.6.1</span> NODATA &lt;what&gt;</h4>
-<div class="outline-text-4" id="text-2-6-1">
-
-<p> No data has been found. Codes for WHAT are:
-</p>
-<dl>
-<dt>1</dt><dd>No armored data.
-</dd>
-<dt>2</dt><dd>Expected a packet but did not found one.
-</dd>
-<dt>3</dt><dd>Invalid packet found, this may indicate a non OpenPGP
- message.
-</dd>
-<dt>4</dt><dd>Signature expected but not found
-</dd>
-</dl>
-
-
-<p>
- You may see more than one of these status lines.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-6-2" class="outline-4">
-<h4 id="sec-2-6-2"><span class="section-number-4">2.6.2</span> UNEXPECTED &lt;what&gt;</h4>
-<div class="outline-text-4" id="text-2-6-2">
-
-<p> Unexpected data has been encountered. Codes for WHAT are:
-</p><dl>
-<dt>0</dt><dd>Not further specified
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-2-6-3" class="outline-4">
-<h4 id="sec-2-6-3"><span class="section-number-4">2.6.3</span> TRUNCATED &lt;maxno&gt;</h4>
-<div class="outline-text-4" id="text-2-6-3">
-
-<p> The output was truncated to MAXNO items. This status code is
- issued for certain external requests.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-6-4" class="outline-4">
-<h4 id="sec-2-6-4"><span class="section-number-4">2.6.4</span> ERROR &lt;error location&gt; &lt;error code&gt; [&lt;more&gt;]</h4>
-<div class="outline-text-4" id="text-2-6-4">
-
-<p> This is a generic error status message, it might be followed by
- error location specific data. &lt;error code&gt; and &lt;error_location&gt;
- should not contain spaces. The error code is a either a string
- commencing with a letter or such a string prefixed with a
- numerical error code and an underscore; e.g.: "151011327_EOF".
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-6-5" class="outline-4">
-<h4 id="sec-2-6-5"><span class="section-number-4">2.6.5</span> SUCCESS [&lt;location&gt;]</h4>
-<div class="outline-text-4" id="text-2-6-5">
-
-<p> Postive confirimation that an operation succeeded. &lt;location&gt; is
- optional but if given should not contain spaces. Used only with a
- few commands.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-6-6" class="outline-4">
-<h4 id="sec-2-6-6"><span class="section-number-4">2.6.6</span> BADARMOR</h4>
-<div class="outline-text-4" id="text-2-6-6">
-
-<p> The ASCII armor is corrupted. No arguments yet.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-6-7" class="outline-4">
-<h4 id="sec-2-6-7"><span class="section-number-4">2.6.7</span> DELETE_PROBLEM &lt;reason_code&gt;</h4>
-<div class="outline-text-4" id="text-2-6-7">
-
-<p> Deleting a key failed. Reason codes are:
-</p><dl>
-<dt>1</dt><dd>No such key
-</dd>
-<dt>2</dt><dd>Must delete secret key first
-</dd>
-<dt>3</dt><dd>Ambigious specification
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-2-6-8" class="outline-4">
-<h4 id="sec-2-6-8"><span class="section-number-4">2.6.8</span> PROGRESS &lt;what&gt; &lt;char&gt; &lt;cur&gt; &lt;total&gt;</h4>
-<div class="outline-text-4" id="text-2-6-8">
-
-<p> Used by the primegen and Public key functions to indicate
- progress. &lt;char&gt; is the character displayed with no &ndash;status-fd
- enabled, with the linefeed replaced by an 'X'. &lt;cur&gt; is the
- current amount done and &lt;total&gt; is amount to be done; a &lt;total&gt; of
- 0 indicates that the total amount is not known. The condition
-</p><pre class="example">
- TOTAL &amp;&amp; CUR == TOTAL
-</pre>
-
-<p> may be used to detect the end of an operation.
-</p>
-<p>
- Well known values for WHAT are:
-</p>
-<dl>
-<dt>pk_dsa </dt><dd>DSA key generation
-</dd>
-<dt>pk_elg </dt><dd>Elgamal key generation
-</dd>
-<dt>primegen</dt><dd>Prime generation
-</dd>
-<dt>need_entropy</dt><dd>Waiting for new entropy in the RNG
-</dd>
-<dt>tick</dt><dd>Generic tick without any special meaning - useful
- for letting clients know that the server is still
- working.
-</dd>
-<dt>starting_agent</dt><dd>A gpg-agent was started because it is not
- running as a daemon.
-</dd>
-<dt>learncard</dt><dd>Send by the agent and gpgsm while learing
- the data of a smartcard.
-</dd>
-<dt>card_busy</dt><dd>A smartcard is still working
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-2-6-9" class="outline-4">
-<h4 id="sec-2-6-9"><span class="section-number-4">2.6.9</span> BACKUP_KEY_CREATED &lt;fingerprint&gt; &lt;fname&gt;</h4>
-<div class="outline-text-4" id="text-2-6-9">
-
-<p> A backup of a key identified by &lt;fingerprint&gt; has been writte to
- the file &lt;fname&gt;; &lt;fname&gt; is percent-escaped.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-6-10" class="outline-4">
-<h4 id="sec-2-6-10"><span class="section-number-4">2.6.10</span> MOUNTPOINT &lt;name&gt;</h4>
-<div class="outline-text-4" id="text-2-6-10">
-
-<p> &lt;name&gt; is a percent-plus escaped filename describing the
- mountpoint for the current operation (e.g. used by "g13 &ndash;mount").
- This may either be the specified mountpoint or one randomly
- choosen by g13.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-2-6-11" class="outline-4">
-<h4 id="sec-2-6-11"><span class="section-number-4">2.6.11</span> PINENTRY_LAUNCHED &lt;pid&gt;</h4>
-<div class="outline-text-4" id="text-2-6-11">
-
-<p> This status line is emitted by gpg to notify a client that a
- Pinentry has been launched. &lt;pid&gt; is the PID of the Pinentry. It
- may be used to display a hint to the user but can't be used to
- synchronize with Pinentry. Note that there is also an Assuan
- inquiry line with the same name used internally or, if enabled,
- send to the client instead of this status line. Such an inquiry
- may be used to sync with Pinentry
-</p>
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-2-7" class="outline-3">
-<h3 id="sec-2-7"><span class="section-number-3">2.7</span> Obsolete status codes</h3>
-<div class="outline-text-3" id="text-2-7">
-
-
-</div>
-
-<div id="outline-container-2-7-1" class="outline-4">
-<h4 id="sec-2-7-1"><span class="section-number-4">2.7.1</span> SIGEXPIRED</h4>
-<div class="outline-text-4" id="text-2-7-1">
-
-<p> Removed on 2011-02-04. This is deprecated in favor of KEYEXPIRED.
-</p></div>
-
-</div>
-
-<div id="outline-container-2-7-2" class="outline-4">
-<h4 id="sec-2-7-2"><span class="section-number-4">2.7.2</span> RSA_OR_IDEA</h4>
-<div class="outline-text-4" id="text-2-7-2">
-
-<p> Obsolete. This status message used to be emitted for requests to
- use the IDEA or RSA algorithms. It has been dropped from GnuPG
- 2.1 after the respective patents expired.
-</p></div>
-
-</div>
-
-<div id="outline-container-2-7-3" class="outline-4">
-<h4 id="sec-2-7-3"><span class="section-number-4">2.7.3</span> SHM_INFO, SHM_GET, SHM_GET_BOOL, SHM_GET_HIDDEN</h4>
-<div class="outline-text-4" id="text-2-7-3">
-
-<p> These were used for the ancient shared memory based co-processing.
-</p></div>
-
-</div>
-
-<div id="outline-container-2-7-4" class="outline-4">
-<h4 id="sec-2-7-4"><span class="section-number-4">2.7.4</span> BEGIN_STREAM, END_STREAM</h4>
-<div class="outline-text-4" id="text-2-7-4">
-
-<p> Used to issued by the experimental pipemode.
-</p>
-
-</div>
-</div>
-</div>
-
-</div>
-
-<div id="outline-container-3" class="outline-2">
-<h2 id="sec-3"><span class="section-number-2">3</span> Format of the &ndash;attribute-fd output</h2>
-<div class="outline-text-2" id="text-3">
-
-
-<p>
- When &ndash;attribute-fd is set, during key listings (&ndash;list-keys,
- &ndash;list-secret-keys) GnuPG dumps each attribute packet to the file
- descriptor specified. &ndash;attribute-fd is intended for use with
- &ndash;status-fd as part of the required information is carried on the
- ATTRIBUTE status tag (see above).
-</p>
-<p>
- The contents of the attribute data is specified by RFC 4880. For
- convenience, here is the Photo ID format, as it is currently the
- only attribute defined:
-</p>
-<dl>
-<dt>Byte 0-1</dt><dd>The length of the image header. Due to a historical
- accident (i.e. oops!) back in the NAI PGP days, this
- is a little-endian number. Currently 16 (0x10 0x00).
-
-</dd>
-<dt>Byte 2</dt><dd>The image header version. Currently 0x01.
-
-</dd>
-<dt>Byte 3</dt><dd>Encoding format. 0x01 == JPEG.
-
-</dd>
-<dt>Byte 4-15</dt><dd>Reserved, and currently unused.
-</dd>
-</dl>
-
-
-<p>
- All other data after this header is raw image (JPEG) data.
-</p>
-
-</div>
-
-</div>
-
-<div id="outline-container-4" class="outline-2">
-<h2 id="sec-4"><span class="section-number-2">4</span> Unattended key generation</h2>
-<div class="outline-text-2" id="text-4">
-
-
-<p>
- Please see the GnuPG manual for a description.
-</p>
-
-</div>
-
-</div>
-
-<div id="outline-container-5" class="outline-2">
-<h2 id="sec-5"><span class="section-number-2">5</span> Layout of the TrustDB</h2>
-<div class="outline-text-2" id="text-5">
-
-
-<p>
- The TrustDB is built from fixed length records, where the first byte
- describes the record type. All numeric values are stored in network
- byte order. The length of each record is 40 bytes. The first record
- of the DB is always of type 1 and this is the only record of this
- type.
-</p>
-<p>
- FIXME: The layout changed, document it here.
-</p>
-
-
-<pre class="example">Record type 0:
---------------
- Unused record, can be reused for any purpose.
-
-Record type 1:
---------------
- Version information for this TrustDB. This is always the first
- record of the DB and the only one with type 1.
- 1 byte value 1
- 3 bytes 'gpg' magic value
- 1 byte Version of the TrustDB (2)
- 1 byte marginals needed
- 1 byte completes needed
- 1 byte max_cert_depth
- The three items are used to check whether the cached
- validity value from the dir record can be used.
- 1 u32 locked flags [not used]
- 1 u32 timestamp of trustdb creation
- 1 u32 timestamp of last modification which may affect the validity
- of keys in the trustdb. This value is checked against the
- validity timestamp in the dir records.
- 1 u32 timestamp of last validation [currently not used]
- (Used to keep track of the time, when this TrustDB was checked
- against the pubring)
- 1 u32 record number of keyhashtable [currently not used]
- 1 u32 first free record
- 1 u32 record number of shadow directory hash table [currently not used]
- It does not make sense to combine this table with the key table
- because the keyid is not in every case a part of the fingerprint.
- 1 u32 record number of the trusthashtbale
-
-
-Record type 2: (directory record)
---------------
- Informations about a public key certificate.
- These are static values which are never changed without user interaction.
-
- 1 byte value 2
- 1 byte reserved
- 1 u32 LID . (This is simply the record number of this record.)
- 1 u32 List of key-records (the first one is the primary key)
- 1 u32 List of uid-records
- 1 u32 cache record
- 1 byte ownertrust
- 1 byte dirflag
- 1 byte maximum validity of all the user ids
- 1 u32 time of last validity check.
- 1 u32 Must check when this time has been reached.
- (0 = no check required)
-
-
-Record type 3: (key record)
---------------
- Informations about a primary public key.
- (This is mainly used to lookup a trust record)
-
- 1 byte value 3
- 1 byte reserved
- 1 u32 LID
- 1 u32 next - next key record
- 7 bytes reserved
- 1 byte keyflags
- 1 byte pubkey algorithm
- 1 byte length of the fingerprint (in bytes)
- 20 bytes fingerprint of the public key
- (This is the value we use to identify a key)
-
-Record type 4: (uid record)
---------------
- Informations about a userid
- We do not store the userid but the hash value of the userid because that
- is sufficient.
-
- 1 byte value 4
- 1 byte reserved
- 1 u32 LID points to the directory record.
- 1 u32 next next userid
- 1 u32 pointer to preference record
- 1 u32 siglist list of valid signatures
- 1 byte uidflags
- 1 byte validity of the key calculated over this user id
- 20 bytes ripemd160 hash of the username.
-
-
-Record type 5: (pref record)
---------------
- This record type is not anymore used.
-
- 1 byte value 5
- 1 byte reserved
- 1 u32 LID; points to the directory record (and not to the uid record!).
- (or 0 for standard preference record)
- 1 u32 next
- 30 byte preference data
-
-Record type 6 (sigrec)
--------------
- Used to keep track of key signatures. Self-signatures are not
- stored. If a public key is not in the DB, the signature points to
- a shadow dir record, which in turn has a list of records which
- might be interested in this key (and the signature record here
- is one).
-
- 1 byte value 6
- 1 byte reserved
- 1 u32 LID points back to the dir record
- 1 u32 next next sigrec of this uid or 0 to indicate the
- last sigrec.
- 6 times
- 1 u32 Local_id of signatures dir or shadow dir record
- 1 byte Flag: Bit 0 = checked: Bit 1 is valid (we have a real
- directory record for this)
- 1 = valid is set (but may be revoked)
-
-
-
-Record type 8: (shadow directory record)
---------------
- This record is used to reserve a LID for a public key. We
- need this to create the sig records of other keys, even if we
- do not yet have the public key of the signature.
- This record (the record number to be more precise) will be reused
- as the dir record when we import the real public key.
-
- 1 byte value 8
- 1 byte reserved
- 1 u32 LID (This is simply the record number of this record.)
- 2 u32 keyid
- 1 byte pubkey algorithm
- 3 byte reserved
- 1 u32 hintlist A list of records which have references to
- this key. This is used for fast access to
- signature records which are not yet checked.
- Note, that this is only a hint and the actual records
- may not anymore hold signature records for that key
- but that the code cares about this.
- 18 byte reserved
-
-
-
-Record Type 10 (hash table)
---------------
- Due to the fact that we use fingerprints to lookup keys, we can
- implement quick access by some simple hash methods, and avoid
- the overhead of gdbm. A property of fingerprints is that they can be
- used directly as hash values. (They can be considered as strong
- random numbers.)
- What we use is a dynamic multilevel architecture, which combines
- hashtables, record lists, and linked lists.
-
- This record is a hashtable of 256 entries; a special property
- is that all these records are stored consecutively to make one
- big table. The hash value is simple the 1st, 2nd, ... byte of
- the fingerprint (depending on the indirection level).
-
- When used to hash shadow directory records, a different table is used
- and indexed by the keyid.
-
- 1 byte value 10
- 1 byte reserved
- n u32 recnum; n depends on the record length:
- n = (reclen-2)/4 which yields 9 for the current record length
- of 40 bytes.
-
- the total number of such record which makes up the table is:
- m = (256+n-1) / n
- which is 29 for a record length of 40.
-
- To look up a key we use the first byte of the fingerprint to get
- the recnum from this hashtable and look up the addressed record:
- - If this record is another hashtable, we use 2nd byte
- to index this hash table and so on.
- - if this record is a hashlist, we walk all entries
- until we found one a matching one.
- - if this record is a key record, we compare the
- fingerprint and to decide whether it is the requested key;
-
-
-Record type 11 (hash list)
---------------
- see hash table for an explanation.
- This is also used for other purposes.
-
- 1 byte value 11
- 1 byte reserved
- 1 u32 next next hash list record
- n times n = (reclen-5)/5
- 1 u32 recnum
-
- For the current record length of 40, n is 7
-
-
-
-Record type 254 (free record)
----------------
- All these records form a linked list of unused records.
- 1 byte value 254
- 1 byte reserved (0)
- 1 u32 next_free
-</pre>
-
-
-
-</div>
-
-</div>
-
-<div id="outline-container-6" class="outline-2">
-<h2 id="sec-6"><span class="section-number-2">6</span> GNU extensions to the S2K algorithm</h2>
-<div class="outline-text-2" id="text-6">
-
-
-<p>
- 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:
-</p><dl>
-<dt>1001</dt><dd>Do not store the secret part at all.
-</dd>
-<dt>1002</dt><dd>A stub to access smartcards (not used in 1.2.x)
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-7" class="outline-2">
-<h2 id="sec-7"><span class="section-number-2">7</span> Keyserver helper message format</h2>
-<div class="outline-text-2" id="text-7">
-
-
-<p>
- The keyserver may be contacted by a Unix Domain socket or via TCP.
-</p>
-<p>
- The format of a request is:
-</p>
-
-
-<pre class="example">command-tag
-"Content-length:" digits
-CRLF
-</pre>
-
-
-<p>
- Where command-tag is
-</p>
-
-
-
-<pre class="example">NOOP
-GET &lt;user-name&gt;
-PUT
-DELETE &lt;user-name&gt;
-</pre>
-
-
-<p>
-The format of a response is:
-</p>
-
-
-
-<pre class="example">"GNUPG/1.0" status-code status-text
-"Content-length:" digits
-CRLF
-</pre>
-
-<p>
-followed by &lt;digits&gt; bytes of data
-</p>
-<p>
-Status codes are:
-</p>
-<dl>
-<dt>1xx</dt><dd>Informational - Request received, continuing process
-
-</dd>
-<dt>2xx</dt><dd>Success - The action was successfully received, understood,
- and accepted
-
-</dd>
-<dt>4xx</dt><dd>Client Error - The request contains bad syntax or cannot be
- fulfilled
-
-</dd>
-<dt>5xx</dt><dd>Server Error - The server failed to fulfill an apparently
- valid request
-</dd>
-</dl>
-
-
-
-</div>
-
-</div>
-
-<div id="outline-container-8" class="outline-2">
-<h2 id="sec-8"><span class="section-number-2">8</span> Object identifiers</h2>
-<div class="outline-text-2" id="text-8">
-
-
-<p>
- OIDs below the GnuPG arc:
-</p>
-
-
-
-<pre class="example">1.3.6.1.4.1.11591.2 GnuPG
-1.3.6.1.4.1.11591.2.1 notation
-1.3.6.1.4.1.11591.2.1.1 pkaAddress
-1.3.6.1.4.1.11591.2.2 X.509 extensions
-1.3.6.1.4.1.11591.2.2.1 standaloneCertificate
-1.3.6.1.4.1.11591.2.2.2 wellKnownPrivateKey
-1.3.6.1.4.1.11591.2.12242973 invalid encoded OID
-</pre>
-
-
-
-
-</div>
-
-</div>
-
-<div id="outline-container-9" class="outline-2">
-<h2 id="sec-9"><span class="section-number-2">9</span> Miscellaneous notes</h2>
-<div class="outline-text-2" id="text-9">
-
-
-
-</div>
-
-<div id="outline-container-9-1" class="outline-3">
-<h3 id="sec-9-1"><span class="section-number-3">9.1</span> v3 fingerprints</h3>
-<div class="outline-text-3" id="text-9-1">
-
-<p> For packet version 3 we calculate the keyids this way:
-</p><dl>
-<dt>RSA</dt><dd>Low 64 bits of n
-</dd>
-<dt>ELGAMAL</dt><dd>Build a v3 pubkey packet (with CTB 0x99) and
- calculate a RMD160 hash value from it. This is used
- as the fingerprint and the low 64 bits are the keyid.
-</dd>
-</dl>
-
-
-</div>
-
-</div>
-
-<div id="outline-container-9-2" class="outline-3">
-<h3 id="sec-9-2"><span class="section-number-3">9.2</span> Simplified revocation certificates</h3>
-<div class="outline-text-3" id="text-9-2">
-
-<p> Revocation certificates consist only of the signature packet;
- "&ndash;import" knows how to handle this. The rationale behind it is to
- keep them small.
-</p>
-</div>
-
-</div>
-
-<div id="outline-container-9-3" class="outline-3">
-<h3 id="sec-9-3"><span class="section-number-3">9.3</span> Documentation on HKP (the http keyserver protocol):</h3>
-<div class="outline-text-3" id="text-9-3">
-
-
-<p>
- A minimalistic HTTP server on port 11371 recognizes a GET for
- /pks/lookup. The standard http URL encoded query parameters are
- this (always key=value):
-</p>
-<ul>
-<li>op=index (like pgp -kv), op=vindex (like pgp -kvv) and op=get (like
- pgp -kxa)
-
-</li>
-<li>search=&lt;stringlist&gt;. This is a list of words that must occur in the key.
- The words are delimited with space, points, @ and so on. The delimiters
- are not searched for and the order of the words doesn't matter (but see
- next option).
-
-</li>
-<li>exact=on. This switch tells the hkp server to only report exact matching
- keys back. In this case the order and the "delimiters" are important.
-
-</li>
-<li>fingerprint=on. Also reports the fingerprints when used with 'index' or
- 'vindex'
-</li>
-</ul>
-
-
-<p>
- The keyserver also recognizes http-POSTs to /pks/add. Use this to upload
- keys.
-</p>
-
-<p>
- A better way to do this would be a request like:
-</p>
-<p>
- /pks/lookup/&lt;gnupg_formatierte_user_id&gt;?op=&lt;operation&gt;
-</p>
-<p>
- 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.
-</p></div>
-</div>
-</div>
-</div>
-
-<div id="postamble">
-<p class="date">Date: 2013-07-03T09:52+0000</p>
-<p class="author">Author: isis</p>
-<p class="email"><a href="mailto:isis@wintermute.patternsinthevoid.net">isis@wintermute.patternsinthevoid.net</a></p>
-<p class="creator"><a href="http://orgmode.org">Org</a> version 7.9.2 with <a href="http://www.gnu.org/software/emacs/">Emacs</a> version 24</p>
-<a href="http://validator.w3.org/check?uri=referer">Validate XHTML 1.0</a>
-
-</div>
-</body>
-</html>