4 ms·

Why would you have a shared SSH authentication key and PGP signing key? That just seems like a really silly idea, and leads to having to deal with situations l

Why would you have a shared SSH authentication key and PGP signing key? That just seems like a really silly idea, and leads to having to deal with situations like this. Logging into a system remotely is a much different activity than signing a file.

richardwhiuk 9y ago
Not really. In both cases you are merely attesting as to who you are.
- cuckcuckspruce 9y ago
  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.
CaliforniaKarl 9y ago
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.
- jlgaddis 9y ago
  Assuming your encryption subkey was also generated on the YubiKey, why did you not replace it as well?
  - CaliforniaKarl 9y ago
    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).
    - hdhzy 9y ago
      For reference for other people this is called Key Escrow [0]. [0]: https://en.wikipedia.org/wiki/Key_escrow https://en.wikipedia.org/wiki/Key_escrow
      - CaliforniaKarl 9y ago
        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 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.

richardwhiuk 9y ago

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

cuckcuckspruce 9y ago
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.

CaliforniaKarl 9y ago

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.

jlgaddis 9y ago
Assuming your encryption subkey was also generated on the YubiKey, why did you not replace it as well?
- CaliforniaKarl 9y ago
  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).
  - hdhzy 9y ago
    For reference for other people this is called Key Escrow [0]. [0]: https://en.wikipedia.org/wiki/Key_escrow https://en.wikipedia.org/wiki/Key_escrow
    - CaliforniaKarl 9y ago
      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 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.