build: Update README.maint.
[gnupg.git] / doc / whats-new-in-2.1.txt
1                       ━━━━━━━━━━━━━━━━━━━━━━━━━━━
2                        GNUPG - WHAT’S NEW IN 2.1
3
4
5                               Werner Koch
6                       ━━━━━━━━━━━━━━━━━━━━━━━━━━━
7
8
9                                2014-11-04
10
11
12 Table of Contents
13 ─────────────────
14
15 1 What’s new in GnuPG 2.1
16 .. 1.1 Removal of the secret keyring
17 .. 1.2 Removal of PGP-2 support
18 .. 1.3 Leaner key generation interface
19 .. 1.4 Support for ECC
20 .. 1.5 Quick generate and sign commands
21 .. 1.6 Improved Pinentry support
22 .. 1.7 Auto-start of the gpg-agent
23 .. 1.8 Duplicate long key id fixes
24 .. 1.9 Enhanced Dirmngr
25 .. 1.10 Better keyserver pool support
26 .. 1.11 Faster keyring format
27 .. 1.12 Auto-generated revocation certificates
28 .. 1.13 Improved card support
29 .. 1.14 New format for key listings
30 .. 1.15 Support for Putty
31 .. 1.16 Improved X.509 certificate creation
32 .. 1.17 Scripts to create a Windows installer
33
34
35 A possibly revised version of this article can be found at:
36 https://gnupg.org/faq/whats-new-in-2.1.html
37
38
39 1 What’s new in GnuPG 2.1
40 ═════════════════════════
41
42   GnuPG version 2.1 comes with a bag of new features which changes some
43   things old-timers are used to.  This page explains the more important
44   ones.  It expects that the reader is familiar with GnuPG version 2.0
45   and aware that GnuPG consists of /gpg/, /gpgsm/, and /gpg-agent/ as
46   its main components.
47
48   • The file /secring.gpg/ is not anymore used to store the secret keys.
49     Merging of secret keys is now supported.
50
51   • All support for /PGP-2 keys/ has been removed for security reasons.
52
53   • The standard key generation interface is now much leaner.  This will
54     help a new user to quickly generate a suitable key.
55
56   • Support for /Elliptic Curve Cryptography/ (ECC) is now available.
57
58   • Commands to create and sign keys from the command line without any
59     extra prompts are now available.
60
61   • The Pinentry may now show the new passphrase entry and the
62     passphrase confirmation entry in one dialog.
63
64   • There is no more need to manually start the gpg-agent.  It is now
65     started by any part of GnuPG as needed.
66
67   • Problems with importing keys with the same long key id have been
68     addressed.
69
70   • The /dirmngr/ is now part of GnuPG proper and also takes care of
71     accessing keyserver.
72
73   • Keyserver pools are now handled in a smarter way.
74
75   • A new format for locally storing the public keys is now used.  This
76     considerable speeds up operations on large keyrings.
77
78   • /Revocation certificates/ are now created by default.
79
80   • Card support has been updated, new readers and token types are
81     supported.
82
83   • The format of the key listing has been changed to better identify
84     the properties of a key.
85
86   • The gpg-agent may now be used on Windows as /pageant/ replacement
87     for /putty/ in the same way it is used for years on Unix as
88     /ssh-agent/ replacement.
89
90   • Creation of X.509 certificates has been improved.  It is now also
91     possible to export them directly in PKCS#8 and PEM format for use on
92     TLS servers.
93
94   • The scripts to create a Windows installer are now part of GnuPG.
95
96   Now for the detailed description of these new features:
97
98
99 1.1 Removal of the secret keyring
100 ─────────────────────────────────
101
102   gpg used to keep the public key pairs in two files: `pubring.gpg' and
103   `secring.gpg'.  The only difference is that secring stored in addition
104   to the public part also the private part of the key pair.  The secret
105   keyring thus contained only the keys for which a private key is
106   available, that is the user’s key.  It required a lot of code to keep
107   both versions of the key in sync and led to sometimes surprising
108   inconsistencies.
109
110   The design of GnuPG-2 demands that only the gpg-agent has control over
111   the private parts of the keys and the actual encryption engine (gpg or
112   gpgsm) does not know about the private key but care only about session
113   keys and keys for symmetric encryption.  This has been implemented
114   about 10 years ago for /gpgsm/ (the S/MIME part of GnuPG).  However,
115   /gpg/ (the OpenPGP part) used the gpg-agent only as passphrase entry
116   and cache device but handles the private key itself.
117
118   With GnuPG 2.1 this changed and /gpg/ now also delegates all private
119   key operations to the gpg-agent.  Thus there is no more code in the
120   /gpg/ binary for handling private keys.  En passant this allows the
121   long time requested “merging of secret keys” and several other
122   advanced key management techniques.
123
124   To ease the migration to the no-secring method, /gpg/ detects the
125   presence of a `secring.gpg' and converts the keys on-the-fly to the
126   the key store of /gpg-agent/ (this is the `private-keys-v1.d'
127   directory below the GnuPG home directory (`~/.gnupg')).  This is done
128   only once and an existing `secring.gpg' is then not anymore touched by
129   /gpg/.  This allows co-existence of older GnuPG versions with GnuPG
130   2.1.  However, any change to the private keys using the new /gpg/ will
131   not show up when using pre-2.1 versions of GnuPG and vice versa.
132
133   Note that the command `--export-secret-keys' still creates an OpenPGP
134   compliant file with the secret keys.  This is achieved by asking
135   /gpg-agent/ to convert a key and return it in the OpenPGP protected
136   format.  The export operation requires that the passphrase for the key
137   is entered so that /gpg-agent/ is able to change the protection from
138   its internal format to the OpenPGP required format.
139
140
141 1.2 Removal of PGP-2 support
142 ────────────────────────────
143
144   Some algorithms and parts of the protocols as used by the 20 years old
145   [PGP-2] software are meanwhile considered unsafe.  In particular the
146   baked in use of the [MD5] hash algorithm limits the security of PGP-2
147   keys to non-acceptable rate.  Technically those PGP-2 keys are called
148   version 3 keys (v3) and are easily identified by a shorter fingerprint
149   which is commonly presented as 16 separate double hex digits.
150
151   With GnuPG 2.1 all support for those keys has gone.  If they are in an
152   existing keyring they will eventually be removed.  If GnuPG encounters
153   such a key on import it will not be imported due to the not anymore
154   implemented v3 key format.  Removing the v3 key support also reduces
155   complexity of the code and is thus better than to keep on handling
156   them with a specific error message.
157
158   There is one use case where PGP-2 keys may still be required: For
159   existing encrypted data.  We suggest to keep a version of GnuPG 1.4
160   around which still has support for these keys (it might be required to
161   use the `--allow-weak-digest-algos' option).  A better solution is to
162   re-encrypt the data using a modern key.
163
164
165   [PGP-2] https://en.wikipedia.org/wiki/Pretty_Good_Privacy
166
167   [MD5] https://en.wikipedia.org/wiki/MD5
168
169
170 1.3 Leaner key generation interface
171 ───────────────────────────────────
172
173   This is best shown with an example:
174
175   ╭────
176   │ $ gpg2 --gen-key
177   │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
178   │ This is free software: you are free to change and redistribute it.
179   │ There is NO WARRANTY, to the extent permitted by law.
180   │
181   │ gpg: keybox '/home/foo/.gnupg/pubring.kbx' created
182   │ Note: Use "gpg --full-gen-key" for a full featured key generation dialog.
183   │
184   │ GnuPG needs to construct a user ID to identify your key.
185   │
186   │ Real name: Glenn Greenwald
187   │ Email address: glenn@example.org
188   │ You selected this USER-ID:
189   │     "Glenn Greenwald <glenn@example.org>"
190   │
191   │ Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
192   │ [...]
193   │ pub   rsa2048/68FD0088 2014-11-03
194   │       Key fingerprint = 0290 5ABF 17C7 81FB C390  9B00 636A 1BBD 68FD 0088
195   │ uid       [ultimate] Glenn Greenwald <glenn@example.org>
196   │ sub   rsa2048/84439DCD 2014-11-03
197   ╰────
198
199   Thus only the name and the mail address are required.  For all other
200   parameters the default values are used.  Many graphical frontends
201   works in the same way.  Note that /gpg/ prints a hint for the old time
202   gpg users on how to get the full option menu.
203
204
205 1.4 Support for ECC
206 ───────────────────
207
208   GnuPG now support Elliptic Curve keys for public key encryption.  This
209   is defined in [RFC-6637].  Because there is no other mainstream
210   OpenPGP implementation yet available which supports ECC, the use of
211   such keys is still very limited.  Thus GnuPG 2.1 currently hides the
212   options to create an ECC key.
213
214   For those who want to experiment with ECC or already want to prepare a
215   key for future use, the command `--gen-full-key' along with the option
216   `--expert' is the enabler:
217
218   ╭────
219   │ $ gpg2 --expert --full-gen-key
220   │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
221   │ This is free software: you are free to change and redistribute it.
222   │ There is NO WARRANTY, to the extent permitted by law.
223   │
224   │ Please select what kind of key you want:
225   │    (1) RSA and RSA (default)
226   │    (2) DSA and Elgamal
227   │    (3) DSA (sign only)
228   │    (4) RSA (sign only)
229   │    (7) DSA (set your own capabilities)
230   │    (8) RSA (set your own capabilities)
231   │    (9) ECC and ECC
232   │   (10) ECC (sign only)
233   │   (11) ECC (set your own capabilities)
234   │ Your selection? 9
235   │ Please select which elliptic curve you want:
236   │    (2) NIST P-256
237   │    (3) NIST P-384
238   │    (4) NIST P-521
239   │    (5) Brainpool P-256
240   │    (6) Brainpool P-384
241   │    (7) Brainpool P-512
242   │ Your selection? 2
243   │ Please specify how long the key should be valid.
244   │          0 = key does not expire
245   │       <n>  = key expires in n days
246   │       <n>w = key expires in n weeks
247   │       <n>m = key expires in n months
248   │       <n>y = key expires in n years
249   │ Key is valid for? (0)
250   │ Key does not expire at all
251   │ Is this correct? (y/N) y
252   │
253   │ GnuPG needs to construct a user ID to identify your key.
254   │
255   │ Real name: Edward Snowden
256   │ Email address: edward@example.org
257   │ Comment:
258   │ You selected this USER-ID:
259   │     "Edward Snowden <edward@example.org>"
260   │
261   │ Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
262   │ [...]
263   │ pub   nistp256/382660E3 2014-11-03
264   │       Key fingerprint = E630 27CF 3D68 22A7 6FF2  093E D179 9E72 3826 60E3
265   │ uid       [ultimate] Edward Snowden <edward@example.org>
266   │ sub   nistp256/48C9A997 2014-11-03 nistp256
267   ╰────
268
269   In this example we created a primary ECC key for signing and an subkey
270   for encryption.  For both we use the NIST P-256 curve.  The key may
271   now be used in the same way as any other key.  It is possible to add
272   an RSA subkey or one can create an RSA or DSA main key and add an ECC
273   subkey for signing or encryption.  Note that the list of offered
274   curves depends on the installed Libgcrypt version.
275
276   For many people the NIST and also the Brainpool curves have an
277   doubtful origin and thus the plan for GnuPG is to use Bernstein’s
278   [Curve 25519] as default.  GnuPG 2.1.0 already comes with support for
279   signing keys using the [Ed25519] variant of this curve.  This has not
280   yet been standardized by the IETF (i.e. there is no RFC) but we won’t
281   wait any longer and go ahead using the proposed format for this
282   signing algorithm.  The format for an encryption key has not yet been
283   finalized and will be added to GnuPG in one of the next point
284   releases.  Recall that an encryption subkey can be added to a key at
285   any time.  If you want to create a signing key you may do it this way:
286
287   ╭────
288   │ $ gpg2 --expert --full-gen-key
289   │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
290   │ This is free software: you are free to change and redistribute it.
291   │ There is NO WARRANTY, to the extent permitted by law.
292   │
293   │ Please select what kind of key you want:
294   │    (1) RSA and RSA (default)
295   │    (2) DSA and Elgamal
296   │    (3) DSA (sign only)
297   │    (4) RSA (sign only)
298   │    (7) DSA (set your own capabilities)
299   │    (8) RSA (set your own capabilities)
300   │    (9) ECC and ECC
301   │   (10) ECC (sign only)
302   │   (11) ECC (set your own capabilities)
303   │ Your selection? 10
304   │ Please select which elliptic curve you want:
305   │    (1) Curve 25519
306   │    (2) NIST P-256
307   │    (3) NIST P-384
308   │    (4) NIST P-521
309   │    (5) Brainpool P-256
310   │    (6) Brainpool P-384
311   │    (7) Brainpool P-512
312   │ Your selection? 1
313   │ gpg: WARNING: Curve25519 is not yet part of the OpenPGP standard.
314   │ Use this curve anyway? (y/N) y
315   │ Please specify how long the key should be valid.
316   │          0 = key does not expire
317   │       <n>  = key expires in n days
318   │       <n>w = key expires in n weeks
319   │       <n>m = key expires in n months
320   │       <n>y = key expires in n years
321   │ Key is valid for? (0)
322   │ Key does not expire at all
323   │ Is this correct? (y/N) y
324   │
325   │ GnuPG needs to construct a user ID to identify your key.
326   │
327   │ Real name: Laura Poitras
328   │ Email address: laura@example.org
329   │ Comment:
330   │ You selected this USER-ID:
331   │     "Laura Poitras <laura@example.org>"
332   │
333   │ Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
334   │ [...]
335   │ pub   ed25519/5C1AFC2A 2014-11-03
336   │       Key fingerprint = ED85 4D98 5D8F 502F C6C5  FFB2 AA81 319E 5C1A FC2A
337   │ uid       [ultimate] Laura Poitras <laura@example.org>
338   ╰────
339
340   Support for ECC keys is available only on some keyservers but it is
341   expected that this will be fixed over the next few months.
342
343
344   [RFC-6637] https://rfc-editor.org/info/rfc6637
345
346   [Curve 25519] http://cr.yp.to/ecdh/curve25519-20060209.pdf
347
348   [Ed25519] http://dx.doi.org/10.1007/s13389-012-0027-1
349
350
351 1.5 Quick generate and sign commands
352 ────────────────────────────────────
353
354   Sometimes it is useful to use only command line options without any
355   parameter file or interactive prompts for generating a key or to sign
356   a key.  This can now be accomplished with a few new commands:
357
358   ╭────
359   │ $ gpg2 --batch --quick-gen-key 'Daniel Ellsberg <ellsberg@example.org>'
360   │ gpg: key 911B90A9 marked as ultimately trusted
361   ╰────
362
363   If a key with that user id already exists, gpg bails out with an error
364   message.  You can force creation using the option `--yes'.  If you
365   want some more control, you may not use `--batch' and gpg will ask for
366   confirmation and show the resulting key:
367
368   ╭────
369   │ $ gpg2 --quick-gen-key 'Daniel Ellsberg <ellsberg@example.org>'
370   │ About to create a key for:
371   │     "Daniel Ellsberg <ellsberg@example.org>"
372   │
373   │ Continue? (Y/n) y
374   │ gpg: A key for "Daniel Ellsberg <ellsberg@example.org>" already exists
375   │ Create anyway? (y/N) y
376   │ gpg: creating anyway
377   │ [...]
378   │ pub   rsa2048/BD19AC1C 2014-11-04
379   │       Key fingerprint = 15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C
380   │ uid       [ultimate] Daniel Ellsberg <ellsberg@example.org>
381   │ sub   rsa2048/72A4D018 2014-11-04
382   ╰────
383
384   Another common operation is to sign a key.  /gpg/ can do this directly
385   from the command line by giving the fingerprint of the to-be-signed
386   key:
387
388   ╭────
389   │ $ gpg2 --quick-sign-key  '15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C'
390   │
391   │ pub  rsa2048/BD19AC1C
392   │      created: 2014-11-04  expires: never       usage: SC
393   │      trust: ultimate      validity: ultimate
394   │  Primary key fingerprint: 15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C
395   │
396   │      Daniel Ellsberg <ellsberg@example.org>
397   ╰────
398
399   In case the key has already been signed, the command prints a note and
400   exits with success.  In case you want to check that it really worked,
401   use `=--check-sigs' as usual:
402
403   ╭────
404   │ $ gpg2 --check-sigs  '15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C'
405   │ gpg: checking the trustdb
406   │ gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
407   │ gpg: depth: 0  valid:   6  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 6u
408   │ pub   rsa2048/BD19AC1C 2014-11-04
409   │ uid       [  full  ] Daniel Ellsberg <ellsberg@example.org>
410   │ sig!3        BD19AC1C 2014-11-04  Daniel Ellsberg <ellsberg@example.org>
411   │ sig!         68FD0088 2014-11-04  Glenn Greenwald <glenn@example.org>
412   │ sub   rsa2048/72A4D018 2014-11-04
413   │ sig!         BD19AC1C 2014-11-04  Daniel Ellsberg <ellsberg@example.org>
414   ╰────
415
416
417   The fingerprint may also be given without the spaces in which case
418   there is no need for the quotes.  If you want to sign only certain
419   user ids of a key, list those user id verbatim after the fingerprint.
420   To create a non-exportable key signature, use the command
421   `--quick-lsign-key' instead.
422
423
424 1.6 Improved Pinentry support
425 ─────────────────────────────
426
427   When using a recent Pinentry module (0.90, GTK+ variant), the
428   gpg-agent will not anymore show two separate Pinentry dialogs to enter
429   a new passphrase and later to confirm the new passphrase.  Instead the
430   first dialog also has the confirm/repeat entry and internally checks
431   whether they match.
432
433   With any Pinentry version the several separate dialogs to inform and
434   ask for confirmation about questionable properties of a new passphrase
435   (e.g. length, only alpha letters) have been combined into one dialog
436   to show all non-asserted constraints at once.
437
438   The GTK+ Pinentry does now allow pasting of values into the entries.
439   Copying them from the entries is still inhibited on purpose.
440   Depending on the system, the option `no-grab' may be required for in
441   the `gpg-agent.conf' file to actually make use of the paste feature.
442
443
444 1.7 Auto-start of the gpg-agent
445 ───────────────────────────────
446
447   The /gpg-agent/ is the central part of the GnuPG system.  It takes
448   care of all private (secret) keys and if required diverts operations
449   to a smartcard or other token.  It also provides support for the
450   Secure Shell by implementing the ssh-agent protocol.
451
452   The classic way to run /gpg-agent/ on Unix systems is by launching it
453   at login time and use an environment variable (`GPG_AGENT_INFO') to
454   tell the other GnuPG modules how to connect to the agent.  However,
455   correctly managing the start up and this environment variable is
456   cumbersome so that that an easier method is required.  Since GnuPG
457   2.0.16 the `--use-standard-socket' option already allowed to start the
458   agent on the fly; however the environment variable was still required.
459
460   With GnuPG 2.1 the need of `GPG_AGENT_INFO' has been completely
461   removed and the variable is ignored.  Instead a fixed Unix domain
462   socket named `S.gpg-agent' in the GnuPG home directory (by default
463   `~/.gnupg') is used.  The agent is also started on demand by all tools
464   requiring services from the agent.
465
466   If the option `--enable-ssh-support' is used the auto-start mechanism
467   does not work because /ssh/ does not know about this mechanism.
468   Instead it is required that the environment variable `SSH_AUTH_SOCK'
469   is set to the `S.gpg-agent.ssh' socket in the GnuPG home directory.
470   Further /gpg-agent/ must be started: Either by using a GnuPG command
471   which implicitly starts /gpg-agent/ or by using `gpgconf --launch
472   gpg-agent' to explicitly start it if not yet done.
473
474
475 1.8 Duplicate long key id fixes
476 ───────────────────────────────
477
478   A deficit of the OpenPGP protocol is that signatures carry only a
479   limited indication on which public has been used to create a
480   signature.  Thus a verification engine may only use this “long key id”
481   to look up the the key in its own store or from a public keyserver.
482   Unfortunately it has now become possible to create a key with a long
483   key id matching the key id of another key.  Importing a key with a
484   long key id already used by another key in gpg’s local key store was
485   not possible due to checks done on import.  Now, if the “wrong” key
486   has been imported first /gpg/ would not allow to later import the
487   second “correct” key.  This problem has been fixed in 2.1 by allowing
488   the import and by doing trial verification against all matching keys.
489
490
491 1.9 Enhanced Dirmngr
492 ────────────────────
493
494   Before version 2.1, /gpg/ used so-called keyserver helpers to access
495   the OpenPGP keyservers.  A problem with that is that they are short
496   living processes which are not able to keep a state.  With 2.1, the
497   formerly separate package Dirmngr (which was separate due to copyright
498   assignment reasons) has been integrated into GnuPG.
499
500   In the past /dirmngr/ was only used by /gpgsm/ for X.509 (S/MIME) CRL
501   and OCSP handling.  Being a proper part of GnuPG /dirmngr/ does now
502   also care about accessing OpenPGP keyservers.  This make its easier to
503   debug problems with the keyservers and to exchange additional
504   information about the keyserver between /gpg/ and /dirmngr/.  It will
505   eventually also be possible to run background tasks to refresh keys.
506
507   Although the ability to start /dirmngr/ as a system service is still
508   available, this is not anymore recommended and instead /dirmngr/ is
509   now by default started on-demand, very similar to /gpg-agent/.
510
511
512 1.10 Better keyserver pool support
513 ──────────────────────────────────
514
515   For load balancing reasons, keyservers are organized in pools to
516   enable instant round-robin DNS assignment of random keyservers.  A
517   problem with that approach is that the DNS resolver is not aware of
518   the state of the keyserver.  If a keyserver has gone down or a routing
519   problems occurs, /gpg/ and its keyserver helpers were not ware of it
520   and would try over and over to use the same, dead, keyserver up until
521   the DNS information expires and a the DNS resolver assigned a new
522   server from the pool.
523
524   The new /dirmngr/ in GnuPG does not use the implicit round-robin of
525   the DNS resolver but uses its own DNS look up and keeps an internal
526   table of all hosts from the pool along with the encountered aliveness
527   state.  Thus after a failure (timeout) of a request, /dirmngr/ flags a
528   host as dead and randomly selects another one from the pool.  After a
529   few hours the flag is removed so that the host will be tried again.
530   It is also possible to mark a specif host from a pool explicitly as
531   dead so that it won’t be used in future.  To interact with the
532   /dirmngr/ the `gpg-connect-agent' tool is used:
533
534   ╭────
535   │ $ gpg-connect-agent --dirmngr 'help keyserver' /bye
536   │ $ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye
537   ╰────
538
539   The first command prints a help screen for the keyserver command and
540   the second command prints the current host table.
541
542
543 1.11 Faster keyring format
544 ──────────────────────────
545
546   The format GnuPG has always used for the public keyring is actually a
547   slightly extended version of the on-the-wire format for OpenPGP key
548   exchange.  This format is quite inflexible to work with when random
549   access to keys in the keyring is required.  In fact /gpg/ always
550   parsed all keys in the keyring until it encountered the desired one.
551   With a large keyring (more than a few thousand keys) this could be
552   quite slow.
553
554   From its very beginning /gpgsm/ has used a different format to store
555   public keys (certificates) which we call a /keybox/. That file format
556   carries meta information about the stored keys and thus allows
557   searching without actually parsing the key and computing fingerprints
558   and such.  The /keybox/ format has been designed protocol independent
559   and with 2.1 support for OpenPGP keys has been added.  Random access
560   to the keys is now really fast and keyrings with 30000 keys and more
561   are now easily possible.  That change also enables us to easily
562   introduce other storage methods
563
564   If no `pubring.gpg' is found, /gpg/ defaults to the new /keybox/
565   format and creates a `pubring.kbx' keybox file.  If such a keybox file
566   already exists, for example due to the use of /gpgsm/, it will also be
567   used for OpenPGP keys.  However, if a `pubring.gpg' is found and no
568   keybox file with OpenPGP keys exists, the old `pubring.gpg' will be
569   used.  Take care: GnuPG versions before 2.1 will always use the
570   `pubring.gpg' file and not know anything about keys stored in the
571   keybox file.
572
573   To convert an existing `pubring.gpg' file to the keybox format, you
574   first rename the file to (for example) `publickeys' so it won’t be
575   recognized by any GnuPG version and then you run the command
576
577   ╭────
578   │ $ gpg2 --import publickeys
579   ╰────
580
581   You may then rename the `publickeys' file back so that it can be used
582   by older GnuPG versions.  Remember that in this case you have two
583   independent copies of the public keys.
584
585
586 1.12 Auto-generated revocation certificates
587 ───────────────────────────────────────────
588
589   This version creates an ASCII armored revocation certificate for each
590   generated keypair and stores that certificate in a file named after
591   the fingerprint of the key in the `openpgp-revocs.d' directory below
592   the GnuPG home directory.  Brief instructions on how to use this
593   revocation certificate are put at the top of the file.
594
595
596 1.13 Improved card support
597 ──────────────────────────
598
599   The /scdaemon/, which is responsible for accessing smardcards and
600   other tokens, has received may updates.  In particular plugable USB
601   readers with a fixed card now work smoothless and similar to standard
602   readers.  The latest features of the /gnuk/ token are supported.  Code
603   for the HSM smartcard has been added.  More card readers with a PIN
604   pad are supported.  The internal CCID driver does now also work with
605   certain non-auto configuration equipped readers.
606
607
608 1.14 New format for key listings
609 ────────────────────────────────
610
611   Due to the introduction of ECC keys the old format to list keys was
612   not anymore suitable.  In particular, the length of an ECC key is
613   defined but its expressiveness is limited without the other parameters
614   of the curve.  The common way to describe an ECC key is by using the
615   assigned name of its curve.  To allow for a common description we now
616   either use the algorithm name with appended key length or use the name
617   of the curve:
618
619   ╭────
620   │ pub   2048D/1E42B367 2007-12-31 [expires: 2018-12-31]
621   │ pub   dsa2048/1E42B367 2007-12-31 [expires: 2018-12-31]
622   │ pub   ed25519/0AA914C9 2014-10-18
623   ╰────
624
625   The first two lines show the same key in the old format and in the new
626   format.  The third line shows an example of an ECC key using the
627   ed25519 curve.
628
629   As a further change the validity of a key is now shown by default;
630   that is `show-uid-validity' is implicitly used for the
631   `--list-options'.
632
633   The annotated key listing produced by the `--with-colons' options did
634   not change.  However a couple of new fields have been added, for
635   example if the new option `--with-secret-' is used the “S/N of a token
636   field” indicates the presence of a secret key even in a public key
637   listing.  This option is supported by recent [GPGME] versions and
638   makes writing of key manager software easier.
639
640
641   [GPGME] https://gnupg.org/related_software/gpgme/
642
643
644 1.15 Support for Putty
645 ──────────────────────
646
647   On Windows the new option `--enable-putty-support' allows gpg-agent to
648   act as a replacement for [Putty]’s authentication agent /Pageant/.  It
649   is the Windows counterpart for the `--enable-ssh-support' option as
650   used on Unix.
651
652
653   [Putty] http://www.chiark.greenend.org.uk/~sgtatham/putty/
654
655
656 1.16 Improved X.509 certificate creation
657 ────────────────────────────────────────
658
659   In addition to an improved certificate signing request menu, it is now
660   possible to create a self-signed certificate using the interactive
661   menu of /gpgsm/.
662
663   In batch mode the certificate creation dialog can now be controlled by
664   a parameter file with several new keywords.  Such a parameter file
665   allows the creation of arbitrary X.509 certificates similar to what
666   can be done with /openssl/.  It may this be used as the base for a CA
667   software.  For details see the “CSR and certificate creation” section
668   in the manual.
669
670   The new commands `--export-secret-key-p8' and –export-secret-key-raw=
671   may be used to export a secret key directly in PKCS#8 or PKCS#1
672   format.  Thus X.509 certificates for TLS use may be managed by /gpgsm/
673   and directly exported in a format suitable for OpenSSL based servers.
674
675
676 1.17 Scripts to create a Windows installer
677 ──────────────────────────────────────────
678
679   GnuPG now comes with the /speedo/ build system which may be used to
680   quickly download and build GnuPG and all its direct dependencies on a
681   decent Unix system.  See the README file for more instructions.
682
683   The very same script may also be used to build a complete NSIS based
684   installer for Windows using the mingw-w64 cross-compiler toolchain.
685   That installer will feature GnuPG proper, GPA as graphical frontend,
686   and GpgEX as a Windows Explorer extension.  GnuPG needs to be unpacked
687   and from the top source directory you run this command
688
689   ╭────
690   │ make -f build-aux/speedo.mk w32-installer
691   ╰────
692
693   This command downloads all direct dependencies, checks the signatures
694   using the GnuPG version from the build system (all Linux distros
695   feature a suitable GnuPG tool), builds everything from source, and
696   uses NSIS to create the installer.  Although this sounds easy, some
697   experience in setting up a development machine is still required.
698   Some versions of the toolchain exhibit bugs and thus your mileage may
699   vary.  Support for keyserver access over TLS is currently not
700   available but will be added with one of the next point releases.
701
702
703
704   # Copyright 2014 The GnuPG Project.
705   # This work is licensed under the Creative Commons
706   # Attribution-ShareAlike 4.0 International License.  To view a copy of
707   # this license, visit http://creativecommons.org/licenses/by-sa/4.0/
708   # or send a letter to Creative Commons, PO Box 1866, Mountain View, CA
709   # 94042, USA.
710   #
711   # The canonical source for this article can be found in the gnupg-doc
712   # git repository as web/faq/whats-new-in-2.1.org.