Set gpg login attribute as separate argument instead of $IDENTITY

[jbagnara]

Followup from #529

ISSUE

brief - the README instructs the user to populate a pgp attribute with possible PII without indicating that this field is public.

Suppose a user wants to generate subkeys for pgp encryption/decryption using subkeys and upload those public keys to a public repository. They set up their yubikey by running export IDENTITY="YubiKey User <yubikey@example.domain>" with their public email so it's easy to look up. This subkey will be different than the keys stored on the yubikey. After initial setup, the $IDENTITY field is not accessible from the card itself on an unauthorized system.

This guide indicates that the user MUST set the login field in order to use subkeys. The problem is that the guide defaults this paramater to use $IDENTITY, which in this example contains the user's name and email address. This enables anybody with physical access to the card to pull the name and email of the individual. Below is the printout from gpg --card-status with my yubikey connected without any prior authentication through the pgp subsystem. This is using a live debian disk:

The "Login data" field is displayed. (I set this to "N/A", but following the guide as it's written, this will display "YubiKey User yubikey@example.domain", or whatever name and email the user filled in.

Unless I am mistaken, with no other context, this pgp parameter is the only PII attribute on the card thats accessible without any authentication. In the case that the key is lost, anyone who finds the key can identify the owner. This is an unneccessary security risk. Please let me know if i'm wrong or my understanding of the expectation of privacy using the pgp subsystem is incorrect.

Changes

• Change the default value for the pgp login attribute to be "My Cool YubiKey - 2025"
• Add a disclaimer to the user regarding the described issue
• Add a hyperlink to the (very brief) explanation of the pgp login attribute

[drduh]

The disclaimer is prudent, however I think we should not include an explicit step to set a new GPG_LOGIN_ATTR variable; the disclaimer could instead instruct setting IDENTITY to a different, non-attributable value since it is the final use. What do you think?

[jbagnara]

Currently the disclaimer recommends that the user set this field to a non-attributable value. I think that the behavior of the script should the consistent with the disclaimer's recommendation. I'd prefer to err on caution and make the script not not use IDENTITY, in which case an explicit step for setting GPG_LOGIN_ATTR is warranted since coming up with a new name for this field is an action the user needs to take.

However if we do still want this value to default to IDENTITY, we could combine the two steps. Since IDENTITY gets referenced later in the doc, instead of setting it to a new value we could combine the two steps but keep the new variable, and have the disclaimer suggest changing GPG_LOGIN_ATTR:

export GPG_LOGIN_ATTR=$IDENTITY

gpg --command-fd=0 --pinentry-mode=loopback --edit-card <<EOF
admin
login
$GPG_LOGIN_ATTR
$ADMIN_PIN
quit
EOF

Which is your preference?