encrypting to expired certificates

[Daniel Kahn Gillmor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140916/1a4368a8/attachment.sig>