I've now had time to create webpages for META Signatures project and cleanup
tech documentation. All current info and documentation is now available at
http://www.metasignatures.org
There are also two mail lists setup:
http://lists.metasignatures.org/mailman/listinfo/metasig-discuss
for general discussions regarding the proposal and its syntax
http://lists.metasignatures.org/mailman/listinfo/metasig-develop
for development and implementation discussion, in particular this
would be mail list for those who want to get involved in metasignatures
sourceforge project which has also been setup
http://forums.metasignatues.org/
web forum access to the same mail lists (yes, they are integrated and
posts to mail lists show to go forum and other way around).
I invite those of you who are interested to participate and in particular
I'm going to try to get started first on EDigest as that would allow to
test how well signatures can survive in real mail environment (and actual
signature crypto staff should then be easy to add and it is well known to
work anyway; for authorization I expect to focus on x509 and/or DNS
fingerprints). Note though, that META Signatures is actually just a small
part of a lot larger email system proposal which I've started trying to
describe directly as internet drafts and those drafts may be taking lot
of my time for next 2-4 months, which will cut in the time I can spare
for programming.
For technical spec the most current one can be found at
http://www.metasignatures.org/meta_signatures_v018.htm
I've cleaned up small grammer errors and also made some style changes so
it would be easier to read. There have also been real technical changes
from last time I've posted about meta signatures (at that time about 0.15):
1. As I kind of mentioned for authentication I'm thinking of DNS RR
specifically for fingerprints. What I proposed is to reuse exactly same
syntax as with SSHFP but new RR type MASFP (Mail Signature Fingerprint)
An example of this for dns zone is something like:
fp1._fp.example.com IN MASFP 1 1 123456789abcdef67890123456789abc
2. Reporting results is done using Authentication-Results header but
not exactly the same syntax, instead small change is that ";" separates
different authentication systems and while results of authentication of
the system overall are listed first in normal way, after that there may
follow info on subcomponents of the system each reported as separate
"component=result" tags and 'result' values for components do not have
to follow list of possible results from sendmail draft (if system that
is looking at the header knows about the main authentication system,
it should know how to interpret results for each of its components).
Here is an example that I show how that works for META Signatures:
Authentication-Results: mail-router.example.com (ip=10.0.0.1)
from=foo(_at_)example(_dot_)com sender=moo(_at_)example(_dot_)net ;
metasig=pass (meta signatures authentication successful, some saved
headers have changed)
meta-signature=verified (t=1094844765.338603 s="example.com"
auth/pk-dnskey=pass (public key successfully retrieved from
"ns:_key1.example.com?type=KEY"))
edigest=verified (t=1094844765.334354 c=nofws num=1252:1192
parts=* mime-types=text/html,text/plain)
edigest=verified (t=1094844765.334355 c=nofws num=350:350
parts=mpart1 mime-types=text/plain)
saved-headers=verified (1094844765338603-From, 1094844765338603-To)
saved-headers=changed (1094844765338603-Subject) ;
spf=pass (unified spf authentication successful, some scopes failed)
spf/hello=pass spf/mfrom=fail spf/submit=pass
3. EDigest header syntax has been extended and it now has additional tags
"h", "m", "p" (last two are separation from what was previously one tag).
- "h" has the same syntax as "h" in META-Signature and is intended to
allow to add MIME headers into signature if Digest is for specific
mime part (but it can also be used to add regular headers from email
and even to use EDigest only to sign certain list of headers)
- "m" tag designed mail part that the hash is for. If present this
specifies mime part by name and if present then it becomes root
for "h" and "p" tags
- "p" tag allows to designate specific list of mime subparts that are
digested together (in given order) from the root mime part, the use
of this allows digest hash to verify if mime parts are rearranged,
at the same time I'm not sure how serious a problem this is and if
its worth it, so this tag is experimental and may well be removed
(and signing individual parts is already possible with "m")
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/