encrypting to expired certificates

[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"?

> 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>