Best practice for periodic key change?

[Jerome Baum]

On Sat, May 7, 2011 at 01:43, MFPA <expires2011 at ymail.com> wrote:

> On Saturday 7 May 2011 at 12:11:06 AM, in
> <mid:BANLkTimNq9nxpf23=pE2n0rR1sTnH3Aicw at mail.gmail.com>, Jerome Baum
> wrote:
>
> > Say my sub-key expired yesterday. Today, you come
> > up to me and ask me to sign something (say, a statement
> > that I agree to specific contractual terms). Whoever is
> > in possession of my sub-key cannot sign that document
> > as at the time that the statement was made available to
> > me for signing, the sub-key was already invalid.
>
> The timestamp of the signature proves nothing. It is merely the time
> on the system clock when the signature was made. The system clock may
> be correct or incorrect; in your scenario above, it looks like you set
> it deliberately a day behind in an attempt to generate plausible
> deniability for your signature.


Then I would say it is the recipients responsibility to only accept
"reasonable" signatures. As you say, it is only an "attempt" to generate
deniability -- nobody who's right in their mind would accept a signature on
a document that is dated before the document itself.

Assuming a responsible recipient, the expiration date makes sense. Yes, a
responsible recipient would refresh their keys. Yes, man-in-the-middle. The
expiration date makes a difference here.

MPFA wrote:

> OK, when was this message signed?
> When was it sent?
> When did the server receive it?


Exactly my point. The three timestamps are different (actually, there is a
fourth time, though not timestamp -- there's "when was this message signed"
and "when was this message allegedly signed). When it was sent and when it
was received wasn't what I meant with the "date of the message". That date
is when it was signed. But I have no idea of knowing when it was signed, so
I have to assume it is when it was allegedly signed -- and yes, this is a
problem under certain circumstances. However, there is at least one
circumstance where the expiration date *does* make a difference, which is
the document dated in the future relative to the signature timestamp, from a
then-already expired key. So in at least one case, the expiration date
helps. It is also not very expensive to have an expiration date. That was my
argument for usefulness.

Let's get a concrete idea of such a "document". Say I want a statement from
you that you legally have access to an email account today. Today is
2011-05-07. I have your key, with a signing sub-key that expired in 2010. I
refresh your key but Mallory manipulates the traffic and so a revocation
certificate wouldn't have helped. It's a good thing that your sub-key
expired, though, because I won't accept the signature from that sub-key as
I'm looking for an up-to-date statement. In fact, I'll probably want: "As of
2011-05-07, I legally have access to email at example.com". There is *no way* I
would accept that when the signature is dated in 2010.

Does that make my point more clear? I wasn't saying that under all
circumstances the expiration date helps. That would be crazy. I was saying
that there are circumstances where it does, and since the cost is so low,
that there is no point in not having them (assuming, of course, that you
separate master and sub-keys).

-- 
Jerome Baum

tel +49-1578-8434336
email jerome at jeromebaum.com
-- 
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110507/1986b8dc/attachment.htm>