Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Daniel Kahn Gillmor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Gerd--

On Tue 2017-02-21 09:34:17 -0500, Gerd v. Egidy wrote:
> I'd like to announce a program I wrote to backup GnuPG and SSH keys as 
> qrcodes on paper:
>
> paperbackup.py 
> https://github.com/intra2net/paperbackup
>
> This is designed as fallback if all your regular backups failed to restore or 
> were lost.
>
> Usage is like this:
>
> gpg2 --armor --export "User Name" >key.asc
> gpg2 --armor --export-secret-key "User Name" >>key.asc
> paperbackup.py key.asc
> paperrestore.sh key.asc.pdf | diff key.asc -
> lpr key.asc.pdf

this is a cool idea.  however, it seems like you might be backing up
more than most people would need.  For most folks, their OpenPGP
certificates (public keys) are stored on the public keyservers.  Or at
least their friends have a copy of them :)

Even if you want the whole certificate, you've duplicated most of the
material here -- just the data produced by --export-secret-key should be
sufficient to reconstruct everything.  Probably, putting less data in
your qrcode backup will make the backup more robust during recovery..

So for most folks, the critical backup that they need is likely to be
only the secret key material itself, since the public key material and
signatures and the like can all be retrieved from from the keyserver
network or from friends.

Are you aware of David Shaw's paperkey?

  http://www.jabberwocky.com/software/paperkey/

This produces significantly less data (still in text form, though), so
it could be combined with your approach to have a nice big, robust,
scannable recovery mechanism.

thanks for publishing your work!

  --dkg
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlitEsgACgkQFJitxsGS
MjfnZQ//ediyODKSSDEj3wEEobXd+27VTv3oOS6EpBUDxyse3ttMAb1q9EBgzJC/
DJAYC1vOqyYzQ7+7uLVAKShE2rMWDhTnxAbIYsbqRpxeS0vGsn5L3yWpiT+u5LkN
sBXONHO5MxDH1kQDZ9+muFZWYUBTSKbJLLHN0R5uk1PqvVRXBMT3HDFusqeS0EBI
W+lBKGGABBGk1P8/Sc1tOX9WbkA5aQxNhGq5Rq0E4FUrR7J6IlAKGDqjVmCHs1++
BzMVKqkfZm2++PQXpGyzCadkTL9oTK4+zMz3E6cvQtwlNWZBZLW1vPZPNwRWBekK
VNbZEyIOuSSZTR/jmDyh7dNDAzsjjKF+1Gspu9uDFWVHUbz72hdUzmyRB0RG8DfN
XfE8zscyJlmJfTccgRYzfuTNXU9QtnlwyThvYyrvZOQ/WMSxfYe+ST3neJOGGB7j
UFnhj4DgfSNVbXT6mEOLWEos3S21YSN8hMiLkOqvyF7+Tnuq98hyEESAX0BRLAjw
Jo1eLkkgdAaB5Ww08VoxrmArSS7dCpvyn1OpeuOvC0BZuKBKJI+93ZuWSAKDRdNr
ouI355qDnOun7ut9cAl1fC0r6ws9qjeGNXTgQUHGAu43bs0A2rkhzaPg0DdHYvrQ
ME3mdC45HOT+EYCysJj9DNueD9ZO/W235MPWTHOcD17uBi5iHr4=
=DPyt
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG2.1 is using the wrong signing subkey

[Daniel Kahn Gillmor]

On Tue 2017-02-21 16:27:55 -0500, Will Dixon (Clemsonopoly94) wrote:
> So I am having an issue signing documents with gpg2.1. Every time I try and 
> sign something, I get:
>
> λ dixonwille [~] → gpg2 --detach-sign Images/EinsteinWP.jpg 
> gpg: using "0xEC933DA229123788" as default secret key for signing
> gpg: signing failed: No secret key
> gpg: signing failed: No secret key
> As the above message specifies I do have a default key set in my config. Here 
> is what my private listing shows:
>
> λ dixonwille [~] → gpg2 -K --with-keygrip
> /home/dixonwille/.gnupg/pubring.kbx
> ---
> sec#  rsa4096/0x496AC5165C585343 2017-01-14 [SC]
>   Key fingerprint = 2092 7961 2A0C EF20 83D0  8244 496A C516 5C58 5343
>   Keygrip = 308FF7DD37FB9E175378D76125FCB2BC4C5C225C
> uid   [ultimate] William E. Dixon 
> uid   [ultimate] William E. Dixon 
> uid   [ultimate] William E. Dixon 
> 
> uid   [ultimate] [jpeg image of size 5910]
> ssb   rsa4096/0xD3522B485A800AFD 2017-01-14 [E] [expires: 2018-01-14]
>   Keygrip = 178AB20F816E5FAA31440968AD6EA06B0340FB90
> ssb   rsa4096/0xEC933DA229123788 2017-01-14 [S] [expires: 2018-01-14]
>   Keygrip = 89A90662E5908D5F271B87A5DC6D26F01B53C9EC
> ssb   rsa4096/0xBAA693EC561AD6D9 2017-01-14 [A] [expires: 2018-01-14]
>   Keygrip = 9D48688AF67C407BB91900BA07725CCE7E08B546
> ssb   rsa4096/0x7A3D17611B1FFDD2 2017-01-14 [S] [expires: 2018-01-14]
>   Keygrip = 50EE902E41E323600B02769FA2A96FE8C51D5A35
> ssb   rsa4096/0xB64824658CE421C8 2017-01-14 [A] [expires: 2018-01-14]
>   Keygrip = D3BD87D77B844A5AE54CEC0466353030A816441B
> ssb   rsa4096/0x7642000294227858 2017-01-16 [S] [expires: 2018-01-14]
>   Keygrip = B10269A98E3D357F3B32C155367B1CEDCAE998E8
> ssb   rsa4096/0x32C4DD59E753B43B 2017-01-16 [A] [expires: 2018-01-14]
>   Keygrip = 40E86DAAEDEE6BA714F26B09FBA38C35C4E4F264
> Now all these keys do not have a private conterpart. Only three of them do 
> (0xD3522B485A800AFD, 0xEC933DA229123788, 0xBAA693EC561AD6D9). To make sure I 
> ran gpg-connect-agent then ran keyinfo --list.

When signing, gpg prefers the most recent subkey that is
signing-capable.  Please see:

   https://bugs.gnupg.org/gnupg/issue1967

for ongoing discussion and a possible patch that's waiting for review by
more knowledgable developers.

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Problems with cert validation via CRL

[NIIBE Yutaka]

Hello, again,

David Gray  wrote:
> dave@dave-VirtualBox:~/.gnupg/crls.d$ dirmngr --debug-all --fetch-crl 
> http://crl.comodoca.com/COMODOSHA256ClientAuthenticationandSecureEmailCA.crl

Reading the code of dirmngr, I think that --fetch-crl (or dirmngr-client
--load-crl) doesn't work well for a CRL which is not signed by system CA
directly.  When dirmngr doesn't know the issuer, it inquires back to the
client, and it fails as:

> dirmngr[3184.0]: DBG: find_cert_bysubject: certificate not returned by caller 
> - doing lookup
> dirmngr[3184.0]: error fetching certificate by subject: Configuration error
> dirmngr[3184.0]: CRL issuer certificate 
> {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found
> dirmngr[3184.0]: crl_parse_insert failed: Missing certificate

When it is gpgsm which asks dirmngr to validate a certificate, I think
it works.

I think that you once successfully did that on this box:

> dave@dave-VirtualBox:~/.gnupg/crls.d$ gpgsm --debug-all --list-keys 
> --with-validation

And the CRL is cached.  Thus,

> gpgsm: DBG: chan_6 -> ISVALID 
> 685A02B9E2BD4B5EE1FA51739B8882AEA38FB3C8.3FAADAD7DD3F946B114321153B76F88C

This is gpgsm asking if your X.509 client certificate is valid or not.

> gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868

Here, I think that the CRL for your X.509 client certificate is cached
and checked.  dirmngr does not ask about anything about your X.509
client certificate or its issuer.

dirmngr inquires back to gpgsm if the root issuer is trusted.

CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust 
AB,C=SE
fingerprint=02FAF3E291435468607857694DF5E45B68851868

then, gpgsm asks to gpg-agent.

> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_7 <- OK

It is trusted.  Then, gpgsm replies back to dirmngr.

> gpgsm: DBG: chan_6 -> D 1
> gpgsm: DBG: chan_6 -> END

It's trusted.

> gpgsm: DBG: chan_6 <- OK

Then, dirmngr answers OK for the validation of your X.509 client certificate.

> gpgsm: DBG: chan_6 -> ISVALID 
> 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21

This is gpgsm asking if the intermediate certificate of following is
valid or not:

CN=COMODO SHA-256 Client Authentication and Secure Email CA,O=COMODO CA 
Limited,
L=Salford, ST=Greater Manchester, C=GB
fingerprint=59B825FC08860B04B392CC25FEC48C760753B689

> gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_7 <- OK
> gpgsm: DBG: chan_6 -> D 1
> gpgsm: DBG: chan_6 -> END
> gpgsm: DBG: chan_6 <- OK

Similar interactions between gpg-agent<->gpgsm<->dirmngr.

> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_7 <- OK

I don't know the exact reason, but gpgsm again asks gpg-agent.

And gpgsm shows your X.509 client certificate:

>ID: 0x2F5900E9
>   S/N: 3FAADAD7DD3F946B114321153B76F88C
>Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email 
> CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB
>   Subject: /EMail=u...@domain.com
>   aka: u...@domain.com
>  validity: 2017-01-02 00:00:00 through 2018-01-02 23:59:59
>  key type: 2048 bit RSA
> key usage: digitalSignature keyEncipherment
> ext key usage: emailProtection (suggested), 1.3.6.1.4.1.6449.1.3.5.2 
> (suggested)
>  policies: 1.3.6.1.4.1.6449.1.2.1.1.1:N:
>   fingerprint: 4A:53:A9:E6:51:32:23:DF:B4:7D:B8:A3:19:F1:3E:A3:2F:59:00:E9
>   [Note: non-critical certificate policy not allowed]
>   [Note: non-critical certificate policy not allowed]
>   [validation model used: shell]
>   [certificate is good]

On the other hand, on your Windows...

> C:\Users\dave\Downloads>gpgsm --list-keys --with-validation --debug-all
[...]
> gpgsm: DBG: chan_0x01c0 -> ISVALID 
> 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21
> gpgsm: DBG: chan_0x01c0 <- INQUIRE ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
[...]
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
> gpgsm: DBG: chan_0x01c0 -> D 1
> gpgsm: DBG: chan_0x01c0 -> END
> gpgsm: DBG: chan_0x01c0 <- OK
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
[...]
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
[...]
> gpgsm: DBG: chan_0x01c0 -> ISVALID 
> 

GnuPG2.1 is using the wrong signing subkey

[Will Dixon (Clemsonopoly94)]

So I am having an issue signing documents with gpg2.1. Every time I try and 
sign something, I get:

λ dixonwille [~] → gpg2 --detach-sign Images/EinsteinWP.jpg 
gpg: using "0xEC933DA229123788" as default secret key for signing
gpg: signing failed: No secret key
gpg: signing failed: No secret key
As the above message specifies I do have a default key set in my config. Here 
is what my private listing shows:

λ dixonwille [~] → gpg2 -K --with-keygrip
/home/dixonwille/.gnupg/pubring.kbx
---
sec#  rsa4096/0x496AC5165C585343 2017-01-14 [SC]
  Key fingerprint = 2092 7961 2A0C EF20 83D0  8244 496A C516 5C58 5343
  Keygrip = 308FF7DD37FB9E175378D76125FCB2BC4C5C225C
uid   [ultimate] William E. Dixon 
uid   [ultimate] William E. Dixon 
uid   [ultimate] William E. Dixon 

uid   [ultimate] [jpeg image of size 5910]
ssb   rsa4096/0xD3522B485A800AFD 2017-01-14 [E] [expires: 2018-01-14]
  Keygrip = 178AB20F816E5FAA31440968AD6EA06B0340FB90
ssb   rsa4096/0xEC933DA229123788 2017-01-14 [S] [expires: 2018-01-14]
  Keygrip = 89A90662E5908D5F271B87A5DC6D26F01B53C9EC
ssb   rsa4096/0xBAA693EC561AD6D9 2017-01-14 [A] [expires: 2018-01-14]
  Keygrip = 9D48688AF67C407BB91900BA07725CCE7E08B546
ssb   rsa4096/0x7A3D17611B1FFDD2 2017-01-14 [S] [expires: 2018-01-14]
  Keygrip = 50EE902E41E323600B02769FA2A96FE8C51D5A35
ssb   rsa4096/0xB64824658CE421C8 2017-01-14 [A] [expires: 2018-01-14]
  Keygrip = D3BD87D77B844A5AE54CEC0466353030A816441B
ssb   rsa4096/0x7642000294227858 2017-01-16 [S] [expires: 2018-01-14]
  Keygrip = B10269A98E3D357F3B32C155367B1CEDCAE998E8
ssb   rsa4096/0x32C4DD59E753B43B 2017-01-16 [A] [expires: 2018-01-14]
  Keygrip = 40E86DAAEDEE6BA714F26B09FBA38C35C4E4F264
Now all these keys do not have a private conterpart. Only three of them do 
(0xD3522B485A800AFD, 0xEC933DA229123788, 0xBAA693EC561AD6D9). To make sure I 
ran gpg-connect-agent then ran keyinfo --list.

λ dixonwille [~] → gpg-connect-agent 
> keyinfo --list
S KEYINFO 178AB20F816E5FAA31440968AD6EA06B0340FB90 D - - - P - - -
S KEYINFO 89A90662E5908D5F271B87A5DC6D26F01B53C9EC D - - - P - - -
S KEYINFO 9D48688AF67C407BB91900BA07725CCE7E08B546 D - - - P - - -
OK
> 
So as you can see my secrets are stored in the gpg-agent. Running echo foo | 
gpg --clearsign -v --debug ipc for debug information showed these intresting 
lines:

gpg: DBG: chan_5 -> HAVEKEY 308FF7DD37FB9E175378D76125FCB2BC4C5C225C
gpg: DBG: chan_5 <- ERR 67108881 No secret key 
gpg: DBG: chan_5 -> HAVEKEY 89A90662E5908D5F271B87A5DC6D26F01B53C9EC
gpg: DBG: chan_5 <- OK
gpg: using "0xEC933DA229123788" as default secret key for signing
gpg: DBG: chan_5 -> HAVEKEY 308FF7DD37FB9E175378D76125FCB2BC4C5C225C 
178AB20F816E5FAA31440968AD6EA06B0340FB90 
89A90662E5908D5F271B87A5DC6D26F01B53C9EC 
9D48688AF67C407BB91900BA07725CCE7E08B546 
50EE902E41E323600B02769FA2A96FE8C51D5A35 
D3BD87D77B844A5AE54CEC0466353030A816441B 
B10269A98E3D357F3B32C155367B1CEDCAE998E8 
40E86DAAEDEE6BA714F26B09FBA38C35C4E4F264
gpg: DBG: chan_5 <- OK
gpg: using subkey 0x7642000294227858 instead of primary key 0x496AC5165C585343
gpg: writing to stdout
gpg: DBG: chan_5 -> KEYINFO B10269A98E3D357F3B32C155367B1CEDCAE998E8
gpg: DBG: chan_5 <- ERR 67108891 Not found 
Which confuses me. It first checks my Primary Master key for secret, it can't 
find it so fails. Then it checks the keygrip for my default key and then states 
using "0xEC933DA229123788" as default secret key for signing. That sounds good 
please do. But then it sends another HAVEKEY for what looks like all my 
keygrips. This returns true as one of them does have a secret. So it then 
states using subkey 0x7642000294227858 instead of primary key 
0x496AC5165C585343which is the latest signing key I did make.

My real question is how can I force GnuPG2.1 to use the key I specified in the 
default-key. Seems like it gets over written with whatever GnuPG2.1 feels like.

To debunk the pinentry answer I know someone might mention if I don't mention 
it now. If I run ssh g...@github.com I get popped up a dialog to input my key 
password (I use the Authentication key for my ssh keys and store in gpg-agent 
as well). So I know my gpg-agent.conf is set correctly and gpg.conf is set 
correctly.

I have a stack overflow question open for about 8 days with no response. Much 
help is appreciated. 
http://stackoverflow.com/questions/42195987/gnupg2-1-is-using-the-wrong-signing-subkey
 

Thanks in advance.___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

No such file or directory error with gpgme

[Joyce Babu]

I am trying to setup a signed apt repository. When I run reprepro, it is
failing with error

$ reprepro includedeb xenial /tmp/mod-pagespeed-stable_current_amd64.deb
Exporting indices...
gpgme gave error Pinentry:32849:  No such file or directory
ERROR: Could not finish exporting 'xenial'!

I tried enabling debug log by setting GPGME_DEBUG=9:/data/mygpgme.log

But I can't decipher which file is missing from the debug log


GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_run_io_cb: call:
item=0xe61e30, handler (0xe593d0, 8)
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: enter: fd=0x8,
buffer=0xe57420, count=1024
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
5b474e5550473a5d 2050524f47524553 [GNUPG:] PROGRES
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
53202d263132203f 203020300a5b474e S -&12 ? 0 0.[GN
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
5550473a5d204245 47494e5f5349474e UPG:] BEGIN_SIGN
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
494e472048380a5b 474e5550473a5d20 ING H8.[GNUPG:]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
50524f4752455353 202d263132203f20 PROGRESS -&12 ?
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check: 3135313620300a
   1516 0.
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: leave: result=87
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: enter:
fds=0xe61e60, nfds=10, nonblock=0
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: check:
fds=0xe61e60, select on [ r0x8 r0xe ]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: check:
fds=0xe61e60, select OK [ r0x8 ]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: leave: result=1
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_run_io_cb: call:
item=0xe61e30, need to check
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: enter:
fds=0x7ffe918a8f10, nfds=1, nonblock=1
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: check:
fds=0x7ffe918a8f10, select on [ r0x8 ]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: check:
fds=0x7ffe918a8f10, select OK [ r0x8 ]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: leave: result=1
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_run_io_cb: call:
item=0xe61e30, handler (0xe593d0, 8)
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: enter: fd=0x8,
buffer=0xe57420, count=1024
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
5b474e5550473a5d 2050494e454e5452 [GNUPG:] PINENTR
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
595f4c41554e4348 454420393436310a Y_LAUNCHED 9461.
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
5b474e5550473a5d 204641494c555245 [GNUPG:] FAILURE
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: check:
207369676e203833 3931383932390asign 83918929.
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: leave: result=63
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: enter:
fds=0xe61e60, nfds=10, nonblock=0
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: check:
fds=0xe61e60, select on [ r0x8 r0xe ]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: check:
fds=0xe61e60, select OK [ r0x8 r0xe ]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: leave: result=2
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_run_io_cb: call:
item=0xe61e30, need to check
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: enter:
fds=0x7ffe918a8f10, nfds=1, nonblock=1
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: check:
fds=0x7ffe918a8f10, select on [ r0x8 ]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: check:
fds=0x7ffe918a8f10, select OK [ r0x8 ]
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_select: leave: result=1
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_run_io_cb: call:
item=0xe61e30, handler (0xe593d0, 8)
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: enter: fd=0x8,
buffer=0xe57420, count=1024
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_io_read: leave: result=0
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_cancel_with_err: enter:
ctx=0xe3f890, ctx_err=83918929, op_err=0
GPGME 2017-02-18 12:36:07 <0x24e7>  _gpgme_io_close: enter: fd=0xb
GPGME 2017-02-18 12:36:07 <0x24e7>  _gpgme_io_close: check: fd=0xb,
invoking close handler 0x7f4418b35800/0xe593d0
GPGME 2017-02-18 12:36:07 <0x24e7>  _gpgme_io_close: leave: result=0
GPGME 2017-02-18 12:36:07 <0x24e7>  _gpgme_io_close: enter: fd=0x8
GPGME 2017-02-18 12:36:07 <0x24e7>  _gpgme_io_close: check: fd=0x8,
invoking close handler 0x7f4418b35800/0xe593d0
GPGME 2017-02-18 12:36:07 <0x24e7>_gpgme_remove_io_cb: call:
data=0xe61e10, setting fd 0x8 (item=0xe61e30) done
GPGME 2017-02-18 12:36:07 <0x24e7>  _gpgme_io_close: leave: result=0
GPGME 2017-02-18 12:36:07 <0x24e7>  _gpgme_io_close: enter: fd=0xe
GPGME 2017-02-18 12:36:07 <0x24e7>  _gpgme_io_close: check: fd=0xe,
invoking close handler 0x7f4418b35800/0xe593d0
GPGME 2017-02-18 12:36:07 

Re: Problems with cert validation via CRL

[David Gray]

Thanks, Peter!

According to the documentation the trusted certainty need to be in a folder 
named "trusted-certs" in the home directory.  I don't believe I've copied them 
there manually, so if it hasn't happened automatically that could very well be 
the issue.  I'm at work but once I get home I'll check it out and report back.

Really appreciate the help,

Dave

Sent from my iPhone

> On Feb 21, 2017, at 10:13 AM, Peter Lebbing  wrote:
> 
>> On 21/02/17 13:20, David Gray wrote:
>> I'm no expert, but when I look at the debug info (attached to
>> original email), it appears that gpgsm is able to get the crl that my
>> cert points to but it may be having trouble parsing it.
> 
> Reading that part made me think it couldn't find the issuer of the CRL:
> 
>> dirmngr[3184.0]: error fetching certificate by subject: Configuration error
>> dirmngr[3184.0]: CRL issuer certificate 
>> {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found
> 
> When I fetch the CRL we're talking about, OpenSSL tells me about it:
> 
>> Certificate Revocation List (CRL):
>>Version 2 (0x1)
>>Signature Algorithm: sha256WithRSAEncryption
>>Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA 
>> Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA
>>Last Update: Feb 20 16:07:34 2017 GMT
>>Next Update: Feb 24 16:07:34 2017 GMT
>>CRL extensions:
>>X509v3 Authority Key Identifier: 
>>
>> keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
>> 
>>X509v3 CRL Number: 
>>822
> 
> The issuer is the certificate that gpgsm knows about:
> 
>> Certificate:
>>Data:
>>Version: 3 (0x2)
>>Serial Number:
>>e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21
>>Signature Algorithm: sha256WithRSAEncryption
>>Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, 
>> CN=AddTrust External CA Root
>>Validity
>>Not Before: Dec 22 00:00:00 2014 GMT
>>Not After : May 30 10:48:38 2020 GMT
>>Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, 
>> CN=COMODO SHA-256 Client Authentication and Secure Email CA
>> [...]
>>X509v3 extensions:
>>X509v3 Authority Key Identifier: 
>>
>> keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
>> 
>>X509v3 Subject Key Identifier: 
>>92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
>> [...]
>> SHA1 Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:89
> 
> I suspect that even though gpgsm knows about it, dirmngr might not,
> hence the failing CRL verification. I think you need to feed the
> certificate to dirmngr as well.
> 
> Whether this is actually the reason you're having problems, I don't know.
> 
> HTH,
> 
> Peter.
> 
> -- 
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at 
> 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

Hi,

I'd like to announce a program I wrote to backup GnuPG and SSH keys as 
qrcodes on paper:

paperbackup.py 
https://github.com/intra2net/paperbackup

This is designed as fallback if all your regular backups failed to restore or 
were lost.

Usage is like this:

gpg2 --armor --export "User Name" >key.asc
gpg2 --armor --export-secret-key "User Name" >>key.asc
paperbackup.py key.asc
paperrestore.sh key.asc.pdf | diff key.asc -
lpr key.asc.pdf

You'll find all the details, reasoning and examples in the README.

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Andrew Gallagher]

On 21/02/17 15:23, Peter Lebbing wrote:
> On 21/02/17 16:19, Andrew Gallagher wrote:
>> And this is the main reason I started running my own keyserver - by
>> refreshing your monkeysphere-host keyring, you are leaking to the
>> keyserver which user credentials have login access to your system. :-)
> 
> But if an attacker can cut off your SSH servers from the keyserver, and
> your SSH servers fail open, meaning that they conclude the old data is
> still valid when it can't get new data, an attacker can keep using a
> compromised and revoked subkey without the server noticing the
> revocation in time.

Using your own keyserver(s) also helps with this, because you're not
relying on external internet connectivity to get your revocations. Now,
if your keyserver loses gossip with the pool you still may not get
revocations, but only if your users push them to the pool and not to
your keyserver, which is a question of defaults.

> It all depends on your threat model.

Absolutely! :-)

A



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Problems with cert validation via CRL

[Peter Lebbing]

On 21/02/17 13:20, David Gray wrote:
> I'm no expert, but when I look at the debug info (attached to
> original email), it appears that gpgsm is able to get the crl that my
> cert points to but it may be having trouble parsing it.

Reading that part made me think it couldn't find the issuer of the CRL:

> dirmngr[3184.0]: error fetching certificate by subject: Configuration error
> dirmngr[3184.0]: CRL issuer certificate 
> {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found

When I fetch the CRL we're talking about, OpenSSL tells me about it:

> Certificate Revocation List (CRL):
> Version 2 (0x1)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA 
> Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA
> Last Update: Feb 20 16:07:34 2017 GMT
> Next Update: Feb 24 16:07:34 2017 GMT
> CRL extensions:
> X509v3 Authority Key Identifier: 
> 
> keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
> 
> X509v3 CRL Number: 
> 822

The issuer is the certificate that gpgsm knows about:

> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, 
> CN=AddTrust External CA Root
> Validity
> Not Before: Dec 22 00:00:00 2014 GMT
> Not After : May 30 10:48:38 2020 GMT
> Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, 
> CN=COMODO SHA-256 Client Authentication and Secure Email CA
> [...]
> X509v3 extensions:
> X509v3 Authority Key Identifier: 
> 
> keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
> 
> X509v3 Subject Key Identifier: 
> 92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
> [...]
> SHA1 Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:89

I suspect that even though gpgsm knows about it, dirmngr might not,
hence the failing CRL verification. I think you need to feed the
certificate to dirmngr as well.

Whether this is actually the reason you're having problems, I don't know.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Peter Lebbing]

On 21/02/17 16:19, Andrew Gallagher wrote:
> And this is the main reason I started running my own keyserver - by
> refreshing your monkeysphere-host keyring, you are leaking to the
> keyserver which user credentials have login access to your system. :-)

But if an attacker can cut off your SSH servers from the keyserver, and
your SSH servers fail open, meaning that they conclude the old data is
still valid when it can't get new data, an attacker can keep using a
compromised and revoked subkey without the server noticing the
revocation in time.

It all depends on your threat model.

My 2 cents,

Peter.

PS: Actually, on reflection, not /my/ 2 cents. I'm just repeating what
Kristian said earlier with some more words attached.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Peter Lebbing]

On 21/02/17 15:58, Kristian Fiskerstrand wrote:
> Keep in mind, the keyring in the scope of monkeysphere is normally one
> keyblock :) But yeah, the crontab frequency will depend a bit on system.

Not for multi-user systems with many accounts; it would only be the case
for personal servers. Is a personal server really "normally" the place
monkeysphere is deployed?

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Andrew Gallagher]

On 21/02/17 15:17, Peter Lebbing wrote:
> On 21/02/17 15:58, Kristian Fiskerstrand wrote:
>> Keep in mind, the keyring in the scope of monkeysphere is normally one
>> keyblock :) But yeah, the crontab frequency will depend a bit on system.
> 
> Not for multi-user systems with many accounts; it would only be the case
> for personal servers. Is a personal server really "normally" the place
> monkeysphere is deployed?

And this is the main reason I started running my own keyserver - by
refreshing your monkeysphere-host keyring, you are leaking to the
keyserver which user credentials have login access to your system. :-)

Andrew.




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Kristian Fiskerstrand]

On 02/21/2017 03:15 PM, Peter Lebbing wrote:
> If Kristian Fiskerstrand says it's okay for SSH servers to refresh their
> keyring every 20 or 30 minutes from the public keyserver netowrk, then I
> guess it really is :-). I had estimated it as inappropriate.

Keep in mind, the keyring in the scope of monkeysphere is normally one
keyblock :) But yeah, the crontab frequency will depend a bit on system.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Qui audet vincit
Who dares wins



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Problems with cert validation via CRL

[David Gray]

Thank you for your response!  I do have the trustlist.txt file on both 
computers - it was automatically populated with the root cert by pin entry when 
I imported my certificate on both machines, and it includes the "relax" keyword 
on both computers.  There are 3 cents total in my hierarchy - root, 
intermediate, and mine.  I've added the fingerprint of the intermediate and 
even my own cert to trustlist.txt to see if that would make a difference, but 
it didn't change anything.  

The --disable-crl-checks option allows me to use the cert for encryption, so 
I'm pretty sure the problem lies with the crl option...there are two files (in 
addition to DIR.TXT) that have been populated in crl.d, and if I do a 
dirmngr--flush they get cleared out and are added back fine the next time I try 
to validate.  The root cert does NOT include a CRL DP, so I've tried turning on 
the option not to require a crl on trusted carts, but that didn't make a 
difference.

I'm no expert, but when I look at the debug info (attached to original email), 
it appears that gpgsm is able to get the crl that my cert points to but it may 
be having trouble parsing it.  The file itself is large, but I don't think 
that's uncommon, so perhaps there is a problem with the file itself.  It's been 
updated since I started investigating, and the problem persists, so it wasn't a 
transient problem. 

Is there a way to have gpgsm (or dirmngr?) validate that it is able to parse 
and interpret the CRL (or the associated .db file in crl.d) to see if that is 
the issue?

I appreciate your help very much.  Thanks,

Dave

Sent from my Mobile Device

> On Feb 20, 2017, at 9:32 PM, NIIBE Yutaka  wrote:
> 
> Hello,
> 
> David Gray  wrote:
>> At the same time, I'm curious as to why the Ubuntu installation is
>> validating the certificate as 'good' while the Windows installation is not -
>> is this just because the Ubuntu installation was able to successfully
>> validate the certificate in the past (presumably when a previous and
>> non-problematic CRL was published)?  If the CA publishes an updated CRL that
>> doesn't have issues, will my Windows installation be able to validate the
>> certificate at that point?
> 
> Please note that my knowledge of gpgsm and X.509 is pretty much limited.
> 
> Do you have .gnupg/trustlist.txt on Ubuntu machine?  It can be created
> when you answer dialog of gpgsm by pinentry interaction.
> -- 


smime.p7s
Description: S/MIME cryptographic signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Andrew Gallagher]

On 21 Feb 2017, at 13:37, Kristian Fiskerstrand 
 wrote:

>> On 02/21/2017 02:21 PM, Peter Lebbing wrote:
>> Revoking the old A key and creating a new one needs to happen on the
>> system you have the primary key on, so you need to subsequently roll out
> 
> Who said anything about creating a new one in this part of the process?

I did. In my original scenario, since you have to load up your primary key in 
order to revoke the compromised subkey, there's little extra effort involved in 
creating a new subkey while you're at it. (Yes, you could have prepared offline 
subkey revocations, but as you say this is very poorly supported and I wouldn't 
recommend it to anyone)

I'm not convinced having different A subkeys for each client device is useful. 
If one of your A subkeys gets compromised, all your servers are vulnerable 
until such point as your revocation gets pushed, and after which point any new 
subkeys will also have been pushed. So rolling A subkeys is an atomic operation 
on the server no matter what way you go about it or whether you have subkeys 
created in advance. On the other hand, if you have separate A subkeys for each 
*server*, then why not make life easy for yourself and just use separate 
primaries? 

Distributing revocations is the Achilles heel of every PKI. I don't know of any 
that has definitively solved it. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Peter Lebbing]

On 21/02/17 14:37, Kristian Fiskerstrand wrote:
> Who said anything about creating a new one in this part of the process?

Since I assumed you were siting behind a trusted machine with your
primary key installed when you revoke, it made no sense to me to just
revoke the key and not create a new one, as you are sitting there in
"gpg --edit-key" with your primary unlocked anyway.

But the rest of the mail makes clear this was not your assumption.

> (this step is actually the most tricky, as
> revocation certificates can't be generated for subkeys - so you need to
> have pre-generated versions of pubkey with it revoked created carefully
> manually beforehand).

Yes, I had kinda assumed that this was not the level of trickery we were
willing to go to when suggesting people to use multiple A subkeys. It's
not even a feature of GnuPG, it's just being clever.

>> certificate would have to be revoked. I don't see much extra effort in
>> rolling it out to the few other systems you use as a client as well.
> 
> not following, you don't have access to the primary key at this point
> (say you're travelling and the primary is on smartcard in a vault)

I did assume that you need the primary to do the revocations, as GnuPG
does not support revocation certificates for subkeys. So I assumed you
could only mitigate the compromise when seated behind your most trusted
system, or something to that effect.

> Whether need for "right now" depends on severity, the compromise is in
> most cases a lost device

I suppose we were working with different definitions of "compromise".
Yours makes more sense. Mine was too narrow.

> so a 20-30 min
> timeframe is likely sufficient in most cases anyways e.g from a regular
> crontab run of monkeysphere, this also should fit with most key
> propagation across network as using a single keyserver can create a SPOF
> and DoS the update

If Kristian Fiskerstrand says it's okay for SSH servers to refresh their
keyring every 20 or 30 minutes from the public keyserver netowrk, then I
guess it really is :-). I had estimated it as inappropriate.

Okay, you have convinced me. To deal with the pyhsical loss of a device
or the medium holding the private key, it makes sense to create an
OpenPGP auth-capable subkey per device. However, the revocation trickery
limits its user-friendliness in a big way.

Thanks for expanding my understanding of this area.

It's still not for me though. I often need to be able to grant access on
a per-client basis. I try to limit access to accounts to client devices
where I actually need it, to somewhat limit the consequences of a single
client machine being compromised. It's not a panacea, more of a defense
in depth thing.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Kristian Fiskerstrand]

On 02/21/2017 02:21 PM, Peter Lebbing wrote:
> Revoking the old A key and creating a new one needs to happen on the
> system you have the primary key on, so you need to subsequently roll out

Who said anything about creating a new one in this part of the process?
each device has separate A subkeys already, you lost your device, you
revoke the A subkey for it (this step is actually the most tricky, as
revocation certificates can't be generated for subkeys - so you need to
have pre-generated versions of pubkey with it revoked created carefully
manually beforehand).

> the new A key to the compromised device. Obviously I assume the primary
> key was not available on the compromised device, because then the whole

obviously

> certificate would have to be revoked. I don't see much extra effort in
> rolling it out to the few other systems you use as a client as well.

not following, you don't have access to the primary key at this point
(say you're travelling and the primary is on smartcard in a vault)

> 
> Also, I think you need to have a way to notify servers that they need to
> get an updated certificate including the revoked old key *right* *now*.
> We're talking about a compromised A key! The attacker has full access to
> your login account for the time that the servers haven't checked for a

Whether need for "right now" depends on severity, the compromise is in
most cases a lost device, not an active attacker, so a 20-30 min
timeframe is likely sufficient in most cases anyways e.g from a regular
crontab run of monkeysphere, this also should fit with most key
propagation across network as using a single keyserver can create a SPOF
and DoS the update

> new key yet! Regular intervals just won't do. This looks to be the
> painful step in the process.

... it depends...

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Qui audet vincit
Who dares wins



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG, subkeys smartcard and computer

[Peter Lebbing]

On 20/02/17 22:51, Kristian Fiskerstrand wrote:
> Revocation of the specific subkey is automatically picked up by all
> systems due to automatic refresh of the public key on regular intervals,
> without losing access to the system from non-compromised devices.

Revoking the old A key and creating a new one needs to happen on the
system you have the primary key on, so you need to subsequently roll out
the new A key to the compromised device. Obviously I assume the primary
key was not available on the compromised device, because then the whole
certificate would have to be revoked. I don't see much extra effort in
rolling it out to the few other systems you use as a client as well.

Also, I think you need to have a way to notify servers that they need to
get an updated certificate including the revoked old key *right* *now*.
We're talking about a compromised A key! The attacker has full access to
your login account for the time that the servers haven't checked for a
new key yet! Regular intervals just won't do. This looks to be the
painful step in the process.

The exception might be a private keyserver that gets hammered by all the
SSH servers every 10 minutes to check whether any updated keys were
uploaded. I don't think it'd be kind to do that to a public keyserver.

I'm not saying an A key per device is bad. Or even that it is not as
good as one A key. I'm just saying that, given you need to transfer
private keys anyway I don't think there's a significant difference in
practice. You can't generate these new A subkeys on the client device
itself, because it will not have the primary key of the OpenPGP
certificate. This is where the difference with plain old OpenSSH private
keys pops up: those you just generate on the client device itself and
you never have to worry about exporting and importing private keys at
all. In addition, it means you can then say "I'd never login to this
server from this client, so it needs not be in the authorized_keys
file". This kind of discrimination that provides defence in depth is not
possible with A subkeys on an OpenPGP certificate that get automatically
picked up by the servers, since they will always accept all A subkeys on
the certificate. So you lose that etra possibility you had with plain
SSH keys per client device.

Cheers,

Peter.

PS: I realised that you can't even generate the A key on the previously
compromised system only after I'd written my previous mail. So the two
stepwise processes should have been:

With A per system:

1) Create new key
2) Roll out new key to compromised system
3) Roll out new key to all server systems
4) Revoke old key on all server systems

With just one A:

1) Create new key
2) Roll out new key to all client systems
3) Roll out new key to all server systems
4) Revoke old key on all server systems

However, since Kristian is placing it in the context of servers
automatically fetching keys, it could be:

With A per system:

1) Create new key, revoke old
2) Roll out new key to compromised system
3) Poke every server system that they need to refresh *now*

With just one A:

1) Create new key, revoke old
2) Roll out new key to all client systems
3) Poke every server system that they need to refresh *now*

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: powertop(8) Points at gpg-agent.

[Ralph Corderoy]

Hi,

I wrote:
> > Note that gpg-agent makes sure that the tick happens on the full
> > second
>
> Noted.  Though those `-tt' times from strace above have it creeping
> forward, off the second?

I wonder if aiming for dead on the second is a good idea.  If everything
did that then there might silence until the next second boundary, but
many cores would wake up to work for a short time.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users