encrypting to expired certificates

[Robert J. Hansen]

> 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 consequences of your decisions, a
lot more can be justified than when you are asking *other people* to
bear the consequences of your decisions.  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.