-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,03
MIC-Info: RSA-MD5,RSA,aks1MnVlUODS6Nb+wp3tCmHcfP7vUKsFwA11XofHoPD
UF6XrTVlfjQWgQV3C4hU26jL2iJwJ+iTgiVEPteAhEpoifm+MVKhhgJKRje8lynL
ImllUyPJhbIr9T3lmyPc0
Many mail relay agents in the Internet today rewrite header lines to
reflect the word view of the recipient (i.e., my mail agent may have
included a header that just read "jis" and some MTA in between me and
you re-writes it to read "jis(_at_)mit(_dot_)edu").
I take it that with your proposed implementation such header re-writing
will invalidate the message's signature. Correct?
Not at all. Suppose you create a message that's roughly: (The lines
of "===" are for demarcation in this message; they're not part of the
text.
============================================================
To: crock
Subject: This is what I typed
<text of message>
============================================================
You then submit it for enhancement and mailing. Depending on which
order you have things implemented, differnet things might happen. Let
me take the case in which the above message is signed exactly as is,
and then submitted for mailing.
After signing, you have a structure that looks roughly like this:
(I'm typing this from memory; I may be botching some of the details.)
============================================================
Content-Type: message/rfc822
To: crock
Subject: This is what I typed
Mime-Version: 1.0
Content-Type: multipart/header-set, boundary = "aaa"
Content-Transfer-Encoding: 7BIT
--aaa
Content-Type: application/pem-signature
Version: 5
Originator-ID: <dname for Jeffrey I. Schiller at MIT>
MIC-Info: <RSA encryption of MD5 hash of the following message
using Schiller's private key.>
--aaa
Content-Type: application/mime-quoted-entity
Content-Type: message/rfc822
To: crock
Subject: This is what I typed
Content-Type: text/plain
<text of message>
--aaa--
============================================================
After it's submitted to your mailer, the first two lines become:
============================================================
Content-Type: message/rfc822
To: crocker(_at_)tis(_dot_)com
From: Jeffrey I. Schiller <jis(_at_)mit(_dot_)edu>
Date: 12:07 P.M. EDT
============================================================
Thus, the only changes that can take place after signing are outside
the protected area. What's inside the protected area depends on what
was submitted. In the above example, your internal name for me is
preserved. Of course, it might not do me much good to know what your
internal names are. For example, if you also sent a copy of the
message to "ted", that probably won't tell me enough about who "ted"
is. Nonetheless, I think it's potentially useful information.
There are two other possibilities, each permissible within the spec
and controlled entirely by your implementation decisions.
1. The expansion of "crock" into "crocker(_at_)tis(_dot_)com" might happen
before
the message is signed. Also, the From and Date fields might be
created before the message is signed.
2. Nothing *requires* that the headers be included. The equivalent of
the current 1421 strategy is also ok. We're simply saying we think
it's better to include whatever headers exist at signature time,
and it's straightforward to do so.
Steve
-----END PRIVACY-ENHANCED MESSAGE-----