Subject: RE: [ietf-dkim] Proposal: get rid of x=

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 7 Apr 2006 09:04:40 -0700

DKIM is not designed to support persistent signatures. This does not mean
that we will not end up creating any under any cirscumstances.

I don't think that the x= has any effect from a legal standpoint. Courts
currently regard an ASCII signature at the bottom of a message as rebuttable
proof of creation. Any information in the header may be used to help prove
that the message came from a particular source. Putting x= in the header
does not affect that.

If companies want to put disclaimers in their messages then they will do
something like add a footer to state 'this is not a contract unless
accompanied by a signed order, this is confidential do not read it, etc.'

I think it would be useful to have a way to express some signer semantics in
the signature or the key record. For example a way for a mailing list to say
'I am a mailing list', a way for an ISP or other open mail provider to say
that and so on.

> [mailto:[email-masked]] On Behalf Of Stephen Farrell

> (A message from the in-two-minds department:-)
> 
> Michael Thomas wrote:
> > Paul Hoffman wrote:
> >> Note that the informative note only says what x= is not. 
> Leaving x= 
> >> in can also lead to silly states.
> > 
> > What states might those be?
> 
> I was also wondering about that. I guess that "x=" is a way 
> to make it crystal clear that this signature is (probably, 
> potentially) totally worthless in some court case in 5 years 
> time - a v. good feature (*). It would also help if someone 
> wanted to auto-generate new signing key-pairs at about the 
> latency with which their DNS stuff becomes available (but I 
> don't know if that info's available to the verifier via DNS - 
> is it?). Were we to ask verifiers to interpret "x=" as 
> guidance, and not as a way in which it MUST fail a signature, 
> then its optional inclusion may well help some layer above DKIM.
> 
> However, on Paul's side of the argument, it is true that 
> many, if not most, people recognize that insisting upon X.509 
> certificates having to have a notAfter date was a mistake. 
> So, there is a bit of prima-fasciae evidence that 
> signed-things-with-stupid-expiry-values
> are problematic in some cases, though that analogy really 
> holds much better against the key record and not the 
> signature. To be concrete about problems-ensuing: I guess if 
> an MUA were DKIM-aware then "x="
> creates a dilemma for the MUA programmer in cases where the 
> mail isn't read until after the relevant time. I also 
> remember trying to shoe-horn a Kerberos thing into being 
> usable on an extranet - the clock skew was such a killer that 
> we had to open the window to ridiculous levels.
> 
> Basically, YMMV!
> 
> But, facts outweigh opinions: are there specific verifier 
> uses cases that act upon the "x=" value?
> 
> Stephen.
> 
> (*) <rant now="y"> If "x=" survives and becomes practically 
> used by verifiers then I would encourage DKIM implementers 
> who *really* want their signatures to be worthless at some 
> point in the future to agree to publish their old private 
> keys a little while after they are finished with using those 
> private keys. Giving everyone the means to repudiate old 
> transactions is IMO an excellent way to prevent a 
> lawyer/<<thing>> from pretending that you meant a signature 
> to be some kind of pseudo-non-repudiable thing!
> </rant>
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 10 Apr 2006 09:12:21 -0700

> [mailto:[email-masked]] On Behalf Of Paul Hoffman

> The receiver *could* honor the signature forever, just as 
> they can with an x= tag. But, in doing so, they would be 
> going against the semantics of the DKIM signature.

I think it is necessary to distinguish between protocol semantics and court
room semantics.

The x= tage would do nothing to change the significance of the signature in
a court of law. People seem to have the idea that putting x= would allow
repudiation after the time expired, it does not.

I don't see that it has any relevance to protocol semantics unless a mail
server starts re-injecting old mail, as occasionally happens. Every so often
an old machine is rebooted and starts executing the old mail queue.

If a party wants the x= semantic the easiest way to do it is to roll their
key distribution points (they can even use the same key).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Tue, 11 Apr 2006 01:17:27 -0400

Why would one care at all about when a sig was signed? A sig will either
pass muster or fail, if passed t=$date < curr_date raises a question of
expiration for the verifier. Obtaining the actual timestamp of when the
message was actually signed doesn't have much value for me. 

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark Delany
Sent: Tuesday, April 11, 2006 1:07 AM
To: [email-masked]
Subject: Re: [ietf-dkim] Proposal: get rid of x=

On Mon, Apr 10, 2006 at 09:11:53PM -0700, Dave Crocker allegedly wrote:
> 
> 
> John R Levine wrote:
> >Without t= we have no idea when a message was signed, since there's
no
> >particular reason that the Date: header has to contain the current
date,
> >or even that there be one.
> 
> 
> And -- just to quibble a bit, but in a *nice* way -- it would not
matter 
> even if it did contain the "current" date.
> 
> The Date field specifies the time of posting.
> 
> Signing might take place at any time after that (or even before that.)

So, color me slow. We know for sure that signing happened in the
past. What specific value do we place on how far in the past that
signing occurred? What code do I write to test that specific value and
what do you recommend that a verifier do with such knowledge?

Mark.