Subject: RE: [ietf-dkim] x= lets senders expire responsibility

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Apr 2006 05:41:31 -0700

I disagree. 

I think the semantics are 'don't count on being able to verify this message
after this date'.

If I do manage to verify I can hold the purported signer resposible
regrdless of wheter x= is there or not.

My fault handling process for 'key not found' is going to be different if x=
has expired.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Delany
> Sent: Wednesday, April 12, 2006 2:13 AM
> To: [email-masked]
> Subject: [ietf-dkim] x= lets senders expire responsibility
> 
> On Wed, Apr 12, 2006 at 01:07:22AM -0400, Hector Santos 
> allegedly wrote:
> 
> > > Remove x=
> 
> > IMO, there is a precise and purposeful rationale.   I  can 
> come up with
> > atleast a dozen reasons or more why a signer may want to utilize an 
> > expiration concept.
> 
> As you say, and I agree, the benefits flow mostly, if not 
> entirely, to the signer ... even though earlier discussions 
> mooted benefits to the verifier.
> 
> 
> As I understand it, when x= expires the signer wants 
> verifiers to treat the mail as unverified - in effect signers 
> get to disclaim responsibility for that email after a certain 
> point in time.
> 
> This seems entirely at odds with DKIM which is about senders 
> taking responsibility for an email for the benefit of the verifier.
> 
> DKIM is not about senders taking responsibility for just 5 
> seconds or just 5 minutes or just 5 days. If a mail is signed 
> and sent, a sender has no right, in my mind, to subsequently 
> disclaim responsibility. It's their content; they wear the 
> consequences forever.
> 
> In short: x= gives senders wiggle room to expire 
> responsibility - that seems at odds with our goals.
> 
> 
> Mark.
> _______________________________________________
> 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: "william(at)elan.net" <[email-masked]>
Date: Wed, 12 Apr 2006 07:37:23 -0700 (PDT)

> I think the semantics are 'don't count on being able to verify this message

This is signer's policy information. From what I've seen so far its 
largely the same set of people who are against this as those against
what you call SSP. I'm afraid this maybe a light prelude to what
you'll see in SSP debates....

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Apr 2006 09:06:47 -0700

>I think the semantics are 'don't count on being able to verify this message

Why would you think that? The semantics of x= say nothing about those 
semantics:
        Signature expiration in seconds-since-1970 format
        as an absolute date, not as a time delta from the signing
        timestamp.  Signatures MUST NOT be considered valid if the
        current time at the verifier is past the expiration date.
If you *want* the semantics to mean 'don't count on being able to 
verify this message after this date', that's fine, but you need to 
ask the WG to change the document for that to happen.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 12 Apr 2006 12:35:09 -0400

----- Original Message ----- 
From: "william(at)elan.net" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>

>> I think the semantics are 'don't count on being able to 
>> verify this message after this date'.
> 

Ha! You got that right!

Boy did you make my day. :-)

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 12 Apr 2006 15:29:37 -0400

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>

> My fault handling process for 'key not found' is going to be
> different if x= has expired.

Why isn't it possible for signers to use the same selector, but set
different expiration timestamps depending on the value of the message they
wish to sent?

It has the same effect.  The different is the the key is still technical
valid because it hashes correctly with the message signature.

This is why we "might" want to consider two cases:

    Expired Valid Signature
    Expired Bad Signature

Is this not consistent with how Browsers work today with SSL certificates?
Both sets of information is convey here.

But if you security person are saying this expiration should mean the
signature should no loner be viewed as valid even it is technically valid,
then that fine by me too.  We just need to make sure that it is consistent
for both dynamic transport level verifiers and post transpost delayed
verifiers.   For the post/delayed verifier, I think it needs to emulated the
dynamic verifier as must as possible.