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: Help about GnuPG 1.4.9
On 9/14/2014 11:05 PM, bonn...@sanboa.info wrote:
Hello,
I'm a completly new possible user of macgpg.
I want to use it but somme security questions don't be resolved :
I've a Mac with Mac OS 10.5.8 Intel Core 2 duo with AppleMail 3.6 and
want to download the free software.
Welcome! Hopefully we can get you straightened out!
I've falled on this site : http://macgpg.sourceforge.net/fr/index.html
which lets download this :
/GNU Privacy Guard/ - pour Mac OS X 10.1 (et suivantes)
* Pour Mac OS X 10.4.x et plus nouveau
o GnuPG v2.x
https://sourceforge.net/project/showfiles.php?group_id=248469,
now a separate project.
o 1.4.9
http://prdownloads.sourceforge.net/macgpg/GnuPG1.4.9.dmg?download,
MD5: 36d9eb482a98774521bfd7bb73e4ad06
I've choosen 1.4.9
GnuPG 1.4.9 is a bit out of date. https://gpgtools.org/ should have a
more recent version, but it seems that it will only work back to Mac OS
X 10.6, not 10.5.
Can you upgrade to a newer version of Mac OS X? 10.5 is quite old and
reached end-of-life in 2011.
You might find
http://support.gpgtools.org/discussions/problems/10783-gpgtools-for-mac-osx-1058
to be of some interest.
But after, I've read : *Never use a GnuPG version you just downloaded
to check the integrity of the source* - use an existing GnuPG installation.
on : https://www.gnupg.org/download/integrity_check.html
and that's the problem for me :
_how can I know if the software downloaded is secure or not ?_
I followed the advices :
gpg --verify 1.4.9
sha1sum 1.4.9
etc., on Terminal.app
It's possible that Mac OS X 10.5 does not have gpg, openssl, or sha1sum
installed. I'm not familiar with systems that old.
However, it appears that the system does have a means of calculating MD5
checksums. You should be able to run the following command from a terminal:
/sbin/md5 /Users/alain1/Desktop/GnuPG1.4.9.dmg
Alternatively, if the Mac has GPG installed already (I know that newer
versions of Mac OS X do, but I'm not sure about 10.5), you can run the
following from the terminal:
gpg --print-md MD5 /Users/alain1/Desktop/GnuPG1.4.9.dmg
but never appeared the good suite MD5 of numbers and letters !
history:
'openssl md5 [nomDeFichier]'Last login: Sun Aug 16 17:52:58 on console
Ordinateur-839:~ alain1$ 'openssl md5
[/Users/alain1/Desktop/GnuPG1.4.9.dmg ]'-bash: openssl md5
[/Users/alain1/Desktop/GnuPG1.4.9.dmg ]: No such file or directory
Ordinateur-839:~ alain1$ 'openssl md5 [GnuPG1.4.9]'
-bash: openssl md5 [GnuPG1.4.9]: command not found
Ordinateur-839:~ alain1$ openssl md5 [/Users/alain1/Desktop/GnuPG1.4.9.dmg]'
What happens if you run the command without the square brackets ([]) or
the single quotes (')?
For example,
openssl md5 /Users/alain1/Desktop/GnuPG1.4.9.dmg
Thus, my second question :
_With which application can I check that the software downloaded is
secure (writing openssl md5…)_
OpenSSL is installed in newer Mac OS X systems, but might not be
installed on 10.5. If it's not installed, you could install it but
that's typically not a trivial thing to do.
Check if it's installed by running:
openssl version
from the terminal.
As for your other questions, I'm not sure. Hopefully someone else can
answer.
Cheers!
-Pete
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
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: setting env vars for gpg-agent
Hi Werner,
So, I replaced my content in .bashrc with yours, but the behavior is
still exactly the same.
* ssh smartcard auth works accross different terminals. (so the agent
must be functional)
* evolution signiging works only if started from the terminal, even if I
comment out the line : if [ $PS1 ]; then
* enigform in firefox doesn't sign the headers.
I did not understand the last paragraph with gpg-connect-agent /bye.
But since the ssh part is working, I don't think that's necessary.
Rgds
Richard
Am Sonntag, den 14.09.2014, 11:31 +0200 schrieb Werner Koch:
On Sat, 13 Sep 2014 22:02, ricu...@gmail.com said:
After gpg-agent stopped to work for ssh auth from OpenPGP smartcard
after some ubuntu upgrade a while back, I launch it and set the env
variables in ~/.bashrc.
I suggest to lauch gpg-agent on the fly: Add
use-standard-socket
to ~/.gnupg/gpg-agent.conf and remove all settings of GPG_AGENT_INFO. I
use this in my ~/.bashrc :
--8---cut here---start-8---
# If running interactively, then:
if [ $PS1 ]; then
# Setup information required by GnuPG and ssh. We use the standard
# socket in GnuPG's homedir, thus there is no need for an
# environment variable. We reset any left over envvar.
# SSH_AGENT_PID should not be set either because it is only used to
# kill ssh-agent (option -k) but we don't want this to kill
# gpg-agent. Because ssh does not know about GnuPG's homedir we
# need to set its envvar to gpg-agent's ssh socket. GPG_TTY needs
# to be set to the current TTY. The extra test is used to avoid
# setting SSH_AUTH_SOCK if gpg-agent has been started with the
# shell on the command line (often used for testing).
unset GPG_AGENT_INFO
unset SSH_AGENT_PID
if [ ${gnupg_SSH_AUTH_SOCK_by:-0} -ne $$ ]; then
export SSH_AUTH_SOCK=${HOME}/.gnupg/S.gpg-agent.ssh
fi
fi
export GPG_TTY=$(tty)
--8---cut here---end---8---
If you want to use gpg-agent's ssh-agent implementaion, you need to make
sure that gpg-agent is started (becuase ssh does not know how to start
gpg-agent). You may do this with gpg-connect-agent /bye
This works since 2.0.16 released 4 years ago. Recent veNote that if you
have ~/.gnupg on some remote file system, this may not work.
Salam-Shalom,
Werner
___
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: setting env vars for gpg-agent
Hi Werner,
I just discovered that signing deb packages is not as smooth as before.
* If I have an active gpg-agent session, it fails with the following
error:
clearsign failed: Allgemeiner Fehler
* If I reinsert the card, I get thw following :
gpg: GPG-Agent ist in dieser Sitzung nicht vorhanden
Geben Sie die PIN ein:
Then I have to enter the pin twice in the terminal. In all other
instances so far it was always in the graphical pinentry dialog.
I can verify, that gpg-agent is still running, and still working for
ssh.
But for regular gpg operation I discovered also other problems:
$ gpg -d mhs_paraeasy_ch.txt.gpg
gpg: Anonymer Empfänger; Versuch mit geheimem Schlüssel 0xx …
Bitte entfernen Sie die Karte und legen stattdessen die Karte mit
folgender Seriennummer ein:
D27xxx
Drücken Sie 'Eingabe' wenn fertig; oder drücken Sie 'c' um abzubrechen:
All this worked with the previous content in .bashrc.
Rgds
Richard
Am Montag, den 15.09.2014, 21:17 +0200 schrieb Richard Ulrich:
Hi Werner,
So, I replaced my content in .bashrc with yours, but the behavior is
still exactly the same.
* ssh smartcard auth works accross different terminals. (so the agent
must be functional)
* evolution signiging works only if started from the terminal, even if I
comment out the line : if [ $PS1 ]; then
* enigform in firefox doesn't sign the headers.
I did not understand the last paragraph with gpg-connect-agent /bye.
But since the ssh part is working, I don't think that's necessary.
Rgds
Richard
Am Sonntag, den 14.09.2014, 11:31 +0200 schrieb Werner Koch:
On Sat, 13 Sep 2014 22:02, ricu...@gmail.com said:
After gpg-agent stopped to work for ssh auth from OpenPGP smartcard
after some ubuntu upgrade a while back, I launch it and set the env
variables in ~/.bashrc.
I suggest to lauch gpg-agent on the fly: Add
use-standard-socket
to ~/.gnupg/gpg-agent.conf and remove all settings of GPG_AGENT_INFO. I
use this in my ~/.bashrc :
--8---cut here---start-8---
# If running interactively, then:
if [ $PS1 ]; then
# Setup information required by GnuPG and ssh. We use the standard
# socket in GnuPG's homedir, thus there is no need for an
# environment variable. We reset any left over envvar.
# SSH_AGENT_PID should not be set either because it is only used to
# kill ssh-agent (option -k) but we don't want this to kill
# gpg-agent. Because ssh does not know about GnuPG's homedir we
# need to set its envvar to gpg-agent's ssh socket. GPG_TTY needs
# to be set to the current TTY. The extra test is used to avoid
# setting SSH_AUTH_SOCK if gpg-agent has been started with the
# shell on the command line (often used for testing).
unset GPG_AGENT_INFO
unset SSH_AGENT_PID
if [ ${gnupg_SSH_AUTH_SOCK_by:-0} -ne $$ ]; then
export SSH_AUTH_SOCK=${HOME}/.gnupg/S.gpg-agent.ssh
fi
fi
export GPG_TTY=$(tty)
--8---cut here---end---8---
If you want to use gpg-agent's ssh-agent implementaion, you need to make
sure that gpg-agent is started (becuase ssh does not know how to start
gpg-agent). You may do this with gpg-connect-agent /bye
This works since 2.0.16 released 4 years ago. Recent veNote that if you
have ~/.gnupg on some remote file system, this may not work.
Salam-Shalom,
Werner
___
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
