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

[Dirk-Willem van Gulik]

> On 31 Jul 2017, at 17:41, Robert J. Hansen <rjh at sixdemonbag.org> 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 strongly advises against this
>> practice.
> 
> I hate to say something bad about a tutorial someone put so much obvious
> love into, but most of these tutorials are _just plain bad_.  And even
> the good ones, I don't recommend.
> 
> A newcomer to GnuPG needs to be told the defaults are safe for the vast
> majority of users, that GnuPG does not require any special tuning before
> use, and that the developers chose the defaults very carefully to be
> applicable to the vast majority of users.
> 
> Debian may have specific needs which GnuPG does not meet in its default
> configuration.  So if Debian wants to put together a tutorial teaching
> people how to configure GnuPG in a way that meets the Debian developer
> needs, I'm all in favor of that -- but I wince every time I see a
> newcomer to GnuPG think that process is somehow necessary for them to
> follow.  It's not.  Use the defaults until and unless you can articulate
> a specific and compelling reason to deviate from them.

For what it is worth - the various best practices at `riseup.net’[1] seem to strike a good middle ground.

This was also were my question came form; while historically (given DSA & patents of that time) it made sense to have S or SC on the master key — the contemporary use seems to be mainly ‘C’.

So one could surmise that the historic default of SC for a non DSA (e.g. RSA or ECC) is a bit out of date.

Hence the question as to what good practice is today.

Dw.

1: https://riseup.net/en/security/message-security/openpgp/best-practices <https://riseup.net/en/security/message-security/openpgp/best-practices> et.al.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170731/c37551b8/attachment-0001.html>