ietf-mailsig
[Top] [All Lists]

Re: MASS Proposals Comparison Matrix

2005-07-18 09:56:35


On Mon, 18 Jul 2005, Douglas Otis wrote:

I've updated my comparison matrix to include DKIM and META Signatures, please see: http://www.elan.net/~william/emailsecurity/emailsignatures- comparisonmatrix.htm

A feature your meta-signature scheme offers is an ability to endure the rearrangement of multi-part MIME sections. I assume this also includes deletion of these sections as well.

Depends on how signer does it. If he creates separate EDigest for each MIME part separately and one of these parts is deleted then the signature could still be verified.

If EDigest has list of MIME parts in 'u' parameter then deletion of one
of these parts would mean that EDigest hash can no longer be verified (META Signature itself could still be verified but it would only tell
if header fields have been changed or not).

My recommendation in regards to dealing with possible deletion of some mime parts is to have certain attachments like .ZIP or .EXE have separate hash in separate EDigest fields and having regular multiple text & html parts as part of common hash data in one main EDigest field.

Is this feature part of your patent?

No.

What systems will mime rearrangement be most problematic?

IBM Lotus and Sun SMTP server are reported to sometimes do it (possibly with
some external software). More often you may see it with mail list processing,
there its usually not rearrangement directly but encapsulation of message parts in a new mime part which would now be "root" - this is to deal with S/MIME and PGP/MIME signatures and it has the same effect on signature as rearrangement.

I also noticed what appears to be a mistake in your grid. You show the MTA signature as being in the body of the message and invisible to the MUA?

It is invisible in most MUAs (its supposed to if MUA follows MIME specs).
MIME says that unknown Multipart types are supposed to be ignored and MTA Signatures takes advantage of that and puts its signature in
Multipart/Postal-data message part.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net


<Prev in Thread] Current Thread [Next in Thread>