On Mon, 18 Jul 2005, Earl Hood wrote:
Content-Digest represents the the digest of the raw entity data,
before any content-transfer-encoding. For verifications, CTE
decoding is done first.
My question: Should the digest be computed on the CTE encoded form
instead?
My preference for EDigest (and in fact how my current perl code is
written) is to do signing on CTE encoded form - this is what metasig
tech specs (up to 0.21) specify in fact.
In writing draft I had to take into considerations current use as the
draft is both for use of META-Signatures and for other uses (largely
because Content-MD5 is inadequate for modern needs) and it was clearly
specified that Content-MD5 hash digest is computed before CTE.
To a degree this (without CTE) is easier and offers better chance for
hash to survive - after all the encoding is for transport and may
between 7bit and 8bit transport changes (with actual data and MIME
header otherwise staying the same). But its also harder for verifiers
as you point out (especially for EDigest).
I'm going to defer decision on what is better and try to get some
more opinions from the community (try to get some form of consensus
on this issue) and thus will raise this question on ietf-822 and
ietf-smtp and perhaps other lists.
Now some more comments to your post are below.
Why I ask? Multiple reasons:
* DKIM does it over the MIME encoded form. This has advantage
of being more efficient since digest computation, and verification,
does not have to be MIME-aware. Basically, the message is treated
in the RFC-2822 domain and not the MIME domain.
DKIM works on entire message. EDigest always treats the data as
MIME part (or collection of MIME parts). There is quite a bit of
difference in what this means.
* OpenPGP (RFC-3156) does signing over the MIME encoded entity
(see Section 5), and not the original raw form.
* S/MIME (RFC-2633) does signing over the MIME encoded entity
(see Section 3), and not the original raw form.
In both of the above cases, both the original and the signature are
then enclosed in new entity and this new entity is what is transported
and may have its own different CTE.
* For EDigest usage, MIME-aware CTE decoding must be done. Will
this be an extra burden for MTAs to deal with?
Therefore, what is the real meaning of Content-Digest? Is it the
digest of a MIME entity or the digest of data that is subsequently
tranlated into a MIME entity?
Its digest of MIME entity.
If it is the later, an extension to Content-Disposition seems more
appropriate. C-D already provides raw data specific attributes,
like filename and creation date. Another parameter, "digest" could
be added for representing the digest of the raw format of the data.
Content-Disposition: inline; digest="sha1:A233sdf..."
Even if digest were to be treated as hash of raw data, I would not agree
to your use of Content-Disposition to carry it. Content-Disposition
specifies what to do with the data, not what the data is.
Since Content-Digest is designed to include header fields, this implies
that it is protecting the email "package" and not what it contains.
I.e. It protects the MIME representation of a piece of data vs the
raw data itself.
Correct.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net