On Mon, 1 Nov 2004, wayne wrote:
In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0411011748360(_dot_)12698-100000(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
On Mon, 1 Nov 2004, Meng Weng Wong wrote:
Could someone please post a concise summary of each
technology, and an explanation of the differences?
http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm
Does that work for you?
I suspect not because I already had sent Meng that link.
I think Meng (and I) are more interested in a paragraph or two of
text, rather than a feature matrix.
The matrix really does describe it, especially where difference is.
Writing "paragraph or two" to describe the difference depends greatly on
who the audience would be and how technical description needs to be.
First I'll note that it might be good if people read on S/MIME or PGP first
because you need to know about public key cryptography and RSA and how its
used with email.
But basicly the difference between DK and IIM is as follows:
1. DK signature is a signed data and does not contain public key so its
not possible to verify the signature without that public key. The
public key can be found by dns lookup to special prefix of signing
domain with TXT dns record expected to contain the public key.
IIM signature is more like S/MIME or PGP and contains both signed
data and public key and additional signed attributes. That means
signature can be verified without additional dns lookup. But to check
that it really is signer's public key that was used (authorization step),
you need to do dns lookup and special dns record (of new DNS type) would
contain either fingerprint (kind of like hash of public key and it is
a lot smaller then entire public key) or a referral to HTTP key
authorization server.
2. DK signs hash of entire email body plus hash of either all headers or
listed list of headers. That means if consequent email servers change
any header or add anything to email body, then hash is different and
entire signature would not verify. That pretty much means that signature
does not survive mail list processing.
IIM signs hash of entire email body but also includes count of number
of characters of the body that went into that hash at the time of signing.
Headers that are signed are duplicated and adding into signature line
itself and their hash is signed. That means that if header is changed,
it has no effect on signature since it includes original header (and
it is expected that MUA would as an option to user allow to show
those signed original headers) plus if there is additional text added
to email body (like mail lists like to do), the signature would also
still verify.
Have you thought about adding a column for SES? It is my
understanding that it does body signing now a days.
The purpose of that matrix was to compare details of RF2822 signing
proposals that were discussed at the MASS BoF and MailSig mailing list.
I also tried to go through proposals that are somewhat similar and
easy enough to compare without too much additional commentaries and
the proposal that was different (TEOS) was not easy to add at all if
you look at it.
Now that said, if somebody else wants to try to create column for SES
and write data to go in ther, I'll take a look at results and if it does
look like something that would fit well into the matrix, I'll add it to
the matrix I have. But in that case SES also MUST be written as one text
proposal text (either HTML or PDF or internet draft document) and somebody
MUST post about and and present MailSig mailing list to be considered part
of that effort.
(BTW, thank you very much for putting together that table, it is very
useful.)
Thank you. I was hoping to help those with technical expertise but without
enough time so they would have quick way to comparing the proposals and
what are their strong and weak points. Its still better to read entire
technical paper describing proposal but not everyone has time for it and
instead they end up listening to constant marketing effort for one particular
proposal which is not reall that good compared to other proposals on
the table.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net