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
