On 11 Oct 2004, John Levine wrote:
Its approach is somewhat different than the other signature schemes.
As best I understand it, it signs the visible headers (to, from,
subject, date) and puts a base64 signature string as an extra header
that the recipient can verify. Rather than signing the text, it
annotates the text with a text URL including the signature at the
bottom of text messages or some extra HTML with that URL in HTML.
And I at first thought it was a typo when I saw:
Base64(signed-digest(<senderAddress><rcptAddress><Assertsions>)
<message_specific_data>)
and that it was supposed to have been:
Base64(signed-digest(<senderAddress><rcptAddress><Assertsions>
<message_specific_data>))
Guess not... I don't see any headers there signed other then Sender and
Recepient, but I'll take your word for it that it does it.
Its not clear how this would survive in case of forwarding since "Sender"
may change and also if we don't sign the message body this seems to allow
for easily spoofed messages. I'm guessing the latter is fought with that
user can go to sender and verify they really sent that message but that
is basicly implementation of full message-tracking.
I actually spent great deal thinking of how to do forward message-tracking
last year and decided it does not scale well to the full internet email
system if we have to require all senders to keep track of every email they
sent and allow fo users and MTAs to verify the message validity by callback
to message tracking service. I discussed this at ASRG some time ago and
switched afterwards to designing cryptography-based message tracking that
does not require to keep track of all emails and only requires callback
to verify validity of the signature with possibility of caching to reduce
number of callbacks.
If the recipient clicks through the URL, it goes back to the signing
agency and shows a window displaying what the signed fields were, and
offering an opportunity to complain if it doesn't match.
Then, this would that require modification to MUA, right?
They didn't work out much of a key distribution scheme and for now it
more or less uses the browser model in which recipients are presumed to
have copies of all the signing keys.
It was originally intended for bulk mail more than one-to-one mail
(although there are people who do sign their mail with Postiva) and
has some of the same text mangling problems as MIME encapsulation for
individual messages, but the signing model is interesting and worth
thinking about.
Why is encapsulation necessary? I thought you said they did not require
signing of message body at all?
Also I asked couple other questions on if MTA that verified the message
were supposed to inform MUA about it by some means and if the sender that
uses postiva have some way to inform recepient about it (i.e. policy
record).
Other then that, please check the current version of matrix at
http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm
and tell me if I understood your explanation about TEOS properly.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net