Re: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22)

On Mon, 31 Jul 2017 10:35:24 +0200, Andre Heinecke wrote: > Hi, > > On Sunday, July 30, 2017 11:41:01 AM CEST Kosuke Kaizuka wrote: >> On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:> >>> I have installed the W32 package for GnuPG 2.1.22 and I find keys >>> cannot be sent to keyservers, or

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

On Mon, Jul 31, 2017 at 5:28 PM, Andrew Gallagher wrote: > There are two enormous holes in this argument: > > 1. If the people you communicate with regularly don't do "gpg > --refresh-keys" regularly they won't find out whether *anything* has > *ever* been revoked. A good

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

On Mon, 31 Jul 2017 18:38:09 +0200 Damien Goutte-Gattat wrote: > The problem with recommanding unnecessary steps is that they will > confuse the beginner and make him think that GnuPG is more difficult > to use than it already is. Which essentially describes my whole

3DES deprecated by NIST

For many years I've been saying that 3DES is a much stronger algorithm than its detractors think, subject to some massive concerns about its 64-bit block size and the near-certainty of a block repeating after about 32Gb of traffic (2**32 blocks, 8 bytes per block). This isn't to say I've been

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

On 07/31/2017 05:49 PM, Dirk-Willem van Gulik wrote: For what it is worth - the various best practices at `riseup.net’[1] seem to strike a good middle ground. For what it is worth, I disagree. The main problem I have with that document is that it implies the user should care about a lot of

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

On 31/07/17 17:49, Dirk-Willem van Gulik wrote: > For what it is worth - the various best practices at `riseup.net > ’[1] seem to strike a good middle ground. IMO, the good middle ground is the defaults. A wide middle. Maybe more a country than a ground ;-). And I wasn't very

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

> On 31 Jul 2017, at 17:41, Robert J. Hansen wrote: > >> Could probably be a direct application of this Debian article (1) on >> subkeys. And meant to to facilitate the recovery of the web of trust in >> case of disaster. >> >> On a separate tutorial (2), Alan Eliasen

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

On Mon, 31 Jul 2017 15:44:52 +0100 Mario Figueiredo wrote: > On a separate tutorial (2), Alan Eliasen strongly advises against this > practice. I'm replying to my own post, because the above seem a little like I'm trying to make an argument from authority. That was not my

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

> Could probably be a direct application of this Debian article (1) on > subkeys. And meant to to facilitate the recovery of the web of trust in > case of disaster. > > On a separate tutorial (2), Alan Eliasen strongly advises against this > practice. I hate to say something bad about a tutorial

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

On 2017/07/31 15:44, Mario Figueiredo wrote: > On a separate tutorial (2), Alan Eliasen strongly advises against > this practice. He does, but his argument is weak. The meat of it is: > Unless everyone that you communicate with regularly does something > like: > > gpg --refresh-keys > > to

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

On Sun, 30 Jul 2017 22:19:22 +0200 Dirk-Willem van Gulik wrote: > I see a growing number of keys that have well managed & expired > separate subkeys for Signing, Encryption and Authentication switch > from ‘SC’ on the master key to just ‘C’ (all RSA, ignoring DSA). > >

Re: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22)

Hi, On Sunday, July 30, 2017 11:41:01 AM CEST Kosuke Kaizuka wrote: > On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:> > > I have installed the W32 package for GnuPG 2.1.22 and I find keys > > cannot be sent to keyservers, or fetched/refreshed. The operation > > fails with the message "keyserver