ietf-mailsig
[Top] [All Lists]

Re: DKIM: Canonicalization

2005-07-19 15:11:16

On 18 Jul 2005, at 1:44 PM, Earl Hood wrote:


Yes!  Since DKIM makes allows digitally signing of message bodies,
there is an implicit indication that message content can be "protected"
via DKIM.


I have to disagree here, as a DKIM author, OpenPGP author, and OpenPGP implementer (and soon to be DKIM implementer).

The whole point of DKIM is *envelope* protection, not body protection. Yes, envelope is metaphorical, and implementation-wise, you have to sign the body to sign the envelope, but the whole point of DKIM is that you know the source of the message where the source is an administrative domain, and not any content signing.

Let me give a bit more of a metaphorical explanation.

Imagine that I send you a letter, and I have signed over the seal of the envelope. Imagine inside that envelope, there is a signed letter.

DKIM is the external signature, OpenPGP and S/MIME are the internal signature.

It seems some comments on this list indicate that such protection
is not to be as solid as S/MIME or OpenPGP, but a "fuzzy" form of
protection, that is not well-defined (a security red flag).


It's not fuzzy at all. It's very well defined. It is however, not what traditionally digital signatures have been used for. It is for authenticity, rather than authentication.

IMHO, I think this is a bad way to go.  If digital signatures of body
parts are to be supported, it should be done with the assumption
that such signatures will be used to verify the integrity of the
content in the way digital signatures are normally used.  If not,
people will probably use it that way anyway.

Unfortunately, the email world tolerates transmission variance,
something that digital signatures do not like.  Therefore, the
debate is what is an acceptable level of variance allowed that
gives us an acceptable level of security risk.


What you are describing above is an anti-goal of DKIM. DKIM does not sign the letter.

        Jon


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