Gpgtools GPG Keychain Access → 1.2b1

Comments and changes to this ticket

• 

  Support June 20th, 2014 @ 03:58 PM

  • State changed from “started” to “fixed”

  (from [cd4c97fc58cc4a581acce91b22064bff4f5dc7ae]) [NEW] Always create revocation certificate when a new key is created. [#244 state:fixed assigned:mento] https://github.com/GPGTools/GPGKeychainAccess/commit/cd4c97fc58cc4a...

• 

  steve June 20th, 2014 @ 11:45 PM

  • State changed from “fixed” to “started”

  Great! Remaining to-dos

  • add "Revoke" option to right-click menu
  • rename "Widerrufen..." to "Widerrufen ..." in top menu > Schlüssel (german localization)
  • add revoke warning message

  Title: Warning! You are about to revoke a key.
  
  Message: You are about to revoke the following key
  
  %&Name Mail KeyID
  
  If you revoke this key, you'll no longer be able to sign messages using that key and others will no longer be able to send you messages encrypted with your key. If you have previously uploaded your public key to the key servers, make sure to upload the revoked key (option is active by default), so others are made aware, that your key has been revoked.
  
  You will still be able to use your revoked key to decrypt mails and files that were previously encrypted with your key. That's why we recommend that you keep the revoked key in GPG Keychain Access.
  
  Are you sure you want to revoke this key?
  
  Cancle | Revoke Key
  
  German:
  
  Title: Achtung! Du bist dabei einen Schlüssel zu widerrufen.
  
  Message: Du bist dabei den Schlüssel
  
  %&Name mail KeyID
  
  zu widerrufen. Sobald der Schlüssel widerrufen ist, kannst du damit keine Nachrichten mehr signieren und andere werden dir keine Nachrichten mehr schicken können, die mit diesem Schlüssel verschlüsselt sind. Sofern du deinen öffentlichen Schlüssel auf einen Schlüsselserver geladen hast, stelle bitter sicher, den widerrufenen Schlüssel erneut auf den Schlüsselserver zu laden (per Voreinstellung aktiv), damit andere mitbekommen, dass der Schlüssel widerrufen wurde.
  
  Du kannst deinen widerrufenen Schlüssel weiterhin zum Entschlüsseln von Mails und Dateien verwenden, die bis jetzt mit deinem öffentlichen Schlüssel verschlüsselt wurden. Wir empfehlen daher den widerrufenen Schlüssel im GPG Schlüsselbund zu behalten.
  
  Willst du diesen Schlüssel widerrufen?
  
  Abbrechen | Schlüssel Widerrufen
  

• You flagged this item as spam.
  

  Mento June 22nd, 2014 @ 03:13 PM

  • State changed from “started” to “fixed”
• 

  steve June 22nd, 2014 @ 04:11 PM

  • State changed from “fixed” to “verified”
• 

  Support September 26th, 2014 @ 03:52 PM

  • State changed from “verified” to “fixed”

  (from [4cdb1eed5173d2342d33c578d18e59a83cb0148b]) [NEW] Always create revocation certificate when a new key is created. [#244 state:fixed assigned:mento] https://github.com/GPGTools/GPGKeychainAccess/commit/4cdb1eed5173d2...

• 

  steve September 27th, 2014 @ 10:00 PM

  • State changed from “fixed” to “verified”
• 

  steve May 26th, 2015 @ 01:30 PM

  • Importance changed from “Medium” to “High”
• 

  steve June 18th, 2015 @ 01:35 PM

  • State changed from “verified” to “released”

  [bulk edit]

• You flagged this item as spam.
  

  Ches Martin April 16th, 2016 @ 07:03 AM

  This caught my eye in the release notes and I looked to see how it works… It seems dangerous to me especially given that users are never informed in the UI that a revocation certificate has been generated automatically nor where it is located on disk (I see that #315 has been filed, but it's not complete and this is already shipped for some 6 months).

  Given that a revocation certificate should be carefully protected, I don't want them dumped on disk in the same place as private key data… If my laptop is stolen then a thief can potentially revoke my keys, invalidating the web of trust that I may have built over years, without even needing my passphrase.

  I don't keep my secret key on my laptop, so if I went to that trouble only to find out later that my key could be revoked anyway without access to my secret key or my passphrase—because of a file that was silently put on disk without my noticing—I'd be quite upset at GPGTools.

  Additionally, if these certificates fall into the hands of thief/assailant, they're readily armed with the ability to first revoke my keys and then issue new ones with my email addresses, making it appear much more like a legitimate key migration situation to the rest of the world. Keeping these on a laptop should not be encouraged.

  I know there are user login passwords and Unix file permissions; hopefully there is FileVault; I've seen #315 and #349; I can understand that this change probably alleviates a lot of support pressure… but still I feel this is unsafe and should not be default behavior with the current UX, or probably ever.

  What I would propose is something like #349, but not as a backup in addition to ~/.gnupg/RevCerts—instead make it the only copy saved. As #349 says, the dialog can explain and strongly stress putting it on safe external storage.

  Finally, thanks for all the work on GPGTools, I don't want this to sound critical without the least bit of gratitude :-)

• 

  Luke Le April 27th, 2016 @ 06:26 PM

  Hi Ches,

  thank you very much for your input.
  We absolutely understand your concern. This case is a good example for user experience vs. better security. From what we've learned over the years is, that a lot of users (users less familiar with gnupg) tend to mistakenly delete their secret keys and after that they have no way of telling the user that the key is lost or no longer in use. By automatically creating a revocation certificate, we're keeping an option open for them. Interestingly enough, with one of the latest updates, gnupg also started to automatically create revocation certificates when creating a key.

  We've written a draft on how to handle this in the future which you can find here:
  https://gpgtools.lighthouseapp.com/projects/65684/tickets/367-infor...

  The approach will be to inform the user that the certificate has been created and urge them to move it onto an external medium. In addition, periodically remind them to move the revocation certificate, if any are still found in their .gnupg folder.

  We'd be happy to hear your input on the new approach.

  We're still not sure however, if not creating the revocation certificate at all is the right way to go.

• You flagged this item as spam.
  

  Ches Martin May 6th, 2016 @ 01:08 PM

  Thanks for your response Luke, sorry for the slow reply, I overlooked that commenting didn't make me automatically watch the ticket for new activity.

  I think #367 looks like a positive direction (note: it runs counter in spirit to #315, for the better IMO)—I may not have been clear on this point in my previous comment, but I don't at all feel that automatically generating a revocation certificate is a fundamentally bad idea, it's just the UX in the current implementation that I feel is dangerous. That there is basically no indication at all that one has been generated (or what it is either), and it's stored in a hidden directory where the user is very unlikely to ever notice. #367 is addressing these points directly.

  I'll move my watching/discussion over to that ticket since this one is closed. Objective C and OS X APIs aren't right in my wheelhouse, but maybe I can contribute substantively at some point in the future…