diff options
Diffstat (limited to 'docs/_static')
| -rw-r--r-- | docs/_static/DETAILS.html | 2677 | ||||
| -rw-r--r-- | docs/_static/agogo.css | 337 | ||||
| -rw-r--r-- | docs/_static/pgp-subkeys.html | 236 | ||||
| -rw-r--r-- | docs/_static/pygments.css | 69 |
4 files changed, 0 insertions, 3319 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 –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 <long_keyid_or_fpr> <username></a></li> -<li><a href="#sec-2-1-3">2.1.3 EXPSIG <long_keyid_or_fpr> <username></a></li> -<li><a href="#sec-2-1-4">2.1.4 EXPKEYSIG <long_keyid_or_fpr> <username></a></li> -<li><a href="#sec-2-1-5">2.1.5 REVKEYSIG <long_keyid_or_fpr> <username></a></li> -<li><a href="#sec-2-1-6">2.1.6 BADSIG <long_keyid_or_fpr> <username></a></li> -<li><a href="#sec-2-1-7">2.1.7 ERRSIG <keyid> <pkalgo> <hashalgo> <sig_class> <time> <rc></a></li> -<li><a href="#sec-2-1-8">2.1.8 VALIDSIG <args></a></li> -<li><a href="#sec-2-1-9">2.1.9 SIG_ID <radix64_string> <sig_creation_date> <sig-timestamp></a></li> -<li><a href="#sec-2-1-10">2.1.10 ENC_TO <long_keyid> <keytype> <keylength></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 <mdc_method> <sym_algo></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 <algo>:<hexdigits></a></li> -<li><a href="#sec-2-1-17">2.1.17 BEGIN_ENCRYPTION <mdc_method> <sym_algo></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 <what> <filename></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 <long-keyid></a></li> -<li><a href="#sec-2-1-23">2.1.23 SIG_CREATED <type> <pk_algo> <hash_algo> <class> <timestamp> <keyfpr></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 <string></a></li> -<li><a href="#sec-2-1-26">2.1.26 PLAINTEXT <format> <timestamp> <filename></a></li> -<li><a href="#sec-2-1-27">2.1.27 PLAINTEXT_LENGTH <length></a></li> -<li><a href="#sec-2-1-28">2.1.28 ATTRIBUTE <arguments></a></li> -<li><a href="#sec-2-1-29">2.1.29 SIG_SUBPACKET <type> <flags> <len> <data></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 <reserved></a></li> -<li><a href="#sec-2-2-3">2.2.3 NO_SGNR <reserved></a></li> -<li><a href="#sec-2-2-4">2.2.4 KEYEXPIRED <expire-timestamp></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 <long keyid></a></li> -<li><a href="#sec-2-2-7">2.2.7 NO_SECKEY <long keyid></a></li> -<li><a href="#sec-2-2-8">2.2.8 KEY_CREATED <type> <fingerprint> [<handle>]</a></li> -<li><a href="#sec-2-2-9">2.2.9 KEY_NOT_CREATED [<handle>]</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 <long main keyid> <string></a></li> -<li><a href="#sec-2-3-3">2.3.3 NEED_PASSPHRASE <long keyid> <long main keyid> <keytype> <keylength></a></li> -<li><a href="#sec-2-3-4">2.3.4 NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash></a></li> -<li><a href="#sec-2-3-5">2.3.5 NEED_PASSPHRASE_PIN <card_type> <chvno> [<serialno>]</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 <long keyid></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 <long keyid> <fingerprint> <user ID></a></li> -<li><a href="#sec-2-4-2">2.4.2 IMPORTED <long keyid> <username></a></li> -<li><a href="#sec-2-4-3">2.4.3 IMPORT_OK <reason> [<fingerprint>]</a></li> -<li><a href="#sec-2-4-4">2.4.4 IMPORT_PROBLEM <reason> [<fingerprint>]</a></li> -<li><a href="#sec-2-4-5">2.4.5 IMPORT_RES <args></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 <what> [<serialno>]</a></li> -<li><a href="#sec-2-5-2">2.5.2 SC_OP_FAILURE [<code>]</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 <what></a></li> -<li><a href="#sec-2-6-2">2.6.2 UNEXPECTED <what></a></li> -<li><a href="#sec-2-6-3">2.6.3 TRUNCATED <maxno></a></li> -<li><a href="#sec-2-6-4">2.6.4 ERROR <error location> <error code> [<more>]</a></li> -<li><a href="#sec-2-6-5">2.6.5 SUCCESS [<location>]</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 <reason_code></a></li> -<li><a href="#sec-2-6-8">2.6.8 PROGRESS <what> <char> <cur> <total></a></li> -<li><a href="#sec-2-6-9">2.6.9 BACKUP_KEY_CREATED <fingerprint> <fname></a></li> -<li><a href="#sec-2-6-10">2.6.10 MOUNTPOINT <name></a></li> -<li><a href="#sec-2-6-11">2.6.11 PINENTRY_LAUNCHED <pid></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 –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 <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: -</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 < - 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 –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 –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 –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 –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 –marginals-needed). -</dd> -<dt>Field 7</dt><dd>Number of completely trusted users to introduce a new - key signer. (gpg's option –completes-needed) - -</dd> -<dt>Field 8</dt><dd>Maximum depth of a certification chain. (gpg's option - –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> - –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 –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 –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 –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 <long_keyid_or_fpr> <username></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 <long_keyid_or_fpr> <username></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 <long_keyid_or_fpr> <username></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 <long_keyid_or_fpr> <username></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 <long_keyid_or_fpr> <username></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 <keyid> <pkalgo> <hashalgo> <sig_class> <time> <rc></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 <args></h4> -<div class="outline-text-4" id="text-2-1-8"> - - -<p> - The args are: -</p> -<ul> -<li><fingerprint_in_hex> -</li> -<li><sig_creation_date> -</li> -<li><sig-timestamp> -</li> -<li><expire-timestamp> -</li> -<li><sig-version> -</li> -<li><reserved> -</li> -<li><pubkey-algo> -</li> -<li><hash-algo> -</li> -<li><sig-class> -</li> -<li>[ <primary-key-fpr> ] -</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 <radix64_string> <sig_creation_date> <sig-timestamp></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 <long_keyid> <keytype> <keylength></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 –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 –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 <mdc_method> <sym_algo></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 <algo>:<hexdigits></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 –show-session-key is - used. The format is suitable to be passed to the option - –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 <mdc_method> <sym_algo></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 <what> <filename></h4> -<div class="outline-text-4" id="text-2-1-19"> - -<p> Start processing a file <filename>. <what> 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 <long-keyid></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 <type> <pk_algo> <hash_algo> <class> <timestamp> <keyfpr></h4> -<div class="outline-text-4" id="text-2-1-23"> - -<p> A signature has been created using these parameters. - Values for type <type> 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> - <class> 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 <name> -</li> -<li>NOTATION_DATA <string> -</li> -</ul> - - -<p> - <name> and <string> 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 <string></h4> -<div class="outline-text-4" id="text-2-1-25"> - -<p> Note that URL in <string> 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 <format> <timestamp> <filename></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 <length></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 <arguments></h4> -<div class="outline-text-4" id="text-2-1-28"> - -<p> The list or argemnts are: -</p><ul> -<li><fpr> -</li> -<li><octets> -</li> -<li><type> -</li> -<li><index> -</li> -<li><count> -</li> -<li><timestamp> -</li> -<li><expiredate> -</li> -<li><flags> -</li> -</ul> - - -<p> - 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 (e.g. 1 for an image). - <index> and <count> indicate that this is the N-th 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: -</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 <type> <flags> <len> <data></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 <reason> <requested_recipient> -</li> -<li>INV_SGNR <reason> <requested_sender> -</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 <reserved></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 <reserved></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 <expire-timestamp></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 <long keyid></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 <long keyid></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 <type> <fingerprint> [<handle>]</h4> -<div class="outline-text-4" id="text-2-2-8"> - -<p> A key has been created. Values for <type> 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 [<handle>]</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 <error_token> -</li> -<li>TRUST_NEVER <error_token> -</li> -<li>TRUST_MARGINAL [0 [<validation_model>]] -</li> -<li>TRUST_FULLY [0 [<validation_model>]] -</li> -<li>TRUST_ULTIMATE [0 [<validation_model>]] -</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 <mailbox> -</li> -<li>PKA_TRUST_BAD <mailbox> -</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 –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 <long main keyid> <string></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 <long keyid> <long main keyid> <keytype> <keylength></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 <cipher_algo> <s2k_mode> <s2k_hash></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 <card_type> <chvno> [<serialno>]</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 <long keyid></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 <long keyid> <fingerprint> <user ID></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 <long keyid> <username></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 <reason> [<fingerprint>]</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 <reason> [<fingerprint>]</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 <args></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><count> -</li> -<li><no_user_id> -</li> -<li><imported> -</li> -<li><imported_rsa> -</li> -<li><unchanged> -</li> -<li><n_uids> -</li> -<li><n_subk> -</li> -<li><n_sigs> -</li> -<li><n_revoc> -</li> -<li><sec_read> -</li> -<li><sec_imported> -</li> -<li><sec_dups> -</li> -<li><skipped_new_keys> -</li> -<li><not_imported> -</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 <what> [<serialno>]</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 [<code>]</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 - <code> 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 <what></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 <what></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 <maxno></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 <error location> <error code> [<more>]</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. <error code> and <error_location> - 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 [<location>]</h4> -<div class="outline-text-4" id="text-2-6-5"> - -<p> Postive confirimation that an operation succeeded. <location> 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 <reason_code></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 <what> <char> <cur> <total></h4> -<div class="outline-text-4" id="text-2-6-8"> - -<p> 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. The condition -</p><pre class="example"> - TOTAL && 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 <fingerprint> <fname></h4> -<div class="outline-text-4" id="text-2-6-9"> - -<p> A backup of a key identified by <fingerprint> has been writte to - the file <fname>; <fname> 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 <name></h4> -<div class="outline-text-4" id="text-2-6-10"> - -<p> <name> is a percent-plus escaped filename describing the - mountpoint for the current operation (e.g. used by "g13 –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 <pid></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. <pid> 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 –attribute-fd output</h2> -<div class="outline-text-2" id="text-3"> - - -<p> - When –attribute-fd is set, during key listings (–list-keys, - –list-secret-keys) GnuPG dumps each attribute packet to the file - descriptor specified. –attribute-fd is intended for use with - –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 <user-name> -PUT -DELETE <user-name> -</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 <digits> 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; - "–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=<stringlist>. This is a list of words that must occur in the key. - The words are delimited with space, points, @ and so on. The delimiters - are not searched for and the order of the words doesn't matter (but see - next option). - -</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/<gnupg_formatierte_user_id>?op=<operation> -</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> diff --git a/docs/_static/agogo.css b/docs/_static/agogo.css deleted file mode 100644 index 2bdc26f..0000000 --- a/docs/_static/agogo.css +++ /dev/null @@ -1,337 +0,0 @@ -* { - margin: 0px; - padding: 0px; -} - -body { - font-family: "Verdana", Arial, sans-serif; - line-height: 1.4em; - font-size: 14px; - color: black; - background-color: #eeeeec; -} - - -/* Page layout */ - -div.header, div.content, div.footer { - width: 70em; - margin-left: auto; - margin-right: auto; -} - -div.header-wrapper { - background: url(bgtop.png) top left repeat-x; - border-bottom: 3px solid #2e3436; -} - -div.headertitle a { - font-family: "Georgia", "Times New Roman", serif; - font-size: 2em; - color: rgb(252, 175, 62); - font-weight: normal; -} - -h1 { - color: #204a87; -} - -/* Default body styles */ -a { - text-decoration: none; - color: #ce5c00; -} - -.clearer { - clear: both; -} - -.left { - float: left; -} - -.right { - float: right; -} - -h1, h2, h3, h4 { - font-family: "Georgia", "Times New Roman", serif; - font-weight: normal; - color: #3465a4; - margin-bottom: .8em; -} - -h1 { - color: #204a87; -} - -h2 { - padding-bottom: .5em; - border-bottom: 1px solid #3465a4; -} - -a.headerlink { - visibility: hidden; - color: #dddddd; - padding-left: .3em; -} - -h1:hover > a.headerlink, -h2:hover > a.headerlink, -h3:hover > a.headerlink, -h4:hover > a.headerlink, -h5:hover > a.headerlink, -h6:hover > a.headerlink, -dt:hover > a.headerlink { - visibility: visible; -} - - - -/* Header */ - -div.header { - padding-top: 10px; - padding-bottom: 10px; -} - -div.header h1 { - font-family: "Georgia", "Times New Roman", serif; - font-weight: normal; - font-size: 160%; - letter-spacing: .08em; -} - -div.header h1 a { - color: white; -} - -div.header div.rel { - margin-top: 1em; -} - -div.header div.rel a { - color: #fcaf3e; - letter-spacing: .1em; - text-transform: uppercase; -} - - -/* Content */ -div.content-wrapper { - background-color: white; - padding-top: 20px; - padding-bottom: 20px; -} - -div.document { - width: 50em; - float: left; -} - -div.body { - padding-right: 2em; - text-align: justify; -} - -div.document ul { - margin-left: 1.2em; - list-style-type: square; -} - -div.document dd { - margin-left: 1.2em; - margin-top: .4em; - margin-bottom: 1em; -} - -div.document .section { - margin-top: 1.7em; -} -div.document .section:first-child { - margin-top: 0px; -} - -div.document div.highlight { - padding: 3px; - background-color: #eeeeec; - border-top: 2px solid #dddddd; - border-bottom: 2px solid #dddddd; - margin-top: .8em; - margin-bottom: .8em; -} - -div.document h2 { - margin-top: .7em; -} - -div.document p { - margin-bottom: .5em; -} - -div.document li.toctree-l1 { - margin-bottom: 1em; -} - -div.document .descname { - font-weight: bold; -} - -div.document .docutils.literal { - background-color: #eeeeec; - padding: 1px; -} - -div.document .docutils.xref.literal { - background-color: transparent; - padding: 0px; -} - - -/* Sidebar */ - -div.sidebar { - width: 20em; - float: right; - font-size: .9em; -} - -div.sidebar h3 { - color: #2e3436; - text-transform: uppercase; - font-size: 130%; - letter-spacing: .1em; -} - -div.sidebar ul { - list-style-type: none; -} - -div.sidebar li.toctree-l1 a { - display: block; - padding: 1px; - border: 1px solid #dddddd; - background-color: #eeeeec; - margin-bottom: .4em; - padding-left: 3px; - color: #2e3436; -} - -div.sidebar li.toctree-l2 a { - background-color: transparent; - border: none; - border-bottom: 1px solid #dddddd; -} - -div.sidebar li.toctree-l2:last-child a { - border-bottom: none; -} - -div.sidebar li.toctree-l1.current a { - border-right: 5px solid #fcaf3e; -} - -div.sidebar li.toctree-l1.current li.toctree-l2 a { - border-right: none; -} - - -/* Footer */ - -div.footer-wrapper { - background: url(bgfooter.png) top left repeat-x; - border-top: 4px solid #babdb6; - padding-top: 10px; - padding-bottom: 10px; - min-height: 80px; -} - -div.footer, div.footer a { - color: #888a85; -} - -div.footer .right { - text-align: right; -} - -div.footer .left { - text-transform: uppercase; -} - - -/* Styles copied form basic theme */ - -/* -- search page ----------------------------------------------------------- */ - -ul.search { - margin: 10px 0 0 20px; - padding: 0; -} - -ul.search li { - padding: 5px 0 5px 20px; - background-image: url(file.png); - background-repeat: no-repeat; - background-position: 0 7px; -} - -ul.search li a { - font-weight: bold; -} - -ul.search li div.context { - color: #888; - margin: 2px 0 0 30px; - text-align: left; -} - -ul.keywordmatches li.goodmatch a { - font-weight: bold; -} - -/* -- index page ------------------------------------------------------------ */ - -table.contentstable { - width: 90%; -} - -table.contentstable p.biglink { - line-height: 150%; -} - -a.biglink { - font-size: 1.3em; -} - -span.linkdescr { - font-style: italic; - padding-top: 5px; - font-size: 90%; -} - -/* -- general index --------------------------------------------------------- */ - -table.indextable td { - text-align: left; - vertical-align: top; -} - -table.indextable dl, table.indextable dd { - margin-top: 0; - margin-bottom: 0; -} - -table.indextable tr.pcap { - height: 10px; -} - -table.indextable tr.cap { - margin-top: 10px; - background-color: #f2f2f2; -} - -img.toggler { - margin-right: 3px; - margin-top: 3px; - cursor: pointer; -} diff --git a/docs/_static/pgp-subkeys.html b/docs/_static/pgp-subkeys.html deleted file mode 100644 index 2fc83b4..0000000 --- a/docs/_static/pgp-subkeys.html +++ /dev/null @@ -1,236 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> -<html><head><title>Using multiple subkeys in GPG</title></head><body style="background-color: white;"> -<div>[ <a href="http://fortytwo.ch/">main gpg page</a> ] -<hr> -<h1>Using multiple subkeys in GPG</h1> -<hr> -<h2>Motivation</h2> -<p> -For a time, I've had two different gpg keys - one at home on my presumably -secure machine, one at the office, with NFS mounted home directory and -quite a few people having accounts everywhere. This worked, but the problem -is that when exchanging key signatures I always had to beg people to sign -both my keys. -</p> -<p> -With gpg and the possibility of having multiple subkeys, I can now have -only one key, but still retain the security feature that I don't have to -revoke my primary key (and lose all signatures on it) if the key at the -office is compromised. -</p> -<p> -<b>NOTE:</b> Most of the following can apply to both signing and encrypting -subkeys. Encryption subkeys can not be used to solve the multiple accounts -problem, though, please see the <a href="#problems">Problems</a> section -further down. Also, note that I don't use multiple encryption subkeys, so I -don't know if there are additional problems with them. -</p> -<p> -The following is based on <b>gnupg 1.2.1</b>. It should all work with newer -versions, too. Older versions do not support everything and have some -additional problems. As I really do recommend you use a recent gpg version, I -have omitted anything related to older gpg versions. -</p> -<h2>Basics</h2> -<p> -Generate a normal key pair, or use an existing key. Usually this will be a -DSA/ElGamal key (this is what I use), but using RSA or other keys is -equally possible. Be sure to do this on a 'really secure' machine. -</p> -<p> -Then "<tt>gpg __edit <i>keyid</i></tt>" the key and add a further subkey -using "<tt>addkey</tt>". "<tt>save</tt>" will store the new subkey on the -keyring. You'll want to save the whole key (secret and public) with -"<tt>gpg __export <i>keyid</i> > pubkey</tt>" and "<tt>gpg -__export-secret-key <i>keyid</i> > seckey</tt>". Best copy those files -onto an offline storage, too. (A basic working knowledge of how to use a -command line and how to deal with files is assumed. Also, you should know -a bit how key handling in gpg works. If you can't see what the above commands -do, you better do <a href="http://www.gnupg.org/gph/en/manual.html">some -reading</a> before continuing here). -</p> -<p> -Now you should also <b>back up your keyrings</b>, as the following has to -work on a keyring to work around some missing or broken gpg features. -</p> -<p> -As you probably will only take one of the subkeys to your not-so-secure -location, "<tt>gpg __edit <i>keyid</i></tt> and delete the subkeys you -don't want to expose (mark them with "<tt>key <i>n</i></tt>" and then delete -them with "<tt>delkey</tt>"). -</p> -<p> -"<tt>gpg __export-secret-subkeys <i>keyid</i> > crippled.seckey</tt>" -will then export the remaining subkeys, without the keymaterial of the -primary key. -</p> -<p> -Now, you can restore the keyrings (secret <em>and</em> public, since -deleting the subkeys has also deleted the public subkeys!), and your secure -machine is ready to use. Perhaps you don't want to use your 'insecure' -subkey on your secure machine - again, "<tt>gpg __edit <i>keyid</i></tt>", -"<tt>key <i>n</i></tt>" and "<tt>delkey</tt>" takes care of this; again, it -is necessary to re-import the public key. -</p> -<p> -On your 'insecure' machine, you do "<tt>gpg __import pubkey -crippled.seckey</tt>" (the same files you've generated above), now you're ready -to use gpg on the 'insecure' machine. To verify that you really don't have any -secret keys you don't want, have a look at the output of "<tt>gpg -__list-secret-keys</tt>": all primary secret key where the key material is not -present are marked with '#'. -</p> -<pre> -$ gpg __list-secret-key testuser -sec<b>#</b> 1024D/971B7A70 2003-01-03 testuser <testuser@mydomain.foo> -ssb 1024g/ACDF80C4 2003-01-03 -ssb 1024R/BE9CA308 2003-01-07 -</pre> -<p> -Of course, you'll have to publish your new public key, so people can -verify your signatures and send you encrypted mail. Read the <a -href="#problems">Problems</a> section for a few comments about this. -</p> -<h2>Effects</h2> -<p> -Keys are always signed with your primary key, so you (or any attacker) won't be -able to sign other keys with the key on the 'insecure' machine. This is why we -started doing all this acrobatics after all. </p> -<p> -You will always be able to revoke a subkey (just "<tt>gpg __edit -<i>keyid</i></tt>", "<tt>key <i>n</i></tt>" and "<tt>revkey</tt>") when you -have the primary secret key available, even if you lose your secret subkey. -Meaning: you may use a secret subkey at an office location, and it is not -strictly necessary to back it up on a secure location (It's still a good idea, -though). The reason for this is that a revocation is really a signature on the -subkey - and this signature is done with the primary key. Of course, this means -that you can't revoke a subkey when you don't have the primary secret key. -</p> -<p> -If you're signing documents, gpg will always try to use a subkey if one -is available, and announce this with a message like "<tt>1024-bit DSA key, ID -E5A7F7D6, created 2002-08-22 (main key ID 92082481)</tt>" . Verifying such -signatures used to cause a similar message, but at least with gpg 1.2.3 no -indication is given that the signature was made with a subkey. If you want to -use a specific subkey (or the primary key), you have to specify it with the -"<tt><i>keyid</i>!</tt>" syntax. I don't remember what happens if more than one -signing subkey is available; I'm sure you can find details on this somewhere in -the <a href="http://www.gnupg.org/documentation/mailing-lists.html">gnupg -mailing list archives</a>. -</p> -<h2><a name="problems">Problems</a></h2> -<p> -The above approach has several problems that may lead to you not doing -things like this. <b>These are not just possible problems. These are real, -and <em>will</em> affect you! You have been warned.</b> -</p> -<p> -First, distributing secret subkeys this way (one subkey for each -account/machine you use) only makes sense with signing subkeys. You can have -multiple encryption subkeys, but you can't force people sending you encrypted -mail using a specific subkey. Naturally, if you're using encryption for -yourself, you can chose the encryption key to use with the -"<tt><i>keyid</i>!</tt>" syntax. The presence of multiple encryption subkeys -is, however, useful if you revoke an older one to replace it with a new one. -</p> -<p> -Old PGP versions apparently can't cope with such keys. I didn't verify this -myself, but people on the gnupg-users mailing list said that current PGP -versions (up to 7.x) can not verify signatures from a subkey. With PGP 8 the -situation is a bit more complicated: PGP 8 can verify subkey signatures, but -has still problems with multiple subkeys: a key with a signing subkey that is -newer than the encryption subkey cannot be used for encryption in PGP 8. A key -where the encryption subkey is newer than the signing subkey can be used for -encryption. So, when you create your key, generate it as 'signing only' key -first, then generate all the signing subkeys you need, and in the end generate -the encryption subkey. (Thanks to David Shaw for this info). -</p> -<p> -Most keyservers can not handle keys with multiple subkeys. Some of them even -make these keys unusable. This should get better soon, as JHarris has written a -patch for the pks keyserver, and keyservers with other software that handles -this are deployed more widely. The keyservers that can handle multiple subkeys -are summarized as <tt>subkeys.pgp.net</tt>. -GnuPG 1.2 added code to recover somewhat when a broken key is retrieved - one -of the subkeys is useable (the others can't be used, as the signature binding -the subkey to the primary is lost). -</p> -<p> -Besides corrupting keys with multiple subkeys, all of these old keyservers -will also only search keys based on the primary key id - so, automatic key -retrieval on signature verification will not work, too. Yet another -reason to oonly use the subkeys.pgp.net keyservers. -</p> -<p> -Finally, keyhandling is not comfortable with such keys - the user interface of -gpg could be better. The following is valid for gpg 1.2.1, some things may be -fixed in newer versions.: -</p> -<ul> -<li> -"<tt>gpg __import <i>secret key</i></tt>" does not merge the keys properly. -If a secret key is already present, additional secret subkeys are not -imported. Also, a dummy primary key is not replaced by the real subkey on -import. Workaround is to shuffle around the keyrings, or do -"<tt>__export</tt>"s at all stages and use "<tt>__delete-secret-key</tt>" -often. (People with masochistic inclination may probably also use -combinations of <tt>gpgsplit</tt>, <tt>cat</tt> and "<tt>gpg __export</tt>" -and "<tt>__import</tt>. I've not tried this.) -</li> -<li> -"<tt>gpg __export-secret-key <i>keyid</i>!</tt>" and <tt>gpg -__export-secret-subkeys <i>keyid</i>!</tt>" should really only export the -named subkey (or the primary stripped of all subkeys). Much keyring shuffling -could be avoided. (<b>2003-02-12:</b>David Shaw added this to the development -branch of the gpg code. Great!) -</li> -</ul> -<h2>Links</h2> -<p> -Some additional reading that might be interesting: -</p> -<ul> -<li> -The <a href="http://www.ietf.org/rfc/rfc2440.txt">rfc2440</a>, specifying -the OpenPGP key format. -</li> -<li> -The <a href="http://www.gnupg.org/gph/en/manual.html">GNU Privacy Handbook</a> -is a fairly complete manual to gpg. -</li> -<li> -The <a -href="http://lists.gnupg.org/pipermail/gnupg-users/2002-August/014721.html">using -various subkeys</a> thread on the gnupg-users mailing list, where most of these -issues were discussed. -</li> -<li> -The <a -href="http://lists.gnupg.org/pipermail/gnupg-devel/2002-September/007700.html">using -subkey signatures</a> thread on gnupg-devel where I asked about the auto key -retrieval problem. -</li> -<li> -Other <a href="http://atom.smasher.org/gpg/">tutorials</a> on advanced black -magic with keys by Atom Smasher, dealing with what you can do with subkeys. -</li> -</ul> -<h2>Acknowledgments</h2> -<p> -Of course, thanks to the gnupg crew for the cool software, and especially to -Werner Koch and David Shaw for replying to my initial questions about this. And -to Jason Harris for fixing pks to accept keys with multiple subkeys, I hope -this patch spreads really fast as soon as it is officially out. -</p> -<p> -</p> -</div> -<hr> -<div style="font-size: x-small;"> -©2002-2004 <a href="mailto:avbidder+gpg@fortytwo.ch">Adrian von Bidder</a> -- Permission to redistribute and/or modify this document is granted if (i) the -original author (Adrian von Bidder, Switzerland) is acknowledged and (ii) the -document remains freely available for distribution and modification. -</div> - -</body></html> diff --git a/docs/_static/pygments.css b/docs/_static/pygments.css deleted file mode 100644 index 45bae6e..0000000 --- a/docs/_static/pygments.css +++ /dev/null @@ -1,69 +0,0 @@ -.hll { background-color: #ffffcc } -.c { color: #8f5902; font-style: italic } /* Comment */ -.err { color: #a40000; border: 1px solid #ef2929 } /* Error */ -.g { color: #000000 } /* Generic */ -.k { color: #204a87; font-weight: bold } /* Keyword */ -.l { color: #000000 } /* Literal */ -.n { color: #000000 } /* Name */ -.o { color: #ce5c00; font-weight: bold } /* Operator */ -.x { color: #000000 } /* Other */ -.p { color: #000000; font-weight: bold } /* Punctuation */ -.cm { color: #8f5902; font-style: italic } /* Comment.Multiline */ -.cp { color: #8f5902; font-style: italic } /* Comment.Preproc */ -.c1 { color: #8f5902; font-style: italic } /* Comment.Single */ -.cs { color: #8f5902; font-style: italic } /* Comment.Special */ -.gd { color: #a40000 } /* Generic.Deleted */ -.ge { color: #000000; font-style: italic } /* Generic.Emph */ -.gr { color: #ef2929 } /* Generic.Error */ -.gh { color: #000080; font-weight: bold } /* Generic.Heading */ -.gi { color: #00A000 } /* Generic.Inserted */ -.go { color: #000000; font-style: italic } /* Generic.Output */ -.gp { color: #8f5902 } /* Generic.Prompt */ -.gs { color: #000000; font-weight: bold } /* Generic.Strong */ -.gu { color: #800080; font-weight: bold } /* Generic.Subheading */ -.gt { color: #a40000; font-weight: bold } /* Generic.Traceback */ -.kc { color: #204a87; font-weight: bold } /* Keyword.Constant */ -.kd { color: #204a87; font-weight: bold } /* Keyword.Declaration */ -.kn { color: #204a87; font-weight: bold } /* Keyword.Namespace */ -.kp { color: #204a87; font-weight: bold } /* Keyword.Pseudo */ -.kr { color: #204a87; font-weight: bold } /* Keyword.Reserved */ -.kt { color: #204a87; font-weight: bold } /* Keyword.Type */ -.ld { color: #000000 } /* Literal.Date */ -.m { color: #0000cf; font-weight: bold } /* Literal.Number */ -.s { color: #4e9a06 } /* Literal.String */ -.na { color: #c4a000 } /* Name.Attribute */ -.nb { color: #204a87 } /* Name.Builtin */ -.nc { color: #000000 } /* Name.Class */ -.no { color: #000000 } /* Name.Constant */ -.nd { color: #5c35cc; font-weight: bold } /* Name.Decorator */ -.ni { color: #ce5c00 } /* Name.Entity */ -.ne { color: #cc0000; font-weight: bold } /* Name.Exception */ -.nf { color: #000000 } /* Name.Function */ -.nl { color: #f57900 } /* Name.Label */ -.nn { color: #000000 } /* Name.Namespace */ -.nx { color: #000000 } /* Name.Other */ -.py { color: #000000 } /* Name.Property */ -.nt { color: #204a87; font-weight: bold } /* Name.Tag */ -.nv { color: #000000 } /* Name.Variable */ -.ow { color: #204a87; font-weight: bold } /* Operator.Word */ -.w { color: #f8f8f8; text-decoration: underline } /* Text.Whitespace */ -.mf { color: #0000cf; font-weight: bold } /* Literal.Number.Float */ -.mh { color: #0000cf; font-weight: bold } /* Literal.Number.Hex */ -.mi { color: #0000cf; font-weight: bold } /* Literal.Number.Integer */ -.mo { color: #0000cf; font-weight: bold } /* Literal.Number.Oct */ -.sb { color: #4e9a06 } /* Literal.String.Backtick */ -.sc { color: #4e9a06 } /* Literal.String.Char */ -.sd { color: #8f5902; font-style: italic } /* Literal.String.Doc */ -.s2 { color: #4e9a06 } /* Literal.String.Double */ -.se { color: #4e9a06 } /* Literal.String.Escape */ -.sh { color: #4e9a06 } /* Literal.String.Heredoc */ -.si { color: #4e9a06 } /* Literal.String.Interpol */ -.sx { color: #4e9a06 } /* Literal.String.Other */ -.sr { color: #4e9a06 } /* Literal.String.Regex */ -.s1 { color: #4e9a06 } /* Literal.String.Single */ -.ss { color: #4e9a06 } /* Literal.String.Symbol */ -.bp { color: #3465a4 } /* Name.Builtin.Pseudo */ -.vc { color: #000000 } /* Name.Variable.Class */ -.vg { color: #000000 } /* Name.Variable.Global */ -.vi { color: #000000 } /* Name.Variable.Instance */ -.il { color: #0000cf; font-weight: bold } /* Literal.Number.Integer.Long */ |