2678 lines
80 KiB
HTML
2678 lines
80 KiB
HTML
<?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>
|