Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pius fails to sign User IDs that have no e-mail address #109

Open
dkg opened this issue Jan 19, 2019 · 3 comments
Open

pius fails to sign User IDs that have no e-mail address #109

dkg opened this issue Jan 19, 2019 · 3 comments
Assignees

Comments

@dkg
Copy link

@dkg dkg commented Jan 19, 2019

some keys, like 25FC1614B8F87B52FF2F99B962AF4031C82E0039, have a user ID that has no e-mail address.

If the user indicates that they intend to certify that user ID, its certification should be attached to any other certification that can be sent -- so the certifications are sent in tandem.

So for example, if an OpenPGP certificate looks like:

uid 0: Alice Jones
uid 1: Alice Jones <alice@example.net>
uid 2: Alice Jones (CEO) <boss@example.biz>

then the e-mail that goes to alice@example.net should contain the certification for User IDs 0 and 1, and the e-mail that goes to boss@example.biz should contain the certification for User IDs 0 and 2.

That way, if the recipient gets any of the e-mails, they can see a certification over the user ID that has no e-mail address.

(this is how caff treats this kind of User ID, as well as how it treats User Attributes (attached photos), fwiw -- i've raised an issue about how pius deals with User Attributes in #110)

@jaymzh
Copy link
Owner

@jaymzh jaymzh commented Feb 9, 2019

That would be a security issue for sure. If I have a key like:

UID 0: Bill Clinton
UID 1: Alice Jones <me@example.net>

And I use your proposed algorithm, the user now validates that this individual is Bill Clinton. Now, granted, one should look down the list of all UIDs before signing, but I think this behavior would be super misleading.

It is an interesting question on how to handle this though. I'm thinking something like an extra prompt. Something like:

$ pius -r /tmp/keyring.gpg --include-no-email-uids -A
pub   rsa4096/A123B456C789D123 ...
         Key fingerprint = ....
uid 0: Alice Jones
uid 1: Alice Jones <alice@example.net>
uid 2: Alice Jones (CEO) <boss@example.biz>

Have you verified this user/key, and if so, what level do you want to sign at?
  0-3, Show again, Next, Help, or Quit? [0|1|2|3|s|n|h|q] (default: n) 3

This key has a UID with no email address (UID 0: Alice Jones). How would you like to handle this:
  (I)gnore this UID, Send it to an (a)lternate UIDs email? [i|a] (default: i) a

Please select where you'd like the signature to go:
  (1) Alice Jones <alice@example.net> (UID 1)
  (2) Alice Jones (CEO) <boss@example.biz> (UID 2)

[1|2|s|q] (default: s) 1

Signing all UIDs on key A123B456C789D123
  There are 3 UIDs on this key to sign
  UID 1 (Alice Jones): signed, emailed to Alice Jones <alice@example.net>
  UID 2 (alice@example.net): signed, emailed
  UID 3 (boss@example.biz): signed, emailed

$

We could do the same thing for photo UIDs...

@jaymzh jaymzh self-assigned this Feb 9, 2019
@ghost
Copy link

@ghost ghost commented Mar 5, 2019

Another solution is to save the unsent sig to a separate directory (suggested in
#126) so at least it's not too hard to find the sig for manual processing.

As for the interactive approach, you could also give the option to post directly to the key server.

Regarding the security issue, the user should ultimately be in control. But indeed the UI shouldn't make it easy to accidentally sign a dodgy key. I think it's quite common for UID's without email to contain strictly a full name that's often an exact match of a prefix of another UID. If pius encounters that trivial case it would be safe to do what the OP suggests automatically without nagging the user. Note that the user is going to skip the whole key if there's a stark difference in names.

(edit)

Maybe this is persnickety but I should also mention the error message says "No email for Bob, cannot send key." While it's a correct statement, the key is not the significant thing that's being sent and could confuse novices. I would phrase it as "cannot send signature" or "cannot send signed key".

@dkg
Copy link
Author

@dkg dkg commented Mar 6, 2019

I agree that there are some security issues involved here, thanks for calling (at least one of) them out, @jaymzh !

I like @libBletchley 's idea about pius being clever about noticing when the human name matches a certificate that you're planning to sign already, and just doing the right thing there.

so that would leave what to do about handling a non-matching e-mail address-less User ID, and how to be sure that the user is ok with signing it. One approach would be to ask the user to type in the name they intend to certify (or hit enter to not certify it at all). Users who know what they want can just copy-and-paste the relevant line, and users who don't know what they want can just hit enter to ignore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants