Subject: RE: [ietf-dkim] Straw poll on x=

From: <[email-masked]>
Date: Tue, 18 Apr 2006 17:28:17 -0400

Current
x=   Signature Expiration (plain-text; RECOMMENDED, default is no
       expiration).  The format is the same as in the "t=" tag,
       represented 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.
       The value is expressed as an unsigned integer in decimal ASCII,
       with the same constraints on the value in the "t=" tag.  The
value
       of the "x=" tag MUST be greater than the value of the "t=" tag if
       both are present.

           INFORMATIVE NOTE:  The x= tag is not intended as an anti-
           replay defense.

Proposed
x=    Expiration date (plain-text; RECOMMENDED, default is no
       expiration).  The format is the same as in the "t=" tag,
       represented 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.
       The value is expressed as an unsigned integer in decimal ASCII,
       with the same constraints on the value in the "t=" tag.  The
value
       of the "x=" tag MUST be greater than the value of the "t=" tag if
       both are present.

           INFORMATIVE NOTE:  The x= tag is not intended as an anti-
           replay defense. Its proposed use is to indicate Key/Signature
expiration. When message is considered expired It becomes the
policy of the verifier on how to further process the message.

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 Stephen Farrell
Sent: Tuesday, April 18, 2006 4:58 PM
To: ietf-dkim
Subject: Re: [ietf-dkim] Straw poll on x=

Results are in:

Keep (8)

[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]

Remove (9)

[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked] (Jim Hill)
[email-masked]

And that includes a vote that changed sides! Let me know
if I've missed anyone, but I suspect it won't make a
difference really.

So there is no clear consensus to delete x=, therefore
we go with the status quo.

Could I ask that someone try propose text for the draft
to clarify the meaning of x=, bearing in mind all of
the list discussion?

Stephen.

_______________________________________________
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: Paul Hoffman <[email-masked]>
Date: Tue, 18 Apr 2006 15:28:34 -0700

>policy of the verifier on how to further process the message.

There is a *huge* difference between key and signature expiration. 
Given that x= appears in a signature, the informative note should say 
"...indicate signature expiration". But, if we do that, we need to 
say what it means for a signature to expire. We can reuse semantics 
on signature expiration from other IETF specs, if we can find one 
that has expiring signatures.

The last sentence in the informative note directly contradicts the 
MUST NOT in the body of the definition. I understand some people want 
it one way and others want it the other way, but we can't have a spec 
that says both.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 19 Apr 2006 21:07:43 -0700

Paul Hoffman wrote:
> "...indicate signature expiration". But, if we do that, we need to say
> what it means for a signature to expire. We can reuse semantics on
> signature expiration from other IETF specs, if we can find one that
> has expiring signatures.
>
+1

There is also a huge difference between key or signature expiration, and
message expiration.  The text "When message is considered expired"
implies that the message itself expires, which it does not do.

-Jim

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 20 Apr 2006 10:21:56 -0700 (PDT)

> implies that the message itself expires, which it does not do.

The text should be "message signature should be treated as invalid after
the the expiration date". This does not say anything about the message
itself being expired only the signature

BTW, the feature saying the message itself is valid up to certain date 
could be quite useful. Many emails are written with expectations that
they would be read in 1-2 days and if not done message content is no 
longer of a significant use to the recipient. This is however a
separate issue.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Mark Delany <[email-masked]>
Date: Thu, 20 Apr 2006 18:02:48 +0000

> longer of a significant use to the recipient. This is however a

Would that be the obsolete Expiry-Date:?

Mark.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 20 Apr 2006 11:52:26 -0700 (PDT)

> Would that be the obsolete Expiry-Date:?

Unless I'm mistaken there is a field called Expires which obsoluted
Expiry-Date.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 20 Apr 2006 11:59:47 -0700 (PDT)

> Unless I'm mistaken there is a field called Expires which obsoluted

Looking at it more, it maybe that Expires is used by different MIME
protocols and is not normally used by email except when mapping from
X.400 or other protocol that actually has this feature. Anyone knows
for sure?