I've updated META Signatures proposal with primarily overhaul being that
of META-Auth headers syntax. The new document for your review is at:
http://www.elan.net/~william/emailsecurity/meta_signatures_v015.htm
(or just use http://www.elan.net/~william/emailsecurity/meta_signatures.htm)
The old spec has been moved to:
http://www.elan.net/~william/emailsecurity/meta_signatures_v011.htm
Here are the changes from what I had before:
1. EDigest header now has additional optional tag "h" which has the same
syntax as in META-Signature and allows to add hash of headers into Digest.
This is primarily intended to be used when digest is created of specific
MIME part so that headers of that MIME part could be included, i.e.:
EDigest: v=1.0 a=sha1 i=system1.example.com c=nofws n=119
t=1094844765.334354 m=mime-part1:mime-subpart1 h=*
d="51f0483a89e441e2fc45a12a4303ca217f34617e="
But this also allows to create a digest of just specific group of
headers of email message (for this canonicaliztion type "none"
is used which means hash of body is not to be included in the digest).
An example of such use is:
EDigest: v=1.0 a=sha1 i=system1.example.com c=none
h=Message-ID,Date,Content-*
d="51f0483a89e441e2fc45a12a4303ca217f34617e="
2. The syntax of META-Auth headers had been changed and instead of locator
tag the full URL is now specified. The META-Auth headers now look like:
META-Auth: s=pk-dktxt u=dns:key1._dk.example.com?type=TXT
META-Auth: s=pk-dnskey u=dns:_key1.example.com?type=KEY
META-Auth: s=kr-dns
u=dns:073FDD7DD6D6EF6D1413FD7B3C577EFC._krs.example.com&TYPE=KR
META-Auth: s=krs u=http://krs.example.com/krs/
META-Auth: s=x509 u=http://_certs.example.com/filename1.cer
META-Auth: s=pgp u=http://pgp.example.net:11371/pks/
In order to check that listed URL is authorized to act on behalf of
signer an SRV lookup maybe needed to _meta.signer-domain. For example
if signer domain ("s" tag) is example.net and URL specified in header
is http://www.example.com:8080/ then correct SRV record is:
_http._tcp._meta.example.net. IN SRV 0 0 8080 www.example.com.
However these SRV lookups are MUST only if domain specified in 'u'
is completely different then signer's domain and if that URL is
for domain that is a system subdomain (with '_', such as _krs.example.com
when for signer's domain is example.com) then SRV lookup is not necessary.
Also of interest is that wildcards can be used with above SRV records
in very usefull way (more about it in the document spec).
3. I introduced new idea of authorization expression. This is envolving
idea of trying to unify specificatoin of various authorization systems
into one but its use is going to be primarily for experimental testing
of new authorization methods and as universal authorization function
for metasignatures implementation (i.e. for software config). The
authorization expression uses some macros and functions to define
authorization system:
----------------------------------------------------------------------------
Address Macros:
{s} - signature signing entity (full "s" tag in META-Signature)
{d} - domain of signing entity (domain part of "s" tag in META-Signature)
{a} - email address in Sender header (From header if Sender is not present)
{ar} - email address in Resent-Sender, Resent-From, Sender, From header
Crypto Data Macros:
{b} - base hash data (hash of all headers that went into signature)
{d} - raw signature data
{k} - entire public key in der encoding
{e} - exponent of rsa public key
{m} - modulus of rsa public key
{f} - fingerprint of der-encoded public key
{f2} - fingerprint calculated as TRUNC(SHA1(({e}{m})),12)
Data Format Modifiers:
4 - base16 (i.e. hex - 0-9, a-f)
6 - base64 (as in section 3 of RFC3548)
6u - base64 URL-safe (as in section 4 of RFC3548)
8 - 8bit data (default)
8u - URL encoding (8-bit characters that are not printable are replaced
with ascii code)
Examples of full macros:
{f/6} - der fingerprint in base64 format
{d/8} - signature data 8bit
Data Retrieval Functions:
URL - retrieve data from specified url
MIME - for multipart data returns specific mime part
HEADER - for Message-RFC2822 data returns specific header
Data-Set Functions:
TEXT_TAG - when data is text with tag used to seperate different values,
returns data from specific tag
DNS - for complex dns records returns specific part of it
ASN1 - when data is in ASN.1 format (X.509 and PKCS7 and alike),
it returns specific element of that set
PGP - for PGP formatted crypto data it returns specific element
XML - for xml data this will return data within specified tags
----------------------------------------------------------------------------
With above the authorization for some of the propoals presented at MASS
can be expressed as follows:
IIM DNS authorization -
URL("dns:{f2/4}._krs.example.com?type=KR").TEXT_TAG("a:")=="pass"
IIM KRS authorization -
URL("http://www.example.com/KRS/?domain={d/8u}&name={a/8u}&keyfp={f2/6u}";)
.TEXT_TAG("a:")=="pass"
DK Public Key authorization -
URL("dns:_key1._dk.example.com?type=TXT").TEXT_TAG("p=")=={k/6}
X.509 authorization -
URL("http://www.example.com/certificate.cert";).ASN1(pk)=={k/8}
Link to S/MIME -
MIME("smime.p7s").ASN1(pk)=={k/8}
And you can mix them together with logical AND (&&) and OR (||) so you
could do:
URL("http://www.example.com/certificate.cert";).ASN1(pk)=={k/8}
&& MIME("smime.p7s").ASN1(pk)=={k/8}
Now I have not yet 100% decided how much above is going to be used. As
I noted currently this is for testing for new authorization, but this
may have potential to replace current "META-Auth" headers with universal
function that could directly be part of META-Signature header, however I
think this system is a bit verbose and a bit too unversal (which maybe
security issue).
Also personally I think that good authorization may involve trying to use
fingerprints (as with IIM) with DNS, but not the way IIM wants to do
it by putting fingerprint in the FQDN but instead just directly putting
fingerprint data inside DNS RDATA. For initial testing we can just reuse
AAAA records which are 128bit (and fingerprint in IIM is 96bit) and for
future define new record type. So in this case authorization expression
would be very simple:
URL("dns:fp1._kr.example.com?type=AAAA")=={f/8}
And example of dns record for fingerprint could be:
fp1._kr.example.com. IN AAAA ::073F:DD7D:D6D6:EF6D:1413:FD7B:3C57:7EFC
Maybe above is a bit too simple and we do need more data as part of the
authorization then just the fingerprint itself but in my view its enough
for intitial deploment and this is pretty damn simple to implement and
almost everyone now allows their customers to add "AAAA" records, so it
should be possible to deploy it with no problems (though I suspect dns
people may not be super happy about having AAAA records reused in this
way even if its done for very specific prefix).
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/