[Gnuk-users] An example for more hardware slots

Srinivas vsrinu26f at gmail.com
Sun Sep 24 12:15:18 UTC 2017 

https://developers.yubico.com/PIV/Introduction/Certificate_slots.html



On September 24, 2017 7:02:32 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 (Srinivas)
>   2. Re: Multiple retired encryption keys (Gary)
>   3. Re: Multiple retired encryption keys (NdK)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sat, 23 Sep 2017 07:29:59 -0500
>From: Srinivas <vsrinu26f at gmail.com>
>To: gnuk-users at lists.alioth.debian.org,
>	gnuk-users-request at lists.alioth.debian.org
>Subject: [Gnuk-users] Multiple retired encryption keys
>Message-ID: <18F20679-70FA-4B01-B249-BFA8D43D7150 at gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>
>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-0001.html>
>
>------------------------------
>
>Message: 2
>Date: Sat, 23 Sep 2017 15:07:07 +0100
>From: Gary <gary at mups.co.uk>
>To: gnuk-users at lists.alioth.debian.org
>Subject: Re: [Gnuk-users] Multiple retired encryption keys
>Message-ID: <a0ca11c1-4aab-e832-f0bd-2452879947fa at mups.co.uk>
>Content-Type: text/plain; charset=utf-8
>
>On 23/09/17 03:51, Duncan wrote:
>> 
>> 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.
>> 
>
>Hi Duncan,
>
>I may caused a little confusion with my original email, I don't need to
>get my private keys off of the gnuk and I'd be worried if that was
>possible (without physically destroying the gnuk anyway).
>
>I have offline copies of my private sub-keys along with my master key
>just in case of gnuk hardware failure and the need to configure a new
>token.
>
>My "problem" is that once my keys expire, I can modify the expiry date
>and keep using them for another 5-10 years, however should they ever
>get
>compromised, that compromises all your data you've ever encrypted with
>that key. So I'd like to rotate my encryption key every few years.
>
>Prior to using a token like the gnuk, this was simple, you just made a
>new encryption sub-key and gnupg would always use that one for new
>encryption but would still have all the old expired encryption keys
>still on the keyring in case you need to access old encrypted data (but
>obviously that suffers from the risks that tokens are there to solve)
>
>With the gnuk and I expect many smart-card/tokens at the moment
>supporting a limited number of keys, there's not really an equivalent
>method to support rotating encryption keys.
>
>The workarounds are not too appealing either:-
>
>1) you could move (from off-line storage) private keys for old
>encryption sub-keys back to gnupg keyring. Losing the advantage tokens
>offer as your key becomes more easily accessible in the case of a
>machine compromise. Although, at least your active encryption key is
>still safe on a token. Can gnupg work with a some of your sub-keys on
>the gnuk and the rest in the regular .gnupg/ keyring though?
>2) keep the old encryption keys on an off-line machine, but that is
>quite inconvenient when you have the need to access archived
>data/emails etc
>3) Buy a new token every time you generate a new encryption subkey and
>retain old tokens. This isn't too bad, but for people who renew subkeys
>every year or so, it would eventually become frustrating to manage not
>to mention the cost of buying a token each year. How frustrating would
>depend on how frequently old data would need to be decrypted though.
>4) Keep extending the expiry date (see below)
>
>> 
>> 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.
>
>Extending the expiry date is what I'll likely do. However, it feels
>like
>a compromise to work around limitations of smartcards/tokens that is
>less than ideal. Obviously whilst tokens have that limitation there's
>no
>other real choice but I could see some people opting not to use tokens
>due to this limitation, if they place a higher security priority on
>cycling keys and this might be something the OpenPGP standard could
>take
>into account for tokens that have the space to store extra keys.
>
>Reason I say that is, over the years the amount of data protected by
>the
>exact same encryption key grows and as PGP has no perfect forward
>secrecy, if the day comes that the key is ever compromised, that's a
>lot
>of data now at risk of decryption.
>
>It'd be great if there was a way to have an optional addition to the
>standard for smart-cards that have the space to store additional
>expired
>keys but I expect that would be quite a long and arduous process to
>achieve? I have no idea what the OpenPGP standards process is like, but
>having seen other standards in action, if it's anything similar I
>expect
>it'd be quite a task to get anything changed.
>
>What are peoples thoughts on the gnuk supporting something like that
>even if the standard does not? Would gnupg devs be willing to accept
>patches to support that if needed? Or would they turn them down due to
>lack of standard compliance?
>
>Regards,
>
>Gary
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Sat, 23 Sep 2017 22:28:47 +0200
>From: NdK <ndk.clanbo at gmail.com>
>To: gnuk-users at lists.alioth.debian.org
>Subject: Re: [Gnuk-users] Multiple retired encryption keys
>Message-ID: <b8e5b598-a6ae-549c-6ec4-5b8685bfdef1 at gmail.com>
>Content-Type: text/plain; charset=utf-8
>
>Il 23/09/2017 00:21, Gary ha scritto:
>
>> 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?
>That's something I started doing some years ago (2013, when studying
>smartcard programming), but then left incomplete.
>
>The smartcards I was using supported many RSA keys and some even NFC,
>so
>I thought to use slots for:
>- 1 key for signature
>- N keys for decryption (selectable by sending a special command)
>- 2 keys for auth (different for contact and contactless operation)
>That would have been completely transparent for GPG.
>
>Moreover I wanted to support secure key export.
>
>Probably a task too big for a newbie, even with the help of Petr
>Svenda.
>You can still find the code on github:
>https://github.com/CSSHL/MyPGPid/
>
>Probably the same technique could be used for the FST-01, to make good
>use of the external memory :)
>
>BYtE,
> Diego
>
>
>
>------------------------------
>
>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 2
>*****************************************

-- 
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/20170924/48b54136/attachment.html>

More information about the gnuk-users mailing list