I've worked quite a bit on META-Signature header field syntax and it
become even more flexible and as I mentioned it turned into something
like framework design that can support many forms of header-based
signatures. As a reminder the latest spec is at and right now its 0.21:
http://www.metasignatures.org/meta_signatures_protocol.htm
The main changes were separation it into multiple segment as follows:
1. Main/Version [Ver] - general signature data including version,
timestamp, expiration
2. Content [Cont] - segment specifies which content is signed by the
signature
3. Signature [Sig] - the actual cryptographic data for this signature
including encrypted data and optionally public key
4. Identity [Id] - segment specifies message identity, this is used
for signature authorization
5. Authorization [Auth] - specifies how (through which service and record)
the signature can be verified and authorized
6. Revocation [Rev] - optional last step after authorization to make
sure the signature is still valid and has not
been revoked
Each section in the signature is represented by one or more sections
separated from each other by ";". As you probably guessed separate
META-Auth header field is gone and 100% integrated as part of auth
section syntax. An example of a signature is below:
META-Signature:
ver=1.0 i=mail.example.org t=1094844754.338503 x=432000 ;
cont=hlist h=Saved-*,Received-*,EDigest,From,Date,Message-ID e=<ver:t> ;
sig=rsa a=sha1 d="grUU7EOwzCbuoejh39KE+epT3zGdmAP693IOGujxSBb+4qttR9
yg1EubJYMDVuuvt1uySVzETz/0GrzxPC2L8w==" e="lw="
m="zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda
s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7
674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek=" ;
id=sender s=example.org a=alex(_at_)example(_dot_)org ;
auth=dk u="dns:brisbane._dk.example.com?type=TXT" ;
id=host s=mail.example.org ;
auth=txt u="dns:mail.example.com?type=SPF" f="fp.1=" e=base64 ;
rev=dnsrl a=23455343543.dnsrl.mail.example.com r=127.0.0.2 ;
this is an extra comment that is ignored
Note: number of tags in above example are really optional,
i.e. signature can be quite a bit smaller. sections
don't have to all start each at new line either
As mentioned multiple sections are possible and one is chosen that is
best supported by verifying system or multiple ones if desired (though
some special rules on that for "id" to check all that are possible)
Processing is very specifically ordered as ver->cont->sig->id->auth->rev
For each segment a first section below it of different segment is chosen
for next processing. That means its possible that after shared "ver"
and "cont" the "sig" could be different (one for RSA and one for DH)
and then different "auth" for each one i.e. :
META-Signature: ver=1.0 ... ; cont=hlist ... ;
sig=rsa a=sha1 d=... ;
id=host s=mail.example.com ;
auth=txt u="dns:mail.example.com?type=SPF" f="fp.1=" ;
sig=dh a=sha256 ... ;
id=sender s=alice(_at_)example(_dot_)org ;
auth=x509 u="http://_certs.example.org/alice.der"; ;
rev=dnsrl a=23455343543.dnsrl.mail.example.org
At the same time its possible for this to get back to shared, i.e. there
could be multiple "id" and they are all verified by same "auth" or there
could be different "ver" sections (like say "ver=1.0" and "ver=1.5" and
then rest of the signature is the same that applies to both). In fact
above example "rev" section would be shared and apply to for both of the
specified different "sig" and "auth" sections.
The signature can now be used for authorization of multiple identities
and those are directly specified in the "id" section of header field.
Usual suspects like "from" and "sender" are supported as well as
"mailfrom" (RFC2821 MAIL FROM) and "host". Host is special identity to
verify hostname of mail server system adding the signature (not
necessarily the same as domain in sender of from as you know) - consider
it like EHLO or verification but with cryptography. If you look at my
diagrams for metasignatures and my old presentations it is clear that
is what I meant to do so that signature could be added by each MTA
in email path (including those forwarding mail), but it all got
sidetracked when I was merging MTAs with design of DK and IIM
proposals that only add signature for original message sender.
For authorization there is now a new generic authorization type "txt"
which can be used for retrieving public key or fingerprint data from
text records in dns (or for that matter from http) with either domainkey
style dns records or SPF records (there its is a modifier). I strongly
prefer fingerprint data in dns because its a lot smaller and size of
it does not depend on the size of the actual public key being used.
Examples of using these authorization sections are as follows:
auth=txt u="dns:mail.example.com?type=SPF" f="fp.1=" e=base16 ;
auth=txt u="dns:s1024._domainkey.yahoo.com?type=TXT" k="p=","\;" e=base64 ;
In above "f" and "k" specify starting text and optionally ending text
(if not present FWS) of the text record for fingerprint and public key data.
For directly referencing Edigest header field from content a new optional
tag "e" can now be used in "cont=hlist" section, this allows to specify
exactly which edigest header fields were added or verified to be correct
at the time signature was created. Also note that entire signature header
field except "sig" sections (rather then specific tags specified with "+="
as in previous metasig spec) are added into signed content, obviously this
is to make any use of the signature in replay attack lot more difficult.
For revocation as you probably guessed I adopted Doug's system and named
it "dnsrl" (dns revocation list). There is also another revocation idea
I've been playing with and I'll talk about it in separate post as its more
relevant to DKIM.
There are also number of other changes, of the ones that I can remember
that are important is that METASIG modifier in SPF is now changed to
require identity or scope, is is entered as "metasig.sender" or
"metasig.host", etc. It means that there should be signature in
mail if you see email coming with such and such identity. BUT it does
not mean that the signature itself is authorizing the listed identity
(i.e. there is an "id" section for that identity) - there can actually
be very good reason that these two statements are not the same.
Oh - did I mention that "META" now stands for "Message Enhancements for
Transfer Authorization" rather then "Mail Enhancements" - this is small
but is there to signify that EMAIL/SMTP may not be the only use for
this design and that any text header-based protocol can use it.
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net