| Summary | Minimize lacking PGP forward secrecy with webmail |
| Queue | IMP |
| Queue Version | Git master |
| Type | Enhancement |
| State | Stalled |
| Priority | 1. Low |
| Owners | |
| Requester | libre (at) immerda (dot) ch |
| Created | 09/27/2007 (6439 days ago) |
| Due | |
| Updated | 11/13/2013 (4200 days ago) |
| Assigned | |
| Resolved | 11/13/2013 (4200 days ago) |
| Milestone | |
| Patch | No |
State ⇒ Stalled
Priority ⇒ 1. Low
Version ⇒ Git master
#7375. Simply put - it is impossible to generate revocationcertificates from within PHP. So that's not possible.
As such, it doesn't make much sense to not allow downloading of the
key after creation. It would be a giant PITA to generate the key and
forward to the keyserver, without the ability to alter this later.
It comes down to the amount of trust one has. If they are not
comfortable or are afraid of clickjacking, then don't use webmail to
send PGP messages. But clickjacking is just as much of a thread on a
console or an OS, so that can't be the controlling concern.
Queue ⇒ IMP
should be able to download it at least at that specific time to back
it up - and to get a warning then about losing it, etc. But otherwise
this seems reasonable to me. Any other thoughts/objections?
However it might be as well a good idea to give the possibility to
view/download a revocation certificate and/or send one to a keyserver
(like you can do it with your public key). otherwise there might be
the problem that people want to generate a new key, but can't revoke
the old one.
Priority ⇒ 2. Medium
State ⇒ Accepted
State ⇒ Feedback
be able to download it at least at that specific time to back it up -
and to get a warning then about losing it, etc. But otherwise this
seems reasonable to me. Any other thoughts/objections?
Priority ⇒ 3. High
Type ⇒ Enhancement
Summary ⇒ Minimize lacking PGP forward secrecy with webmail
Due ⇒ 09/28/2007
Queue ⇒ Horde Base
State ⇒ New
passphrase is known to an attacker, all prior and all future mails can
be decrypted if intercepted. Webmail applications are especially
vulnerable to keylogger (or looking over ones shoulders) attacks
because they are often used in insecure environments. Horde lets you
export the secret key thus one successfull attacks suffices to
compromise all prios and all future mails. I therefore suggest to omit
this "feature" (exporting of the secret key) in future versions.
I think, it is not really important for users to export their secret
key. If they wish to have a copy on their harddisk, they should have a
secure place anyway and thus probably have the possibility to generate
a key pair on this system and import it into Horde afterwards. If they
want to change to a local mailsystem, they should generate a new key
anyway if it was possible to export the key without their knowledge
beforehand.