(OT) encrypting to expired certificates
On 17/09/14 22:46, michaelquig...@theway.org wrote: The discussion has been most entertaining and enlightening. And to think I blew a gasket because I grossly misinterpreted this sentence: As a farm kid, the answer is a resounding yes, and you should be thanking me. Which I interpreted as that /I/ should throw out food that's past its expiration date. And that I should thank Robert for showing me the error of my ways, which is the part that got me fuming. And was a completely wrong interpretation! Well, people, you are welcome for the entertainment! I hope I actually made a few good points as well :). Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (OT) encrypting to expired certificates
And to think I blew a gasket because I grossly misinterpreted this sentence: To clarify: I think that the body politic should thank producers of food for being willing to throw away food (and thus, profit) in the interests of preserving the safety of the public's food supply. That's all. The reason why I find the metaphor appropriate for GnuPG is because it highlights the different responsibilities producers have versus consumers. A producer is expected to provide product (food, encrypted communications, whatever) that exceeds the standard of the consumer. Similarly, the use case of I forgot to add a new expiration date on my own key is different from the use case of my correspondent forgot to add a new expiration date on his key. These two use cases revolve around policy, not mechanism. In the former, whether you want to hack up the system time to get around the expiration issue is wholly your lookout -- whatever policy one decides, I neither get to judge it nor comment on it. In the latter, I get to say, I cannot imagine a world where this makes sense. The certificate has expired; don't use it. Again, producers are -- must be -- held to a higher standard than consumers. Peter, I hope this makes my feelings on the matter clear. It was not my intent to tell you how to run your refrigerator, or that you are somehow doing it incorrectly. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Wed, 17 Sep 2014 03:57, 2014-667rhzu3dc-lists-gro...@riseup.net said: gpg: Invalid option --faked-system-time 1.4.18 and 2.0.26 (on Windows) both give me that error. Might be - I have not used 2.0 for years. GPGSM has this option, though. Users with very advanced requests are expected to use a very advanced version (2.1-beta) .-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 17/09/14 03:16, Werner Koch wrote: ... and the 2400 other subscribers are having a bag of popcorn while watching the discussion. scnr, Had to look that one up. I suppose Sorry could not resist[1]. I don't mind. The bit best watched with a bag of popcorn wasn't very much about GnuPG though. All I really wanted was an apology for 'a resounding [...] you should be thanking me.' and an apology for misrepresenting my words by very selectively quoting. Too bad that seemed out of reach. Peter. [1] Although Signal to Coherent Noise Ratio seems rather appropriate in the discussion as well. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Wed, 17 Sep 2014 11:21, pe...@digitalbrains.com said: Had to look that one up. I suppose Sorry could not resist[1]. I don't mind. I was not aware that some of the old usenet terms are out of fashion today. [1] Although Signal to Coherent Noise Ratio seems rather appropriate in the discussion as well. Indeed Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/17/2014 at 4:25 AM, Werner Koch w...@gnupg.org wrote: Users with very advanced requests are expected to use a very advanced version (2.1-beta) .-) = Seems to need a 'very advanced' downloading too ;-) Could not find 2.1-beta on the GnuPG download page. Where is it available? TIA, vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Wed, 17 Sep 2014 19:31, ved...@nym.hush.com said: Seems to need a 'very advanced' downloading too ;-) $ lftp ftp.gnupg.org lftp ftp.gnupg.org:~ cd gcrypt cd ok, cwd=/gcrypt lftp ftp.gnupg.org:/gcrypt cd gnupg cd ok, cwd=/gcrypt/gnupg lftp ftp.gnupg.org:/gcrypt/gnupg cd unstable cd ok, cwd=/gcrypt/gnupg/unstable lftp ftp.gnupg.org:/gcrypt/gnupg/unstable ls total 0 -rw-r--r-- 1 1000 1000 265 Oct 26 2010 README -rw-r--r-- 1 1000 1000 2934302 Jun 5 17:08 gnupg-2.1.0-beta442.tar.bz2 -rw-r--r-- 1 1000 1000 286 Jun 5 17:08 gnupg-2.1.0-beta442.tar.bz2.sig -rw-r--r-- 1 1000 1000 3078612 Jul 3 11:55 gnupg-2.1.0-beta751.tar.bz2 -rw-r--r-- 1 1000 1000 287 Jul 3 11:55 gnupg-2.1.0-beta751.tar.bz2.sig -rw-r--r-- 1 1000 1000 3095003 Aug 14 17:33 gnupg-2.1.0-beta783.tar.bz2 -rw-r--r-- 1 1000 1000 287 Aug 14 17:33 gnupg-2.1.0-beta783.tar.bz2.sig -rw-r--r-- 1 1000 1000 2529923 Oct 26 2010 gnupg-2.1.0beta1.tar.bz2 -rw-r--r-- 1 1000 1000 158 Oct 26 2010 gnupg-2.1.0beta1.tar.bz2.sig -rw-r--r-- 1 1000 701 2527999 Mar 8 2011 gnupg-2.1.0beta2.tar.bz2 -rw-r--r-- 1 1000 701 287 Mar 8 2011 gnupg-2.1.0beta2.tar.bz2.sig -rw-r--r-- 1 1000 1000 2594988 Dec 20 2011 gnupg-2.1.0beta3.tar.bz2 -rw-r--r-- 1 1000 1000 287 Dec 20 2011 gnupg-2.1.0beta3.tar.bz2.sig -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 16 September 2014 at 11:03:29 PM, in mid:5418b3b1.4010...@dougbarton.us, Doug Barton wrote: When you get into the edit-key menu you can do 'uid *' (or specifically select the uids you want to update, if not all). Then update the expiry. Do key UIDs have an expiry date? I never noticed that. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net To know what we know, and know what we do not know, is wisdom. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlQZ5yVXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p2vsD/R5PsAnhYdi+uj5piOoZQ7BjYo1L2ga40jDa WZylOfdjuZ0gonS4dKkh0xFG/b62hu9/PUQnwju+A5aMLyNgjWN7HaGrhX22xC5e dRf2FyRomeAhShiKdQLjvs7JtKsiAGYPH6IBnln2fELfVyXcO62N50YC8LxXBmbO cxBailQ9 =5CUt -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Mi 17.09.2014, 20:54:22 schrieb MFPA: Do key UIDs have an expiry date? I never noticed that. The mainkey expiration date is implemented via the UID expiration date. This is because you need a signature and the mainkey itself doesn't have one. The mainkey expires if all UIDs have expired. Thus usually all UIDs have the same expiration date. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Gnupg-users gnupg-users-boun...@gnupg.org wrote on 09/16/2014 09:55:18 PM: - Message from Werner Koch w...@gnupg.org on Wed, 17 Sep 2014 03:16:29 +0200 - ... and the 2400 other subscribers are having a bag of popcorn while watching the discussion. That's me--although I've had to settle for pretzels and chips as I haven't had time to make popcorn. The discussion has been most entertaining and enlightening. Both sides have valid points. I believe no software will ever do everything everyone wants. (I know mine doesn't.) I, too, get passionate about my thoughts at times. Then I simply try to remind myself it's software and generally not a life-and-death matter. (Although I understand problems with encryption could be far more harmful to some folks than me.)___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Sep 17, 2014, at 3:54 PM, MFPA 2014-667rhzu3dc-lists-gro...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 16 September 2014 at 11:03:29 PM, in mid:5418b3b1.4010...@dougbarton.us, Doug Barton wrote: When you get into the edit-key menu you can do 'uid *' (or specifically select the uids you want to update, if not all). Then update the expiry. Do key UIDs have an expiry date? I never noticed that. Both keys and UIDs can have expiration dates in OpenPGP. Though both date fields live on the UID self-sig, they're not the same thing and aren't necessarily set to the same value. GnuPG, like most OpenPGP clients, only really implements key expiration, though it should properly honor a UID expiration if someone generates it elsewhere. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 15/09/14 21:56, Robert J. Hansen wrote: From the plain meaning of the word, expiration. There's a half-finished liter of milk in my fridge that's now a week past its expiration date. (Yes, yes, I'm going to throw it out once I get home...) If you want, feel free to come by. I'll pour you a glass of milk. After all, an expiration date doesn't mean don't use this, right? It's only a number that's to be interpreted according to however someone wants. Sure! A week might be a bit much, but if it were 3 or 4 days I'd agree. Starting from slightly before the expiration date to well past, I simply sniff it, pour out a little, look if it is curdling... and if none of those things apply, I happily pour myself some perfect moo juice. A bloody shame to throw it away. You really throw out perfectly good food? Just because someone said well, given our process variations, even the worst piece, even the milk produced on a hot day and picked up a bit late, would still be okay for one and a half week. To cover our asses, let's say we warrant it for a week? In the cases you made, I think GnuPG would be improved by removing those options. This argument really isn't a winner. Your milk argument is worse. It advocates wasting food, and food is a scarce resource. But the argument that if someone /knows/ the expired key is actually good, he or she should be free to override it, makes a lot of sense to me. Also, I see a tendency to replace: This key is valid until X with: This key is invalid after X Those are not equivalent. You might decide that is how you wish to interpret it, but I don't see that interpretation mandated anywhere, and it's certainly not the only reasonable interpretation. David Shaw wrote it as: 5.2.3.6 defines it as the validity period of the key. In other words, after that specified time has elapsed, the key is not valid. I disagree. It says that something is true up to a certain point, it doesn't say it's false afterwards. Otherwise, extending the expiration date would conflict with the old expiration date in a very strict interpretation. Revocations do work like this: it's final. Also, RFC's try to be very explicit. If a term is only named, you can't draw conclusions from meaning just from a common interpretation of the name. I'm pretty darn sure a key is only ever used with a lock, not with another key. Still, we decided to name the thing key, in straight defiance of common knowledge that you need a lock for a key to be a useful thing. But if you wish to infer meaning from a name anyway, I think an expiration date on food makes perfect sense to infer the opposite of what David is arguing. I interpret it as the date up till which the producer guarantees I can eat or drink it, providing proper storage. After that, I need to use my own nose and common sense to see if it's still okay. I think Hauke makes a pretty good case, although I disagree with the slight titbit: That is an offline mainkey and he is probably not capable (or willing) to extend the validity period. If he's not willing to extend the validity period, he doesn't seem to care enough, just send him plaintext already. Not capable, as in, there are more important things he needs to do first before he has time to get out his offline key, I would accept that. But not willing to extend? His problem, not mine. I won't make extra effort then either. But that doesn't diminish his other good arguments. I support inclusion of an override of the expiration date. Interpretation of key expiration is policy, not technical or mandated by RFC (AFAIK). Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 16/09/14 02:12, Robert J. Hansen wrote: If you can find half a dozen *real users* who are being *really impacted* by this, I'd love to hear about them. I wanted to encrypt a document to myself on an offline system[1]. However, that copy of my own key was expired, and it wouldn't do it. I was in a bit of a hurry, trying to get things done. Now, I had to get a USB drive, start another computer, export my updated key, and import it on the offline system. If I had --expert followed by yes to an Are you sure? prompt, I would have done that and updated the copy when I had more time. Together with Hauke and his correspondent with the offline main key, you now already have two actual cases, taken from real situations that actually happened. At this rate, we'll be done this week. But so far, all the discussion is so hypothetical that it's hard for me to take it seriously. I was slightly baffled by this comment as Hauke actually gave an example that happened in real life. That is a lot more than I usually see when people argue for or against a feature. You can't argue that these aren't real users. You can't argue it's not a real impact. You can only argue that the impact isn't that big. But that is a long shot from so hypothetical it's hard to take seriously. I don't understand where that came from. Peter. [1] This in the interest of security. You dislike the word, so it's in a footnote to make it less offensive to you ;). -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am 16.09.2014 um 12:13 schrieb Peter Lebbing: On 15/09/14 21:56, Robert J. Hansen wrote: From the plain meaning of the word, expiration. There's a half-finished liter of milk in my fridge that's now a week past its expiration date. (Yes, yes, I'm going to throw it out once I get home...) If you want, feel free to come by. I'll pour you a glass of milk. After all, an expiration date doesn't mean don't use this, right? It's only a number that's to be interpreted according to however someone wants. Sure! A week might be a bit much, but if it were 3 or 4 days I'd agree. Starting from slightly before the expiration date to well past, I simply sniff it, pour out a little, look if it is curdling... and if none of those things apply, I happily pour myself some perfect moo juice. A bloody shame to throw it away. You really throw out perfectly good food? Just because someone said well, given our process variations, even the worst piece, even the milk produced on a hot day and picked up a bit late, would still be okay for one and a half week. To cover our asses, let's say we warrant it for a week? Just as a side node. The usage of this example is a little unlucky because it has so many traps based on cultural differences. I saw that discussion coming when I read it. In Germany on food products you will find the word Expiration Date which literally means: Don't eat me after that date. But there is a discussion to change that because what they are actually meaning in this context is: I won't change my shape, taste and rigidity till that date. So I guess, people with such a background are a little more open to the interpretation of that phrase. But as far as I know, in the US it says Best before to avoid that confusion and make clear that this product is probably still good, some time after that date. And I think the same confusion is going on with respect to the expiration date in our context. And I am all for not overloading the meaning of words, so if I read expiration date than for me this is a dead line. If you mean best before than I would prefer if people say it like this. Martin ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 16/09/14 12:52, Martin Behrendt wrote: But as far as I know, in the US it says Best before to avoid that confusion and make clear that this product is probably still good, some time after that date. In the Netherlands, we have both. Expiration means the food might be spoiled and you could get sick if you eat it. Best before means it might taste less, or have a different texture, simply: it won't be the same quality. So I'm aware of the difference. Milk definitely has an expiration date. I happily use it beyond that, when it looks good. It's a reasonably apt comparison because it is easy to judge if milk is still good, just like you can confirm out of band that a key is still good. I'm fully aware that normally, a key shouldn't be used beyond it's expiration. But there can be perfectly good reasons to use it anyway, unlike a revoked key. Just like you can send an e-mail encrypted to a key that doesn't bear that e-mail address in it's UID's, because you know the recipient actually has more e-mail addresses than UID's. This example was, to my surprise, mentioned in this thread as something you shouldn't be allowed to do either. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 09/16/2014 06:45 AM, Peter Lebbing wrote: On 16/09/14 02:12, Robert J. Hansen wrote: If you can find half a dozen *real users* who are being *really impacted* by this, I'd love to hear about them. I wanted to encrypt a document to myself on an offline system[1]. However, that copy of my own key was expired, and it wouldn't do it. I was in a bit of a hurry, trying to get things done. Now, I had to get a USB drive, start another computer, export my updated key, and import it on the offline system. If I had --expert followed by yes to an Are you sure? prompt, I would have done that and updated the copy when I had more time. I've been in a situation where i'm sitting with a friend, talking about a project we're hoping to work on together, and i wanted to send them confidential information about the project to read later. I know they have an OpenPGP cert, so i fire up an e-mail, only to discover that their cert is expired (they don't use it often, and hadn't noticed). I point it out to them, they blush and say yeah, that's on my laptop, which is fine, but it's at home. I'll update the expiration date when i get home. Now i have to wait for that to happen, for them to publish the update, for it to propagate on the keyserver network, for me to fetch it, and then finally i can send the mail. A dangerous flaw? no. But it's one of the thousand papercuts that make it more difficult to use the system than it needs to be. That's three real-world use cases now. And i've got another one (this one from last week, actually): A friend asked me for an introduction to another friend about an employment issue. Both have OpenPGP keys. One of them was expired. I contacted the friend with the expired key via other (admittedly insecure) means and had a chat about the expired key, which they promised to put on their stack of things to do, but they couldn't get to right away (i don't know the details about why they couldn't drop everything else they were doing and update their expiration, but hey, people have things they need to work on, and for many people, just looking up how to extend the expiration date is a major context switch from their regular work). But the introduction seemed like it was time-sensitive, and needed to go out, so i went ahead and made the introduction in the clear, since i couldn't encrypt the message to both parties. If i could have encrypted to the expired key, i would happily have done that. Instead, I sent the message in the clear. Of course, i had some other options: i could have mailed an encrypted message to the requester with the other contact's info, and then mailed a cleartext introduction to the one with the expired key; that would have reduced some of the cleartext traffic, at the cost of a more complicated e-mail setup (and broken threading on the eventual replies between the two of them). I could have waited until whatever was blocking the expiration date got cleared up, and then made the introduction. I could have nagged hard to encourage them to update their expiration date. I could have done a little training about how to do it so that they were sufficiently annoyed at the interruption in their work that they just copy/pasted the commands i told them to run without thinking about it just to get me to stop. Maybe some of these choices would have been better than what i ended up doing. But again, a thousand papercuts. So that's four real-world use cases where the ability to override would have meant easier or more confidential communication. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Can anyone explain to me why one would want to continue using a key and yet not simply change the expiry date? I really find all of the examples being given to be incredibly contrived. It takes no time at all these days to change the date and distribute the new key. As I've said, if the tools to do this kind of thing easily do not exist, they need to be created. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Sure! A week might be a bit much, but if it were 3 or 4 days I'd agree. Yes, and this is reasonable. My example was against what I saw as Hauke's overly broad expiration dates don't mean anything except what you project onto them. No, expiration dates *do* mean something, and you've agreed with me here. :) A bloody shame to throw it away. You really throw out perfectly good food? As a farm kid, the answer is a resounding yes, and you should be thanking me. We raise cattle on my family farm (as well as soybeans, corn, and the like). We've never had a case of Mad Cow, but my family has decided what we'll do if we get such a steer: we'll take the financial hit involved in putting the entire herd down. Sure, 99% of the cattle would be healthy... but we're not willing to take that risk with the food supply. And I think you should be thanking your food providers that we are willing to throw out perfectly good food, simply because we cannot *prove* that it is perfectly good food. American, European and Australian food supplies are the safest in the world precisely because we throw away so much good food. Can we prove that the food is safe? No? Then we get rid of it. There's a subtlety there that I think you're missing. Just because something is good doesn't necessarily mean you can prove that it's good... but knowing you *can't* prove that it's good is still enough to tell you what to do. But the argument that if someone /knows/ the expired key is actually good, he or she should be free to override it, makes a lot of sense to me. It doesn't to me. You're only looking at half the risk-versus-reward equation -- more accurately, you're only looking at the reward half. Reward: A small number of users who currently have to jump through hoops to use expired certificates will be able to do so more easily. Risk: A large number of users may wind up, through accident, error, or misadventure, disabling expiration checks on certificates. If you truly need to do this, then I'm just fine with making you jump through hoops if it means not providing casual users with a pistol that's conveniently pre-loaded and pre-aimed at their head. Also, I see a tendency to replace: This key is valid until X with: This key is invalid after X Those are not equivalent. Correct, but this is sort of quibbling. The most accurate would be, There is no assurance this certificate is valid, since we are past X in time. Therefore, I will treat it as invalid until the certificate owner makes a new assurance. While I agree that I will treat this certificate as invalid is a different thing from this certificate is invalid, in practice there's not much difference. I disagree. It says that something is true up to a certain point, it doesn't say it's false afterwards. True but irrelevant. I have a smoke detector that uses alien technology to tell me if my house is on fire. My Zarbnulaxian smoke detector (which I picked up at a Zarbnulaxian Best Buy the last time they kidnapped me; next time I'm on Zarbnulax I'm going to grab one of their quantum computers!) doesn't detect smoke -- it determines the truth or falsity of statements, subject to a certain low .01% error rate. It will sometimes certify a true statement as being false, but it will never certify a false statement as being true. I started off by programming it to test the truth of the statement, My apartment is on fire. As long as it tells me The statement 'my apartment is on fire' is false, then I can be confident my house isn't on fire. Unfortunately, one night my apartment caught fire. That made the statement true, and my smoke detector sometimes certifies true statements as false... so it continued to tell me, The statement 'my apartment is on fire' is false. I barely got out with my life (and my Zarbnulaxian technology). So in my new apartment, I set up my Zarbnulaxian smoke detector to test the truth of the statement, My apartment is not on fire. This statement is usually true, and that means sometimes it tells me (incorrectly), The statement 'my apartment is not on fire' is false. These false alarms are really annoying, but I also know my Zarbnulaxian smoke detector will *never* fail to detect a fire. After all, if the statement 'my apartment is not on fire' is false, the Zarbnulaxian smoke detector is incapable of erroneously reporting it as true. The same logic applies to certificates. You think that the expiration date means the certificate is valid to a given point, not that it is invalid after. Which is true, but misses the point. The point is that the absence of a certification is, itself, enough reason to avoid using a certificate. I need to use my own nose and common sense to see if it's still okay. So would you be fine with a restaurant serving you expired milk, if the proprietor says oh, hey, I used my nose and common sense, and it's okay? When you are the only one bearing the
Re: encrypting to expired certificates
On 09/16/2014 10:04 AM, Nicholas Cole wrote: Can anyone explain to me why one would want to continue using a key and yet not simply change the expiry date? I really find all of the examples being given to be incredibly contrived. incredibly contrived suggests that the people who are reporting the scenarios have made them up. I did not make up either example, and i doubt that Peter or Hauke did either. They simply happened, and we experienced them and are reporting them. Do you really think any of us made them up? It takes no time at all these days to change the date and distribute the new key. Yes, it is trivial to update the expiration and publish it if (a) you know how, and (b) you don't have an offline master key. In fact, for updating the primary key, it is just: gpg --edit-key $PGPID expire gpg --send-key $PGPID But sometimes, it is the encryption-capable subkey that is the thing that expired. in that case, it's a little bit more complex: gpg --edit-key $PGPID gpg key 1 gpg expire gpg save gpg --send-key $PGPID of course, it might be key 2 or something else if you have more than one subkey. i've definitely seen people update their primary key's expiration date and fail to update the expiration date of their subkey, so they have a valid cert, but it still can't be used for encryption. So they have to go back and do the second step later, after a poke from someone more knowledgeable about OpenPGP who figures out why no one can encrypt messages to them. Is it getting complicated enough yet for you to believe these real-world reports? The cost is not just the time to do it, it's the time to: 0) understand what needs to be done 1) figure out the interface to do it This is non-trivial, for most people: the context switch alone from regular work to thinking about key management is expensive and distracting. And it is also scary -- people who understand a little about key management have probably heard that if you screw it up, you can screw up pretty big, in unrecoverable ways. So there are both cognitive and emotional barriers to overcome, in addition to the time it takes. As I've said, if the tools to do this kind of thing easily do not exist, they need to be created. Do you know of any tools that do this easily for users who don't already think about key management daily? I don't, unfortunately. And even if they exist, some people might not have access to them. I'm all for building those friendly key-management tools, i would love to see them. But we need to also let people use the tools we have in light of real-world scenarios. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
I wanted to encrypt a document to myself on an offline system[1]. However, that copy of my own key was expired, and it wouldn't do it. I was in a bit of a hurry, trying to get things done. Now, I had to get a USB drive, start another computer, export my updated key, and import it on the offline system. If I had --expert followed by yes to an Are you sure? prompt, I would have done that and updated the copy when I had more time. And how much impact did this really have on you? What was to prevent you from using symmetric encryption? It's not as if you don't have a secure communication channel with yourself over which a symmetric key can be negotiated. I've had the exact same situation before. My solution was to use symmetric encryption using a strong passphrase -- a few lines of The God Forsakes Antony by Cavafy, if memory serves.[1] Together with Hauke and his correspondent with the offline main key, you now already have two actual cases, taken from real situations that actually happened. At this rate, we'll be done this week. We have one person who has had minimal impact and for whom an easy workaround exists, and we have Hauke's case. I'm not asking to see six real users who are really impacted for no reason, Peter. I'm asking because this dramatically cuts down on bikeshedding and lets us prioritize things. If encryption with Elgamal keys suddenly breaks, okay, thousands of users are affected in a critical way for which no easy mitigation exists: that's something that should be fixed immediately. But the lack of a flag to allow people to ignore the expiration date? I'm not seeing a large number of users who are facing serious impacts because of this. I was slightly baffled by this comment as Hauke actually gave an example that happened in real life. That is a lot more than I usually see when people argue for or against a feature. And I am overwhelmingly against those feature requests, too. You can't argue that these aren't real users. You can't argue it's not a real impact. Sure I can. You weren't really impacted by it. You had easy mitigations available to you. [1] A particularly beautiful poem by the Greek poet Constantin Cavafy, inspired by the legend of Mark Antony realizing he was destined to lose the city of Alexandria when he saw Bacchus and his entourage depart the city. It's not particularly germane to this discussion, but -- well. It is beautiful, and what the hell: beauty ought be shared. :) If unexpectedly, in middle night, an unseen company be heard to pass, with music and with voices exquisite -- turn not away and uselessly lament your fortune that is giving in, your work that came to nothing, the projects of your life that proved illusory from first to last. As one prepared long since, as fits the brave, bid now farewell to the departing city, farewell to the Alexandria you love. And above all, do not deceive yourself: say not that your impression was a dream, that, it may be, your hearing played you false: to futile hopes like these never descend. As one prepared long since, as fits the brave, as most fits you who gained so great a city, approach the open window steadily, and with emotion, but without the plaints and supplications of the timorous, listen -- knowing it to be your last delight -- listen to the Elysian sounds, the exquisite instruments of the mystic company; and bid farewell to the city you are losing, farewell to the Alexandria you love. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Mon, 15 Sep 2014 23:53, do...@dougbarton.us said: Actually the sematics of an expired (sub)key may come from the 1999 or so idea of adding features to mitigate the effect of the UK RIP act (or whatever it is called now). Wow, blast from the past. :) It's not clear to me how you're tying those 2 things together though. Ben Laurie wrote an I-D to add forward secrecy to OpenPGP. It is possible that I did some changes to the subkey expiry mechanism as a first step to implement that (I can't remember and would need to spend time ready ChangeLogs and mails). The idea was to have rolling subkey, a fresh one each month, you keep the subkeys for the last two months online, and delete older subkeys. Then if the --show-session-key stuff won't be accepted by the bobby asking for the key for a certain message, you could claim that you have only keys for the last two months (or weeks) and that the software deletes all older stuff. Never fully implemented, though. Frankly I wish the option had never been added to the spec, but (thankfully) I'm not in charge. :) I like the expiration date because it somehow helps against forgotten passphrases (although it is questionable, that those who know about expiration dates will forget passphrases) and lost secret keys. But it is indeed an advanced topic. A feature request could be to remove the expiration time prompt when not in expert mode. OTOH, only experts use the command line and yes, the GUIs may do without the expiration time. I will consider this for GPA. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tue, 16 Sep 2014 12:52, martin-gnupg-us...@dkyb.de said: In Germany on food products you will find the word Expiration Date which literally means: Don't eat me after that date. But there is a Actually you find mindestens haltbar bis DATE which literally means at least stable/durable until DATE. It is the guarantee promise from the vendor. Which would actually support Hauke. To put this discussion to an end, he may simply do a jump to the left and put the option --faked-system-time ISODATESTRING on his command line. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tuesday, 16 September 2014, Peter Pentchev r...@ringlet.net wrote: On Tue, Sep 16, 2014 at 03:04:08PM +0100, Nicholas Cole wrote: Can anyone explain to me why one would want to continue using a key and yet not simply change the expiry date? I really find all of the examples being given to be incredibly contrived. Uhm, are you sure that you really mean to say incredibly contrived as in you guys must have tried your imagination really hard to come up with these examples, none of which will happen in the real world, or do you really mean highly unlikely except in isolated use cases? Because what people are showing you are real use cases, ones that have happened with real people in the real world. Unlikely and isolated, yes, but I wouldn't use contrived in this case. I apologise for my poor choice of language. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tue, Sep 16, 2014 at 04:01:27PM +0100, Nicholas Cole wrote: On Tuesday, 16 September 2014, Peter Pentchev r...@ringlet.net wrote: On Tue, Sep 16, 2014 at 03:04:08PM +0100, Nicholas Cole wrote: Can anyone explain to me why one would want to continue using a key and yet not simply change the expiry date? I really find all of the examples being given to be incredibly contrived. Uhm, are you sure that you really mean to say incredibly contrived as in you guys must have tried your imagination really hard to come up with these examples, none of which will happen in the real world, or do you really mean highly unlikely except in isolated use cases? Because what people are showing you are real use cases, ones that have happened with real people in the real world. Unlikely and isolated, yes, but I wouldn't use contrived in this case. I apologise for my poor choice of language. Uh, and come to think of it, I'm truly sorry if the above sounded a bit harsh. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tue, Sep 16, 2014 at 03:04:08PM +0100, Nicholas Cole wrote: Can anyone explain to me why one would want to continue using a key and yet not simply change the expiry date? I really find all of the examples being given to be incredibly contrived. Uhm, are you sure that you really mean to say incredibly contrived as in you guys must have tried your imagination really hard to come up with these examples, none of which will happen in the real world, or do you really mean highly unlikely except in isolated use cases? Because what people are showing you are real use cases, ones that have happened with real people in the real world. Unlikely and isolated, yes, but I wouldn't use contrived in this case. It takes no time at all these days to change the date and distribute the new key. As I've said, if the tools to do this kind of thing easily do not exist, they need to be created. The tools exist. The issue - in most of the cases here - is that sometimes people don't use all their PGP keys all the time and sometimes it may happen that a key will be unused for months and the owner will honestly not notice that (the system that the key resides on may not even have been powered up for months). G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am 16.09.2014 um 16:41 schrieb Werner Koch: On Tue, 16 Sep 2014 12:52, martin-gnupg-us...@dkyb.de said: In Germany on food products you will find the word Expiration Date which literally means: Don't eat me after that date. But there is a Actually you find mindestens haltbar bis DATE which literally means at least stable/durable until DATE. It is the guarantee promise from the vendor. Which would actually support Hauke. To put this discussion to an end, he may simply do a jump to the left and put the option --faked-system-time ISODATESTRING on his command line. Ups, yea you are right, my bad. But that doesn't change my point, that expiration date is something else than best before or best used until. So if an enforced expiration date does not make sense, I would prefer to rename it to any of the other options and than allow sending encrypted messages to these keys. Until than you're solution should work, too. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/16/14 6:58 AM, Daniel Kahn Gillmor wrote: I've been in a situation where i'm sitting with a friend, talking about a project we're hoping to work on together, and i wanted to send them confidential information about the project to read later. I know they have an OpenPGP cert, so i fire up an e-mail, only to discover that their cert is expired (they don't use it often, and hadn't noticed). I point it out to them, they blush and say yeah, that's on my laptop, which is fine, but it's at home. I'll update the expiration date when i get home. I agree with Robert that symmetric encryption is your best bet, given that you're sitting right there. Meanwhile, all of the real world cases listed so far involve people who have mismanaged their keys by not updating their expiration date. I'm not sure that adding features to make that situation less painful is the right direction to move. I do like Werner's idea of moving the expiration date to the expert menu. That would give us less instances of users twisting a knob just because it's there. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
This is a resent because I accidentally mailed Peter Lebbing directly without the mailing list. Allow me to lay to rest all the confusion in this thread. On Tue, Sep 16, 2014 at 6:45 AM, Peter Lebbing pe...@digitalbrains.com wrote: I wanted to encrypt a document to myself on an offline system[1]. However, that copy of my own key was expired, and it wouldn't do it. I was in a bit of a hurry, trying to get things done. Now, I had to get a USB drive, start another computer, export my updated key, and import it on the offline system. If I had --expert followed by yes to an Are you sure? prompt, I would have done that and updated the copy when I had more time. Not really sure where you're going with this. It has already been *established* that if you're the key owner you can adjust the expiration date of the key. I think there's a lot of confusion around the intention of a floating expiration here. Expiring keys have the following function: Expiring local copies of public keys on other peoples' computers to force them to get a public key update from the owner. That is to say that if I have Peter Lebbing's public key and it has expired that means I must reach out to Peter Lebbing for the latest copy of the public key of the exact same fingerprint. Expiration in this context does not mean the key is forever invalid. It means that *my copy* is invalid until I get a more recent update from Peter Lebbing. That just means Peter Lebbing would have changed the expiration date of his public key and extended it. So when I get his new expiration date that is the time in which I must reach out to him next for another public key update of the same finger print. This protects both the key owner and correspondent in a couple ways. 1) If I have an expired key and I check to see what the latest key is of Peter Lebbing, he may have revoked it. In this case it forced me to go out and check and see that it was revoked so I *must* not use this key again. He can give me his new key with proper WoT validation. 2) If Peter Lebbing as a key owner loses his key and my local public key of Peter Lebbing expires then the next time I reach out to Peter Lebbing for the latest key copy he can tell me he, in fact, lost the key and give me a new one with proper WoT validation. To bring this full circle: the expiration date's purpose is to force users of any public key to periodically check with the key owner that the public key is still valid. RESOLUTION So if a key is expired I *must* not encrypt with it. I *should* instead reach out to the key owner and ask for their latest public key of the same fingerprint which would have a new adjusted expiration date. This ensures I'm not encrypting to a compromised key, a revoked key, or a key in which the owner lost the private key. If you're the owner of a key that has an expired date, you *should* extend it to allow further use of the key by your contacts. If you decide you don't want to use the key any longer then you *should* revoke the key. If you accidentally lose your key then no worries, because eventually it will expire and nobody could encrypt to it even if they wanted to. Hope this helps, SAM -- GPG FINGERPRINT 4096 KEY 8D8B F0E2 42D8 A068 572E BF3C E8F7 3234 7257 E65F https://keybase.io/samrocketman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/16/2014 at 10:51 AM, Werner Koch w...@gnupg.org wrote: To put this discussion to an end, he may simply do a jump to the left and put the option --faked-system-time ISODATESTRING on his command line. = Does this work on GnuPG 1.4.x ? GnuPG (1.4.16) gives me the following error: gpg: Invalid option --faked-system-time vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tue, 16 Sep 2014 17:44, martin-gnupg-us...@dkyb.de said: until. So if an enforced expiration date does not make sense, I would prefer to rename it to any of the other options and than allow sending I doubt that it makes sense to add an extra option for a rare corner use case. There are more often no keys at all than expired keys. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 16/09/14 16:31, Robert J. Hansen wrote: And how much impact did this really have on you? What was to prevent you from using symmetric encryption? It's not as if you don't have a secure communication channel with yourself over which a symmetric key can be negotiated. Because I was archiving the file for later use and I had no desire to come up with a good passphrase and try to remember it for I don't know how long. You can't argue that these aren't real users. You can't argue it's not a real impact. Sure I can. You weren't really impacted by it. You had easy mitigations available to you. Ouch, that's really selective quoting you're doing. In one day you object to people misunderstanding what you say and twist the words of another. The very next sentence handles exactly this: how large the impact is. In that context, I was clearly referring to real as in existing not as in significant, and you know it. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/16/14 9:26 AM, Werner Koch wrote: On Tue, 16 Sep 2014 16:26, d...@fifthhorseman.net said: i've definitely seen people update their primary key's expiration date and fail to update the expiration date of their subkey, so they have a valid cert, but it still can't be used for encryption. So they have to There needs to be warning in this case. Can you please file a bug? FWIW, I recently experienced that myself. The combination of knobs needed to select both the primary and the encryption sub key for updating the expiration was not intuitive, and I was quite surprised to see that when I updated the expiration date the first time that the subkey was not also updated. In fact I would not have known that at all if I hadn't done 'list-keys' after I edited the key just to be sure. Doug (It's only paranoia if they're not actually out to get you) :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 16/09/14 16:16, Robert J. Hansen wrote: As a farm kid, the answer is a resounding yes, and you should be thanking me. American, European and Australian food supplies are the safest in the world precisely because we throw away so much good food. Can we prove that the food is safe? No? Then we get rid of it. Utter nonsense. I'm not advocating putting an expiry date on something beyond what you can reasonably guarantee (in practice, milk sometimes curdles before the expiration date, even though I sure didn't leave it out of the fridge. Or fruit rots). I'm advocating that you judge what you put in your mouth based on your own common sense. This may be a cultural thing; I think they might care less about waste of scarce resources in the US, but to me it is offensive to suggest you should throw out perfectly good food or food with a few minor spots that you can cut out. I certainly wasn't raised that way. It's illegal to sell or even give out food that is past its expiry date. Once it's in my fridge, I will decide whether I will eat it or not. And that you appeal to authority and say I should take food health and safety advice from you because you were raised on a farm... well... let's just say it's a bit silly. Let's keep it at that. By the way, if stuff regularly exceeds the expiration date in your home, you should buy smaller portions, not throw out more. That's advice from someone who isn't exactly a city boy but a farm boy neither. But back on topic: It was claimed that an expiry date should be seen as a hard deadline. It was claimed that this was in the very word itself, as can be seen in food and drinks expiry dates. I strongly state that this is a very poor basis to conclude that on, because an expiry date on food is certainly not commonly and largely viewed as a hard deadline for consumption. Maybe in some cultures, but I don't see a list of cultures used during drafting the RFC among the references. There's a subtlety there that I think you're missing. Just because something is good doesn't necessarily mean you can prove that it's good... but knowing you *can't* prove that it's good is still enough to tell you what to do. I missed no such thing. I think you're missing what a super market is allowed to sell or give away and what I'm allowed to eat. Risk: A large number of users may wind up, through accident, error, or misadventure, disabling expiration checks on certificates. Yes, because GnuPG surely knows better that even if it warns the user with some capitals and asterisks and requires them to type 'yes', that still, the user is probably too dumb to be reasonable about this. I thought you yawned over this feature. It looks more like a growl. Correct, but this is sort of quibbling. Opposing becasue of the addition of a really minor risk of misconfiguration (who said anything about it being a persistent option?), that's quibbling. There is no assurance this certificate is valid, since we are past X in time. Therefore, I will treat it as invalid until the certificate owner makes a new assurance. It's not treated as invalid. You can trivially override the validity check on the command line. It's treated as effectively temporarily revoked. While I agree that I will treat this certificate as invalid is a different thing from this certificate is invalid, in practice there's not much difference. You are arguing with yourself. You bring up a difference, and then refute it. I never talked about treating and being. The point is that the absence of a certification is, itself, enough reason to avoid using a certificate. So would you be fine with a restaurant serving you expired milk, if the proprietor says oh, hey, I used my nose and common sense, and it's okay? Here we go again. The restaurant is selling me something. I'm glad there are laws for this. However, if my neighbour handed me the drink with the same words when I come over for coffee (er, milk), then yes, I would drink it. And I never even made the point of handing it to anyone else, I made the point of using your own judgement to determine what you put in your own mouth. Let me be quite frank now. I can't quite imagine you don't see the difference yourself. I think you're purposely ignoring it for the sake of argument. When you are the only one bearing the consequences of your decisions, a lot more can be justified than when you are asking *other people* to bear the consequences of your decisions. Hey, what do you know. You remembered! When it's part of your side of the argument. I honestly wrote the previous paragraph before I read this one. I started replying when you again advocated food waste and I got offended, and went from there. And when you send email encrypted to an expired certificate, you are asking *your recipient* to put the confidentiality of your communication with them entirely in the hands of your judgment about whether their I no longer certify this for use
Re: encrypting to expired certificates
On 16/09/14 16:41, Werner Koch wrote: To put this discussion to an end, he may simply do a jump to the left and put the option --faked-system-time ISODATESTRING on his command line. Regardless of whether you personally support or oppose the possibility to override the expiry date, as it's your decision, I do want to point out that this creates an issue with encrypt-and-sign. Although a little footnote saying hey dude, since your key expired in April, I had to sign in April could be added. I do wonder how many people would understand that footnote, though. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tue, 16 Sep 2014 16:26, d...@fifthhorseman.net said: i've definitely seen people update their primary key's expiration date and fail to update the expiration date of their subkey, so they have a valid cert, but it still can't be used for encryption. So they have to There needs to be warning in this case. Can you please file a bug? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/16/14 10:18 AM, Peter Lebbing wrote: On 16/09/14 16:41, Werner Koch wrote: To put this discussion to an end, he may simply do a jump to the left and put the option --faked-system-time ISODATESTRING on his command line. Regardless of whether you personally support or oppose the possibility to override the expiry date, as it's your decision, I do want to point out that this creates an issue with encrypt-and-sign. Although a little footnote saying hey dude, since your key expired in April, I had to sign in April could be added. I do wonder how many people would understand that footnote, though. which further highlights that adding options to make life easier for people who don't understand what key expiry means, or how to manage it properly, is probably not a good idea. :) Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 16/09/14 16:16, Robert J. Hansen wrote: A bloody shame to throw it away. You really throw out perfectly good food? As a farm kid, the answer is a resounding yes, and you should be thanking me. I'm sorry I keep going on, but I have got to get this off my chest. You are urging me to do something in direct defiance of how I was raised and my personal beliefs, and even urging me to thank you for that! That really is bloody facetious. You've really got nerve, man. Peter. PS: And when you send email encrypted to an expired certificate, you are asking *your recipient* to put the confidentiality of your communication with them entirely in the hands of your judgment about whether their I no longer certify this for use statement should be respected. I only see the statement I certify this key until X. That is certainly what I did when I thought really well about how I wanted it to be and put an expiry date on my key. I never made the statement I no longer certify this. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Di 16.09.2014, 10:31:00 schrieb Doug Barton: which further highlights that adding options to make life easier for people who don't understand what key expiry means, or how to manage it properly, is probably not a good idea. :) What I want would make life easier mostly for the contacts of those who don't manage their keys well. Furthermore it seems proven to me now that even the elite of the OpenPGP users don't understand what key expiry means. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Ouch, that's really selective quoting you're doing. No, I'm using the same verbiage I did before. Quoting myself: = Hauke, this entire argument is what I meant when I talked about gilding the lily repeatedly. If you can find half a dozen *real users* who are being *really impacted* by this, I'd love to hear about them. = A real user is not a user that technically exists but has only ever used GnuPG once and is unlikely to do so again; a real user is one who has a significant need for GnuPG and uses it to address these needs. Really impacted doesn't mean an impact barely greater than epsilon; it means significant impact. My usage is consistent. If you've chosen to reinterpret my words as existence rather than significance, that's on you; you've dropped my threshold from significance to it's okay if the user and the impact are completely insignificant, just so long as they exist, which is clearly not what I meant at all. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/16/14 11:53 AM, Hauke Laging wrote: Am Di 16.09.2014, 10:31:00 schrieb Doug Barton: which further highlights that adding options to make life easier for people who don't understand what key expiry means, or how to manage it properly, is probably not a good idea. :) What I want would make life easier mostly for the contacts of those who don't manage their keys well. Yes, I think we all understand that. My vote is that what you want to do is a bad idea. Furthermore it seems proven to me now that even the elite of the OpenPGP users don't understand what key expiry means. I admire your determination to believe that you are the one who is right, and that everyone else is wrong. :) Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
I'll admit that I hadn't actually realised how hard it is to make GnuPG change the expiry dates of subkeys at the same time as changing the expiry date of the main key. What is the approved way to do this? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
You can't argue that these aren't real users. You can't argue it's not a real impact. You can only argue that the impact isn't that big. But that is a long shot from so hypothetical it's hard to take seriously. I don't understand where that came from. Sure I can. You weren't really impacted by it. You had easy mitigations available to you. I was exactly asserting that you can only argue about the extent of the impact, not that there exists an impact. Telling me that [I] can't argue that it's not a real impact, when the meaning of real that I've been using has been significance, and I clearly *can* argue that it's not a real/significant impact, is an invitation for me to do just that. Your examples are not real impacts. Which suddenly makes it look like I made a false statement, when in fact I was simply stating that something that has an arguably small impact is a long shot from something that is so hypothetical it's hard to take seriously. Not really. This 'problem' is so hypothetical it's hard to take seriously. I'm still waiting to see one single real user who has had real impact from this, and that means the problem is still hypothetical. There, I've said it. Deal with it. In fact, thank me for it. [shrug] As soon as I let the opinions of other people I've never met start weighing heavily on my self-esteem, I'll let you know. Until then, I really don't care. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/16/2014 at 2:56 PM, Hauke Laging mailinglis...@hauke-laging.de wrote: What I want would make life easier mostly for the contacts of those who don't manage their keys well. = Which is especially reasonable, since it seems that the option of '--faked-system-time' (which used to work on earlier versions of GnuPG 2.x), but doesn't work on current versions of 2.x, and never worked on 1.x, now make it especially cumbersome to encrypt to an expired key, (by requiring changing the system clock and changing it back again). As the '--faked-system-time' option is interesting, maybe re-implementing it in both 2.x and 1.x might be an easy workaround in those cases where a user has forgotten to update an expired key. With regard to the resulting sign and encrypt problem, a simple workaround would be to clearsign first, and the encrypt the clearsigned mesage with the '--faked-system-time' option . vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tue, 16 Sep 2014 21:30, ved...@nym.hush.com said: As the '--faked-system-time' option is interesting, maybe re-implementing it in both 2.x and 1.x might be an easy workaround in those cases where a user has forgotten to update an expired key. No. --faked-system-time is actually a debugging options and helpful for regression tests. It might be easier to use than pther faketime tools With regard to the resulting sign and encrypt problem, a simple workaround would be to clearsign first, and the encrypt the clearsigned mesage with the '--faked-system-time' option . A much much easier to solution it to patch out the check and go ahead. After all the source code is always there. IIRC, g10/getkey.c, function merge_keys_and_subkeys . Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (Really OT!) encrypting to expired certificates
However, I can't help but feel angry by your dismissal of my beliefs I did not dismiss your beliefs, nor did I mock them. When I said in deference to Peter's hot-button issue of food expiration, there was no perjoration or sarcasm attached to that. I said precisely, exactly, what I meant: in order to avoid tromping on something that is a sensitive subject for you, I elected to use other examples. You may wish to rethink whether that amounts to a dismissal of your beliefs or consideration of them. But even if you are of stone, maybe you should remember that it's actual people you are conversing with who have emotions and might feel strongly about things. We are not our ideas. Our ideas are separate things from us, and one can be a virtuous and commendable soul even if one's notions are nonsense. A Young-Earth Creationist who volunteers to feed the hungry is still showing great personal virtue. Their idea may be flamingly wrong, but only a heartless fool would think that fact should somehow diminish their worth or value. We live in a society that encourages us to wear labels. Atheist. Agnostic. Buddhist. European. American. Black. White. Arab. There's nothing wrong with those labels, really -- but there's something wrong with letting ourselves *be defined by* our labels. And in the end, the ideas you hold are just another label. Don't let your labels define you. Especially don't let them define your self-worth. You are more, and richer, than that. We all are. Not just everyone on this mailing list, but every human being throughout the world. (Even the ones currently kidnapped on Zarbnulax.) I'm sending this to the entire list because it's something I'd like to tell the entire list. None of us are our ideas. It is normal and natural for ideas to come into violent collision. If your idea prevails, congratulations, but that doesn't make you a better human being. If your idea doesn't, I wouldn't lose any sleep over it: no one worth knowing would think that having an incorrect idea was any kind of reflection on you as a person. You certainly don't have to agree with any of this. They're just ideas, after all... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/16/14 12:12 PM, Nicholas Cole wrote: I'll admit that I hadn't actually realised how hard it is to make GnuPG change the expiry dates of subkeys at the same time as changing the expiry date of the main key. What is the approved way to do this? It wasn't *that* hard, just not what I expected. :) When you get into the edit-key menu you can do 'uid *' (or specifically select the uids you want to update, if not all). Then update the expiry. Then also do 'key *' (or specifically select the subkeys you want to update). Then you can update the expiry for the subkey(s). The thing that I found unexpected is that even if you do both 'uid *' and 'key *' you can still only update the expiry for one or the other, apparently whichever one of those you executed last. hth, Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Di 16.09.2014, 12:03:20 schrieb Doug Barton: On 9/16/14 11:53 AM, Hauke Laging wrote: Am Di 16.09.2014, 10:31:00 schrieb Doug Barton: which further highlights that adding options to make life easier for people who don't understand what key expiry means, or how to manage it properly, is probably not a good idea. :) What I want would make life easier mostly for the contacts of those who don't manage their keys well. Yes, I think we all understand that. I wonder why you made the above statement then. Furthermore it seems proven to me now that even the elite of the OpenPGP users don't understand what key expiry means. I admire your determination to believe that you are the one who is right, and that everyone else is wrong. :) I'm sorry if that is your impression. My impression is that we have seen that both opinions about the suitable interpretation are backed by several people. I.e. there is no concensus. And the majority of those who have commented supports my suggestion. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 9/16/14 3:38 PM, Hauke Laging wrote: | Am Di 16.09.2014, 12:03:20 schrieb Doug Barton: | On 9/16/14 11:53 AM, Hauke Laging wrote: | Am Di 16.09.2014, 10:31:00 schrieb Doug Barton: | which further highlights that adding options to make | life easier for people who don't understand what key expiry | means, or how to manage it properly, is probably not a good | idea. :) | | What I want would make life easier mostly for the contacts of | those who don't manage their keys well. | | Yes, I think we all understand that. | | I wonder why you made the above statement then. Sorry I wasn't clear. I meant that what you want is clear to everyone. The fact that it's a bad idea seems to remain unclear to you. | Furthermore it seems proven to me now that even the elite of | the OpenPGP users don't understand what key expiry means. | | I admire your determination to believe that you are the one who | is right, and that everyone else is wrong. :) | | I'm sorry if that is your impression. My impression is that we have | seen that both opinions about the suitable interpretation are | backed by several people. I.e. there is no concensus. And the | majority of those who have commented supports my suggestion. Even if your last statement were correct (and I don't think it is), you should be careful drawing conclusions from it. The danger is that people with unusual views (such as that expired doesn't mean expired) are more likely to comment than the proverbial silent majority who, if they gave any thought to the topic at all, concluded long ago that, Of course 'expired' means 'expired,' and moved on with their lives. Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUGMg7AAoJEFzGhvEaGryE8XcIAL35gNduqXOpKbwtlqirXgTb c8LUlI+rEv3EoeAVW/xVuq2jFJLNpU5RPmC81rJIs6Ugw5sMqXQ+wN/4PCqDNUhf ddy8W2cZwspO72FBO67BmFpB9W+Km7lTkl79653GVtDgn1T8RRR5H8977IgFdS6Z kcuz0Al2GtPVe/peRPDu6LsXuT6XHARbMGPSm+QQ6QyWecsw/tcyyzOoIlvAhXGq U/e4T1zhSkw5s9BlaPPvpIPDeOYTCchl+U+pxIZlfkJfkvXo+BlSrzR64Df1Umqp sbaXEbtulJFiQgZpybz8YZsCpIZ8DMJkYNnthZBZJHV10WYSAdEQ5GXco77+G1k= =92bY -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Wed, 17 Sep 2014 00:38, mailinglis...@hauke-laging.de said: several people. I.e. there is no concensus. And the majority of those who have commented supports my suggestion. ... and the 2400 other subscribers are having a bag of popcorn while watching the discussion. scnr, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 16 September 2014 at 6:16:07 PM, in mid:54187057.4080...@digitalbrains.com, Peter Lebbing wrote: By the way, if stuff regularly exceeds the expiration date in your home, you should buy smaller portions, not throw out more. Depends on pricing. Where I live, it is often cheaper to buy too much and waste some. Milk is currently about 0.50 for a pint, 0.90 for two pints, 1.00 for four pints. So we typically buy it in four-pint bottles and throw out about a third of the bottle when it goes off, which is up to about three days either way from the stated use-by date. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Two wrongs don't make a right. But three lefts do. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlQY5xJXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pvwwEALGhJCGnVAck1s09SAoBwtIdS4mLfSLlSHBW uIKuJ09uAOf61WWred+rdyn+yxmyOTPj45T6nlkc8nXHUdVYrc1EkB7sI3/EOA1D A4FGQH/mGFIN6T1AQZSgdv7bVba7AeyhhOAXjXBhbwt2Lud1rKWhpJ85NN+DPplB jlOE0ocQ =ZUOU -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 16 September 2014 at 5:15:12 PM, in mid:20140916161512.3f40260...@smtp.hushmail.com, ved...@nym.hush.com wrote: Does this work on GnuPG 1.4.x ? GnuPG (1.4.16) gives me the following error: gpg: Invalid option --faked-system-time 1.4.18 and 2.0.26 (on Windows) both give me that error. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Dogs look up to us. Cats look down on us. Pigs treat us as equals. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlQY6qJXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pUYsEAIaV4h3o9Ka6FABYVMc9lqTl1cjiqgy+ndga lwunpIAzdpWi0kJEt5pkaaB/s1CkaALv2lfVTVd33Y6tEaocxex9NcLMelf8/NnL xVj5mnGxqoWJEw8G9RMq8FLnltTfnWN0cCrnsLvRzyQudYhg1cQ0PEpdbeTUL5y7 Y7EMvVnr =2NzT -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Monday, 15 September 2014, Hauke Laging mailinglis...@hauke-laging.de wrote: Hello, after filing a bug report for my mail client because it does not allow me to encrypt to an expired certificate (neither does Enigmail) I was surprised to notice that I didn't manage to encrypt to an expired certificate with gpg in the console (2.0.22). Is this not possible (what about gpgme?) or am I just not aware of how to get that done? I would consider not being able to encrypt to an expired key a severe security flaw because it may force the sender to send the message unencrypted. It is OK to warn the user but it must be possible to override this warning. Expiration is not a security problem (let alone a severe one). It does not even work with --encrypt-to. And the man page says about this command: No trust checking is performed for these user ids and even disabled keys can be used. Non-valid keys are OK, disabled keys are OK but the least severe case expiration is not OK? Hauke Opportunistic encryption with a fall-back mode to plain text, which seems to be your model, is dangerous. Yes, it is always dangerous to have a protocol that sends in plain text if encryption is impossible. However, I don't think the fault is with GPG. If a key has an expiry date, GPG can be very very certain that that key should not be used after a particular date. In fact, I don't think that user interfaces should ever have encouraged people to encrypt to 'not valid' keys at all, but if they key itself says that it should not be used, then it really should not be used. You can't make assumptions for the reason a key has an expiry date. It could be that after that date it would be insecure to send encrypted data to that key. I think that implementations should respect the expiry dates on keys. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Mo 15.09.2014, 09:48:47 schrieb Nicholas Cole: Opportunistic encryption with a fall-back mode to plain text, which seems to be your model, is dangerous. Yes, it is always dangerous to have a protocol that sends in plain text if encryption is impossible. This is not about opportunistic encryption (which I do not use BTW). It is about being capable at all to encrypt in a certain situation. [quote order changed] If a key has an expiry date, GPG can be very very certain that that key should not be used You can't make assumptions for the reason a key has an expiry date. Do you think these two statements are consistent? I don't object to a key should not be used, BTW. I object to a key must not be used / a key cannot be used. Those are very strong assumptions which are hardly ever justified. In particular this is not a decision for a low level tool like GnuPG. A low level tool (usually directly used by experts) shall give the GUIs the information they need (in this case: the key is invalid because it is expired) and let them decide what to do. There is a whole section Doing things one usually doesn't want to do. in gpg's man page... It could be that after that date it would be insecure to send encrypted data to that key. How is that possible without anything encrypted to this key before the expiration date becoming insecure, too? If a key has become insecure then it is to be revoked. I think that implementations should respect the expiry dates on keys. I agree with that. I just disagree with translating respect to not allow any override at all (for this problem only, allowing overrides for all other kinds of worse problems...). In fact, I don't think that user interfaces should ever have encouraged people to encrypt to 'not valid' keys at all, I don't think that any UI (I know) encourages people to do that. Allowing (after a warning and confirmation) is not encouraging. but if they key itself says that it should not be used, then it really should not be used. I agree. But expiration does not necessarily mean don't use at all. Expiration is not the same as revocation. This is not affected by the fact that revocation may be impossible (private key lost and compromised). The RfC is quite clear about revocations. It is not about expirations. http://tools.ietf.org/html/rfc4880#section-5.2.3.3 Expiration is a good feature. Handling expired keys in this way discourages using expiration dates, though. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am 15.09.2014 um 14:10 schrieb Hauke Laging: I agree. But expiration does not necessarily mean don't use at all. Expiration is not the same as revocation. This is not affected by the fact that revocation may be impossible (private key lost and compromised). The RfC is quite clear about revocations. It is not about expirations. http://tools.ietf.org/html/rfc4880#section-5.2.3.3 Expiration is a good feature. Handling expired keys in this way discourages using expiration dates, though. 2 arbitrary use cases: 1. One uses the expiration date as a reminder, to think about maybe updating it to new standards or what so ever. In this case, a warning when using an expired case is enough. 2. One lives in an hostile environment and it is possible that someone can retrieve his private-key/pass-phrase and prevents him from revoking the key. In this case preventing someone from sending you information which might harm your well being is a good thing.* Since the sender can't know how you use the expiration date I guess the more conservative approach is the safer one if you consider extreme cases like scenario 2. Greetings Martin *This is probably highly theoretical, I don't know. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Mon, Sep 15, 2014 at 1:10 PM, Hauke Laging mailinglis...@hauke-laging.de wrote: If a key has an expiry date, GPG can be very very certain that that key should not be used You can't make assumptions for the reason a key has an expiry date. Do you think these two statements are consistent? It could be that after that date it would be insecure to send encrypted data to that key. How is that possible without anything encrypted to this key before the expiration date becoming insecure, too? If a key has become insecure then it is to be revoked. I don't know. If a key says on it You can use this key for these email addresses up until this date I think that tools SHOULD NOT use the key beyond that date or for other email addresses. I think in the case of the expiry date, I'd see a strong case for MUST NOT. The expiry date is there exactly so that users do not have to explicitly revoke keys. Or do you think one should be able to encrypt to revoked keys too? I do see a difference with merely NOT VALID keys, because those keys might be checked using some external trust system, though it is bad practice 99% o the time, I suspect. I can't see any justification for encrypting to a key past its expiry date. Either your correspondent is in a position to update the key, or he/she isn't. In the latter case, the key should not be used. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Sep 14, 2014, at 9:05 PM, Hauke Laging mailinglis...@hauke-laging.de wrote: Hello, after filing a bug report for my mail client because it does not allow me to encrypt to an expired certificate (neither does Enigmail) I was surprised to notice that I didn't manage to encrypt to an expired certificate with gpg in the console (2.0.22). Is this not possible (what about gpgme?) or am I just not aware of how to get that done? I would consider not being able to encrypt to an expired key a severe security flaw because it may force the sender to send the message unencrypted. It is OK to warn the user but it must be possible to override this warning. Expiration is not a security problem (let alone a severe one). I disagree with this. Expiration is the way the key owner (the person who knows best whether the key should be used or not) tells the world, Do not use this key after this date. If someone encrypts to the key anyway, they are going against the key owner's statement. I'm sure people can come up with particular scenarios where it is either okay or very not okay to use a key after it is expired, but either way, the key owner gave a date. Who are we to disregard that? David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Mo 15.09.2014, 14:33:55 schrieb Nicholas Cole: The expiry date is there exactly so that users do not have to explicitly revoke keys. I doubt that this is the common interpretation of this feature. One of the effects of expiration is that you can recognize (non- compromised) dead keys. Or do you think one should be able to encrypt to revoked keys too? That is already easily possible: You can delete the revocation signature. That's it. There are even cases in which I would consider that. If a revocation signature says that the key has been replaced then there is no reason to consider it unsafe. If I cannot verify the new key then it might be a good idea to use the revoked one. However, that is not the point. As a revocation is a MUCH stronger statement than an expiration (key revocations are hardly superseded but it is normal that the key validity period is extended) you cannot reasonably argue that the same behaviour should be applied to both. But the general rule applies here, too: A low level tool has to tell the user or higher level application what they need to know and has to let THEM decide how to react. A low level tool should provide every action that is possible. Not in the meaning that every possible action should be implemented but in that that nothing is absolutely prevented. I can't see any justification for encrypting to a key past its expiry date. Either your correspondent is in a position to update the key, or he/she isn't. In the latter case, the key should not be used. OK, reality check. The reason for this thread is that a friend has sent an encrypted email to me yesterday. I could not reply to that because his certificate has expired (two weeks ago, one year after creation, because I set this expiration date). I have created his certificate. That is an offline mainkey and he is probably not capable (or willing) to extend the validity period. He is not going to replace the key. It is not considered compromised. We(?) even talked on the phone today. It is far from a serious assessment of the situation to claim that the key owner want me not to use this key any more. And this situation is far less strange than the other ones offered in this thread. If you set an expiration date (no matter whether with GnuPG or the well- known GUIs) then the software does not tell you that senders were not allowed / not capable to use this key after that date. It says something about How long shall it be valid?. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Some time ago one of the well-known users of this list wrote: Secure communication with noobs is impossible. Period. (or similar) Wasn't me: I think a statement like that is arrogant even by my standards. It implies the speaker can accomplish this task, and if the history of communications security tells us anything it's to be deeply skeptical of anyone making such a claim. For that matter, what does secure mean, anyway? Most people would say it means an adversary can't intercept the communication or modify it. Fine. Who's the adversary? If your adversary is a smart 12-year-old, a good way to establish secure communication is to walk into your nearest bar and tell the bouncers to be on the lookout for 12-year-olds trying to get inside. If the adversary is an outfit with a lot of professional experience at intercepting communications, then you're completely screwed and there's nothing you can do about it. I really wish we could get over our obsession with the word secure. In twenty years of talking about PGP/GnuPG, I have yet to see it add one iota of meaning to any conversation. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Mon, Sep 15, 2014 at 5:13 PM, Hauke Laging mailinglis...@hauke-laging.de wrote: [snip] I have created his certificate. That is an offline mainkey and he is probably not capable (or willing) to extend the validity period. He is not going to replace the key. It is not considered compromised. We(?) even talked on the phone today. It is far from a serious assessment of the situation to claim that the key owner want me not to use this key any more. And this situation is far less strange than the other ones offered in this thread. If you set an expiration date (no matter whether with GnuPG or the well- known GUIs) then the software does not tell you that senders were not allowed / not capable to use this key after that date. It says something about How long shall it be valid?. Respectfully, Hauke, we just disagree on this. But your last comment raises a crucial point that I think has bugged OpenPGP for far too long: the software we use for OpenPGP has actually been far too liberal about letting people use not valid keys. This has taken pressure off the writers of user interfaces to find ways of encouraging users to use the software properly, and at the same time the web of trust has been shrouded in far too much mystique and mystery! If a user sets up a key and sets the flag on the key that explicitly means, Do not use it after this point I think the software should enforce that. I can see that it creates a (small?) potential for a DoS attack, and I can see that there might be cases you want to override it in special circumstances. As it happens though, it isn't exactly a strong protection for someone willing to delete revocation signatures and so on to make things work. The work-around is simple: wind your computer clock back and you'll be fine in this case. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Respectfully, Hauke, we just disagree on this. But your last comment raises a crucial point that I think has bugged OpenPGP for far too long: the software we use for OpenPGP has actually been far too liberal about letting people use not valid keys. If by too liberal you mean it's possible to do it, then I don't see how to avoid it. You'd need a trusted timestamp on the certificate and a trusted timestamp on the machine using the certificates, and trusted timestamps are a hard, *hard* problem. Yes, OpenPGP is quite permissive about letting people encrypt to expired certificates, but I think that's more a factor of it being incredibly hard to prevent it than it is any neglect on the part of the OpenPGP authors. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Sorry. I've confused too issues. Yes, it is hard to enforce expiry dates in a 'secure' way. I wasn't meaning to suggest it was something openpgp should try to do. I don't think we should make it easy to ignore them, that's all. Well, I still respectfully disagree, because -- oh, that's a rant. Then again, when has something being a rant ever stopped me? Okay: hang tight for some heresy. I've been using PGP and GnuPG for over twenty years now, and in those twenty years I've reached only a handful of beliefs. I love the math because you don't need to believe math: the theorem either works or it doesn't. Belief is a harder thing, and because of that it's wise to be very careful before forming beliefs. Here's my belief: anyone who advocates PGP/GnuPG, with or without supporting tools like Enigmail, to average end-users is committing professional malpractice. If they don't recognize they're doing it, they should take that as a sign they don't understand GnuPG/OpenPGP anywhere near as well as they think they do. GnuPG is not a communications security solution. It is a communications security *toolbox*, and an incomplete toolbox at that. GnuPG provides mechanism and only mechanism. GnuPG does not provide policy, and precious few of the tools supporting GnuPG fill in that gap. Enigmail doesn't. GPA doesn't. Pretty much nothing does. For that reason, recommending these tools to end-users is professional malpractice because end-users do not have the skills or experience to wisely determine policy. (I don't, either. If I were drafting policy I would need, at the least, assistance from HR [to tell me about human-factor concerns], Legal [to tell me about regulatory concerns], and IT [because they'd be the ones supporting the thing]. I doubt that anyone on this list, up to and including Werner, is capable of drafting a competent and effective policy for an entire organization on their own) Whew. That was a good beginning to a rant. Let me take a deep breath here... Policy -- who signs what, whose certificates are trusted and why, whether persona certifications should carry different semantic meaning than generic certifications, whether signatures should carry expiration dates, whether those expiration dates should be respected -- is, in a word, *IMPORTANT*. Further, policy will vary from person to person to person and organization to organization. This is one of the reasons why the should we use inline or PGP/MIME? question will never be conclusively answered. That's not a technical question, it's a policy question that people insist on treating like a technical question. Technical questions have only one answer: policy questions can only truly be answered with a, well, it depends... Here's something else about policy: putting together good policy is *HARD*. I've sat in on policy meetings before to provide technical advice, and let me tell you, I'd much rather be debugging Win32 binaries using gdb and a broken keyboard. Policy is driven by human factors as much as, or more than, by technical factors and that means your average geek is completely adrift in this space. Once you've got a usage policy, your next three questions become monitoring, remediation, and enforcement. How do you monitor usage to ensure it complies with policy? When something falls out of spec, what's the process to bring it back into spec? When you find who's responsible for it falling out of spec, what happens to them? These questions, too, get discussed and resolved in policy meetings. So, put it all together and here's what you need, at a minimum, to effectively use GnuPG: 1. Cryptographic tools. GnuPG provides these. 2. Usage policy. You're on your own. 3. Monitoring policy. You're on your own. 4. Remediation policy. You're on your own. 5. Enforcement policy. You're on your own. ... So, yeah. Whenever I see someone talk about how we need to improve GnuPG's adoption numbers!, I roll my eyes. Invariably they talk about how we need to make GnuPG easier to use. But that's not the problem and it's never been the problem. The problem is *policy*. Werner has, IMO wisely, decided that GnuPG will not make policy for the user. I think that's the absolutely correct decision to make. GnuPG should not be telling me what my usage, monitoring, remediation or enforcement policies should be. But the total absence of policy has led to the vast majority of GnuPG users *not even knowing that it's absent*. As a result, we as a community drastically understate (or in many cases don't even state!) the difficulty, expense, and necessity of policy. So, to tie all this back to your original remarks, Nicholas, I disagree that we need to do something about making it harder to encrypt to expired certificates. That's a policy decision, and as such it's outside the scope of GnuPG. But if you want to start waving the banner of, POLICY! GET SOME!, well, the line starts behind me. :)
Re: encrypting to expired certificates
On Monday, 15 September 2014, Robert J. Hansen r...@sixdemonbag.org wrote: Sorry. I've confused too issues. Yes, it is hard to enforce expiry dates in a 'secure' way. I wasn't meaning to suggest it was something openpgp should try to do. I don't think we should make it easy to ignore them, that's all. Well, I still respectfully disagree, because -- oh, that's a rant. Then again, when has something being a rant ever stopped me? Okay: hang tight for some heresy. (Snip) But if you want to start waving the banner of, POLICY! GET SOME!, well, the line starts behind me. :) I enjoyed that rant so much that I don't even mind that you have misinterpreted what I said and attributed to me ideas I don't hold: for which I'm prepared to take 50% of the blame! Just for the record: all I've ever said in this thead is that I don't think there is a compelling case to add an option to gpg to ignore expiration dates. That's all. Although, gosh! It already lets users do so many silly things perhaps one more doesn't matter. Your rant was a good one. I agree with much of it. Frankly, as a community we haven't developed the tools and culture that might have assisted users to develop good policy and good practice. I also despair a little. PGP made more sense, in some ways, in the early 1990s when most home and business computers were offline most of the time. Maybe not been then. Nowadays, I'm not at all sure I would trust openpgp to protect me if I were really worried about my privacy being under any kind of targeted attack: frankly I can't think of an OS platform I really trust to be secure, and if you can't trust the platform then a bets are off. Even Apple, who have every incentive to do so and control of both hw and sw, can't manage to keep their platforms secure. Of course, an air gap might help, but that really is a very major hassle and I don't have cause. I'm interested in the user interface problems that OpenPGP presents. That's kept my interest in it alive for all these years. I don't have any high hopes it will ever be widely adopted though: for most people, most of the time, there is limited benefit, if any. Nicholas. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Mo 15.09.2014, 09:47:21 schrieb David Shaw: I disagree with this. Expiration is the way the key owner (the person who knows best whether the key should be used or not) tells the world, Do not use this key after this date. Where do you take that from? Neither the RfC uses this description nor GnuPG nor any GUI I know. It is OK (not meaning: being safe from getting criticized by the key owner for sending clear text instead) if you treat the expiration date this way. But it is absolutely not OK to enforce this really not obvious interpretation on others. If someone encrypts to the key anyway, they are going against the key owner's statement. No. As nearly everything in the OpenPGP environment the definition of this statement is much too vague to justify this assessment. Even if you get a contrary statement in person (No problem, I just forgot to extend the validity period in time, use this key) you CANNOT do that. This behaviour makes using offline mainkeys (which should be strongly encouraged) more difficult. either way, the key owner gave a date. Who are we to disregard that? a) It seems that nobody wants it disregarded. Regarding this information means: Tell the user about it. Narrowing regard to prevent is the second non-obvious interpretation. b) As I have explained above there is no reason to assume that the average user understands expire the way you do. Indeed, he gave a date, not a prohibition. c) Because we disregard it everywhere else. GnuPG (and other very important parts of the OpenPGP environment) does not care about the key owner's statements in any other point in this absolute way. In general, you do not want to use this option as it allows you to violate the OpenPGP standard. Quote from the man page. --cipher-algo --digest-algo --compress-algo --force-mdc All made to override a key owner's statements (clearly RfC-backed statements in these cases). And, of course, the keyserver no-modify flag. Not GnuPG's fault, of course. In other words: OpenPGP users are used to their statements being (easily) ignored. d) It does not make any sense to forbid someone the use of a key if you cannot forbid him to send the information without any encryption instead. But it often makes sense to use an expired key for encryption. It does not make sense to assume that a key owner would prefer a clear text message over one encrypted for an expired key. It is a strange decision (to say it politely) to enforce a non-obvious interpretation which has a clear alternative (revocation) and does not make sense. e) Today those users who want to make a strong statement can do that: They can revoke their certificate. They cannot do that in advance but that is not a problem (I would support future revocations in the next OpenPGP version though). In your interpretation those who just want to give a hint cannot do that. There are two distinct features. Why should they not be treated differently though they are obviously used differently and understood differently? f) There is no change in security by reaching the expiration date. If there was one then nobody should encrypt information to a key if he wants this information to be secure after the expiration date, too. This is a pure formality which makes more sense with signatures than with encryption. Formality does not have priority over security. g) I can show real-world damage. Can you show (similar) real-world advantage? (I.e. not just some unclear formality.) The probably greatest point about OpenPGP is that it is so flexible. You can use it on the one side with users who hardly understand what they are doing using opportunistic encryption and on the other side you can use it for highly secure communication. The difference is about how to use GnuPG (and, as Rob just explained, policy which is not GnuPG's business). Due to this flexibility OpenPGP usually does not prevent users from doing stupid and dangerous things. If it does so in just one point and this point is even harder to justify than many things which are not done then this is a bug. You cannot explain the behaviour of GnuPG with a single rule. You need an exception for this case. And that is taste not logic. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
I enjoyed that rant so much that I don't even mind that you have misinterpreted what I said and attributed to me ideas I don't hold: for which I'm prepared to take 50% of the blame! Okay, I apparently misread. I'm sorry about that. It really annoys me when people misread me, and I suspect you feel likewise. [F]rankly I can't think of an OS platform I really trust to be secure, and if you can't trust the platform then a bets are off. Even Apple, who have every incentive to do so and control of both hw and sw, can't manage to keep their platforms secure. There's an old saw about a drunken man who's leaning up against a streetlamp while looking around for his keys. A passer-by halfway down the block finds the keys and takes them to the drunk. Why were you looking for them under the streetlamp if you lost them down the block? the passer-by asks. The drunk answers, I may have lost 'em down the block, but the streetlamp I need to lean against is right here! I often think that's how many of us treat GnuPG. Securing communications is *hard*. Tool development, which is only one part of the equation, is easily-definable and quite tractable. And rather than say, okay, the easily-definable and quite tractable part is done to an acceptable level, now let's tackle the hard stuff, we instead have a tendency to shout No! 3DES shouldn't be a mandatory cipher! It's weak! And oh God we're using 2048-bit keys by default and that's a disaster! And we don't support larger than 4096-bit keys! And... Rather than tackle the Herculean problem of pulling the weeds from the garden, we insist on gilding all the lilies... and then gilding them again and again and again, because there's still so much work to do. All the while, the weeds keep growing. So, yeah. Violent agreement here. I see a community that's obsessed with gilding the lily again and again, and that has been very resistant to suggestions that we need to broaden our perspective. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Where do you take that from? From the plain meaning of the word, expiration. There's a half-finished liter of milk in my fridge that's now a week past its expiration date. (Yes, yes, I'm going to throw it out once I get home...) If you want, feel free to come by. I'll pour you a glass of milk. After all, an expiration date doesn't mean don't use this, right? It's only a number that's to be interpreted according to however someone wants. But it is absolutely not OK to enforce this really not obvious interpretation on others. As has already been explained elsewhere, this cannot be enforced. It is not GnuPG's job to set policy: if you really need the ability to encrypt to expired certificates, go right ahead and do it. However, there is something to be said for making people go through an additional couple of hoops before shooting themselves in the foot. In other words: OpenPGP users are used to their statements being (easily) ignored. In the cases you made, I think GnuPG would be improved by removing those options. This argument really isn't a winner. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/15/14 12:06 PM, Hauke Laging wrote: Am Mo 15.09.2014, 09:47:21 schrieb David Shaw: I disagree with this. Expiration is the way the key owner (the person who knows best whether the key should be used or not) tells the world, Do not use this key after this date. Where do you take that from? Neither the RfC uses this description nor GnuPG nor any GUI I know. Hauke, Is this perhaps a language issue? The common English meaning of the word expire is that after the date listed the thing that expired is no longer valid/good/useable/etc. As far as I can tell, everyone on this list who responded to you had the same understanding, which is that after the expiration date the key is no longer valid. (A view I share, FWIW.) Meanwhile, you're presenting the options for an expired key as use the key, or send plain text. There is a third, and I daresay significantly more preferable option, which is to use OOB communication to ascertain how the other party would like you to proceed. Imagine this scenario ... Alice sets an expiration date on her key because she knows that after that expiration date her key is: 1. Likely to be compromised 2. Certain to be compromised 3. No longer in her control 4. Is actually now in Mallory's control 5. Other You have no way to know which of those scenarios is the case. Further (assuming that you took the step of refreshing Alice's key) you have no way to know why she did not update the expiry date. In this situation, it is certainly NOT safe to use that key for encryption, and in fact Don't send the message at all is almost certainly the right answer, unless you can determine in some OOB manner what Alice wants you to do. So FWIW, I think that GnuPG is doing the right thing here, and you may wish to reconsider your perspective on the issue. hth, Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Sep 15, 2014, at 3:06 PM, Hauke Laging mailinglis...@hauke-laging.de wrote: Am Mo 15.09.2014, 09:47:21 schrieb David Shaw: I disagree with this. Expiration is the way the key owner (the person who knows best whether the key should be used or not) tells the world, Do not use this key after this date. Where do you take that from? Neither the RfC uses this description nor GnuPG nor any GUI I know. It is OK (not meaning: being safe from getting criticized by the key owner for sending clear text instead) if you treat the expiration date this way. But it is absolutely not OK to enforce this really not obvious interpretation on others. I suspect that the word expired was expected to be clear on its own in the RFC. If there was some non-common meaning of expired, the term would have been explicitly defined. RFCs don't seek to confuse things. 5.2.3.6 defines it as the validity period of the key. In other words, after that specified time has elapsed, the key is not valid. Are you arguing that in other places we allow people to use non-valid keys, so why not here as well? I don't agree with that, but I do understand it. (valid being a fairly weakly defined term without, yes, policy). In any event, the choice being presented here between use an expired key vs send in plain text strikes me as misleading. There is a third case, which is Stop. Something is wrong. Figure it out before proceeding. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Monday 15 September 2014 at 9:48:47 AM, in mid:CAAu18hcXojRy=z3bh0kopuezoa9qvogcwr+rmpqgc2enrzv...@mail.gmail.com, Nicholas Cole wrote: Opportunistic encryption with a fall-back mode to plain text, which seems to be your model, is dangerous. Yes, it is always dangerous to have a protocol that sends in plain text if encryption is impossible. I would characterise the use of Opportunistic encryption somewhat differently:- 1. Plaintext is expected. and 2. If encryption is possible I'll use it, but that's a bonus. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Life is far too important a thing ever to talk seriously about -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlQXSZxXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pnVsD/0psQRGyGcZcaHK+IhhNDknlsfdN4JTilJCq vCAZbszBN2jEFM6t32sCdJYz5gDmOVnS2Z6UwqnBUNwT2jjU0Co7ayjDXsr7emdw X9KtBUwQzYbUknD/k0RRjOhntMPJZIs80DyieZxSag9SAnaxET0Uf4Znh6ECKxcg OZX+WBkh =yw+0 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Rather than tackle the Herculean problem of pulling the weeds from the garden, we insist on gilding all the lilies... Sorry, that's idiomatic English. For the non-English speakers: gilding the lily means to foolishly try to improve on something that's already magnificent. Gilding means to paint something with gold. A lily is already a beautiful flower: gilding the lily will not make it more beautiful -- it will only waste your time and your labor. Not to be confused with gelding the filly, which, if you're doing, well, as I said, you're probably quite confused... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/15/2014 at 3:57 PM, Robert J. Hansen r...@sixdemonbag.org wrote: if you really need the ability to encrypt to expired certificates, go right ahead and do it. However, there is something to be said for making people go through an additional couple of hoops before shooting themselves in the foot. = GnuPG tries to be very accommodating to almost all types of users, and has succeeded admirably in this case. I always wondered why anyone would ever really 'need' an expiration date, and how they would know in advance that they would need it to expire in the exact time they listed when the key was generated. A simple way to work around it, is to designate another one of the person's most trusted keys, as the 'revoker' key, or to generate a revocation certificate right after the key was made, and that way, if there is any future reason to not want people to encrypt to that key, to just revoke it then. But, if for whatever reason, one didn't do so, and lost the key or forgot the passphrase, and wanted the key to eventually 'pass on', then one could insure for its painless expiration, by making a timely expiration date ... Now, suppose someone got into the habit of routinely making an 'expiration' date, but still has the the secret key and passphrase, and didn't yet generate a newer encryption key, then it's nice for him to know that GnuPG allows for the possibility for people to still encrypt to that key, until he makes other arrangements, and that GnuPG is prudently set up so that it 'shouldn't be 'too easy' to do, so that one will think twice it one 'really' needs to do it. vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Monday 15 September 2014 at 8:06:17 PM, in mid:5740197.zZZLHD6fs4@inno, Hauke Laging wrote: (I would support future revocations in the next OpenPGP version though). How would this future revocation differ from an expiry date? - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net ETHERNET(n): device used to catch the Ether bunny -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlQXUJVXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pwdcEAL704IYOWIqV6W8eBdAHvxmc88mO20CaND6s IypPoa+j/hm9id9LYNqv4SYLtu6BprC1wfEvp36srJ5urY8mweTrg0p9ZWyIchCg ilnwXu9pH3V1BdzDZaCgaKnfhUDNr9ZtbD2dWhNkI82hxR7Vt1LgvShePv7WLgpM jKuNRir7 =Bevw -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 09/15/2014 04:16 PM, David Shaw wrote: There is a third case, which is Stop. Something is wrong. Figure it out before proceeding. I think Hauke is explaining that he is already in this third case; he figured out what was wrong (his peer doesn't have the means to update the cert's expiration date right now, but does not believe the key is compromised), and is now trying to get to the proceeding part. But the obvious path to proceed is to go ahead and use the key anyway, which gnupg isn't letting him do (without, say, a reset of the system clock or libfaketime or something). I agree with Hauke here that GnuPG should not be this strict for this circumstance, particularly because it is not setting strong policy elsewhere. I consider encrypting to a key with no certifications on it at least as problematic as encrypting to a key whose well-certified cert has recently expired. GnuPG lets you encrypt to the former, but not the latter. There are reasonable policy use cases (e.g. opportunistic encryption) that suggest that both mechanisms should be available (though they should both produce a warning under default policy for sure). --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Monday 15 September 2014 at 7:43:13 PM, in mid:caau18hd_gw8c567cndl2fakkhdrr-pfsbpfb8ydkomrrcp1...@mail.gmail.com, Nicholas Cole wrote: Even Apple, who have every incentive to do so and control of both hw and sw, can't manage to keep their platforms secure. In what way does Apple have any more incentive than anybody else to secure their platforms? - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Don't talk unless you can improve on the silence -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlQXV1VXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pq1QEAMEfdgluVoBSyaLAkDJKRzk0oN2qK0vSAaxC N2zdpXoT7QNM6FMmkh48TwqgrgO3QJ8lgr7ZRJQTIGCohPwWhXKEstMiGG1ATMvY qqVqsJ9MZMNcUMQ9KqSD/j8oDzHUCk3tPlchE1jzSm724CNvxp76spsuCfXSWFqr /QF0eFN7 =og0G -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Mon, 15 Sep 2014 21:22, do...@dougbarton.us said: Imagine this scenario ... Alice sets an expiration date on her key because she knows that after that expiration date her key is: 0. Deleted to achieve some forward secrecy. Actually the sematics of an expired (sub)key may come from the 1999 or so idea of adding features to mitigate the effect of the UK RIP act (or whatever it is called now). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Mo 15.09.2014, 13:19:10 schrieb Robert J. Hansen: Yes, OpenPGP is quite permissive about letting people encrypt to expired certificates, Did you really mean that? I am not aware of any way how to do that within GnuPG (i.e. without faking the time which would affect a signature). This thread started with my question whether that was possible and except for this remark by you nobody has even indicated that it could be done. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/15/14 2:26 PM, Werner Koch wrote: On Mon, 15 Sep 2014 21:22, do...@dougbarton.us said: Imagine this scenario ... Alice sets an expiration date on her key because she knows that after that expiration date her key is: 0. Deleted to achieve some forward secrecy. Yeah, I'm sure there are other scenarios I was not smart enough to consider. :) Actually the sematics of an expired (sub)key may come from the 1999 or so idea of adding features to mitigate the effect of the UK RIP act (or whatever it is called now). Wow, blast from the past. :) It's not clear to me how you're tying those 2 things together though. Meanwhile, I left out of my previous post my overwhelming dislike of the expiration date feature. :) Robert has a really good point about GnuPG not providing policy, and unfortunately a lot of users see the expiration date knob and cannot resist the urge to twist it, without understanding what it means, or why it should (or should not be) used, or in many cases even that they themselves can extend the expiration date if they choose to. Frankly I wish the option had never been added to the spec, but (thankfully) I'm not in charge. :) Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/15/14 1:52 PM, Daniel Kahn Gillmor wrote: I think Hauke is explaining that he is already in this third case; he figured out what was wrong (his peer doesn't have the means to update the cert's expiration date right now, but does not believe the key is compromised), and is now trying to get to the proceeding part. So let's practice some argumentum ad absurdum. Let's say that I'm Hauke's correspondent, and I set an expiration date on my key because I felt there was a legitimate concern that myself, my key, or both were going to come under the control of a hostile entity. Now that worst case scenario has actually occurred, and it is no longer safe for anyone to send me encrypted communications using that key. But HALLELUJAH!, I'm safe because the software honors the spec and will not allow Hauke to encrypt to my key because it is expired. But Doug, that's ridiculous! Hauke's correspondent already told him that it's safe. Well of course she did, because that's what the hostile entity TOLD her to say. :) Now that scenario has a lot of potential holes in it, so please don't waste electrons arguing how plausible it is or is not. The point I'm trying to make is simply that we don't know what we don't know. What we do know is that at this time Hauke's correspondent is not in control of her key, and as a result it's not safe to encrypt content to it. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Yes, OpenPGP is quite permissive about letting people encrypt to expired certificates, Did you really mean that? I am not aware of any way how to do that within GnuPG... Yes. Hence my choosing of the term OpenPGP, as opposed to GnuPG. signature). This thread started with my question whether that was possible and except for this remark by you nobody has even indicated that it could be done. Within the OpenPGP spec, there's nothing preventing you. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
What we do know is that at this time Hauke's correspondent is not in control of her key, and as a result it's not safe to encrypt content to it. Minor nit: it is not that we know Hauke's correspondent is not in control of her key -- it is that we do not know if she is. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On 9/15/14 3:10 PM, Robert J. Hansen wrote: What we do know is that at this time Hauke's correspondent is not in control of her key, and as a result it's not safe to encrypt content to it. Minor nit: it is not that we know Hauke's correspondent is not in control of her key -- it is that we do not know if she is. In dkg's version of this particular conjecture he said, his peer doesn't have the means to update the cert's expiration date right now. I think my conclusion, she does not currently have control of her key is reasonable, although I admit to a bit of hyperbole in order to make my version of the conjecture seem more dramatic. :) OTOH, what scenario do you envision where not having the means to update the certificate does not translate into not having control of the key, even if on a temporary basis? I'm not saying that the key is compromised ... simply that she does not have access to all the things she needs (secure computer, the secret key, etc.) at this time. If you don't call that not in control what terminology do you think is more appropriate? Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
If you don't call that not in control what terminology do you think is more appropriate? Loss of control breaks continuity of control, and CoC is the sine qua non of certificate management. She lost control of the cert == CoC is broken, do not use again even if control is re-established I do not know if she has control of the cert == CoC may be broken, do not use until CoC can be established. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Mo 15.09.2014, 15:02:14 schrieb Doug Barton: I set an expiration date on my key because I felt there was a legitimate concern that myself, my key, or both were going to come under the control of a hostile entity. a) What period do you choose for that? A day, a week, a month, a year? b) What prevents this hostile entity from extending the validity period? Now that worst case scenario has actually occurred, and it is no longer safe for anyone to send me encrypted communications using that key. But HALLELUJAH!, I'm safe because the software honors the spec and will not allow Hauke to encrypt to my key because it is expired. You are under the control of a hostile entity but you are safe? Lucky you! What would happen in real life? Someone in such a situation (personal safety at risk) would establish a policy for key usage with those contacts who send information to him of which the disclosure might cause severe problems. In other words: Even if GnuPG allowed them to use expired keys (if expiration was considered a security means under this policy) they would not consider using them. Und the other hand: Everyone who relies on expiration disabling being enforced (and seriously: Who does? Who even knew before this thread what the exact behaviour of GnuPG is? Not even I did. And I a quite sure that information which not even I have about GnuPG cannot be the base for an expectation motivated rule.) is dangerously stupid. The point I'm trying to make is simply that we don't know what we don't know. That does not seem like an argument to me for telling the user what is best for him. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Am Mo 15.09.2014, 15:56:04 schrieb Robert J. Hansen: There's a half-finished liter of milk in my fridge that's now a week past its expiration date. (Yes, yes, I'm going to throw it out once I get home...) If you want, feel free to come by. I'll pour you a glass of milk. After all, an expiration date doesn't mean don't use this, right? It's only a number that's to be interpreted according to however someone wants. It is quite similar to the certificate case. It is (if exceeded) a warning to the user: Think well before you use it. Don't blame me if you do. And not I will be really upset if you use it!. For the milk we get here I guess most people would not consider it a problem if it has exceeded its expiration date by one or two days. For other food even weeks or months may not seem dangerous. But you can still access the milk without having to break additional locks. The big difference between food and keys is that you know that food becomes bad. You do not exactly know when. The milk producer cannot make the milk in your fridge good milk by printing a later date on it. For keys this is common. On the other hand I would handle certificates differently if one has expired two weeks ago and the other one two years ago. I would handle them differently if it was the first contact for one and I had regularly (and recently) used the other. It is not GnuPG's job to set policy That's what I am asking for. if you really need the ability to encrypt to expired certificates, go right ahead and do it. It seems that I would have to patch the code for that. Beside the fact that this would indeed affect security I do not want a solution for me only but an improvement for the OpenPGP environment. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
That does not seem like an argument to me for telling the user what is best for him. Hauke, this entire argument is what I meant when I talked about gilding the lily repeatedly. If you can find half a dozen *real users* who are being *really impacted* by this, I'd love to hear about them. But so far, all the discussion is so hypothetical that it's hard for me to take it seriously. I get that you view the current situation as in need of changing. I don't agree, and I won't agree until I see six real life users whose usage of GnuPG would be made significantly better by making this change. Until then, all I can do about this 'problem' is yawn. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tue, Sep 16, 2014 at 1:12 AM, Robert J. Hansen r...@sixdemonbag.org wrote: That does not seem like an argument to me for telling the user what is best for him. Hauke, this entire argument is what I meant when I talked about gilding the lily repeatedly. If you can find half a dozen *real users* who are being *really impacted* by this, I'd love to hear about them. But so far, all the discussion is so hypothetical that it's hard for me to take it seriously. I get that you view the current situation as in need of changing. I don't agree, and I won't agree until I see six real life users whose usage of GnuPG would be made significantly better by making this change. Until then, all I can do about this 'problem' is yawn. ^ The six-real-user test should really be applied to all features in all software! Hauke, you make one strong case and one weak one. Yes, I agree that GnuPG already lets you override so many things, why shouldn't it let you override this? It's not exactly logical (though I think that one can reconstruct the logic). But you are on weak ground when you try to say that expiration dates are only a warning, or draw a distinction between 'strong' and 'weak' statements that a key should not be used. That maybe how you use them, and it may be that expiry dates on milk are only warnings, but I have always read an 'expiry date' on a key to mean 'Do not use after this date', just like an expiry date on an ID card. Yes, perhaps you do use them in other ways, but still. I can see you've hit a key-management problem. That is really the thing that needs fixing, and if easy tools to do that are not available, then they need to be. Robert is right, I think. A little more 'policy', at least in the sense of software assisting a shared sense of good practice, would really help. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
encrypting to expired certificates
Hello, after filing a bug report for my mail client because it does not allow me to encrypt to an expired certificate (neither does Enigmail) I was surprised to notice that I didn't manage to encrypt to an expired certificate with gpg in the console (2.0.22). Is this not possible (what about gpgme?) or am I just not aware of how to get that done? I would consider not being able to encrypt to an expired key a severe security flaw because it may force the sender to send the message unencrypted. It is OK to warn the user but it must be possible to override this warning. Expiration is not a security problem (let alone a severe one). It does not even work with --encrypt-to. And the man page says about this command: No trust checking is performed for these user ids and even disabled keys can be used. Non-valid keys are OK, disabled keys are OK but the least severe case expiration is not OK? Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
