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

Validation fails for keys with non-standard subkey layouts #11

Open
garrettr opened this issue Jan 22, 2016 · 1 comment
Open

Validation fails for keys with non-standard subkey layouts #11

garrettr opened this issue Jan 22, 2016 · 1 comment
Labels

Comments

@garrettr
Copy link

redmine_openpgp validates signed messages, and then checks that the signature was made by the key corresponding to the sender. In lib/decrypt_mails.rb:

# compare identity of signature with sender
      if valid
        valid = false
        sender_email = email.from.to_a.first.to_s.strip
        user = User.find_by_mail sender_email if sender_email.present?
        key = Pgpkey.find_by user_id: user.id
        signatures.each do |s|
          valid = true if key.fpr == s.fpr
        end if not signatures.empty?
      end

This works for most but not _all GPG keys. By default, when GPG creates a new key, it actually creates two subkeys: one for certification (signing other keys, including your own subkeys) and signing (signing data), and one for encryption. Because the certification and the signing subkey are the same, the check valid = true if key.fpr == s.fpr works: the certify subkey (from which the key's fingerprint is derived) and the signing subkey are the same.

However, it is possible to use a different subkey layout for your GPG keys. A common alternative is to have separate subkeys for all capabilities: separate and dedicated keys for certification, signatures, encryption, and authentication. This is commonly seen among users of GPG smartcards, who often put their "every-day usage" (for signing and encrypting data, and authenticating) subkeys on one smartcard, but store their certification key elsewhere, and only bring it out when they want to sign other's keys.

This provides a security benefit: if one's "every-day" subkeys are lost or compromised, they can be rotated, signed with the same certify subkey. This allows you to maintain your position in the web of trust (since when you sign a key, you sign its certify key with your certify key) while rotating your potentially compromised subkeys.

The issue here is that the certification and signing subkey are different, so the check comparing the key.fpr (the fingerprint of the certify subkey) to the s.fpr (the fingerprint of the signing subkey) no longer works. The email is still validly signed, but redmine_openpgp will fail to detect this, and will erroneously reject it if "Valid signature only" is enabled.

garrettr added a commit to garrettr/redmine_openpgp that referenced this issue Jan 22, 2016
Fixes C3S#11.

This commit has some additional debug logging that should be removed
before it is submitted for merge.
garrettr added a commit to garrettr/redmine_openpgp that referenced this issue Jan 22, 2016
Fixes C3S#11.

This commit has some additional debug logging that should be removed
before it is submitted for merge.
garrettr added a commit to garrettr/redmine_openpgp that referenced this issue Jan 22, 2016
Fixes C3S#11.

This commit has some additional debug logging that should be removed
before it is submitted for merge.
garrettr added a commit to garrettr/redmine_openpgp that referenced this issue Jan 22, 2016
garrettr added a commit to garrettr/redmine_openpgp that referenced this issue Jan 22, 2016
@timegrid timegrid added the bug label Mar 17, 2017
@timegrid
Copy link
Member

I see, thanks for clarification. As I understand, this issue is resolved with your pull request, which seems fine at first glance. I'll do some further testing and will try to catch up with your fork next month.

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

No branches or pull requests

2 participants