Subject: [ietf-dkim] Attempted text for x=

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 16:44:33 +0100

Folks,

We've decided to stick with the status quo and keep
x= but we do seem to need some different text.

Barry and I would like finalising that text to be the
topic for tomorrow's jabber session. Maybe a bit
ambitious but we do need to kill the topic.

So to make that a bit easier, here's my suggestion
based on what I've seen on the list. Feel free to
beat it up, but we (as chairs) are going to have to
declare for some text after tomorrow. So beating
this up by proposing a better alternative is really
much more likely to be effective.

And during the jabber session, please try to
remind yourself that perfection is in this case
almost certainly the enemy of the good.

Stephen.

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=     Signature Expiration/Best-Before (plain-text, OPTIONAL, default is
       no expiration/best-before). The format is the same as the "t=" tag,
       represented as an absolute date, not as a time delta from the
       signing timestamp.  Verifiers who support x= MUST conside a 
       signatuure invalid if the current time at the verifier is past 
       the expiration date. If a signature is invalid for this reason, 
       then the normal rules apply, so the signature SHOULD be treated 
       the same as if cryptographic checking had failed or as if the 
       public key could not be retrieved. Verifiers MUST NOT asssume 
       that there is any particular relationship between the x= value 
       and the life cycle of a public key.
       Signers MAY include an x= value at their discretion. 
       Verifiers SHOULD support checking of x= values.
       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 NOTES:  

           1) The x= tag is not intended as an anti- replay defense.
           2) There is no real point in including a nonsense value in
              this tag - if the signer has no reason to include any 
              particular value then this tag is better omitted.
           3) There is no particular reason to include values here
              that are very far in the future, e.g. if it expected
              that a verifier might not see the message for a long
              time. In such cases omitting x= will probably be better.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Apr 2006 10:14:01 -0700

This looks pretty good! One major stumbling block, though.

At 4:44 PM +0100 4/19/06, Stephen Farrell wrote:
>. . .

 From RFC 2119, which DKIM normative references:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.
. . .
    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

What is the interoperability or harm-limiting purpose of verifiers 
checking x= values? If there is none, the sentence above needs to be 
a MAY.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 19 Apr 2006 14:15:58 -0400

Proposed change:

3.5  The DKIM-Signature header field
   
      ...

 x=  Signature Expiration (plain-text; RECOMMENDED, default is no
     expiration).  Signature expiration in seconds-since-1970 format
     as an absolute date, not as a time delta from the signing
     timestamp.  The value is expressed as an unsigned integer
     in decimal ASCII, with the same constraints on the value in
     the "t=" tag.

     The expiration is a DKIM signature descriptor exposing the
     responsible domain intent to expire or revoke a DKIM 
     signature validity. Although, in practice, this control might 
     be viewed as a domain key management and security concept, 
     the domain's true intent and purpose is out of the scope.

     If present, the expiration time MUST be compared against
     the Transaction Reception Time (TRT).  

     Extracting the TRT depends on where the DKIM verifier 
     is implemented. For transport (SMTP) level verifier
     operations, the TRT is the current system time.  For non-SMTP
     verifier operations, the TRT is the time extracted from 
     the 2822.Received: header as  required to be added by the 
     transport SMTP receiver.  

     To satisfy step 2 in section 6.2, verifiers MAY choose to 
     perform a DKIM verification before the expiration 
     time is checked.  This will help on deciding between
     a permanent or temporary response code.

     ABNF:

        sig-x-tag    = %x78 [FWS] "=" [FWS] 1*12DIGIT

6.2  Get the Public Key

  ...
  [Editor note: Renumbered the list]

  1.  If signature has an expiration (x=) tag, check if the signature
      has expired. Signatures MUST NOT be considered valid if the
      current time at the verifier is past the expiration date.
      Verifiers MAY choose to check key selector for revocation or
      DNS removal. See Step 3.

  2.  Retrieve the public key as described in (Section 3.6) using the
      domain from the "d=" tag and the selector from the "s=" tag.

  3.  If the query for the public key fails to respond and the
      signature has not expired (in step 1),  the verifier  SHOULD 
      defer acceptance of this email (normally this will be
      achieved with a 451/4.7.5 SMTP reply code).

      If the query for the public key fails to respond and the 
      signature has expired (in step 1) the verifier SHOULD
      reject the transaction of this email (normally this will be
      achieved with a 551/5.7.5 SMTP reply code).

Editor Change Checklist:

[X] Consolidate Formatting/Type text

[X] Domain signer's reasons for expiration tag is out of scope.

[X] Change Current Time to "Transaction Reception Time" to satisfy
    the two types of SMTP operations - SMTP plug-ins verifiers 
    versus post SMTP acceptance Verifiers.  To use the "Current
    Time" for post verifiers would be technically incorrect which
    could promote premature expirations.

[X] Satisfy Step 2 in Section 6.2 (now step 3).

[X] Allow for optimization consideration (No Verification Required).

[X] Remove Information Note about replay attacks.  Considered or not, 
    DKIM can't control what the VERIFIER will experience and the
    knowledge gain to address such issues.

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

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 19 Apr 2006 14:37:19 -0400

Steve, I posted my proposed change hopefully satisfying some other spec's
issues.

>        Verifiers SHOULD support checking of x= values.

I think this must be a MUST.  In my view, this is risking malpractice and
product liability problems if a domain has exclusively expressed an
expiration and it is not honored by the verifier.  If there are any harm or
damages some some entity (user or domain), this is subject for action
(asking for trouble.)   I don't think I am off base with this opinion,
especially when there is such a strong DKIM charter of establish domain
responsibility and reputation stake.

>        particular value then this tag is better omitted.

I don't think this information notes is necessary. I think covered it with
the 3rd note.

---

From: Jon Callas <[email-masked]>
Date: Wed, 19 Apr 2006 11:51:30 -0700

> x= but we do seem to need some different text.

I want to disagree with that. I don't believe we really considered  
just removing x=. When we had the straw poll, we were also talking  
about putting in implied TTLs on messages and or keys. We talked  
*around* just removing it, but a simple up/down on it wasn't the way  
I understood the straw poll.

	Jon

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 19:52:04 +0100

> Steve, I posted my proposed change hopefully satisfying some other spec's

I saw that - thanks.

> responsibility and reputation stake.

REQUIRING that the verifer honour the sender's wishes is
tricky in general and a MUST there is getting close to that,
as you say.

And I've seen no example of any actual harm that might accrue.

But whatever the consensus is...so long as we get there quickly!

> I don't think this information notes is necessary. I think covered it with

Sure, only put it in 'cause of all the 2038 type dates you see in
X.509. It may be overkill, but OTOH...

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 20:03:13 +0100

Hi Jon,

Jon Callas wrote:
> I want to disagree with that. I don't believe we really considered just 
> removing x=. When we had the straw poll, we were also talking about 
> putting in implied TTLs on messages and or keys. We talked *around* just 
> removing it, but a simple up/down on it wasn't the way I understood the 
> straw poll.

Ok, but one opinion change either way still wouldn't amount to
a consensus for change, and to be fair, I have to say I think
it was clear when I asked for keep/remove opinions only.

Stephen.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Apr 2006 12:35:37 -0700

At 2:37 PM -0400 4/19/06, Hector Santos wrote:
>expiration and it is not honored by the verifier.

Armchair lawyering should be out of scope for this discussion. 
Everyone should, of course, implement from the spec in any way they 
want to with respect to their perceptions of the law. But that's an 
implementation choice, not a spec choice.

>   If there are any harm or
>(asking for trouble.)

Similarly, threats of legal action, even by third parties, should 
also be out of scope.

>I don't think I am off base with this opinion,

I do, given the long list of IETF specifications that allow the 
recipient to decide what they do or don't want to do based on local 
policy, and the amazing lack of "malpractice and product liability 
problems" that have come up.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Apr 2006 21:45:53 +0200

Stephen Farrell wrote:
> ------------------------------------------------------------------------
>
>
> Current:
>

Hi Stephen,

Thanks for the text.  Modulo MUST/SHOULD/MAY concerns I would be okay
with your strawman.  I think MUST MUST be reserved for substantial
security problems or interoperability problems, and here I see neither. 
And so where you list MUST I would label them SHOULD.  Because we really
don't have a firm grasp on the usefulness of this function, I believe
verifiers MAY support checking of x= values.  Indeed my own perspective
is that support of x= is counter-productive because the information
contained therein should be in the DNS and not in the message.  After
all, if someone cracks the key, then x= won't really help, so the only
thing we *may* be doing is reducing the number of queries, and as DNS is
read optomized, I don't really care about that a whole lot.

Eliot

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 19 Apr 2006 16:18:21 -0400

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>

> Armchair lawyering should be out of scope for this discussion.

Armchair? Please Paul.  I have dealt with legal product liabilities every
day for the past 25_ years in corporate and private enterprises.  No
responsible manager should be ignorant of it.  Lawyers don't think things
up.  You do.  Sorry Paul. I understand the cliche and I try to avoid such
debates myself.  But when needed, you just need to bring it out before it
hurts people.  It is a new era when we are placing a new responsibility of
domains signers who seek extra protection and immediate detectable
segregation from the bad.  I can understand these product liabilities
issues and now does John Levine. From his trip report:

http://www.circleid.com/posts/california_frets_about_goodmail_email/

    ....
    In the questions that followed we learned several
    interesting things. One is that AOL and Goodmail both agree
    that they are responsible for the mail they stamp, to the extent
    that if a phish or virus sneaks through with a stamp, they're
    on the hook for damages. This is something new in the world
    of e-mail.
    ....

> implementation choice, not a spec choice.

Agree, but the specs should provide guidance. I was responding to Steve to
correct my statement and agree with your post too.  The wording should
probable be:

    Verifiers MAY support checking of x= values. If verifiers
    supports checking the  expiration x= tag, they MUST
    honor the signature expiration.

This is the safer approach. I personally don't like it when your spend alot
of effort on a new protocol and you have relaxed provisions at receivers
that basically nullifies its objectives, but I agree that you don't always
want to create situations that promotes liability issues too.

> Similarly, threats of legal action, even by third parties, should

Were you attributing my statement above to a threat?  Hahaha, out of the
world.  It was a point. Ask john. He is well verse on the subject now.

> problems" that have come up.

Absolutely, uncategortically incorrect.
If you need help

  1) Start with US EPCA 1986 provisions.
  2) See the TOC that were established because of it,
  3) See all the lawsuits that were based on it,
  4) See Canadian Malpractice Bills for ISP currently in play.
  5) See Verizon's recent settlement that was 100% reliable to your
     misconception above and lack of understanding of #1.

Many I can go on and on,  I don't wish to get into this because it is
obvious you are not well verse on product liability concerns.

It is this attitude that continues to make people believe they really can do
what they want with accepted mail.  It is fallacy and if you don't believe
that is the case, talk to a high tech lawyer that is familiar with the laws.
Or better, setup an Commercial EMAIL server, get commercial customers and go
ahead and use this "Oh Well, I can do what I want with your email" mode of
operation.  If a customer was harm, lost of business or whatever because of
your malpractice, you are liable - PERIOD. Your TOC means nothing when you
ACCEPT mail and don't deliver it without notification. That is what happen
to Verizon just last month with their Class Action Lawsuit settlement but
its long been precedence.

--
HLS

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Apr 2006 13:40:39 -0700

I think that the actual problem here is when we try to attach any sort of
receive side semantics to the presense or lack of a signature. As I've said
many times, DKIM produces many more states than just "verified"
and "unverified" since there are many, many different states in verified.
The new "bodyhash" is yet another outcome where a signature might be
partially valid (eg, good header, broken body).

The real solution here, IMO, is to resist being perscriptive about what
the receiever should do with this information. What we really need to
do is list the possible states as outcomes of the verification process and
leave it at that. Ie, no recommendation at all; just input to a receiver's
evaluation logic. That way we postpone *all* of these semantic
discussions for which we are at this point ill prepared to pass judgement.
These would make *excellent* topics for a BCP when we have some
CP.

       Mike

Paul Hoffman wrote:

> checking x= values? If there is none, the sentence above needs to be a 
> MAY.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Apr 2006 15:01:37 -0700

Proposed:

x=     Signature Expiration (plain-text, OPTIONAL, default is
        no expiration). The format is the same as the "t=" tag,
        represented as an absolute date, not as a time delta from the
        signing timestamp.

        Verifiers who support x= should consider a signature invalid
        when the [received] time at the verifier is past the
        expiration date.  Verifiers that do not support x= and
        forward messages, may refuse acceptance of messages
        when the x= tag is present to avoid causing DSNs.

        When a signature becomes invalid, and is not accepted by a
        subsequent MTA, a mechanism to rate-limit initial senders
        may be required to control the level of DSNs.  If a signature
        is initially found invalid for this reason, then normal rules
        apply, so the signature SHOULD be treated the same as if
        cryptographic checking had failed, or as if the public key
        could not be retrieved.

        Verifiers should not assume that there is any particular
        relationship between the x= value and the life cycle of a
        public key.  Signers MAY include an x= value at their
        discretion.

        Verifiers MAY support checking of x= values or may refuse to
        accept messages with the x= tag.  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 NOTES:
            1) Messages with invalid signatures or x= parameters
               may be rejected by subsequent MTAs.
            2) When the signer has no reason to include any
               particular value, then this tag is better omitted.
            3) There is no particular reason to include values far
               into the future, e.g. if it expected that a verifier
               might not see the message for a long time. In such
               cases omitting x= will probably be better.

---

From: John Levine <[email-masked]>
Date: 19 Apr 2006 22:22:03 -0000

>At 2:37 PM -0400 4/19/06, Hector Santos wrote:

Try ignoring Hector.  Just about everyone else does.

R's,
John

---

From: <[email-masked]>
Date: Wed, 19 Apr 2006 18:54:05 -0400

Why would a verifyer refuse a message that had a value for x=?
 "Verifiers MAY support checking of x= values or may refuse to
        accept messages with the x= tag."
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Douglas Otis
Sent: Wed 4/19/2006 6:01 PM
To: Stephen Farrell
Cc: ietf-dkim
Subject: Re: [ietf-dkim] Attempted text for x= with DSN considerations
 
Proposed:

            INFORMATIVE NOTES:

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 19 Apr 2006 19:02:36 -0400

Because if we put that in the spec then we've effectively gotten rid of x= 
because no one would use it then and that's what he wants perhaps?

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Apr 2006 16:34:40 -0700

>   accept messages with the x= tag."

Some MTAs are known to forward email.  Stringent examination is  
required based upon the principle a sewer pipe must never become  
smaller.  The changed expiry text makes the x= parameter optional,  
but then excludes concerns regarding subsequent message rejection on  
that basis.

There was another minor change that used [received] time rather than  
[current] time to better define rules for various transports.  This  
was also to introduce the concept that there is a time interval  
between the received time and when the message may be forwarded.  An  
MTA can not continuously evaluate these message expiries.  When an  
MTA does not have a rate-limiting mechanism to handle in-hand expiry,  
the only safe practice would be to refuse messages that require such.

base-01:
,---
| It is beyond the scope of this specification to describe what actions
| a verifier system should make...
|
| If the verifying MTA is capable of verifying the public key of the
| signer and check the signature on the message synchronously with the
| SMTP session and such signature is missing or does not verify the MTA
| MAY reject the message with an error such as:
|
|    550 5.7.1 Unsigned messages not accepted
|
|    550 5.7.5 Message signature incorrect
'---

An effort subsequent to completion of the base draft is aimed  
specifically at providing a mechanism for the signing-domain to  
report that all messages have a valid signature.  A verifier can act  
upon that information and reject all messages purported to be from  
_that_ domain without a valid signature.  An expired signature is  
defined as _not_ being valid.

A safer practice would be to allow the receiver to evaluate the time  
the message was posted or signed.  There is a significant risk  
changing the validity of a signature on a per second basis, largely  
due to policy issues and foul play.  A slew of DSNs could be harmful  
to the reputation of the MTA.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 20 Apr 2006 00:28:01 -0400

And this is from a person who has a nasty habit of censoring and banning
people from his so called anti-spam research areas.  If you were ignoring
me, and you know you don't, you wouldn't have read the message.

Ignore me if you want. I won't ignore you.  The fact is, certified mail
concepts raises the legal bar.  You come to realized this yourself, finally.
It is worth repeating:

    ....

---
HLS

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 20 Apr 2006 02:06:51 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>

>> I think this must be a MUST.
>

Agreed.

If we change it to relaxed wording like so:

    Verifiers MAY support checking of x= values. If verifiers
    supports checking the  expiration x= tag, they SHOULD
    honor the signature expiration.

Then basically, this effectively defines for implementations, the x= tag is
worthless and that if the domains wants to truly expire a signature they
need to either:

     a) revoke the public key by setting p=data to empty, or
     b) purge the publc key DNS record from DNS.

In this case, x=tag becomes an *optional* optimization or non-DNS based fast
rejection feature or concept.

The wording might be:

    DKIM offers an key expiration optimization option using an x=expiration
date
    tag in DKIM signatures.  Verifiers MAY use this tag to accelerate the
    classification of a signature to an invalid state.  Signers MAY set this
    x= value, however, signers MUST be aware that verifiers may not support
this
    option and the only effective way to expire a signature or revoke a
public
    key is to clear the public key or remove the selector DNS record.

That is all that basically needs to be said from my point of view as an
implementator.

Signers now will basically view x as the day the key data is cleared or the
DNS record is removed,  and decide for themselves if they want to assist the
verifier world with the x=tag optimizer.

Lets keep in mind, tag or not tag, you still have step 2 in section 6.2 and
the 451 recommendation is not something verifiers will just willing honor
across the board. That is definitely a candidate for local policy setting to
551.  In short, the coding for the verifier might be:

     NXDOMAIN, no tag, not expired  ---> 451
     NXDOMAIN, signature expired    ---> 551

---

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

>        no expiration/best-before). The format is the same as the "t=" tag,

I'm not sure I want to start another discussion about the "t=" tag like
we had about the "x=" tag, but I'm even less sure what to do with t=. 
Do we want to base the format on that of t=?
>        public key could not be retrieved.
The latter isn't a very good example, since section 6.2 refers to
deferring acceptance of messages if the public key can't be retrieved,
and that would not be desirable in the case of an expired signature.
>  Verifiers MUST NOT asssume 

I'm not clear on what the above statement means.  What would be an
action that results from an assumption of this sort?

-Jim

---

From: Mark Delany <[email-masked]>
Date: Thu, 20 Apr 2006 14:30:15 +0000

> Do we want to base the format on that of t=?

Good point. I presume we might get to the semantics of t= at some
point. The safest definition for x= might be self-contained.

Mark.

---

From: Jon Callas <[email-masked]>
Date: Thu, 20 Apr 2006 11:34:39 -0700

On 19 Apr 2006, at 10:14 AM, Paul Hoffman wrote:

> checking x= values? If there is none, the sentence above needs to  
> be a MAY.

I don't want to torture people with my reasoning, but x= needs to be  
a MAY, but for possibly different reasons.

My reasons are that I don't think that an implementer needs to  
"carefully weigh" whether to implement x=. I think that casually  
weighing it is just fine. I've been thinking a lot about uses for x=,  
and some of them might allow someone to game DKIM against other parts  
of a mail filtering system. And yes, I know that this comes close to  
conflating SHOULD-implement vs. SHOULD-deploy, but I would not think  
ill of an implementor whose decision was "I don't understand it well,  
so I'm not implementing it," which is the antithesis of SHOULD.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Apr 2006 11:49:00 -0700

On Apr 20, 2006, at 11:34 AM, Jon Callas wrote:

> I don't want to torture people with my reasoning, but x= needs to  
> be a MAY, but for possibly different reasons.
>
> weighing it is just fine. I've been thinking a lot about uses for  
> x=, and some of them might allow someone to game DKIM against other  
> parts of a mail filtering system. And yes, I know that this comes  
> close to conflating SHOULD-implement vs. SHOULD-deploy, but I would  
> not think ill of an implementor whose decision was "I don't  
> understand it well, so I'm not implementing it," which is the  
> antithesis of SHOULD.

The jabber chat concluded MAY...

There is also a downside ignoring x= when forwarding mail.  Safe  
solutions for this involve changing the way MTAs operate.  Gaming is  
also possible when not paying attention, especially when invalidated  
signatures offer a basis for rejection.  When this happens down- 
stream, MTAs not paying attention will be left dealing with DSNs.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Apr 2006 15:55:49 -0700

>Do we want to base the format on that of t=?
Do statistics and forensics count for nothing these days?

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Apr 2006 17:07:28 -0700

On Apr 20, 2006, at 3:55 PM, Michael Thomas wrote:

>> we had about the "x=" tag, but I'm even less sure what to do with  
>> t=. Do we want to base the format on that of t=?
>

 From a prior conversation, I think the concern was whether to use  
seconds from 1970 or the RFC2822 date time format.  Standardizing on  
a consistent format with that of the other headers being examined  
would also permit a recipient to understand what the time stamp value  
represents.  The conversion routines are already be available.

The draft could recommend encompassing an evaluated Date header  
within the signature, or providing for a human readable t= time stamp  
when the Date header differs significantly.

-Doug

---

From: Tony Hansen <[email-masked]>
Date: Thu, 20 Apr 2006 21:41:03 -0400

*If* we're going to switch away from "seconds from 1970", we should use
the standardized time format described in RFC 3339: Date and Time on the
Internet: Timestamps. IMHO, using anything else would be irresponsible.

However, I don't think we have to switch.

	Tony Hansen
	[email-masked]

Douglas Otis wrote:
> seconds from 1970 or the RFC2822 date time format.  Standardizing on a
> consistent format with that of the other headers being examined would
> also permit a recipient to understand what the time stamp value
> The draft could recommend encompassing an evaluated Date header within
> the signature, or providing for a human readable t= time stamp when the
> Date header differs significantly.

---

From: [email-masked]
Date: Thu, 20 Apr 2006 18:51:15 -0700 (PDT)

> However, I don't think we have to switch.

I agree on all points.

				Ned

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Apr 2006 20:02:39 -0700

>> However, I don't think we have to switch.

If I recall there was difficulty comparing hex seconds with other  
mail headers.  RFC3339 is much cleaner.  A human readable form is  
more user friendly, assuming a user has a reason to examine the  
date.  The current second count t= will provide nothing in that  
respect.  While there might not be a pressing reason to switch at  
this point, looking at raw headers will offer better diagnostics when  
the date is readable.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 21 Apr 2006 22:01:44 -0500

> However, I don't think we have to switch.

Neither do I.

-- 
Arvel