[Gnuk-users] Multiple retired encryption keys

Sat Sep 23 12:29:59 UTC 2017

It is important to re think all usecases and create rfc or so to update standards.

Please see PIV standards they hold about 32 slots or more if I remember correct.

The hard ware tokens should support more slots to hold expired subkeys and also if possible some signed public keys or whatever as a means for offline WOT.

I Know GnuPG will no settle for unsafe practices like not rotating subkeys because of old standards.

Its time to make GnuPG Great again. Make it more usable while not compromising on security.

You guys rock 🎸

On September 23, 2017 7:02:36 AM CDT, gnuk-users-request at lists.alioth.debian.org wrote:
>Send gnuk-users mailing list submissions to
>	gnuk-users at lists.alioth.debian.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://lists.alioth.debian.org/mailman/listinfo/gnuk-users
>or, via email, send a message with subject or body 'help' to
>	gnuk-users-request at lists.alioth.debian.org
>
>You can reach the person managing the list at
>	gnuk-users-owner at lists.alioth.debian.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of gnuk-users digest..."
>
>
>Today's Topics:
>
>   1. Multiple retired encryption keys (Gary)
>   2. Re: Multiple retired encryption keys (Duncan)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 22 Sep 2017 23:21:46 +0100
>From: Gary <gary at mups.co.uk>
>To: gnuk-users at lists.alioth.debian.org
>Subject: [Gnuk-users] Multiple retired encryption keys
>Message-ID: <93f105f8-fe38-fe3a-415b-7650475d5a74 at mups.co.uk>
>Content-Type: text/plain; charset=utf-8
>
>Hi all,
>
>I've been wondering what to do when my current sub-keys expire. Modify
>the expiry date to keep them active for another few years, or generate
>a
>new encryption sub-key.
>
>The latter option would be preferable but then it raises the question
>of
>what to do about the old encryption key(s) given that the gnuk only
>supports 3 slots for E,S,A and I'd want to retain access to old
>encrypted data.
>
>Is there any way to add extra keys beyond the 3 slots for E,S,A the
>gnuk
>provides?
>
>If not, what level of work would be involved to get gnupg+gnuk to
>support the addition of multiple expired/old encryption keys? Is this
>something that's likely to happen?
>
>
>Regards,
>
>Gary
>
>
>
>------------------------------
>
>Message: 2
>Date: Sat, 23 Sep 2017 02:51:00 +0000
>From: Duncan <dguthrie at posteo.net>
>To: gnuk-users at lists.alioth.debian.org
>Subject: Re: [Gnuk-users] Multiple retired encryption keys
>Message-ID: <3a32a650-76a3-9f1d-19d6-8bf11cac0751 at posteo.net>
>Content-Type: text/plain; charset=utf-8
>
>Hi Gary,
>
>Gary:
>> Hi all,
>> 
>> I've been wondering what to do when my current sub-keys expire.
>Modify
>> the expiry date to keep them active for another few years, or
>generate a
>> new encryption sub-key.
>> 
>> The latter option would be preferable but then it raises the question
>of
>> what to do about the old encryption key(s) given that the gnuk only
>> supports 3 slots for E,S,A and I'd want to retain access to old
>> encrypted data.
>> 
>> Is there any way to add extra keys beyond the 3 slots for E,S,A the
>gnuk
>> provides?
>> 
>> If not, what level of work would be involved to get gnupg+gnuk to
>> support the addition of multiple expired/old encryption keys? Is this
>> something that's likely to happen?
>> 
>> 
>> Regards,
>> 
>> Gary
>> 
>
>This appears to be less of a question of "what can Gnuk do", and more
>of
>backing up the private key material before exporting it to the
>smartcard/token.
>
>For future reference, if you have an offline computer where your master
>key material is stored, where you generate subkeys and then export them
>to smartcards/tokens, you can choose not to save that they have been
>exported from the master key after running the keytocard option. This
>means you can still have access to private key material of the subkeys
>after exporting the key to the card/token.
>
>Unfortunately, the OpenPGP card standard does not allow more keys to be
>added. I do not think it makes much sense to extend the standard, due
>to
>the design of smartcards. In any case, when we update Gnuk, you would
>lose access to the private key on the token anyway. However, Gnuk token
>is not completely standards-compliant, so maybe it would be possible,
>at
>a push.
>
>I think your best option, since it is not possible (without invasive
>methods, and even then quite difficult) to extract private key material
>from the Gnuk token, is to keep the old tokens if you wish to keep
>access to these, and use new tokens for your new keys (while following
>the practice above).
>
>If your subkeys have not been compromised (I think in most cases this
>would mean that the token did not get stolen - something that's
>implicit
>from what you've said), and there is no reason to regenerate keys for
>security reasons, then I don't see what's wrong with extending the
>expiry date of your old keys and then creating keys marked 'new', e.g.
>write "new long-term signing key" in the comment for the new signing
>subkey, and "old long-term signing key" in the comment for the old key.
>
>Best,
>Duncan
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>gnuk-users mailing list
>gnuk-users at lists.alioth.debian.org
>https://lists.alioth.debian.org/mailman/listinfo/gnuk-users
>
>
>------------------------------
>
>End of gnuk-users Digest, Vol 95, Issue 1
>*****************************************

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20170923/8d8861ba/attachment.html>