ietf-mailsig
[Top] [All Lists]

META Signatures - 0.21 update. Edigest Header Field.

2005-06-08 10:10:34


I've made update to META Signatures to 0.21, this is a temporary spec
because 0.22 will be ready end of the month, but there will no technical changes, only some text improvements. Current spec is as always at:
  http://www.metasignatures.org/meta_signatures_protocol.htm

In this email I'll go through smaller portion of the spec - EDigest

The changes that were done are as follows:
 1. The "m" and "p" tags for referencing actual MIME part by name
    are gone and have been replaced with "u" tag, which can reference
    MIME part by URI, specifically by means of "cid:" URI as defined
    in RFC2392. This seems most appropriate and IETF standard way
    of doing it. As before it is optional and if "u" is not present
    the EDigest (if directly in Email Header) is digest hash for
    entire message data (and if somebody wants to they can make
    sure its for correct message by using "mid:" URI from same RFC2392).
 2. New optional tag "e" for encoding has been added and it is used to
    list value from Content-Transfer-Encoding field at the time digest
    is created. In case its not the same in the received message
    an attempt maybe made to do conversion (worked in at least one
    of my test cases).
 3. It has been clarified that "h" tag for inclusion of header fields
    in message digest works differently then with META-Signature and
    is position-independent from location of EDigest, i.e. if EDigest
    is used inside MIME header or Mail header the fields specified
    would be both for those above and below it.
 4. The names for canonicalization "c" tag had been changed to "all",
    "nofws" and "none" with 'all' meaning that entire data is used with
    no canonicalization and 'none' means no message/mime data (special
    reserved use of Edigest just for some header fields). Specifying
    canonicalization is now optional and by default its "all".
 5. The names for "a" tag, i.e. hash/digest algorithm have been
    specified. It can be: md5, sha1, sha224, sha256, sha384, sha512
 6. A step-step procedure of how edigest is created and verified is
    described

Here is an example of EDigest with all optional fields in it:
   EDigest: v=1.0 a=sha1 i=system1.example.com t=1094844768.4914354
       u=cid:foo4*foo1@example.com,cid:foo5*foo1@example.com
       c=nofws e=7bit h=Content-Type
       n=195 d="51f0483a89e441e2fc45a12a4303ca217f34617e="

And here is minimum form of Edigest:
   EDigest: v=1.0 a=sha1 d="51f0483a89e441e2fc45a12a4303ca217f34617e="

As I mentioned I'm starting work on Internet-Draft for this and do not anticipate any more changes to the syntax.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net


<Prev in Thread] Current Thread [Next in Thread>
  • META Signatures - 0.21 update. Edigest Header Field., william(at)elan.net <=