51
54
value for most purposes
52
55
n = Don't trust this key at all
53
56
m = There is marginal trust in this key
54
f = The key is full trusted.
55
u = The key is ultimately trusted; this is only used for
56
keys for which the secret key is also available.
57
f = The key is fully trusted
58
u = The key is ultimately trusted. This often means
59
that the secret key is available, but any key may
60
be marked as ultimately trusted.
57
62
3. Field: length of key in bits.
58
64
4. Field: Algorithm: 1 = RSA
59
16 = ElGamal (encrypt only)
65
16 = Elgamal (encrypt only)
60
66
17 = DSA (sometimes called DH, sign only)
61
20 = ElGamal (sign and encrypt)
67
20 = Elgamal (sign and encrypt - don't use them!)
62
68
(for other id's see include/cipher.h)
63
5. Field: KeyID either of
64
6. Field: Creation Date (in UTC)
65
7. Field: Key expiration date or empty if none.
66
8. Field: Used for serial number in crt records (used to be the Local-ID)
72
6. Field: Creation Date (in UTC). For UID and UAT records, this is the
73
self-signature date. Note that the dae is usally printed
74
in seconds since epoch, however, we are migrating to an ISO
75
8601 format (e.g. "19660205T091500"). This is currently
76
only relevant for X.509, A simple way to detect the format
77
is be scannning for the 'T'.
79
7. Field: Key or user ID/user attribute expiration date or empty if none.
81
8. Field: Used for serial number in crt records (used to be the Local-ID).
82
For UID and UAT records, this is a hash of the user ID contents
83
used to represent that exact user ID. For trust signatures,
84
this is the trust depth seperated by the trust value by a
67
87
9. Field: Ownertrust (primary public keys only)
68
88
This is a single letter, but be prepared that additional
69
information may follow in some future versions.
89
information may follow in some future versions. For trust
90
signatures with a regular expression, this is the regular
91
expression value, quoted as in field 10.
70
93
10. Field: User-ID. The value is quoted like a C string to avoid
71
94
control characters (the colon is quoted "\x3a").
72
95
This is not used with --fixed-list-mode in gpg.
75
98
In gpgsm the issuer name comes here
76
99
An FPR record stores the fingerprint here.
77
100
The fingerprint of an revocation key is stored here.
78
102
11. Field: Signature class. This is a 2 digit hexnumber followed by
79
103
either the letter 'x' for an exportable signature or the
80
104
letter 'l' for a local-only signature.
81
105
The class byte of an revocation key is also given here,
82
106
'x' and 'l' ist used the same way.
83
108
12. Field: Key capabilities:
87
A key may have any combination of them. The primary key has in
88
addition to these letters, uppercase version of the letter to
89
denote the _usable_ capabilities of the entire key.
90
13. Field: Used in FPR records for S/MIME keys to store the fingerprint of
91
the issuer certificate. This is useful to build the
92
certificate path based on certificates stored in the local
93
keyDB; it is only filled if the issue certificate is
94
available. The advantage of using this value is that it is
95
guaranteed to have been been build by the same lookup
96
algorithm as gpgsm uses.
113
A key may have any combination of them in any order. In
114
addition to these letters, the primary key has uppercase
115
versions of the letters to denote the _usable_
116
capabilities of the entire key, and a potential letter 'D'
117
to indicate a disabled key.
119
13. Field: Used in FPR records for S/MIME keys to store the
120
fingerprint of the issuer certificate. This is useful to
121
build the certificate path based on certificates stored in
122
the local keyDB; it is only filled if the issuer
123
certificate is available. The root has been reached if
124
this is the same string as the fingerprint. The advantage
125
of using this value is that it is guaranteed to have been
126
been build by the same lookup algorithm as gpgsm uses.
97
127
For "uid" recods this lists the preferences n the sameway the
129
For "sig" records, this is the fingerprint of the key that
130
issued the signature. Note that this is only filled in if
131
the signature verified correctly. Note also that for
132
various technical reasons, this fingerprint is only
133
available if --no-sig-cache is used.
99
135
14. Field Flag field used in the --edit menu output:
137
15. Field Used in sec/sbb to print the serial number of a token
138
(internal protect mode 1002) or a '#' if that key is a
139
simple stub (internal protect mode 1001)
102
141
All dates are displayed in the format yyyy-mm-dd unless you use the
103
142
option --fixed-list-mode in which case they are displayed as seconds
112
151
! !------ for information number of bits in the value
113
152
!--------- index (eg. DSA goes from 0 to 3: p,q,g,y)
155
The "tru" trust database records have the fields:
157
2: Reason for staleness of trust. If this field is empty, then the
158
trustdb is not stale. This field may have multiple flags in it:
161
t: Trustdb was built with a different trust model than the one we
165
0: Classic trust model, as used in PGP 2.x.
166
1: PGP trust model, as used in PGP 6 and later. This is the same
167
as the classic trust model, except for the addition of trust
170
GnuPG before version 1.4 used the classic trust model by default.
171
GnuPG 1.4 and later uses the PGP trust model by default.
173
4: Date trustdb was created in seconds since 1/1/1970.
174
5: Date trustdb will expire in seconds since 1/1/1970.
176
The "spk" signature subpacket records have the fields:
178
2: Subpacket number as per RFC-2440 and later.
179
3: Flags in hex. Currently the only two bits assigned are 1, to
180
indicate that the subpacket came from the hashed part of the
181
signature, and 2, to indicate the subpacket was marked critical.
182
4: Length of the subpacket. Note that this is the length of the
183
subpacket, and not the length of field 5 below. Due to the need
184
for %-encoding, the length of field 5 may be up to 3x this value.
185
5: The subpacket data. Printable ASCII is shown as ASCII, but other
186
values are rendered as %XX where XX is the hex value for the byte.
117
189
Format of the "--status-fd" output
118
190
==================================
122
194
more arguments in future versions.
125
GOODSIG <long keyid> <username>
198
May be issued right before a signature verification starts. This
199
is useful to define a context for parsing ERROR status
200
messages. No arguments are currently defined.
202
GOODSIG <long_keyid_or_fpr> <username>
126
203
The signature with the keyid is good. For each signature only
127
204
one of the three codes GOODSIG, BADSIG or ERRSIG will be
128
205
emitted and they may be used as a marker for a new signature.
129
206
The username is the primary one encoded in UTF-8 and %XX
207
escaped. The fingerprint may be used instead of the long keyid
208
if it is available. This is the case with CMS and might
209
eventually also be available for OpenPGP.
132
EXPSIG <long keyid> <username>
211
EXPSIG <long_keyid_or_fpr> <username>
133
212
The signature with the keyid is good, but the signature is
134
213
expired. The username is the primary one encoded in UTF-8 and
137
EXPKEYSIG <long keyid> <username>
214
%XX escaped. The fingerprint may be used instead of the long
215
keyid if it is available. This is the case with CMS and might
216
eventually also be available for OpenPGP.
218
EXPKEYSIG <long_keyid_or_fpr> <username>
219
The signature with the keyid is good, but the signature was
220
made by an expired key. The username is the primary one
221
encoded in UTF-8 and %XX escaped. The fingerprint may be used
222
instead of the long keyid if it is available. This is the
223
case with CMS and might eventually also be available for
226
REVKEYSIG <long_keyid_or_fpr> <username>
138
227
The signature with the keyid is good, but the signature was
139
made by an expired key. The username is the primary one
140
encoded in UTF-8 and %XX escaped.
142
BADSIG <long keyid> <username>
143
The signature with the keyid has not been verified okay.
144
The username is the primary one encoded in UTF-8 and %XX
147
ERRSIG <long keyid> <pubkey_algo> <hash_algo> \
228
made by a revoked key. The username is the primary one encoded
229
in UTF-8 and %XX escaped. The fingerprint may be used instead
230
of the long keyid if it is available. This is the case with
231
CMS and might eventually also be available for OpenPGP.
233
BADSIG <long_keyid_or_fpr> <username>
234
The signature with the keyid has not been verified okay. The
235
username is the primary one encoded in UTF-8 and %XX
236
escaped. The fingerprint may be used instead of the long keyid
237
if it is available. This is the case with CMS and might
238
eventually also be available for OpenPGP.
240
ERRSIG <long_keyid_or_fpr> <pubkey_algo> <hash_algo> \
148
241
<sig_class> <timestamp> <rc>
149
242
It was not possible to check the signature. This may be
150
caused by a missing public key or an unsupported algorithm.
151
A RC of 4 indicates unknown algorithm, a 9 indicates a missing
152
public key. The other fields give more information about
153
this signature. sig_class is a 2 byte hex-value.
243
caused by a missing public key or an unsupported algorithm. A
244
RC of 4 indicates unknown algorithm, a 9 indicates a missing
245
public key. The other fields give more information about this
246
signature. sig_class is a 2 byte hex-value. The fingerprint
247
may be used instead of the long keyid if it is available.
248
This is the case with CMS and might eventually also be
249
available for OpenPGP.
251
Note, that TIMESTAMP may either be a number with seconds since
252
epoch or an ISO 8601 string which can be detected by the
253
presence of the letter 'T' inside.
155
255
VALIDSIG <fingerprint in hex> <sig_creation_date> <sig-timestamp>
158
The signature with the keyid is good. This is the same
159
as GOODSIG but has the fingerprint as the argument. Both
160
status lines are emitted for a good signature.
161
sig-timestamp is the signature creation time in seconds after
162
the epoch. expire-timestamp is the signature expiration time
163
in seconds after the epoch (zero means "does not expire").
256
<expire-timestamp> <sig-version> <reserved> <pubkey-algo>
257
<hash-algo> <sig-class> [ <primary-key-fpr> ]
259
The signature with the keyid is good. This is the same as
260
GOODSIG but has the fingerprint as the argument. Both status
261
lines are emitted for a good signature. All arguments here
262
are on one long line. sig-timestamp is the signature creation
263
time in seconds after the epoch. expire-timestamp is the
264
signature expiration time in seconds after the epoch (zero
265
means "does not expire"). sig-version, pubkey-algo, hash-algo,
266
and sig-class (a 2-byte hex value) are all straight from the
267
signature packet. PRIMARY-KEY-FPR is the fingerprint of the
268
primary key or identical to the first argument. This is
269
useful to get back to the primary key without running gpg
270
again for this purpose.
272
The primary-key-fpr parameter is used for OpenPGP and not
273
available for CMS signatures. The sig-version as well as the
274
sig class is not defined for CMS and currently set to 0 and 00.
276
Note, that *-TIMESTAMP may either be a number with seconds
277
since epoch or an ISO 8601 string which can be detected by the
278
presence of the letter 'T' inside.
165
280
SIG_ID <radix64_string> <sig_creation_date> <sig-timestamp>
166
281
This is emitted only for signatures of class 0 or 1 which
191
313
TRUST_UNDEFINED <error token>
192
TRUST_NEVER <error token>
196
For good signatures one of these status lines are emitted
197
to indicate how trustworthy the signature is. The error token
198
values are currently only emiited by gpgsm.
314
TRUST_NEVER <error token>
315
TRUST_MARGINAL [0 [<validation_model>]]
316
TRUST_FULLY [0 [<validation_model>]]
317
TRUST_ULTIMATE [0 [<validation_model>]]
318
For good signatures one of these status lines are emitted to
319
indicate how trustworthy the signature is. The error token
320
values are currently only emitted by gpgsm. VALIDATION_MODEL
321
describes the algorithm used to check the validity of the key.
322
The defaults are the standard Web of Trust model for gpg and the
323
the standard X.509 model for gpgsm. The defined values are
325
"pgp" for the standard PGP WoT.
326
"shell" for the standard X.509 model.
327
"chain" for the chain model.
330
PKA_TRUST_GOOD <mailbox>
331
PKA_TRUST_BAD <mailbox>
332
Depending on the outcome of the PKA check one of the above
333
status codes is emitted in addition to a TRUST_* status.
334
Without PKA info available or
201
337
This is deprecated in favor of KEYEXPIRED.
335
501
(only the first character should be checked)
336
502
class: 2 hex digits with the signature class
504
Note, that TIMESTAMP may either be a number with seconds since
505
epoch or an ISO 8601 string which can be detected by the
506
presence of the letter 'T' inside.
338
KEY_CREATED <type> <fingerprint>
508
KEY_CREATED <type> <fingerprint> [<handle>]
339
509
A key has been created
340
510
type: 'B' = primary and subkey
343
513
The fingerprint is one of the primary key for type B and P and
344
the one of the subkey for S.
514
the one of the subkey for S. Handle is an arbitrary
515
non-whitespace string used to match key parameters from batch
518
KEY_NOT_CREATED [<handle>]
519
The key from batch run has not been created due to errors.
346
522
SESSION_KEY <algo>:<hexdigits>
347
523
The session key used to decrypt the message. This message will
348
only be emmited when the special option --show-session-key
524
only be emitted when the special option --show-session-key
349
525
is used. The format is suitable to be passed to the option
350
526
--override-session-key
413
594
0x02 = this attribute packet is revoked
414
595
0x04 = this attribute packet is expired
597
CARDCTRL <what> [<serialno>]
598
This is used to control smartcard operations.
599
Defined values for WHAT are:
600
1 = Request insertion of a card. Serialnumber may be given
601
to request a specific card.
602
2 = Request removal of a card.
603
3 = Card with serialnumber detected
604
4 = No card available.
605
5 = No card reader available
608
PLAINTEXT <format> <timestamp> <filename>
609
This indicates the format of the plaintext that is about to be
610
written. The format is a 1 byte hex code that shows the
611
format of the plaintext: 62 ('b') is binary data, 74 ('t') is
612
text data with no character set specified, and 75 ('u') is
613
text data encoded in the UTF-8 character set. The timestamp
614
is in seconds since the epoch. If a filename is available it
615
gets printed as the third argument, percent-escaped as usual.
617
PLAINTEXT_LENGTH <length>
618
This indicates the length of the plaintext that is about to be
619
written. Note that if the plaintext packet has partial length
620
encoding it is not possible to know the length ahead of time.
621
In that case, this status tag does not appear.
623
SIG_SUBPACKET <type> <flags> <len> <data>
624
This indicates that a signature subpacket was seen. The
625
format is the same as the "spk" record above.
627
SC_OP_FAILURE [<code>]
628
An operation on a smartcard definitely failed. Currently
629
there is no indication of the actual error code, but
630
application should be prepared to later accept more arguments.
631
Defined values for CODE are:
632
0 - unspecified error (identically to a missing CODE)
637
A smart card operaion succeeded. This status is only printed
638
for certain operation and is mostly useful to check whether a
639
PIN change really worked.
641
BACKUP_KEY_CREATED fingerprint fname
642
A backup key named FNAME has been created for the key with
646
Format of the "--attribute-fd" output
647
=====================================
649
When --attribute-fd is set, during key listings (--list-keys,
650
--list-secret-keys) GnuPG dumps each attribute packet to the file
651
descriptor specified. --attribute-fd is intended for use with
652
--status-fd as part of the required information is carried on the
653
ATTRIBUTE status tag (see above).
655
The contents of the attribute data is specified by 2440bis, but for
656
convenience, here is the Photo ID format, as it is currently the only
659
Byte 0-1: The length of the image header. Due to a historical
660
accident (i.e. oops!) back in the NAI PGP days, this is
661
a little-endian number. Currently 16 (0x10 0x00).
663
Byte 2: The image header version. Currently 0x01.
665
Byte 3: Encoding format. 0x01 == JPEG.
667
Byte 4-15: Reserved, and currently unused.
669
All other data after this header is raw image (JPEG) data.
672
Format of the "--list-config" output
673
====================================
675
--list-config outputs information about the GnuPG configuration for
676
the benefit of frontends or other programs that call GnuPG. There are
677
several list-config items, all colon delimited like the rest of the
678
--with-colons output. The first field is always "cfg" to indicate
679
configuration information. The second field is one of (with
682
version: the third field contains the version of GnuPG.
686
pubkey: the third field contains the public key algorithmdcaiphers
687
this version of GnuPG supports, separated by semicolons. The
688
algorithm numbers are as specified in RFC-2440.
690
cfg:pubkey:1;2;3;16;17
692
cipher: the third field contains the symmetric ciphers this version of
693
GnuPG supports, separated by semicolons. The cipher numbers
694
are as specified in RFC-2440.
696
cfg:cipher:2;3;4;7;8;9;10
698
digest: the third field contains the digest (hash) algorithms this
699
version of GnuPG supports, separated by semicolons. The
700
digest numbers are as specified in RFC-2440.
702
cfg:digest:1;2;3;8;9;10
704
compress: the third field contains the compression algorithms this
705
version of GnuPG supports, separated by semicolons. The
706
algorithm numbers are as specified in RFC-2440.
710
group: the third field contains the name of the group, and the fourth
711
field contains the values that the group expands to, separated
714
For example, a group of:
715
group mynames = paige 0x12345678 joe patti
718
cfg:group:mynames:patti;joe;0x12345678;paige
586
912
1 byte max_cert_depth
587
913
The three items are used to check whether the cached
588
914
validity value from the dir record can be used.
915
1 u32 locked flags [not used]
590
916
1 u32 timestamp of trustdb creation
591
917
1 u32 timestamp of last modification which may affect the validity
592
918
of keys in the trustdb. This value is checked against the
593
919
validity timestamp in the dir records.
594
1 u32 timestamp of last validation
920
1 u32 timestamp of last validation [currently not used]
595
921
(Used to keep track of the time, when this TrustDB was checked
596
922
against the pubring)
597
1 u32 record number of keyhashtable
923
1 u32 record number of keyhashtable [currently not used]
598
924
1 u32 first free record
599
1 u32 record number of shadow directory hash table
925
1 u32 record number of shadow directory hash table [currently not used]
600
926
It does not make sense to combine this table with the key table
601
927
because the keyid is not in every case a part of the fingerprint.
602
928
1 u32 record number of the trusthashtbale
832
1158
clear that these are extensions for GNU, the next bytes gives the
833
1159
GNU protection mode - 1000. Defined modes are:
834
1160
1001 - do not store the secret part at all
837
Usage of gdbm files for keyrings
838
================================
839
The key to store the keyblock is its fingerprint, other records
840
are used for secondary keys. Fingerprints are always 20 bytes
841
where 16 bit fingerprints are appended with zero.
842
The first byte of the key gives some information on the type of the
844
1 = key is a 20 bit fingerprint (16 bytes fpr are padded with zeroes)
846
2 = key is the complete 8 byte keyid
847
data is a list of 20 byte fingerprints
848
3 = key is the short 4 byte keyid
849
data is a list of 20 byte fingerprints
850
4 = key is the email address
851
data is a list of 20 byte fingerprints
853
Data is prepended with a type byte:
855
2 = list of 20 byte padded fingerprints
856
3 = list of list fingerprints (but how to we key them?)
1161
1002 - a stub to access smartcards (not used in 1.2.x)
1166
NOTE: This is deprecated and will be removed in future versions.
862
1168
This mode can be used to perform multiple operations with one call to
863
1169
gpg. It comes handy in cases where you have to verify a lot of
864
1170
signatures. Currently we support only detached signatures. This mode
added
removed
doc/DETAILS
