Creating identities after keytocard

How do I add a new identity to the key once it has been moved to the yubikey (keytocard)?

I have two yubikeys and would like to add a new identity. The guide has adding identities after creating the sub keys but nothing explicitly (that i could find) about adding identities after the fact.

I am assuming I will need to start here as if I was renewing sub keys or rotating keys except I adduid instead?

I tried it on a spare key.

It works for one key, I wasn't able to try it for a second duplicate key.

After generating a key on the card (or on disk then keytocard) you can just:

gpg --edit-key @.*** gpg> adduid .... gpg> save

If you are following the procedure for duplicate keys, I believe you will be out of luck as you wouldn't be able to add a second UID to the card.

When I added a new UID to my key I tried using some spare keys and couldn't find a way.

I ended up rebuilding the key from scratch, adding comments to say what fingerprint key replaced/replaces which key, and signing each key before moving the key to card.

On Mon, 25 Jul 2022 at 03:38, Matthieu Robineau @.***> wrote:

How do I add a new identity to the key once it has been moved to the yubikey (keytocard)?

I have two yubikeys and would like to add a new identity. The guide has adding identities after creating the sub keys but nothing explicitly (that i could find) about adding identities after the fact.

I am assuming I will need to start here https://github.com/drduh/YubiKey-Guide#setup-environment as if I was renewing sub keys or rotating keys except I adduid instead?

— Reply to this email directly, view it on GitHub https://github.com/drduh/YubiKey-Guide/issues/337, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABU6FGIOLHEF2JP3NJY6IATVVX4ZFANCNFSM54QVJ4YA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Ian Stanley

@.***

@iandstanley Thanks for your reply. Are you saying that I can't add new UIDs using the master key backup and then keytocard the master key (as if it was a new key setup) to each yubikey?

And secondly, is there a drawback to manually doing the gpg --edit-key on each card separately to add the UID?

If you are using the master key backup (the backup you made before you keytocard) then effectively you are just rewinding the process back. You should be able to keytocard twice to your two yubikeys (remembering to: save after adding the uid & quit after the first keytocard & save after the second keytocard // or alternately restore the backup after the first keytocard).

This should give you two yubikeys that both have the new uid.

I /THINK/ that gnupg places the UIDs directly into the private key and/or the public key and not in the subkeys on the card. I suspect both as you can recreate the stub from the public key WITH the yubikey using the fetch subcommand. (I did wonder if just adding the key to the stub private key and the public key would be sufficient as we have to re-export the public key anyway ... but I am less familiar with the internals of the gnupg program and exactly what it puts in what file on the disk)

You cannot run gpg --edit-key on each card separately as the key stub appears to keep the uids (I tested this and gnugp refuses to add it to with the second key inserted as it was already on the stub). If you restored a backup prior to the adduid before you ran keytocard the second time then I guess it should be possible.

The whole process can be a bit messy with restoring backups between each execution step.

As mentioned in the docs you will get the issue of switching duplicate yubikeys as gnupg keeps a track of the last yubikey it ran keytocard on ... making a note of it in the stub. You must force gpg-connect-agent to learn which yubikey is inserted to prevent it from asking for the other yubikey by serial number. See my script switch-to-backup-yubikey in the repo or the relevant section of the guide. This will be required to be run each time you switch between keys (for whatever reason)

On Tue, 26 Jul 2022 at 21:45, Matthieu Robineau @.***> wrote:

@iandstanley https://github.com/iandstanley Thanks for your reply. Are you saying that I can't add new UIDs using the master key backup and then keytocard the master key (as if it was a new key setup) to each yubikey?

And secondly, is there a drawback to manually doing the gpg --edit-key on each card separately to add the UID?

— Reply to this email directly, view it on GitHub https://github.com/drduh/YubiKey-Guide/issues/337#issuecomment-1195962870, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABU6FGMO44UFB2XQ2F3KJ5TVWBE6NANCNFSM54QVJ4YA . You are receiving this because you were mentioned.Message ID: @.***>

Ian Stanley

@.***

Just to add a +1 to Ian's advice and hopefully give you a bit more confidence in the process, I had exactly this problem when my old GitHub email address leaked (I had dumbly started using -s on commits without realising the implications).

I jumped through the hoops of creating a replacement and let GitHub generate a "privacy enabled" email address, and then faced the problem of adding the new identities to my "built-alike" pair of YubiKeys.

I restored the backup snapshot taken immediately prior to my original key-to-card, added the new identities, took an updated backup snapshot, and did key-to-card on the first YubiKey.

I did a bit of testing to convince myself that everything was where it should be on the first YubiKey.

Then I restored the just-taken backup, and did key-to-card on the second YubiKey.

A bit more testing to assure myself that both YubiKeys were still "built-alike" and … job done!

I think the biggest hole you can dig for yourself with YubiKeys is either not taking a backup before the key-to-card process, or losing your backup. If anything, I think I'm more paranoid about making sure my encrypted backup is backed-up a few times, and that all the copies can make the round trip of restore + decryption.

Would there be a difference between using the master key backup to add the UID versus calling adduid on each yubikey (aside from the backup keeping the new UID)?

I don't know enough about GPG to know if this would change the secret key or public key in any meaningful way. As in, if both have the same new UID and I export the public keys to upload to github for example, would both yubikeys generate the same public key?

Can't say - but that's because I don't really understand the question.

This is a guess. If I'm wrong then, hopefully, other people who really do understand this stuff will chime in and correct me.

My understanding is that only the private keys live on the YubiKey, with the public keys living in ~/.gpg. The identities must be bonded into both. I think that's what you see when you run gpg -k and gpg -K.

I have never tried adduid directly "on" a YubiKey. I wouldn't even know where to start. But, assuming it was possible, it seems to me that all it would achieve is associating the new identity with the private keys on the YubiKey, leaving the older public keys untouched. That might be fixable but...

As noted before, I started by restoring the backup snapshot of my temporary GPG directory. Then, according to the notes I made at the time (January 2022), for each identity I wanted to add, it was:

$ KEYID=«yourKeyIDhere»
$ gpg --expert --edit-key $KEYID 
…

gpg> adduid
Real name: «something»
Email address: «something@something»
Comment: «something»
You selected this USER-ID:
    "something (something) <something@something>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
…

gpg> trust
…
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
…
gpg> save
$

Next, I exported everything. I don't know whether every command below was totally necessary but I am always over-cautious when I really have no idea what I'm doing:

$ gpg --export --armor $KEYID > $KEYID.gpg.public.key
$ gpg --export-secret-keys --armor $KEYID > $KEYID.gpg.master.key
$ gpg --export-secret-subkeys --armor $KEYID > $KEYID.gpg.sub.key
$ gpg --output $KEYID.gpg.revocation-cert.asc --gen-revoke $KEYID

Then I took a revised backup snapshot.

As a way of proving that the revised backup snapshot was viable, I deleted everything, restored the snapshot, and ran gpg -k and gpg -K to convince myself that the identities I had just added were actually "there".

And then it was:

First YubiKey

$ gpg --edit-key $KEYID
gpg> key 1
gpg> keytocard
Your selection? 1
gpg> key 1
gpg> key 2
gpg> keytocard
Your selection? 2
gpg> key 2
gpg> key 3
gpg> keytocard
Your selection? 3
gpg> key 3
gpg> save
$

Some testing with the new key.
Restore backup again.
Second YubiKey - as for first YubiKey.

At this point I must've stopped taking notes (got lazy because I was on the home stretch - the things ye come to regret, huh?).

But I think I needed to upload the updated public key ($KEYID.gpg.public.key) to the key-server, and run around importing the updated public key on the various hosts where I actually use the YubiKeys.

The various steps above come with some faffing-about as you are prompted for passphrases and PINs but I guess you can cope with those as they arise.

Whether any of this answers your question or helps…

Oh and don’t do it late at night when you are tired - learnt that the hard way when I managed to create a key and mistype the passphrase not only the twice when I created the key but also twice when I ran key to card to two Yubikeys. That hurt my head trying to figure that one out.

As far as creating keys and backups go I create my keys on a pristine install of TailsOS with a protected partition. Once created I then get TailsOS to duplicate itself to two other usb drives. I also make a couple of encrypted archives on different media that I can store offsite.

After that I use one of them to keytocard my primary Yubikey, then I boot again off my primary TailsOS and re image the usb that I keytocard off before repeating the whole process again.

You always want multiple encrypted copies on different media of your original generated keys made before you do anything with a Yubikey as it is too easy to make mistakes when using more than one Yubikey and do things in the wrong order or using the wrong drive or backup.

Be careful, methodical and precise and even the difficult can be overcome.

On 27 Jul 2022, at 03:01, Phill @.***> wrote:

Can't say - but that's because I don't really understand the question.

This is a guess. If I'm wrong then, hopefully, other people who really do understand this stuff will chime in and correct me.

My understanding is that only the private keys live on the YubiKey, with the public keys living in ~/.gpg. The identities must be bonded into both. I think that's what you see when you run gpg -k and gpg -K.

I have never tried adduid directly "on" a YubiKey. I wouldn't even know where to start. But, assuming it was possible, it seems to me that all it would achieve is associating the new identity with the private keys on the YubiKey, leaving the older public keys untouched. That might be fixable but...

As noted before, I started by restoring the backup snapshot of my temporary GPG directory. Then, according to the notes I made at the time (January 2022), for each identity I wanted to add, it was:

$ KEYID=«yourKeyIDhere» $ gpg --expert --edit-key $KEYID …

gpg> adduid Real name: «something» Email address: @.» Comment: «something» You selected this USER-ID: "something (something) @.>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O …

gpg> trust … Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y … gpg> save $ Next, I exported everything. I don't know whether every command below was totally necessary but I am always over-cautious when I really have no idea what I'm doing:

$ gpg --export --armor $KEYID > $KEYID.gpg.public.key $ gpg --export-secret-keys --armor $KEYID > $KEYID.gpg.master.key $ gpg --export-secret-subkeys --armor $KEYID > $KEYID.gpg.sub.key $ gpg --output $KEYID.gpg.revocation-cert.asc --gen-revoke $KEYID Then I took a revised backup snapshot.

As a way of proving that the revised backup snapshot was viable, I deleted everything, restored the snapshot, and ran gpg -k and gpg -K to convince myself that the identities I had just added were actually "there".

And then it was:

First YubiKey

$ gpg --edit-key $KEYID gpg> key 1 gpg> keytocard Your selection? 1 gpg> key 1 gpg> key 2 gpg> keytocard Your selection? 2 gpg> key 2 gpg> key 3 gpg> keytocard Your selection? 3 gpg> key 3 gpg> save $ Some testing with the new key.

Restore backup again.

Second YubiKey - as for first YubiKey.

At this point I must've stopped taking notes (got lazy because I was on the home stretch - the things ye come to regret, huh?).

But I think I needed to upload the updated public key ($KEYID.gpg.public.key) to the key-server, and run around importing the updated public key on the various hosts where I actually use the YubiKeys.

The various steps above come with some faffing-about as you are prompted for passphrases and PINs but I guess you can cope with those as they arise.

Whether any of this answers your question or helps…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

As an aside because we are talking about backups

Did you know that the email address used for a GPG key doesn’t have to be a valid email address. By that I mean the domain name doesn’t have to be a valid domain name. You can enter an “email address” of @. without a TLD. I have a separate key for encrypting backups. I create my backups and encrypt them both to my main GPG key associated with my email address AND ALSO the fake email address (say @.) that way I have two ways to restore my backups particularly useful if I have to replace my key for some reason and don’t think to keep a copy of the old key around for restoring backups.

Did you guys know that GNUPG ships with a version of gnu tar that uses GPG (see man gpgtar).

If you need to go the other way and make sure that you can only decrypt a backup on the device it was made on then you can create a GPG key and store it on a TPM using the keytotpm subcommand in —edit-key. This can be useful in some instances.

On 27 Jul 2022, at 03:01, Phill @.***> wrote:

Can't say - but that's because I don't really understand the question.

This is a guess. If I'm wrong then, hopefully, other people who really do understand this stuff will chime in and correct me.

My understanding is that only the private keys live on the YubiKey, with the public keys living in ~/.gpg. The identities must be bonded into both. I think that's what you see when you run gpg -k and gpg -K.

I have never tried adduid directly "on" a YubiKey. I wouldn't even know where to start. But, assuming it was possible, it seems to me that all it would achieve is associating the new identity with the private keys on the YubiKey, leaving the older public keys untouched. That might be fixable but...

As noted before, I started by restoring the backup snapshot of my temporary GPG directory. Then, according to the notes I made at the time (January 2022), for each identity I wanted to add, it was:

$ KEYID=«yourKeyIDhere» $ gpg --expert --edit-key $KEYID …

gpg> adduid Real name: «something» Email address: @.» Comment: «something» You selected this USER-ID: "something (something) @.>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O …

gpg> trust … Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y … gpg> save $ Next, I exported everything. I don't know whether every command below was totally necessary but I am always over-cautious when I really have no idea what I'm doing:

$ gpg --export --armor $KEYID > $KEYID.gpg.public.key $ gpg --export-secret-keys --armor $KEYID > $KEYID.gpg.master.key $ gpg --export-secret-subkeys --armor $KEYID > $KEYID.gpg.sub.key $ gpg --output $KEYID.gpg.revocation-cert.asc --gen-revoke $KEYID Then I took a revised backup snapshot.

As a way of proving that the revised backup snapshot was viable, I deleted everything, restored the snapshot, and ran gpg -k and gpg -K to convince myself that the identities I had just added were actually "there".

And then it was:

First YubiKey

$ gpg --edit-key $KEYID gpg> key 1 gpg> keytocard Your selection? 1 gpg> key 1 gpg> key 2 gpg> keytocard Your selection? 2 gpg> key 2 gpg> key 3 gpg> keytocard Your selection? 3 gpg> key 3 gpg> save $ Some testing with the new key.

Restore backup again.

Second YubiKey - as for first YubiKey.

At this point I must've stopped taking notes (got lazy because I was on the home stretch - the things ye come to regret, huh?).

But I think I needed to upload the updated public key ($KEYID.gpg.public.key) to the key-server, and run around importing the updated public key on the various hosts where I actually use the YubiKeys.

The various steps above come with some faffing-about as you are prompted for passphrases and PINs but I guess you can cope with those as they arise.

Whether any of this answers your question or helps…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

Thanks for the responses all. I will close this ticket as answered.

drduh / YubiKey-Guide

Creating identities after keytocard #337