diff options
Diffstat (limited to 'docs/_static/DETAILS.html')
| -rw-r--r-- | docs/_static/DETAILS.html | 2677 |
1 files changed, 2677 insertions, 0 deletions
diff --git a/docs/_static/DETAILS.html b/docs/_static/DETAILS.html new file mode 100644 index 0000000..7b0b9f8 --- /dev/null +++ b/docs/_static/DETAILS.html @@ -0,0 +1,2677 @@ +<?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> |