On Sat, May 7, 2011 at 01:43, MFPA <[email protected]> wrote: > On Saturday 7 May 2011 at 12:11:06 AM, in > <mid:[email protected]>, 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 protected]". 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 [email protected] -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
