39
39
tru = trust database information
40
40
spk = signature subpacket
42
2. Field: A letter describing the calculated trust. This is a single
42
2. Field: A letter describing the calculated validity. This is a single
43
43
letter, but be prepared that additional information may follow
44
44
in some future versions. (not used for secret keys)
45
45
o = Unknown (this key is new to the system)
48
48
(deprecated - use the 'D' in field 12 instead)
49
49
r = The key has been revoked
50
50
e = The key has expired
51
- = Unknown trust (i.e. no value assigned)
51
- = Unknown validity (i.e. no value assigned)
52
q = Undefined validity
53
53
'-' and 'q' may safely be treated as the same
54
54
value for most purposes
55
n = Don't trust this key at all
56
m = There is marginal trust in this key
57
f = The key is fully trusted
58
u = The key is ultimately trusted. This often means
56
m = The key is marginal valid.
57
f = The key is fully valid
58
u = The key is ultimately valid. This often means
59
59
that the secret key is available, but any key may
60
be marked as ultimately trusted.
60
be marked as ultimately valid.
62
If the validity information is given for a UID or UAT
63
record, it describes the validity calculated based on this
64
user ID. If given for a key record it describes the best
65
validity taken from the best rated user ID.
67
For X.509 certificates a 'u' is used for a trusted root
68
certificate (i.e. for the trust anchor) and an 'f' for all
69
other valid certificates.
62
71
3. Field: length of key in bits.
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'.
81
6. Field: Creation Date (in UTC). For UID and UAT records, this is
82
the self-signature date. Note that the date is usally
83
printed in seconds since epoch, however, we are migrating
84
to an ISO 8601 format (e.g. "19660205T091500"). This is
85
currently only relevant for X.509. A simple way to detect
86
the new format is to scan for the 'T'.
79
88
7. Field: Key or user ID/user attribute expiration date or empty if none.
88
97
This is a single letter, but be prepared that additional
89
98
information may follow in some future versions. For trust
90
99
signatures with a regular expression, this is the regular
91
expression value, quoted as in field 10.
100
expression value, quoted as in field 10.
93
102
10. Field: User-ID. The value is quoted like a C string to avoid
94
103
control characters (the colon is quoted "\x3a").
95
This is not used with --fixed-list-mode in gpg.
104
For a "pub" record this field is not used on --fixed-list-mode.
96
105
A UAT record puts the attribute subpacket count here, a
97
106
space, and then the total attribute subpacket size.
98
107
In gpgsm the issuer name comes here
99
108
An FPR record stores the fingerprint here.
100
109
The fingerprint of an revocation key is stored here.
102
11. Field: Signature class. This is a 2 digit hexnumber followed by
103
either the letter 'x' for an exportable signature or the
104
letter 'l' for a local-only signature.
105
The class byte of an revocation key is also given here,
106
'x' and 'l' ist used the same way.
111
11. Field: Signature class as per RFC-4880. This is a 2 digit
112
hexnumber followed by either the letter 'x' for an
113
exportable signature or the letter 'l' for a local-only
114
signature. The class byte of an revocation key is also
115
given here, 'x' and 'l' is used the same way. IT is not
108
118
12. Field: Key capabilities:
124
134
this is the same string as the fingerprint. The advantage
125
135
of using this value is that it is guaranteed to have been
126
136
been build by the same lookup algorithm as gpgsm uses.
127
For "uid" recods this lists the preferences n the sameway the
137
For "uid" records this lists the preferences in the same
138
way the gpg's --edit-key menu does.
129
139
For "sig" records, this is the fingerprint of the key that
130
140
issued the signature. Note that this is only filled in if
131
141
the signature verified correctly. Note also that for
152
162
!--------- index (eg. DSA goes from 0 to 3: p,q,g,y)
155
The "tru" trust database records have the fields:
165
Example for a "tru" trust base record:
167
tru:o:0:1166697654:1:3:1:5
157
171
2: Reason for staleness of trust. If this field is empty, then the
158
172
trustdb is not stale. This field may have multiple flags in it:
170
184
GnuPG before version 1.4 used the classic trust model by default.
171
185
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.
187
4: Date trustdb was created in seconds since 1970-01-01.
188
5: Date trustdb will expire in seconds since 1970-01-01.
189
6: Number of marginally trusted users to introduce a new key signer
190
(gpg's option --marginals-needed)
191
7: Number of completely trusted users to introduce a new key signer.
192
(gpg's option --completes-needed)
193
8: Maximum depth of a certification chain.
194
*gpg's option --max-cert-depth)
176
196
The "spk" signature subpacket records have the fields:
178
2: Subpacket number as per RFC-2440 and later.
198
2: Subpacket number as per RFC-4880 and later.
179
199
3: Flags in hex. Currently the only two bits assigned are 1, to
180
200
indicate that the subpacket came from the hashed part of the
181
201
signature, and 2, to indicate the subpacket was marked critical.
316
336
TRUST_FULLY [0 [<validation_model>]]
317
337
TRUST_ULTIMATE [0 [<validation_model>]]
318
338
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
339
indicate the validity of the key used to create the signature.
340
The error token values are currently only emitted by gpgsm.
341
VALIDATION_MODEL describes the algorithm used to check the
342
validity of the key. The defaults are the standard Web of
343
Trust model for gpg and the the standard X.509 model for
344
gpgsm. The defined values are
325
346
"pgp" for the standard PGP WoT.
326
347
"shell" for the standard X.509 model.
327
348
"chain" for the chain model.
350
Note that we use the term "TRUST_" in the status names for
351
historic reasons; we now speak of validity.
330
353
PKA_TRUST_GOOD <mailbox>
331
354
PKA_TRUST_BAD <mailbox>
339
362
KEYEXPIRED <expire-timestamp>
340
363
The key has expired. expire-timestamp is the expiration time
341
in seconds after the epoch.
364
in seconds sice Epoch. This status line is not very useful
365
because it will also be emitted for expired subkeys even if
366
this subkey is not used. To check whether a key used to sign
367
a message has expired, the EXPKEYSIG status line is to be
343
370
Note, that TIMESTAMP may either be a number with seconds since
344
371
epoch or an ISO 8601 string which can be detected by the
686
713
pubkey: the third field contains the public key algorithmdcaiphers
687
714
this version of GnuPG supports, separated by semicolons. The
688
algorithm numbers are as specified in RFC-2440.
715
algorithm numbers are as specified in RFC-4880.
690
717
cfg:pubkey:1;2;3;16;17
692
719
cipher: the third field contains the symmetric ciphers this version of
693
720
GnuPG supports, separated by semicolons. The cipher numbers
694
are as specified in RFC-2440.
721
are as specified in RFC-4880.
696
723
cfg:cipher:2;3;4;7;8;9;10
698
725
digest: the third field contains the digest (hash) algorithms this
699
726
version of GnuPG supports, separated by semicolons. The
700
digest numbers are as specified in RFC-2440.
727
digest numbers are as specified in RFC-4880.
702
729
cfg:digest:1;2;3;8;9;10
704
731
compress: the third field contains the compression algorithms this
705
732
version of GnuPG supports, separated by semicolons. The
706
algorithm numbers are as specified in RFC-2440.
733
algorithm numbers are as specified in RFC-4880.
708
735
cfg:compress:0;1;2;3
723
Key generation shows progress by printing different characters to
725
"." Last 10 Miller-Rabin tests failed
726
"+" Miller-Rabin test succeeded
727
"!" Reloading the pool with fresh prime numbers
728
"^" Checking a new value for the generator
729
"<" Size of one factor decreased
730
">" Size of one factor increased
732
The prime number for Elgamal is generated this way:
734
1) Make a prime number q of 160, 200, 240 bits (depending on the keysize)
735
2) Select the length of the other prime factors to be at least the size
736
of q and calculate the number of prime factors needed
737
3) Make a pool of prime numbers, each of the length determined in step 2
738
4) Get a new permutation out of the pool or continue with step 3
739
if we have tested all permutations.
740
5) Calculate a candidate prime p = 2 * q * p[1] * ... * p[n] + 1
741
6) Check that this prime has the correct length (this may change q if
742
it seems not to be possible to make a prime of the desired length)
743
7) Check whether this is a prime using trial divisions and the
745
8) Continue with step 4 if we did not find a prime in step 7.
746
9) Find a generator for that prime.
748
This algorithm is based on Lim and Lee's suggestion from the
749
Crypto '97 proceedings p. 260.
750
See the Libcrypt manual.
752
753
Unattended key generation
789
790
and all keys are written to that file. If a new filename is given,
790
791
this file is created (and overwrites an existing one).
791
792
Both control statements must be given.
794
Enable a mode where the command "passphrase" is ignored and
795
instead the usual passphrase dialog is used. This does not
796
make sense for batch key generation; however the unattended
797
key generation feature is also used by GUIs and this feature
798
relinquishes the GUI from implementing its own passphrase
799
entry code. This is a global option.
801
Disable the ask-passphrase mode.
792
803
o The order of the parameters does not matter except for "Key-Type"
793
804
which must be the first parameter. The parameters are only for the
794
805
generated keyblock and parameters from previous key generations are not
825
836
The 3 parts of a key. Remember to use UTF-8 here.
826
837
If you don't give any of them, no user ID is created.
827
838
Expire-Date: <iso-date>|(<number>[d|w|m|y])
828
Set the expiration date for the key (and the subkey). It
829
may either be entered in ISO date format (2000-08-15) or as
830
number of days, weeks, month or years. Without a letter days
839
Set the expiration date for the key (and the subkey). It may
840
either be entered in ISO date format (2000-08-15) or as number
841
of days, weeks, month or years. The special notation
842
"seconds=N" is also allowed to directly give an Epoch
843
value. Without a letter days are assumed. Note that there is
844
no check done on the overflow of the type used by OpenPGP for
845
timestamps. Thus you better make sure that the given value
846
make sense. Although OpenPGP works with time intervals, GnuPG
847
uses an absolute value internally and thus the last year we
848
can represent is 2105.
832
849
Creation-Date: <iso-date>
833
850
Set the creation date of the key as stored in the key
834
851
information and which is also part of the fingerprint
1104
GNUPG uses PGP 2 packet headers and also understands OpenPGP packet header.
1105
There is one enhancement used with the old style packet headers:
1107
CTB bits 10, the "packet-length length bits", have values listed in
1108
the following table:
1110
00 - 1-byte packet-length field
1111
01 - 2-byte packet-length field
1112
10 - 4-byte packet-length field
1113
11 - no packet length supplied, unknown packet length
1115
As indicated in this table, depending on the packet-length length
1116
bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field
1117
are a "packet-length field". The packet-length field is a whole
1118
number field. The value of the packet-length field is defined to be
1119
the value of the whole number field.
1121
A value of 11 is currently used in one place: on compressed data.
1122
That is, a compressed data block currently looks like <A3 01 . . .>,
1123
where <A3>, binary 10 1000 11, is an indefinite-length packet. The
1124
proper interpretation is "until the end of the enclosing structure",
1125
although it should never appear outermost (where the enclosing
1126
structure is a file).
1128
+ This will be changed with another version, where the new meaning of
1129
+ the value 11 (see below) will also take place.
1131
+ A value of 11 for other packets enables a special length encoding,
1132
+ which is used in case, where the length of the following packet can
1133
+ not be determined prior to writing the packet; especially this will
1134
+ be used if large amounts of data are processed in filter mode.
1136
+ It works like this: After the CTB (with a length field of 11) a
1137
+ marker field is used, which gives the length of the following datablock.
1138
+ This is a simple 2 byte field (MSB first) containing the amount of data
1139
+ following this field, not including this length field. After this datablock
1140
+ another length field follows, which gives the size of the next datablock.
1141
+ A value of 0 indicates the end of the packet. The maximum size of a
1142
+ data block is limited to 65534, thereby reserving a value of 0xffff for
1143
+ future extensions. These length markers must be inserted into the data
1144
+ stream just before writing the data out.
1146
+ This 2 byte field is large enough, because the application must buffer
1147
+ this amount of data to prepend the length marker before writing it out.
1148
+ Data block sizes larger than about 32k doesn't make any sense. Note
1149
+ that this may also be used for compressed data streams, but we must use
1150
+ another packet version to tell the application that it can not assume,
1151
+ that this is the last packet.
1154
1118
GNU extensions to the S2K algorithm
1155
1119
===================================
1156
1120
S2K mode 101 is used to identify these extensions.
1161
1125
1002 - a stub to access smartcards (not used in 1.2.x)
1166
NOTE: This is deprecated and will be removed in future versions.
1168
This mode can be used to perform multiple operations with one call to
1169
gpg. It comes handy in cases where you have to verify a lot of
1170
signatures. Currently we support only detached signatures. This mode
1171
is a kludge to avoid running gpg n daemon mode and using Unix Domain
1172
Sockets to pass the data to it. There is no easy portable way to do
1173
this under Windows, so we use plain old pipes which do work well under
1174
Windows. Because there is no way to signal multiple EOFs in a pipe we
1175
have to embed control commands in the data stream: We distinguish
1176
between a data state and a control state. Initially the system is in
1177
data state but it won't accept any data. Instead it waits for
1178
transition to control state which is done by sending a single '@'
1179
character. While in control state the control command os expected and
1180
this command is just a single byte after which the system falls back
1181
to data state (but does not necesary accept data now). The simplest
1182
control command is a '@' which just inserts this character into the
1185
Here is the format we use for detached signatures:
1186
"@<" - Begin of new stream
1187
"@B" - Detached signature follows.
1188
This emits a control packet (1,'B')
1189
<detached_signature>
1190
"@t" - Signed text follows.
1191
This emits the control packet (2, 'B')
1193
"@." - End of operation. The final control packet forces signature
1195
"@>" - End of stream
added
removed
doc/DETAILS
