Why a full keys and sub keys backup are not proposed when keys and sub keys are done on-card ?
Hi, Just for information, I wanted to known why you don't propose a full backup of the three keys (Sign, encryption and authentication) when keys are generated on-card. Because only encryption key is backupted, a good idea will be perhaps to add also authentication key in the backup. Thanks for more information about it. Best Regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why a full keys and sub keys backup are not proposed when keys and sub keys are done on-card ?
On Sun, 27 Sep 2009 09:38, tux.tsn...@free.fr said: Just for information, I wanted to known why you don't propose a full backup of the three keys (Sign, encryption and authentication) when keys are generated on-card. Because only encryption key is backupted, a good idea will be perhaps to add also authentication key in the backup. A lost of a signing or authentication key is usually not that problematic. You can simply create a new one and use it from then on. If you don't have access to the decryption key anymore you won't be able to decrypt any of the data you decrypted in the past to that key. Thus some kind of recovery is in most cases very useful. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Why a full keys and sub keys backup are not proposed when keys and sub keys are done on-card ?
Hi Werner, Thanks for your answer, I'm agree with you for sign key, but for the authentication key, if it's used to ssh server connection on more than 100 servers for the user root for example, if you lost this key, you cannot more connect on server with the user root. In this case, I think it will be a big problematic. It's for that than I suggested to add the authentication key, but it's just a suggestion. Best Regards - Mail Original - De: Werner Koch w...@gnupg.org À: tux tsndcb tux.tsn...@free.fr Cc: gnupg-users@gnupg.org Envoyé: Dimanche 27 Septembre 2009 13h09:36 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: Why a full keys and sub keys backup are not proposed when keys and sub keys are done on-card ? On Sun, 27 Sep 2009 09:38, tux.tsn...@free.fr said: Just for information, I wanted to known why you don't propose a full backup of the three keys (Sign, encryption and authentication) when keys are generated on-card. Because only encryption key is backupted, a good idea will be perhaps to add also authentication key in the backup. A lost of a signing or authentication key is usually not that problematic. You can simply create a new one and use it from then on. If you don't have access to the decryption key anymore you won't be able to decrypt any of the data you decrypted in the past to that key. Thus some kind of recovery is in most cases very useful. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On 09/25/2009 02:40 PM, Ingo Klöcker wrote: 0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo Klöcker went to the same school and the same university as I did.) 0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99, 0xAFA03822, 0x91190EF9 (this last one is definitely still in use) ok, thanks, those are not expired, though i only see non-unicode in three of them: 104B0FAF and F661F608, and 91190EF9. Those keyholders should probably create a new User ID that *is* UTF-8, with the same e-mail address as the non-UTF-8 one, and encourage the people who have certified the old User ID to re-certify the new one. Once enough certifications are through on the new, valid one, they can revoke the old one and move forward with a fully OpenPGP-compliant key. True. Actually, I lied about KMail using key IDs. Since about 6.5 years KMail uses gpgme and leaves all of those hairy details (like telling gpg what keys to use) to this library. This seems like a reasonable stance for authors of MUAs and Plugins to use. Werner, it looks like you're the upstream author on GpgME; does GpgME do any different selection technique than GPG? I don't see why harmless changes (see David's example) shouldn't be ignored. If the user hard-coded the key Alice1, then what's wrong with using this key as long as it's valid. Obviously, any changes making a hard-coded key invalid need to be escalated and such a key must not be used anymore by the MUA. If the user hard-coded a specific key (by fingerprint) to the Alice User ID, then of course GPG should respect that preference (and it should emit warnings if the key ever becomes invalid), but i don't think that users should be asked to make permanent choices like this, since they might become invalidated by future circumstances; how will they know that another (maybe better) choice is available, or should be made? If for some email address multiple matching valid keys are found by KMail (or rather gpgme) then KMail asks the user which key(s) to use (and then remembers the user's choice). This transparency gives me a better feeling than some automagic behind-my-back key selection based on user ID/email address. I hear what you're saying, but i think there are two problems with it: 0) for many users, they are being asked to make a choice that they don't understand; there are few things more frustrating than this. If the tool *can* make a good choice based on the knowledge available to it, it shouldn't need to pester the user, who may or may not have as much understanding of the problem space. 1) users are being asked to make an effectively permanent decision, even though relevant circumstances may change in the future. Presumably, this binding will produce warnings (with the option to change the binding) if the bound key suddenly actually drops into unknown calculated validity (for example, if you decide to revoke ownertrust on a relevant intermediary; has this been tested?) But there might be other changes that make this selection suboptimal without causing it to throw warnings. so i'm not a big fan of prompting users to hardcode bindings in general (though i certainly support allowing users to hardcode bindings if they prefer) --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Joachim Blomberg/VRD/VR-GRUPPE ist außer Haus.
Ich werde ab 28.09.2009 nicht im Büro sein. Ich kehre zurück am 02.10.2009. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. In dringenden Fällen bin auf meinm Dienst-Handy erreichbar . ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
