On Sun, 12 Dec 2004, Hallam-Baker, Phillip wrote:
Because this whole requirement was dropped eight years ago.
The general design view is still to use "X-" for intitial testing and then
move to regular header name once system is standartized. Some argue that
"X-" should be used only if the header being attached has meaning only
(i.e. what it is and the syntax are understood) for other systems on the
same network (i.e. its for internal company use) but it is not for general
public use or carries no standard syntax that general public can decide on
when looking at that header.
In this case, I'd agree with use of non-X header since they published a
draft and intend header to be understood by systems outside Y!
or to get even more to
the brutal point, has anyone noticed that the bloke creating
all the domainkey specification documents appears to have
begun this with no background in either security/cryptography
(eg: initially recommended assymetric key sizes that were
crackable in mere seconds),
That does not matter. SSL 1.0 was designed by a neophyte and broken in ten
minutes.
I don't care how experienced the writer of the spec is provided the
reviewers have experience and the author is willing to listen to their
advice.
This has not so far been the case with Y!
nor in email (eg: utterly ignores
the fact that headers get inserted everywhere nowdays
(eg: spam/virus/etc scanners) and that contents get changed by MTAs
(eg: quoted<=>8bit),
That's ok now, after much argument the point is now taken.
No it has not. The headers are not only inserted but changed as well
It is necessary to be selective and copy some headers while just signing
the others (like trace headers that are never changed and copying them
is waste of resources especially as trace headers are too large).
After looking at least 4 ways of doing all that I finally found a way
that is flexible to work for all cases and not require duplication of
headers that have not changed (but potentially could) every time.
nor even in programming (eg: his idea of
"folding cr/lf/blankspace" is just to remove it all),
This compromise works quote well to get around common email alterations
that mail systems do. Perhaps if standards for email processing were
better understood, this would not have been necessary, but in any case
this is not a big deal as removing cr/lf/blank does not change content
of what has been signed.
that matter, common sense (S/MIME already exists; the entire
DK system could have been rolled out with S/MIME just by
attaching the headers before the signature, people might want
to verify old emails, etc etc).
The companies round the table include two who have a very big stake in
S/MIME. We also know that like PGP S/MIME was designed to do encryption
and signature was an afterthought.
I still believe that S/MIME based signatures would have been better as far
as technical design goes, but its also more complicated that what is needed
and has practical problems that not everyone is using MIME (although I
don't see any problem if we cause it to happen, its time).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net