Implications of a common private keys directory in 2.1

[Carola Grunwald]

Hello Werner!

On Mon, 21 Nov 2016 10:28:47 +0100, you wrote:

>On Sun, 20 Nov 2016 21:37, caro at nymph.paranoici.org said:
>
>>>Is there any chance to get that disentangled, maybe by defining a
>>>separate secret key directory for each public .kbx keyring in use?
>
>No.
>
>> The silence makes me believe that what I described is intended behavior,
>> not a 2.1 design flaw. I'd like to know whether that's correct. Any
>
>Correct.  The gpg-agent takes care of private keys and does not know
>about gpg or gpgsm.  Deleting a private key is not easy because it may
>be used by several protocols.  This is the reason you see an extra
>confirmation message when trying to delete a private key.
>
>BTW, the use of the --keyring option is in general not a good idea.  We
>would very much like to entirely get rid of them due to the problems
>assocciated with that kludge (or well, that upward compatibility with
>PGP).

IMHO for several reasons there has to be some method to structure larger
key depositories.

Just to name a few ...

- Performance drops with the number of available keys, especially when
data lacking a key-ID (--throw-keyids) have to be decrypted.

- In a multi-user environment the key owning recipient has to be granted
access to the private key with some sender being restricted to only use
the public key no matter whether there's any chance s/he guesses the
correct passphrase.

- There's no reason to have keys used for different tasks together on a
single keyring, as key management gets chaotic with such a hodgepodge.
And confusion would increase even more trying to mimic v1.4 by running
multiple GPG Agents dedicated to tasks which have to be separated.

Even if there's no chance to return to completely separated keyrings,
which without doubt have stood the test of time in GnuPG 1.4, I think
there at least has to be a method to group public as well as private
keys in some way to allow the selection of only one or a few of these
subsets to take part in processing. Currently for example apart from the
accidental deletion of private keys I earlier described I don't see any
concept of dealing with orphaned files in the private-keys and
openpgp-revocs directory. An Agent managing all lists of key subsets
would gain the information needed to solve all these problems, for
example delete the private key file when all list entries associated
with that privat key are removed.

Though not very familiar with GnuPG internals I hope I made my concerns
somewhat clearer.

Good night, and good luck

Caro