On 1/27/08 at 8:23 PM -0500, Bruce Lilly wrote:
On Sunday 27 January 2008 11:18:37 Frank Ellermann wrote:
they can pick UTC. Maybe 2822upd could drop the SHOULD (?)
I'd like to see it dropped, or better still, replaced by a
recommendation to use UTC. That would partially remove the need to
define "local".
Using UTC is a terrible idea. The entire idea of the "Date:" field is
to allow the author to convey the time at which the message was
created. It is often important information to the author (and to the
reader) what local time the message was created. ("Was this written
in the morning or the evening for the author?") There *are* valid
reasons not to use local time (when you want to hide the information
for some reason, or when you cannot reliably calculate it), hence the
SHOULD, but implement the spec in such a way that you always use UTC
creates information loss to the author and reader, and "the full
implications must be understood".
Regardless, there are security implications related to use of
"local" rather than UTC. The issues arise from the difficulty in
converting *correctly* to an unambiguous time reference (i.e. UTC)
which in turn is partially due to an unfortunate choice in the sign
of the offset, (resulting in erroneously adding the offset to local
time to get UTC when it should be subtracted). They also partially
arise from the "local" time issue of "Daylight Savings Time" (or
equivalent by any other name) and the horrendously complicated rules
(which vary from year to year and place to place) for additional
offsets.
The above are not security implications; they are reasons people
sometimes get local time wrong. Programming is sometimes hard.
I recall one instance where a person was wrongly accused because his
ISP made the offset conversion incorrectly (unfortunately I cannot
now find a reference), and here is a link to a case (not
mail-related) of the DST issue, also resulting in wrongful
accusation:
http://yro.slashdot.org/article.pl?sid=07/04/17/1240237
That's not a security implication; that's a legal implication.
Aside from those issues, there are ambiguities in the 2822upd-04 text:
and the zone MUST be
within the range -9959 through +9959.
Is +2586 legal (it IS within the numeric range -9959 through +9959)?
Yeah, someone else mentioned this to me. I've changed it to:
"and the last two digits of zone MUST be within the range 00 through 59."
What about semantics; what does +2718 mean (there are no actual time
zones outside the range -1200 to +1400, and none whose offset is not
a multiple of precisely 15 minutes [*])?
It's semantically valid, whether or not it is currently used. There
is no good reason to disallow such a value.
It seems highly inconsistent that the 2822upd-04 text is so pedantic
about semantic validity of day-of-week, day-of-month, and
time-of-day, yet so lax about semantic validity of zone offsets.
Using a "Bob" for the day-of-week, or "31 Feb", or "75:75:75" for the
time-of day has the potential to really screw up code. I'm not clear
on how having strange zone offsets does.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102