Re: [Asrg] E-mail Postmarks

["william(at)elan.net" <william at elan.net>]

On Sat, 5 Jun 2004, Jon Kyme wrote:

> Signing for these purposes needn't be all that elaborate, and any "relay"
> which mutilates the message by design *MUST* break the signature, 

Not by design. First for purposes of this email post, I'll define "relay" 
as being any MTA though which email is just passing though, i.e. which is 
neither source nor desitination for this email. Now there are relays that
1. Only add received header indicating message has passed through
2. Add or change email headers but not change message body below last header
3. Change both headers and body of email

#1 Applies primarily only to systems that simply relayed through the network
without caring about its content at all. These are backup mail servers,
outgoing and incoming gateways, etc.

#2 Are almost all mail lists and most forwarding and relay systems. However
at the same time they can be classified into:
2a. Ones that change headers (To, CC, From, Subject etc).
 - Some headers such as "Sender:" and "Subject" are more commonly changed, 
   but others are very rare
2b. Ones that add new headers below the existing headers
 - This is most common behavior for mail lists and forwards, they all want 
   to add some new headers and all of them usually go below existing set 
   of headers. Spam and Antivirus systems also comonly add new headers
   below existing ones

#3 are fairly rare and primarily just few mailing list that like to add 
their own footer (sometimes an add) and many of these presented with 
complex multi-part mime content, they would not change the existing mime 
part but add this new "footer" as new mime content part

> while canonicalisation would be designed to minimise the chance of 
> accidental breakage.
> 
> However, a single mutilating stage (as at a gateway) is easily accomodated
> in a simple scheme: The mutilator should verify the sig before breaking it,
> and re-sign the message, including its verification header (or whatever).
> So we have a secure trace back to the first signer (if not mutilated) or to
> the signer before the last mutilator (if we trust the mutilator), or not
> (if sig doesn't verify).

How would you have a traceback if the previous verification header would 
not be verifiable? That is since the data that was signed has been changed,
now MD5 hash of that data is different, so the signature based on that 
hash would be of no use as well, right?

> So the minimum we require is the canonicalisation algorithm
Please exlain what you mean by "canonicalisation algorithm", is this like 
creating pre-signature data has or fingerprint?

> a pair of headers
I guess one header is signature, which is the 2nd one you have in mind?

> and some per-domain public key retrieval mechanism.
Which we actually have - KEY data type which unfortunetly can no longer be 
used for email. THough if that is done under specific subdomain (i.e. 
_email_key.domain.com) that may reduce possible problem with subtyping.

-- 
William Leibzon
Elan Networks
william at elan.net






_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg