This is the awesome part, they're actually separate keys, with separate policies!

(Or, well, separate sub-keys.)

With GPG, the only key that _has_ to be used for signing is the master key, the first key that appears in a user's key listing. For all other sub-keys, each key is explicitly marked as having a specific purpose.

Unfortunately, it doesn't look like you can see it on a public key server, but you can see this yourself if you have GPG, using these two commands:

gpg --keyserver pgp.mit.edu --recv-keys e5e5afc8 gpg -k e5e5afc8

(You might not need the `--keyserver pgp.mit.edu` part, if you have a keyserver specified already in your ~/.gnupg/gpg.conf file.)

(Also, I'm using GPG version 2.2.0. Older versions might not show the same content. For example, GPG 1.4.16 does not.)

The first line of output from the second command should be this:

    pub   rsa4096 2015-12-13 [SC] [expires: 2025-12-10]

That's my public key, the main part of the key, and it is only able to be used for signing stuff (the `S`), and for binding other sub-keys to the public key (the `C`).

Later on, you have entries like this:

    sub   rsa4096 2015-12-13 [E] [expires: 2025-12-10]
    sub   rsa4096 2017-10-21 [A] [expires: 2019-04-14]
    sub   rsa4096 2017-10-21 [S] [expires: 2019-04-14]

Each of those lines represents a subkey, with an explicit purpose. The first sub-key is for encryption/decryption of stuff, the second for authentication, and the third for signing.

The signing sub-key is what was generated on my Yubikey, and is used for signing stuff like email and Git commits. The authentication sub-key was _also_ generated on my Yubikey, and is what gets transformed into an SSH key.

So, each sub-key is a key in its own right. The only common things between them are that they are bound into the same GPG public key, and they are contained on the same physical device.

One important thing to note, though, is that the OpenPGP Card standard (which the Yubikey implements) has an optional flag, which requires the PIN every time you do a signature. So, for me, the authentication key is like a local agent-stored SSH key: You "unlock" it once, and then it works for a while before you have to re-enter the PIN. But for signing, I have to re-enter the PIN every time.

So yes, different activities, each with a key explicitly marked for that activity, with different policies as to how I can access it.

> With GPG, the only key that _has_ to be used for signing is the master key, the first key that appears in a user's key listing. For all other sub-keys, each key is explicitly marked as having a specific purpose.

Well it's only by-convention [0]:

> By convention, the top-level key provides signature services, and the subkeys provide encryption services.

[0]: https://tools.ietf.org/html/rfc4880#section-5.5.1.2

Personally I left the main key with Certify only (disabled Sign when creating the key with expert mode) and generated signing keys as subkeys.

> One important thing to note, though, is that the OpenPGP Card standard (which the Yubikey implements) has an optional flag, which requires the PIN every time you do a signature. So, for me, the authentication key is like a local agent-stored SSH key: You "unlock" it once, and then it works for a while before you have to re-enter the PIN. But for signing, I have to re-enter the PIN every time.

A middle ground for encryption and authentication keys is Yubico's touch-to-use [1], you enter your PIN once and then have to touch the token to use the key.

[1]: https://developers.yubico.com/PGP/Card_edit.html#_yubikey_4_...

Assuming your encryption subkey was also generated on the YubiKey, why did you not replace it as well?

My encryption subkey was explicitly _not_ generated inside the Yubikey. That was an intentional choice; I chose to sacrifice some security by generating the key in software and transferring it to the Yubikey, in exchange for the convenience of having the ability to do so again in the future. I made that choice because the encryption subkey is the one kind of subkey where I do not have full control over its use.

What I mean is (for people still getting into this PGP stuff), with the signing and authentication subkeys, I'm the one who is performing those actions (ignoring things like compromised keys). For encryption, the sender is the one who chooses which of the encryption subkeys to use, and there is no way for me to be sure that their copy of my public key is up-to-date.

(Totally off-the-rails side note: For anyone who works with Kerberos, and aliases/CNAMEs, you also have to deal with this problem, because it's the client who chooses exactly which service principal to request a ticket for.)

I know that my current encryption subkey isn't going to last forever, but I wanted to be able to use it on multiple "cards" (or in this case, a Yubikey).

> My encryption subkey was explicitly _not_ generated inside the Yubikey.

I figured that was the reason.

I use an offline master key and have separate [S,E,A] subkeys on my YubiKeys as well, although I generated them on a machine that is fairly well hardened and offline anyways -- mostly because I didn't want to risk losing them but also because I have multiple YubiKeys that I wanted to use them on.

For reference for other people this is called Key Escrow [0].

[0]: https://en.wikipedia.org/wiki/Key_escrow

I don't think it is exactly key escrow, because there is no third-party involved. I generated my own keys for my own use, and nobody has access to them (that I know of).

I know this might just be a semantic argument, but the Wikipedia article linked is a good example of how controversial proper key escrow (involving a third party) is.

If I'd refer people to a Wikipedia article, the article on Key Management (https://en.wikipedia.org/wiki/Key_management) might be a better one, as it is more general, and my blog post touches on many key management topics.

Okay, I hadn't followed that in your post. Thank you for clarifying.

Not really. In both cases you are merely attesting as to who you are.

If you want to get pedantic, yes. However, the intent of what you are doing is, in my mind, much different.

Logging into a system expresses the intent to run something there - you want to perform some actions as a result of authenticating - it's an active process.

Signing a document is about authenticating the document - it's something passive.