Question with Subkeys and Yubikeys

[Brandon Anderson via Gnupg-users]

Hello,
I have a gpg key that was generated on a yubikey with the gpg card 
generate command. I now have a second yubikey, and I would like to 
generate and store a signature and authentication subkey on this second 
yubikey, but I am running into some issues. Ideally, I would like to be 
able to type in `gpg --expert --edit-key KeyID` and then go `addcardkey` 
with the secondary yubikey attached. This starts to work and generates a 
key on the secondary yubikey, but then it will ask me to insert the 
primary yubikey presumably to sign the change; however, even after I 
insert the primary yubikey, GPG does not recognize it, and if I remove 
the secondary yubikey the process is aborted. The other thing I tried 
was to run `generate` on the secondary yubikey so that it would generate 
its key slots and then once again run `gpg --expert --edit-key KeyID`, 
but this time called `addkey` and select option 13 to add an existing 
key hoping that it would just need the primary yubikey to sign off on 
the changes. Still, even after it asks for the pin of the primary 
yubikey, it then asks for the secondary yubikey and runs into the same 
issue. What is the best way to do this where the subkeys are generated 
on the yubikey and then signed by the primary yubikey?
Also, unrelated question, but I could not find much information on this; 
on the Yubico website, it says if you call generate on the smartcard
>When prompted, specify if you want to make an off-card backup of your 
encryption key.
 >Note: This is a shim backup of the private key, not a full backup, 
and cannot be used to restore to a new YubiKey.
What exactly is a shim backup? Is this just the private encryption key 
but nothing else, or does it not actually include any private encryption 
key? Is there a way to generate this key where the encryption key is 
never exposed outside the yubikey?


-- Brandon Anderson


OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key


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

Re: Multiple Yubikeys/Smartcards and Thunderbird email client

[Brandon Anderson via Gnupg-users]

On 15 Jul 2021, at 12:54, john doe via Gnupg-users 
 wrote:


Is this still relevent with the built-in gpg stuff of TB?
Very much so. Thunderbird’s native Open PGP support is quite basic, 
and anything to do with smartcards still has to be delegated to an 
external gnupg process.


A



Another weird behavior I am just now noticing, and maybe it is 
related. When I insert the Yubikey that Thunderbird wants, and type 
into the terminal `gpg --card-status`, it outputs as expected. The 
same thing occurs if I insert my GPG smartcard v2.1. However, my 
primary Yubikey 5 Nano, which is usually on my desktop and the one I 
want Thunderbird to play nice with when inserted and `gpg 
--card-status` is run outputs:



➜  yubikeyLockPassword gpg --card-status
gpg: selecting card failed: End of file
gpg: OpenPGP card not available: End of file

The first time and then when you rerun `gpg --card-status`, it outputs 
the proper and expected result every time. However, this is repeatable 
as every time I remove and reinsert this particular Yubikey, the first 
card-status call falls, all later ones succeed. I wonder if this odd 
behavior is what's causing Thunderbird to ignore this one Yubikey.


Sincerely,

Brandon Anderson



So, following up on this email, I went to sign some git commits, and the 
same issue that I reported happening on thunderbird happened with my git 
commits. The issue is similar to what is reported here three years ago 
https://stackoverflow.com/questions/46330629/signing-commits-in-git-uses-wrong-subkey 
where only the most recent signature key is attempted even if the system 
has a smartcard or private key to an alternative valid signing key. I 
have deleted the subkeys for the non-primary smartcards on my desktop 
and while it works is less than the desired solution, as I can not 
insert other smartcards for signing and may want to verify in gpg those 
subkeys signatures. Any insight would be greatly appreciated.




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: Multiple Yubikeys/Smartcards and Thunderbird email client

[Brandon Anderson via Gnupg-users]

On 15 Jul 2021, at 12:54, john doe via Gnupg-users  
wrote:

Is this still relevent with the built-in gpg stuff of TB?

Very much so. Thunderbird’s native Open PGP support is quite basic, and 
anything to do with smartcards still has to be delegated to an external gnupg 
process.

A



Another weird behavior I am just now noticing, and maybe it is related. 
When I insert the Yubikey that Thunderbird wants, and type into the 
terminal `gpg --card-status`, it outputs as expected. The same thing 
occurs if I insert my GPG smartcard v2.1. However, my primary Yubikey 5 
Nano, which is usually on my desktop and the one I want Thunderbird to 
play nice with when inserted and `gpg --card-status` is run outputs:



➜  yubikeyLockPassword gpg --card-status
gpg: selecting card failed: End of file
gpg: OpenPGP card not available: End of file

The first time and then when you rerun `gpg --card-status`, it outputs 
the proper and expected result every time. However, this is repeatable 
as every time I remove and reinsert this particular Yubikey, the first 
card-status call falls, all later ones succeed. I wonder if this odd 
behavior is what's causing Thunderbird to ignore this one Yubikey.


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: Call me crazy, but ...

[Brandon Anderson via Gnupg-users]

On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 
 wrote:


It would tell me as 3rd party that for WoT puposes, if this is still 
used,
Alice and her good friend Bob were able to sign their pub keys 
remotely,

based on a free of charge verification method.


That’s what ordinary third-party sigs do. Adding medical data to a
public key does not add anything to the process.


If it would be only medical data you are correct! But, and here a big 
but,

this medical data contains the full name and birthday of the certificate
holder *digitally signed* by EU *authorities* in this field while the 
cert

holder had to show his *valid* ID-card to the issuer.


You should also beware that medical information is treated as
sensitive personal data under GDPR, and this subject to stricter
rules. Keyserver operators already have enough legal issues handling
ordinary personal data (email addresses etc) without adding
vaccination certificates to the dataset.


As I said a duplicate key is not meant for keyserver distribution and
if this should happen by accident, well than it happened. No one can
be sued about this. It is or was only said in some news that one should
not publish such QR-codes on social media.

At its core, the problem here is you still are not proving this 
verifiable secret has not been shared with any other party. Are these 
being scanned to go to work? Are these being scanned to travel? Are 
these being used in other hypothetical key exchanges? I am going to 
assume you currently have one of these QR codes. Assuming you want me to 
sign your public key, prove to me now that you have never shared or 
shown it to anyone ever. If you cannot do this, I cannot be assured you 
are the actual party that is sharing it as it could have been an earlier 
party you shared it with or someone eavesdropping on the communication 
channel you shared it upon.


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: Call me crazy, but ...

[Brandon Anderson via Gnupg-users]

On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 
 wrote:


It would tell me as 3rd party that for WoT puposes, if this is 
still used,
Alice and her good friend Bob were able to sign their pub keys 
remotely,

based on a free of charge verification method.
That’s what ordinary third-party sigs do. Adding medical data to a 
public key does not add anything to the process.


You should also beware that medical information is treated as 
sensitive personal data under GDPR, and this subject to stricter 
rules. Keyserver operators already have enough legal issues handling 
ordinary personal data (email addresses etc) without adding 
vaccination certificates to the dataset.


A

I would argue what he is proposing doesn't do that at all. It is like
publically posting a password to your google account and telling
people they can verify it is your account by trying to sign in! Once
you send your 'proof of identity,' anyone can make the same claims
even if you are not sharing this on a keyserver. It's made worse by
this being something I expect people will be sharing to prove
vaccination, so it will likely have many potential areas to be copied.
If you tell me you have not shared it with anyone yet, that still
means nothing because you could be impersonating the persons whose QR
code you already received from an earlier exchange. Even if this was
not the case, and it indeed was a verifiable secret never shared with
anyone, it does not verify the identity of the public key owner
because it's susceptible to a simple man-in-the-middle attack.

Assume Bob wishes to prove his ownership of public key pub_bob to
Alice. Bob and Alice are communicating in a way compromised by Eve.
Bob affixes his Vaccine QR code to a public key and transmits it to
Alice. On route to Alice, Eve intercepts the public key, generates a
key pair Pub/Priv_eve, adds bobs QR code to the public key Pub_eve,
and sends it to Alice. Alice sees Pub_eve with Bob's QR code and
concludes that Pub_eve is owned by Bob and signs it as verified.

Again, this is not a secure way to verify identity. Do not do this. It
is considerably worse than just having a public key exchange over the
phone/video call because it gives others a way to impersonate you. If
you wanted to have a video call over the internet and show "proof of
identity" over that call and that was sufficient for you, then fine,
but whatever you do, don't attach your proof of identity to the public
key.


Why do you assume such a workflow?

Alice sends the duplicate ASCII armored in an encrypted and signed
message to Bob.

Bob is already for a long time in possession of Alice's pub key.

After receiving Alice's message he extracts the QR-code, verifies it
and compares both pub keys fingerprints. Once done he deletes the
duplicate and the extracted QR-code.

Finally he can sign Alice's pub key, sends it back to her and she can
then upload it to a keyserver.

When designing a scheme for cryptography, you should always assume the 
worst situation, so it is secure in every situation. So in this 
hypothetical, you are only using this scheme if Bob has already somehow 
verified Alices' public key? How has he managed to do so? I assume 
either in person or with the web of trust. However, Bob has managed to 
do this should be the same way Alice verified Bob's key. This brings us 
right back to the this QR-code does not prove ownership of Bob's public 
key. Again if Eve ever has seen this QR-code, either with an earlier 
communication or otherwise, Eve could be sending the encrypted message 
to Alice with Bob's QR code. From Alice's viewpoint, who has not 
verified Bob's public key, there is no way for her to know who is 
sending it, so she should not trust it.


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: Multiple Yubikeys/Smartcards and Thunderbird email client

[Brandon Anderson via Gnupg-users]

On 7/15/2021 12:24 PM, Ingo Klöcker wrote:
On Donnerstag, 15. Juli 2021 03:22:47 CEST Brandon Anderson via 
Gnupg-users

wrote:

I have several Yubikeys and smartcards in my setup, each with its own
signing subkeys, and I use these, among other things, to sign email
messages. Whenever I want to send an email on thunderbird, it demands a
specific smartcard by serial number for email signing and will 
refuse to

use the smartcard/Yubikey plugged into the system.


Which version of gpg are you using? If you are not using 2.3, then 
please

retry with gpg 2.3.1. Support for multiple smartcards was significantly
improved in 2.3.

Sorry I should have included that I am using version "gpg (GnuPG) 2.3.1 
libgcrypt 1.9.3"




Is this still relevent with the built-in gpg stuff of TB?

According to 
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards#Allow_the_use_of_external_GnuPG 



Use the Thunderbird config editor (found at the bottom of 
preferences/options), and search for 
mail.openpgp.allow_external_gnupg. Switch the value to true.


Enabling this preference will cause Thunderbird to attempt to decrypt 
a message using GnuPG, whenever RNP fails to decrypt a message with 
the secret keys that are available inside Thunderbird's key storage.#


So I do not see why its not relevant if its just passing the stuff down 
to gpg.


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

Multiple Yubikeys/Smartcards and Thunderbird email client

[Brandon Anderson via Gnupg-users]

I have several Yubikeys and smartcards in my setup, each with its own 
signing subkeys, and I use these, among other things, to sign email 
messages. Whenever I want to send an email on thunderbird, it demands a 
specific smartcard by serial number for email signing and will refuse to 
use the smartcard/Yubikey plugged into the system. At first, I thought 
this was a thunderbird problem; however, according to the thunderbird 
docs, for smartcard signing, it sends the requests directly to GPG. When 
I rebooted my system and issued the command `gpg --clearsign` followed 
by some test data to sign, it also demanded the same specific smartcard 
for digital signing rather than the smartcard that was plugged into the 
system and had a valid subkey for signing. This behavior would go away, 
and gpg would pick the first valid signature subkey for which it had 
access after I ran the command `gpg --card-status`, but the issue does 
not clear on thunderbird. My public key is viewable here 
https://keyserver.ubuntu.com/pks/lookup?search=0xAA35E492383D0F8A2E145261255837AEF812E87E&fingerprint=on&op=index. 
Normally, I have my desktop Yubikey with the signature subkey 
ed25519/CC3C9B2F10BCED15, but thunderbird and gpg on boot (before `gpg 
--card-status`) refuse to sign with any other key than 
ed25519/5A55707CAA63F689 even when the smartcard for that key is not on 
the system and the smartcard for the other key is.


Interestingly, thunderbird has no issue decrypting a message with the 
smartcard normally used on my system; it just refuses to sign if not 
with a specific smartcard. The fact that on-system boot gpg is 
exhibiting the same behavior and that thunderbird is supposedly directly 
using gpg for smartcard-related actions makes me think this is something 
I have misconfigured. Any idea what I should be doing differently?


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: Call me crazy, but ...

[Brandon Anderson via Gnupg-users]

On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 
 wrote:

It would tell me as 3rd party that for WoT puposes, if this is still used,
Alice and her good friend Bob were able to sign their pub keys remotely,
based on a free of charge verification method.

That’s what ordinary third-party sigs do. Adding medical data to a public key 
does not add anything to the process.

You should also beware that medical information is treated as sensitive 
personal data under GDPR, and this subject to stricter rules. Keyserver 
operators already have enough legal issues handling ordinary personal data 
(email addresses etc) without adding vaccination certificates to the dataset.

A
I would argue what he is proposing doesn't do that at all. It is like 
publically posting a password to your google account and telling people 
they can verify it is your account by trying to sign in! Once you send 
your 'proof of identity,' anyone can make the same claims even if you 
are not sharing this on a keyserver. It's made worse by this being 
something I expect people will be sharing to prove vaccination, so it 
will likely have many potential areas to be copied. If you tell me you 
have not shared it with anyone yet, that still means nothing because you 
could be impersonating the persons whose QR code you already received 
from an earlier exchange. Even if this was not the case, and it indeed 
was a verifiable secret never shared with anyone, it does not verify the 
identity of the public key owner because it's susceptible to a simple 
man-in-the-middle attack.


Assume Bob wishes to prove his ownership of public key pub_bob to Alice. 
Bob and Alice are communicating in a way compromised by Eve. Bob affixes 
his Vaccine QR code to a public key and transmits it to Alice. On route 
to Alice, Eve intercepts the public key, generates a key pair 
Pub/Priv_eve, adds bobs QR code to the public key Pub_eve, and sends it 
to Alice. Alice sees Pub_eve with Bob's QR code and concludes that 
Pub_eve is owned by Bob and signs it as verified.


Again, this is not a secure way to verify identity. Do not do this. It 
is considerably worse than just having a public key exchange over the 
phone/video call because it gives others a way to impersonate you. If 
you wanted to have a video call over the internet and show "proof of 
identity" over that call and that was sufficient for you, then fine, but 
whatever you do, don't attach your proof of identity to the public key.


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: Call me crazy, but ...

[Brandon Anderson via Gnupg-users]

Andrew Gallagher wrote:
On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users 
 wrote:


Viktor wrote:


It's the same as putting any other public information in public key
certificate. You can put first and last name, email address and even
photo of another person.


But this information can be digitally verified and is issued EU wide by
Governemnt trusted sources in this field.


But this puts logical causality the wrong way around. Just because the
thing *being signed* is genuine, does not prove that the thing *doing
the signing* is genuine.

IMO this proposal is abuse of the public key infrastructure. If you
want to sign an ID document, just sign an ID document and distribute
it through other channels. Attaching it as a signed packet to a key
adds zero value, at nonzero cost.


What abuse do you see here, if I may ask? I see it as an non-public 
option
among virtual GnuPG friends to include in a duplicate certified data, 
which

is not meant to been distributed on keyservers etc. or made public to
the world and acts for two pub keys comparison.




Again, this does not sound very secure or make much sense to me. It also 
seems to make several assumptions that I do not think are proper in any 
security situation that would call for GPG to begin with. You want to 
share a secret credential that you have with someone not in person to 
prove identity, something which can be copied and shared with others no 
differently than when you shared it with them. It is like using a 
government-backed CA but worse because you give everyone you communicate 
with access to the secret. You are assuming the person you are sharing 
this picture with won't use it themselves to impersonate you. You are 
assuming the communication channel you are using to share this picture 
with is secure and not being intercepted or spied upon, which could 
result in someone stealing and using this credential themselves. This 
then begs the question, if you have a channel that securely communicates 
between the two parties (the other party you trust enough to share this 
secret credential with) anyways, what the need for the QR code to begin 
with is? Just share your public key and be done with it.




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

Re: Call me crazy, but ...

[Brandon Anderson via Gnupg-users]

What exactly stops me, a person wanting to impersonate that user, from 
putting the same QR-Code I got from that public key into my own keypair?


On 7/14/21 5:45 AM, Стефан Васильев via Gnupg-users wrote:
if a person, within the EU, would put his COVID vaccination 
certificate QR-Code
in his pub-key as photo-ID I would say that than another GnuPG user, 
within
the EU, or maybe later in the U.S. and elsewhere too, would have the 
assurance,
without that the public key is otherwise signed, that this pub key 
belongs to that

person.

On GitHub is a decoder available, which allows users to verify the 
digital signature

of such COVID certs, with trustlists from EU member states.

https://github.com/stapelberg/coronaqr

Regards
Stefan

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


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: HID Omnikey 3121 Smart Card Reader and GPG

[Brandon Anderson via Gnupg-users]

On Thu,  8 Jul 2021 16:48, NIIBE Yutaka said:


So, I think that Omnikey CardMan 3121 can work in the use case with
OpenPGP card if it's key is RSA 1024.

Exactly, I used to use Omnikey readers too but I had to gave up due to
this problem.  On Windows Omnikey's driver uses proprietary escape codes
to make it work:

   /* We employ a hack for Omnikey readers which are able to send
  TPDUs using an escape sequence.  There is no documentation
  but the Windows driver does it this way.  Tested using a
  CM6121.  This method works also for the Cherry XX44
  keyboards; however there are problems with the
  ccid_transceive_secure which leads to a loss of sync on the
  CCID level.  If Cherry wants to make their keyboard work
  again, they should hand over some docs. */

The 6121 is a PCMCIA style reader which I could make work for my old
laptop.  As usual with reader vendors they use their ASICs for all types
of readers and thus he sees the problem also with the 3121.  I have an
5121 here but I can use it only for RFID.

He may be able to use the 3121 with ECC keys.




Wow, that is interesting to know; I guess I will return the Omnikey 3221 
and pick up an Identiv SCR3310 instead. I really liked the vertical slot 
design on the Omnikey for the card as all the cheaper no-name readers 
that were vertical would give me USB problems if plugged in permanently, 
so I was hoping the Omnikey would be a better reader. Anyway, thank you 
both for letting me know what was going on.


- 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

HID Omnikey 3121 Smart Card Reader and GPG

[Brandon Anderson via Gnupg-users]

So I have purchased an Omnikey 3121 smart card reader for use with my 
GPG smart card version 2.1. Whenever I put my card in and request `gpg 
--card-status`, the reader flashes its light for about a minute, and 
then finally, gpg returns with:


```

➜  ~ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

```

Now I know the card reader works because if I use pscs_scan I 
immediately get:


```

➜  ~ pcsc_scan
Using reader plug'n play mechanism
Scanning present readers...
0: HID Global OMNIKEY 3x21 Smart Card Reader [OMNIKEY 3x21 Smart Card 
Reader] 00 00


Wed Jul  7 17:41:24 2021
 Reader 0: HID Global OMNIKEY 3x21 Smart Card Reader [OMNIKEY 3x21 
Smart Card Reader] 00 00

  Event number: 2
  Card state: Card inserted,
  ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C

ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
+ TS = 3B --> Direct Convention
+ T0 = DA, Y(1): 1101, K: 10 (historical bytes)
  TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
    129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
  TC(1) = FF --> Extra guard time: 255 (special value)
  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
-
  TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1
-
  TA(3) = FE --> IFSC: 254
  TB(3) = 75 --> Block Waiting Integer: 7 - Character Waiting Integer: 5
  TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface 
bytes following

-
  TA(4) = 03 --> Clock stop: not supported - Class accepted by the 
card: (3G) A 5V B 3V

+ Historical bytes: 00 31 C5 73 C0 01 40 00 90 00
  Category indicator byte: 00 (compact TLV data object)
    Tag: 3, len: 1 (card service data byte)
  Card service data byte: C5
    - Application selection: by full DF name
    - Application selection: by partial DF name
    - EF.DIR and EF.ATR access services: by GET DATA command
    - Card without MF
    Tag: 7, len: 3 (card capabilities)
  Selection methods: C0
    - DF selection by full DF name
    - DF selection by partial DF name
  Data coding byte: 01
    - Behaviour of write functions: one-time write
    - Value 'FF' for the first byte of BER-TLV tag fields: invalid
    - Data unit in quartets: 2
  Command chaining, length fields and logical channels: 40
    - Extended Lc and Le fields
    - Logical channel number assignment: No logical channel
    - Maximum number of logical channels: 1
    Mandatory status indicator (3 last bytes)
  LCS (life card cycle): 00 (No information given)
  SW: 9000 (Normal processing.)
+ TCK = 0C (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
    OpenPGP Card V2

```

And if I run `pkcs15-tool -k`, I get the following returned:

```

➜  ~ pkcs15-tool -k
Using reader with a card: HID Global OMNIKEY 3x21 Smart Card Reader 
[OMNIKEY 3x21 Smart Card Reader] 00 00

Private RSA Key [Signature key]
    Object Flags   : [0x03], private, modifiable
    Usage  : [0x20C], sign, signRecover, nonRepudiation
    Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, 
local

    Algo_refs  : 0
    ModLength  : 4096
    Key ref    : 0 (0x00)
    Native : yes
    Auth ID    : 01
    ID : 01
    MD:guid    : 

Private RSA Key [Encryption key]
    Object Flags   : [0x03], private, modifiable
    Usage  : [0x22], decrypt, unwrap
    Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, 
local

    Algo_refs  : 0
    ModLength  : 4096
    Key ref    : 1 (0x01)
    Native : yes
    Auth ID    : 02
    ID : 02
    MD:guid    : 

Private RSA Key [Authentication key]
    Object Flags   : [0x03], private, modifiable
    Usage  : [0x222], decrypt, unwrap, nonRepudiation
    Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, 
local

    Algo_refs  : 0
    ModLength  : 4096
    Key ref    : 2 (0x02)
    Native : yes
    Auth ID    : 02
    ID : 03
    MD:guid    : 

```

So I believe the card reader is working fine, but gpg is just not 
working with it for some reason. On the GPG howto page, it's listed as 
(https://www.gnupg.org/howtos/card-howto/en/ch02s02.html):


Omnikey Cardman 3121 (and 2020)
This USB card reader supports CCID and PC/SC. The older Omnikey Cardman 
2020 is no longer produced. The newer reader has not been tested, but 
Omnikey says that the two readers are compatible.


To add some context, I am able to use my Identiv SCR3500 just fine with 
the same system using the same card; I just wanted a more permanent 
setup for my desktop. I am using gpg version 2.3.1 on Debian Sid. Are 
there steps I can/should take to diagnose what's going on? Is this card 
reader not compatible with the GPG drivers? Any advice would be appreciated.


Sincerely,

B

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

[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: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[Brandon Anderson via Gnupg-users]

The keyserver situation seems a bit difficult currently, maybe
https://keys.openpgp.org/ is the best (easiest) workaround for now.

But WKD is really worth looking at!



My understanding is the Ubuntu Key-server is staying up, I could be 
wrong, but https://keyserver.ubuntu.com/ seems to be functioning. It is 
worth noting that the keys.openpgp.org keyserver is not web of trust but 
explicitly trusting that keyserver to validate a person's identity.




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: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[Brandon Anderson via Gnupg-users]

Starting on the morning of June 21 between ~6am and 9am PDT, one of 
our CI jobs which fetches gpg keys with:


gpg --keyserver hkp://pool.sks-keyservers.net 
 --recv-keys ...
 started failing because of what looks like a failure to resolve 
the pool name.


FWIW the following also fails in the same way:

gpg --keyserver hkp://ipv4.pool.sks-keyservers.net 
 --recv-keys ...


And testing from my machine, it looks like these names now get 
NXDOMAIN when attempting to resolve in DNS:


$ host ipv4.pool.sks-keyservers.net 

Host ipv4.pool.sks-keyservers.net 
 not found: 3(NXDOMAIN)



$ host pool.sks-keyservers.net 

Host pool.sks-keyservers.net  not 
found: 3(NXDOMAIN)





Did these names get permanently deleted? Any workarounds or 
suggestions would be appreciated.





Hey Alex,

From what I can tell a lot of the keyservers are being shutdown. Take a 
look at the message on the SKS site (the SSL cert is expired) 
https://sks-keyservers.net/.


You can read about some of whats going on from here 
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f.


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

[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

[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

[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

[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

[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

Long Term Key Management With Hardware Tokens

[Brandon Anderson via Gnupg-users]

Hey everyone,

I have a question regarding using secure hardware such as 
Yubikey/Nitrokey, GPG smartcards, and the handling of encryption key 
rotation and replacement. I currently have a GPG key with a 4096 bit RSA 
key generated on a GPG smart card version 2.1. I have recently acquired 
two Yubikey 5's, both of which support curve25519. It is unclear if 
version 3.4 of the GPG smart card supports this curve, but if it does, I 
would be interested in using it as well. As I am looking to generate a 
new key that uses the curve25519, I was trying to plan out how I should 
handle key management and revocation. I was thinking that sub-signing 
keys could be generated on the secure hardware and a sub decryption key 
could be generated and imported onto each of these devices with an 
air-gapped system. Then the non-secure copy of the key is destroyed. 
Ideally, these subkeys would only ever exist on the secure hardware. 
When either a token is lost, a new one is added, or enough time has 
passed that I want to roll the keys, I would revoke the subkey in use, 
generate a new one via the same process and add it to the security 
tokens in use.


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. 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? 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?


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