Re: Long Term Key Management With Hardware Tokens

[Valtteri Vuorikoski]

Brandon Anderson via Gnupg-users  writes:

> Thanks for posting about the PivApplet project. I was looking for
> something like that for either the basic cards or java cards as I
> wanted to tinker around with them. Do you have a specific Java card
> model you are using?

You'll want something that implements at least JavaCard 3.0.4, since
that's the first version with useful EC operations. This came out in
2011 but because smartcards move at a glacial place there are still a
lot of 2.x cards on the market.

The NXP J3H145 appears to be a popular and widely available
dual-interface card. There is some discussion regarding cards on the
SmartPGP applet issue tracker:
https://github.com/ANSSI-FR/SmartPGP/issues/17 .

I haven't tried other Javacards besides the J3H145. They work well,
though a caveat is that they are quite slow compared to for example a
Yubikey 5: operations take approximately twice as long. The J2H145
should be pretty much identical but lacks the contactless interface and
is a bit cheaper. The newer J3R180 is supposedly quite a bit faster.

Unless you're buying large quantities and are prepared to deal with
weighty NDAs, make sure that the seller performs card
initialization/pre-personalization. GlobalPlatform tools won't be able
to access the card before this step. Most stores that sell single cards
will do this by default, but eBay/Aliexpress sellers might not.

 -Valtteri
 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

Whatever the merits of retired key slots for their intended use, there's
another use case for them which was probably not considered by NIST:
alternate certificates for X.509, SSH and similar authorization
applications to work around deficiencies in existing systems.

Examples:

   - Github allows associating one SSH public key with one account. If
 you need to operate multiple Github accounts, you need multiple SSH
 keys.

   - Support for EC certificates in the Samba KDC was broken at least as
 of version 4.10. If you need an EC certificate for SSH, you can't
 use the key associated with your AD/Kerberos X.509 certificate,
 since only RSA works for Kerberos.

   - Similarly, the OS on Mikrotik routers at least before version 7.x
 supports only RSA SSH keys.

Hence, having multiple key slots available for authorization keys is
quite convenient. It might be better to call these something else than
"retired" slots unless aiming for total terminological consistency with
PIV though.

I'm currently using pivy  with Yubikeys
and JavaCards with PivApplet PIV for this kind of multi-key
scenarios. It would be convenient if all external applications could go
through gpg-agent/scute in the future instead of having to deal with
pcsc-shared or similar workarounds.

  -Valtteri

Those are great points; I had not thought of those use-cases! I only 
used the term retirement slots because it was an existing term used in 
PIV smartcards, but we could just call them alternative slots, 
supplemental slots, auxiliary slots, peripheral slots, secondary slots, 
or anything really, so long they can hold old keys decryption keys; my 
use-case is met.


Thanks for posting about the PivApplet project. I was looking for 
something like that for either the basic cards or java cards as I wanted 
to tinker around with them. Do you have a specific Java card model you 
are using?


OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Valtteri Vuorikoski]

Werner Koch via Gnupg-users  writes:

> Frankly, I am not convinced about the retirement slots on the card.
> They are of course useful if you rotate you key.  But the question is
> why you want to do this given that the keys are anyway securely stored
> on a card.

Whatever the merits of retired key slots for their intended use, there's
another use case for them which was probably not considered by NIST:
alternate certificates for X.509, SSH and similar authorization
applications to work around deficiencies in existing systems.

Examples:

  - Github allows associating one SSH public key with one account. If
you need to operate multiple Github accounts, you need multiple SSH
keys.

  - Support for EC certificates in the Samba KDC was broken at least as
of version 4.10. If you need an EC certificate for SSH, you can't
use the key associated with your AD/Kerberos X.509 certificate,
since only RSA works for Kerberos.

  - Similarly, the OS on Mikrotik routers at least before version 7.x
supports only RSA SSH keys.

Hence, having multiple key slots available for authorization keys is
quite convenient. It might be better to call these something else than
"retired" slots unless aiming for total terminological consistency with
PIV though.

I'm currently using pivy  with Yubikeys
and JavaCards with PivApplet PIV for this kind of multi-key
scenarios. It would be convenient if all external applications could go
through gpg-agent/scute in the future instead of having to deal with
pcsc-shared or similar workarounds.

 -Valtteri
 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

Thanks for your offer.  However, it is mainly a spec and hardware thing
and the software part is minor.

If you are a vendor of an OpenPGp comliant card, you are likely already
in contact with Achin Pietig, who is responsible for the specs.

Yea, I am not a vendor of an OpenPGP card, just an interested user. Have 
the old GPGcard 2.1, but I want to wait until 25519 support and more 
slots are available before I buy new ones. That being said, please reach 
out if you need help.


OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Werner Koch via Gnupg-users]

On Thu, 24 Jun 2021 02:21, Brandon Anderson said:

> First, if you are working on a new revision of the OpenPGP card,
> please let me know if I can reasonably do anything to help. While I

Thanks for your offer.  However, it is mainly a spec and hardware thing
and the software part is minor.

If you are a vendor of an OpenPGp comliant card, you are likely already
in contact with Achin Pietig, who is responsible for the specs.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

I am not arguing that paper copies are less reliable; of course, they 
are; however, they are not as secure.
As I reread this email, I realized what I said here may have been 
unclear. I meant to say, of course, paper copies are more reliable than 
hardware tokens; they are just less secure.


OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

concerned, you could use three. The probability that one card out of
ten will have a failure in a decade is far higher than the chance that

You should also be concerned that malware bricks your (backup) card.
You can only avoid that by using an always air-gaped box which is pretty
inconvenient.

Paper copies are actually much more reliable.  I meanwhile scribble down
the key using a pencil and paper.  Modern keys are short enough to do
that.  (you should also note the creation date).
I am not arguing that paper copies are less reliable; of course, they 
are; however, they are not as secure. I prefer greater security and key 
protection at the risk of less key reliability. I would be ecstatic if 
malware on my system chose to brick my smartcard over getting access to 
decrypted communication that it could be snooping on. I personally would 
prefer to lose access to my own data than let an adversary gain access 
to it. That being said, if I could avoid losing access to my data by 
having a proper redundant setup, I would prefer it.

all two or three cards will have a failure. Allowing retirement key
slots means you can easily choose your level of redundancy while still
keeping your keys on secure hardware only.

Back to your original request.  A new revision of the OpenPGP card is in
the works and the plan is to add more key slots.  Surely there will be
some support for this in GnuPG.  If you want support for the extra PIV
slots, we first need to find a business case for this (its not just the
development effort but also the future maintanence work which I have to
consider).


First, if you are working on a new revision of the OpenPGP card, please 
let me know if I can reasonably do anything to help. While I don't have 
as much free time as I like, I am a software developer and would love to 
help get this feature added if possible. With that being said, what do 
you mean by a business case for this? Is there some format of a proposal 
that you are particularly expecting, or is anything that outlines 
options, benefits, risks, etc., sufficient?


Sincerely,

Brandon Anderson



OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Werner Koch via Gnupg-users]

On Tue, 22 Jun 2021 21:53, Brandon Anderson said:

> concerned, you could use three. The probability that one card out of
> ten will have a failure in a decade is far higher than the chance that

You should also be concerned that malware bricks your (backup) card.
You can only avoid that by using an always air-gaped box which is pretty
inconvenient.

Paper copies are actually much more reliable.  I meanwhile scribble down
the key using a pencil and paper.  Modern keys are short enough to do
that.  (you should also note the creation date).

> all two or three cards will have a failure. Allowing retirement key
> slots means you can easily choose your level of redundancy while still
> keeping your keys on secure hardware only.

Back to your original request.  A new revision of the OpenPGP card is in
the works and the plan is to add more key slots.  Surely there will be
some support for this in GnuPG.  If you want support for the extra PIV
slots, we first need to find a business case for this (its not just the
development effort but also the future maintanence work which I have to
consider).


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

Or is it money? Something else?
Money and usability are certain factors here. Most of these tokens are 
in the realm of $50 apiece; the GPG smart card, while closer to $20, is 
still another $30 in shipping, so it would be costly unless I purchased 
all ten upfront. Not to mention the user experience suffers; if I search 
my email archive for some old record, I have to look through ten 
different cards to find the correct one.

If this single OpenPGP smartcard which holds all of your keys of the last
decade breaks, what then? Then you have lost access to all encrypted documents
of the last decade. If you'd  use separate OpenPGP smartcards instead, then
you'd lose access to only one key rotation interval worth of old encrypted
documents.

Regards,
Ingo


Having retirement key slots makes it easier, not harder, to have 
redundancy to protect against this. In my particular case, I would use 
two smart cards at the initial state as safe backups. If one was very 
concerned, you could use three. The probability that one card out of ten 
will have a failure in a decade is far higher than the chance that all 
two or three cards will have a failure. Allowing retirement key slots 
means you can easily choose your level of redundancy while still keeping 
your keys on secure hardware only.


Sincerely,

Brandon Anderson





___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Ingo Klöcker]

On Dienstag, 22. Juni 2021 20:47:45 CEST Brandon Anderson via Gnupg-users 
wrote:
> I agree that for most people having a paper backup stolen is unlikely,
> but then again, most people are not using GPG, to begin with, let alone
> GPG with smartcards or security tokens. There are several security
> concerns which having retirement keyslots can address. They can also
> improve the user experience as you won't have to air-gap a machine to
> view old records with revoked keys. All in all, it's about providing the
> option of having only security token access, not requiring it. I would
> expect any smartcard stored in a safe and only used infrequently during
> key changes and the occasional old record decryptions to last well over
> a decade.

I really fail to see your point. I can accept that you do not want to have a 
not-hardware-token-secured copy of your encryption keys. But what is the 
problem with having one OpenPGP smartcard for each retired key? Why do you 
want to cram all retired keys on a single OpenPGP card?

Is your motivation the environment (less retired still functional hardware 
tokens -> less wasted resources)? I'd applaud that, but I also question it. 
Deleting all those old and probably mostly useless encrypted emails might be 
better for the environment than keeping them in an archive (with several 
backups), which needs to be refreshed/copied to new archive storage every few 
years.

Or is it money? Something else?

If this single OpenPGP smartcard which holds all of your keys of the last 
decade breaks, what then? Then you have lost access to all encrypted documents 
of the last decade. If you'd  use separate OpenPGP smartcards instead, then 
you'd lose access to only one key rotation interval worth of old encrypted 
documents.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

Many tutorials, examples, and articles that are talking about using 
Yubikeys and smartcards currently suggest making paper backups of the 
encryption key so you can add it to new devices if needed. But this, at 


least to me, feels like it's significantly reducing the value of 
using secure hardware like smartcards in the first place. Having the 
keys only ever exist on secure hardware, including the backups, would 
make this unnecessary.


The disadvantage of only ever storing secret key material on a finite 
number of secure hardware devices is that all such devices have a 
lifetime, and once they're all dead your information is gone. You'll 
still find yourself re-encrypting all your data to a new encryption 
(sub)key when you get down to your last working hardware device.


Having a non-secure offline backup does not negate all the advantages 
of secure hardware. It depends on the threat model of course, but 
*most* people are much more likely to have their laptop compromised 
remotely than have their safe cracked and the paper backup stolen.
I agree that for most people having a paper backup stolen is unlikely, 
but then again, most people are not using GPG, to begin with, let alone 
GPG with smartcards or security tokens. There are several security 
concerns which having retirement keyslots can address. They can also 
improve the user experience as you won't have to air-gap a machine to 
view old records with revoked keys. All in all, it's about providing the 
option of having only security token access, not requiring it. I would 
expect any smartcard stored in a safe and only used infrequently during 
key changes and the occasional old record decryptions to last well over 
a decade.


OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Andrew Gallagher via Gnupg-users]

On 22/06/2021 17:53, Brandon Anderson via Gnupg-users wrote:
Many tutorials, examples, and articles that are talking about using 
Yubikeys and smartcards currently suggest making paper backups of the 
encryption key so you can add it to new devices if needed. But this, at 


least to me, feels like it's significantly reducing the value of using 
secure hardware like smartcards in the first place. Having the keys only 
ever exist on secure hardware, including the backups, would make this 
unnecessary.


The disadvantage of only ever storing secret key material on a finite 
number of secure hardware devices is that all such devices have a 
lifetime, and once they're all dead your information is gone. You'll 
still find yourself re-encrypting all your data to a new encryption 
(sub)key when you get down to your last working hardware device.


Having a non-secure offline backup does not negate all the advantages of 
secure hardware. It depends on the threat model of course, but *most* 
people are much more likely to have their laptop compromised remotely 
than have their safe cracked and the paper backup stolen.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

For the benefit of the archives, it is possible to encrypt outgoing 
emails to your own key as well as the recipient's key, which ensures 
that the sent-mail folder is readable by the sender. Most email 
clients will do so by default (e.g. mutt, thunderbird/enigmail), and 
in most such clients all you need to do to re-encrypt to the 
recipient's new subkey is "Edit" -> "Send" or similar. So in the 
general case this is a reasonable request, although it cannot be 
relied upon (of course).

Good to know; I will look into my settings.


the PIV functions only support 2048 RSA and NIST curves. The only card

That's per PIV specs.


I assumed as much; otherwise, there would be more offerings. There are 
x509 certificate cards/HSM smartcards like the one I posted that offer 
more than the PIV spec, but again it's a question of how compatible they 
are to work with GPG; my initial guess is it would be a lot of work.



Frankly, I am not convinced about the retirement slots on the card.
They are of course useful if you rotate you key.  But the question is
why you want to do this given that the keys are anyway securely stored
on a card.
If a key truly lived and died on a single secure device, and that was 
your only concern, then yes, it would not be helpful. I am thinking 
about my situation: I have two Yubikeys in everyday use and a GPG 
smartcard in a safe. I imagine a scenario where one of the Yubikeys 
dies, is lost or is stolen. In all of those situations, the encryption 
key and the other device-specific keys would need to be revoked and a 
new one issued. The GPG card in the safe would store the old encryption 
key in a retired key slot so I can decrypt old emails. If I did, for 
example, annual key rotations and only stored the retired keys on the 
card in the safe, then in the event one of my Yubikey's was stolen, and 
the thief could guess or know the pin, the only data at risk would be 
what was encrypted since the last key rotation. Whether it is reasonable 
to assume that a thief could know your pin or not is purely a matter of 
your risk tolerance (a keylogger on one of the computers you used, 
etc.). Another reason the encryption key might want to be rolled is if 
you are adding another new secure device to your existing set and you 
want it to be able to decrypt messages. Since ideally, the encryption 
key would only exist on the secure hardware, and there would be no way 
to give a new token the existing encryption key so that you would roll a 
new encryption key on all the devices.
Many tutorials, examples, and articles that are talking about using 
Yubikeys and smartcards currently suggest making paper backups of the 
encryption key so you can add it to new devices if needed. But this, at 
least to me, feels like it's significantly reducing the value of using 
secure hardware like smartcards in the first place. Having the keys only 
ever exist on secure hardware, including the backups, would make this 
unnecessary.


Sincerely,

Brandon Anderson



OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Andrew Gallagher via Gnupg-users]

On 22/06/2021 07:47, Brandon Anderson via Gnupg-users wrote:


If you know the recipient, then solving the latter is easy. Ask the 
recipient

to resend the message encrypted with your new key.

In my setup, when something is sent, only the encrypted mail is sent to 


my sent folder, so if I were asked as you suggest, I would have no way 
to send the letter without rewriting it; I assume this is true for 
others as well. But even so, if it's old mail, the request may be 
impossible.


For the benefit of the archives, it is possible to encrypt outgoing 
emails to your own key as well as the recipient's key, which ensures 
that the sent-mail folder is readable by the sender. Most email clients 
will do so by default (e.g. mutt, thunderbird/enigmail), and in most 
such clients all you need to do to re-encrypt to the recipient's new 
subkey is "Edit" -> "Send" or similar. So in the general case this is a 
reasonable request, although it cannot be relied upon (of course).


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Werner Koch via Gnupg-users]

On Mon, 21 Jun 2021 23:47, Brandon Anderson said:

> the PIV functions only support 2048 RSA and NIST curves. The only card

That's per PIV specs.

> What would it take to add support for retirement key slots into the
> GPG smartcard specification? If retirement slots were added to the
> smartcard spec, then after several years, other smartcard

Frankly, I am not convinced about the retirement slots on the card.
They are of course useful if you rotate you key.  But the question is
why you want to do this given that the keys are anyway securely stored
on a card.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

If you know the recipient, then solving the latter is easy. Ask the 
recipient

to resend the message encrypted with your new key.

In my setup, when something is sent, only the encrypted mail is sent to 
my sent folder, so if I were asked as you suggest, I would have no way 
to send the letter without rewriting it; I assume this is true for 
others as well. But even so, if it's old mail, the request may be 
impossible.


GnuPG 2.3 does support PIV smartcards and you can create OpenPGP keys 
(and
X.509 certificates/certificate requests) for those card keys. So far, 
only the
standard key slots are supported, but I guess adding support for 
retired keys

wouldn't be too hard. So, you could consider using PIV tokens as hardware
tokens.

I will look into that. Do you know of any PIV cards that support the 
25519 curve? Unfortunately, while the Yubikey supports 25519 for GPG, 
the PIV functions only support 2048 RSA and NIST curves. The only card I 
see so far that supports this is 
https://www.cardlogix.com/product/l-plus-hardware-security-module-hsm-card/, 
but I am unsure what would be involved in getting it to work as I doubt 
it would be compatible out the box with GPG; I will try to obtain one 
and experiment.


What would it take to add support for retirement key slots into the GPG 
smartcard specification? If retirement slots were added to the smartcard 
spec, then after several years, other smartcard implementations might 
add support for it over time. Is that something I could help contribute 
with?


Well, you could re-encrypt everything encrypted to the retired keys 
with the
new keys. This will make sure that you can still decrypt everything 
even if

you kept tokens with the retired keys and those tokens die.

I thought about this as well. Having an encrypted offline copy of the 
decryption keys encrypted with a smartcard would have the same benefits 
as the limited password attempts and hardware security around the key. 
The problem is that whenever I need/want to decrypt old messages, I 
would have to set up an air-gapped system and, on that system, load the 
decryption key on a token, a rather tedious process. That being said, I 
will probably go with this option in the interim unless others have a 
better suggestion on how to do this. I would like to help if I could on 
adding key retirement slots to the smartcard specification if possible.


Sincerely,

Brandon Anderson



OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Ingo Klöcker]

On Montag, 21. Juni 2021 04:52:37 CEST Brandon Anderson via Gnupg-users wrote:
> The problem, of course, comes when I need to decrypt old messages signed
> with the revoked key or if someone at a later point sends an encrypted
> message to the revoked key.

If you know the recipient, then solving the latter is easy. Ask the recipient 
to resend the message encrypted with your new key.

> Ideally, I would keep one security token
> that is assigned the encryption subkey simultaneously as the others
> before it is destroyed from the computer.This token's job would be to
> store historic encryption keys if I ever needed to decrypt messages with
> the older encryption keys. PIV smartcards, including the Yubikey
> implementation, support Slots 82-95: Retired Key Management which is
> specifically built for the purpose of key rotation while letting a user
> store many old encryption keys before they need to acquire new hardware.
> As neat as this is, the GPG smart card implementations seem to offer no
> such similar feature. The GPG keys on the smartcards seem specialized
> specifically for the type of key, be it signing or encryption; you cant
> even store 3~4 encryption keys per card. Is there a proper way to do
> this similar to the PIV retired key management scheme?

GnuPG 2.3 does support PIV smartcards and you can create OpenPGP keys (and 
X.509 certificates/certificate requests) for those card keys. So far, only the 
standard key slots are supported, but I guess adding support for retired keys 
wouldn't be too hard. So, you could consider using PIV tokens as hardware 
tokens.

> Most people say
> to just backup offline the encryption keys. Still, I feel like security
> is lost if that key is ever recoverable in a form other than the secure
> hardware (e.g., it somehow leaks, resulting in old messages being able
> to be decrypted). Is there a reason the GPG smart card system does not
> have retired key slots as part of the design? How is one supposed to
> best go about this without getting new cards everytime you rotate
> encryption subkeys?

Well, you could re-encrypt everything encrypted to the retired keys with the 
new keys. This will make sure that you can still decrypt everything even if 
you kept tokens with the retired keys and those tokens die.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users