Subject: [Asrg] Introducing META Signatures (a unification of DK, IIM, MTA Signatures plus support for linking to S/MIME and PGP)

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 30 Nov 2004 04:27:51 -0800 (PST)

This is information on new cryptographic mail signature proposal about
which I've just posted at ietf-mailsig. This is a near-copy of that post 
and if you have interest in talking about this more, I'd suggest it take 
place on ietf-mailsig list (its possible in the future I'll also create 
separate list just for META Signatures development, if that happens, I'll 
post about in on ASRG during next month). To subscribe to mailsig please
see http://www.imc.org/ietf-mailsig/index.html

------------------------------------------------------------------------

After creating the matrix of proposals presented at last MASS Bof (see
http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm)
I was surprised to see how much in common various proposals have, in 
particular for almost every feature there was at least one and usually
two or more other proposals  that also had that feature done in similar 
way. So I started to see if and how proposals could be put into one that 
would allow the signer to decide what features to use and I believe I now 
have the beginning of such framework ready to show you. 

This "unified" proposal's technical details are available for your review at:
 http://www.elan.net/~william/emailsecurity/meta_signatures.htm
(when reading it I recommend part1 first, then going immediatly to examples
 in part3 and then if you want more technical info, go through part2)

Now below will be somewhat long (for post on public list) as I'll attempt 
to briefly describe META Signatures syntax, if you read above webpage 
you'll find all that info (in better details) there already.

------------------------------------------------------------------------

This signature design involved separation of signature creation in basic 
components - email body canonicalization and hash creation, choosing what 
headers and how are to be included in signature, public key cryptography 
and actual signature creation, and way algorithm for signature authorization
Then I compared how different proposals do each part and which features 
they offer. The result is that each part is now represented a separate 
header which to a large degree made for a more structured system in my view.

First part is creating a hash of email body and it basicly means adding 
digest header. Those who want, can use good old MD5-Digest which is already
a standard, but of course MD5 is no longer considered a strong hash and 
that header can not be used with different canonicalization algorithm, 
so here is an introduction to new extended digest header:
 EDigest: v=1.0 a=sha1 c=nofws n=500 i=system1.example.com
        t=1094844765.334354 d="51f0483a89e441e2fc45a12a4303ca217f34617e=" 

In above - "a" is digest algorithm, "c" is canonicalization, "n" is 
number of characters after canonicalization (this is optional), "t" is 
timestamp with unique id (also optional) and "d" is actual hash data. In 
addition to above if somebody wants a digest can also be added for 
specific MIME part seperately (MIME part is specified by optional "m" tag)
and that can allow to verify email even if MIME parts get rearranged by 
some system or some deleted.

Now actual signature header no longer needs to worry about email body or 
canonicalization and represents ONLY signature of the list of headers.
Some headers can be duplicated and I already described it before. I've chosen 
"Saved-" prefix for adding duplicated header value and to allow for unique
reference to such headers a unique id can be added right after Saved-, like:
 Saved-1094844765338603-From: Boogyman <[email-masked]>

As I already mentioned before when this is done with separate headers, its
possible for subsequent signatures to reference existing "Saved" header 
instead of making another duplicate. Same also true about EDigest header, 
i.e. once one is added if email body has not been modified, then other
META signatures can reference that one EDigest header.

Now finally comes the META Signature header, which does not include
authorization info (this is in separate header) and so it has fairly 
simple structure:
    META-Signature: v=1.0 a=rsa-sha1 s+=example.com 
        t+=1094844765.338603 x+=432000
        h=Edigest,META*,Received*,Original*,Message-ID,Date
        d="Tg67/+k8oltzxIBxN4mevOgbP/+xqxeuT0ugZJ1VoaEm3bJ7JHAOy+X5FEMRF
             /SLZ+GBYIA7wtEmjgbHNuVRnbJQWu732PRbI6UKNGocCEX0TvVdZxFTQzbh3x
             zaEj6BIWx6GYIo8oWoeM3kzZTiip2pPhuvaXu9Ho+3eR81MZ4="  

In the above "s" is signer email or domain, "t and "x" are timestamp and 
expiration like in IIM, "h" is list of headers (like in DK but it has 
extended syntax) and 'd" is actual signature data. Where you see "+=" it 
means the content is added as part of signature data (i.e. like signed 
attribute in X.509). Also not shown above but possible as optional tags
are "e" and "m" which are for exponent and modulus of public key if
signer wants it included with the signature.

Last part of the puzzle are META-Auth headers which describe how signature
is to be authorized/verified. The syntax for them largely comes from MTA
Signatures (its called Certificate-Verification-Service there) and basicly 
it desribes verification type name (which as part of it includes IANA service
name) and locator info (something similar to DK's selector). Multiple 
META-Auth headers can be included for same signature if somebody supports
multiple verification types (i.e. somebody could decide to support both
DK and IIM at the same time for example), this feature actually may come 
very usefull for accreditation and reputation. One more interesting note 
is that I found a way to use those META-Auth headers as a way to link META
Signature directly to S/MIME or PGP signatures (in such case locator would
point to correct S/MIME pkcs7-signature attachment). Here are some
examples of META-Auth headers:
    META-Auth:  s=domain:txt:dk  l=_key1._dk  t=1094844765.338603
    META-Auth:  s=http:KRS  l=_krs f=krs_service  t=1094844765.338603
    META-Auth:  s=http:download:x509:der  l=_certs f=filename1.cer  
    META-Auth:  s=::pkcs7-signature:s-mime  l=pkcs7-attachment-1  
I'll note that I'm still working on syntax, in particular possibly replacing
locator with URL and I also working on more universal syntax for describing
authorization algorithm itself, I'll write more about it end of the week.

Now for those of you still around, finally here are some examples of how 
this all looks like. First one is simpler DK-style signature:
  META-Signature: v=1.0 a=rsa-sha1 s+=football.example.com  
     t+=1094844765.338603 x+=432000 h=* 
     d="dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR="
  META-Auth: s=domain:txt:dk  l=brisbane._dk
  EDigest: v=1.0 a=sha1 c=simple t=1094844765.334354 
     d="51f0483a89e441e2fc45a12a4303ca217f34617e="

Second is example of MTAS-like syntax where some headers are copied and
digest is not only for main body but for some mime parts (plus listed
are multiple authorization methods):
  META-Signature: v=1.0 a=rsa-sha1 i=mta.example.com s+=example.com
      t+=1094844765.334354 x+=432000
      h=META-*, EDigest, Saved-*, Received, Date, Message-ID
      d="Tg67/+k8oltzxIBxN4mevOgbP/+xqxeuT0ugZJ1VoaEm3bJ7JHAOy+X5FEMRF
           /SLZ+GBYIA7wtEmjgbHNuVRnbJQWu732PRbI6UKNGocCEX0TvVdZxFTQzbh3x
           zaEj6BIWx6GYIo8oWoeM3kzZTiip2pPhuvaXu9Ho+3eR81MZ4="
  META-Auth: m=domain:key:email  l=_key1._pk
  META-Auth: m=http:download:x509:der  l=_certs f=filename1.cer  
  EDigest: v=1.0 a=sha1 c=nofws  n=1192
      t=1094844765.334354 d="51f0483a89e441e2fc45a12a4303ca217f34617e="
  EDigest: v=1.0 a=sha1 c=nofws  n=350 m=mime1-text
      t=1094844765.334354 d="4j343ja134ars4390129343ajh124j33sek2424ke="  
  EDigest: v=1.0 a=sha1 c=nofws  n=825 m=mime2-html
      t=1094844765.334354 d="9si343ksa43junxm343nxldo43jdruy580jyt0z95pe="  
  Saved-1094844765338603-From: John Doe <[email-masked]> 
  Saved-1094844765338603-Subject: RE: Lunch

And last, but not least, is an example is IIM-style (with header inclusion 
syntax in safest way, so that signature would survive header reordering;
I personally think chance of that being a serious problem are very low):
  META-Signature: v=1.0 a=rsa-sha1 i=iim.example.com s+=example.com
      t+=1094844765.334354 x+=432000
      h=META-Auth/t=1094844765.338603/a, EDigest/t=1094844765.338603/a,
          Saved-1094844765338603-From//a, Saved-1094844765338603-Date//a,
          Saved-1094844765338603-Subject//a
      d="Tg67/+k8oltzxIBxN4mevOgbP/+xqxeuT0ugZJ1VoaEm3bJ7JHAOy+X5FEMRF
           /SLZ+GBYIA7wtEmjgbHNuVRnbJQWu732PRbI6UKNGocCEX0TvVdZxFTQzbh3x
           zaEj6BIWx6GYIo8oWoeM3kzZTiip2pPhuvaXu9Ho+3eR81MZ4="
      e="Iw=="
      m="zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda
            s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7 
            674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="
  META-Auth: s=http:KRS  l=_krs f="krs_service"  t=1094844765.338603
  EDigest: v=1.0 a=sha1 c=nofws n=1192 t=1094844765.338603
      t=1094844765.334354 d="51f0483a89e441e2fc45a12a4303ca217f34617e="
  Saved-1094844765338603-From: John Doe <[email-masked]> 
  Saved-1094844765338603-Date: Fri, 10 Sep 2004 12:25:51 -0700 (PDT)
  Saved-1094844765338603-Subject: RE: Lunch

The above flexibility and choice of what and how is to be included in 
the signature is totally on the discretion of the signer. So if signer
thinks that if any modifications are done to the message, then the
signature should no longer be trusted, then just don't specify number
of characters after canonicalization (dont add "n" tag), similarly if you 
dont want headers copied - dont do it and reference header directly.

One last thing I'd like to note is that by adding hash of body in separate
EDigest header, it becomes possible to begin to do signature verification 
and authorization right after the headers were received, i.e MTA can still
be receiving longer email body but may already be in process of getting
public key from dns record and can verify that cryptography is valid. Then
after all data is received the remaining detail is to verify that SHA1
hash of EDigest was correct (which BTW can also done while message is
still in process of being received).

Anyway if you like what you saw above, please feel free to discuss this on 
the list and I welcome all suggestions on how this can be improved further.
I'd like to finish initial design within next month and have implementation
ready by February (it may/should even be possible to reuse existing DK or 
IIM implementation). I also plan to submit all the above as internet drafts
by next IETF.

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg