May 04, 2004
Implementation for header signature - first draft The signature will apply to the head of the message only and it will include the following headers:
From, To, Date, Subject, [TODO: what other headers ?]
The value of the headers, with the whitespaces at the beginning and end removed will be concatenated, and the MD5 digest will be computed on the resulting value.  The result will be signed using DSA alghoritm with an 128 bit key. The signature will be then encoded using Base64, and this will be used in the value of the signature header.

The following headers will be added to the message:
  • X-Head-Sig: TYPE VALUE
  • X-Head-Key-Location: TYPE URL
A message may have one or more signatures, but only one of each type.

The types of signatures are:
  • User signature - indicates the key belong to the user, and is associated with the From address
  • Domain signature - indicate the key belongs to the MTA and is associated with the domain of the From address
  • Relay signature - indicates the key belongs to the MTA and the message is a relayed from an entity that is authorized by the MTA.
There are few types of keys:
  • CA-issues keys of class 2 or 3 - used for MTAs for Domain and Relay signature
  • CA-issued class 1 - used for User signature. The CAs are verifying the email address is valid and sometimes more.
  • PGP key available on a key server.
  • PGP key available in HTTP location

Notes and issues:
  • the whitespace need to be removed to facilitate transit with MTAs that may reformat them and to make it easier to implement with MTA or client APIs that doesn't preserve the original structure - for example presents the headers as a hashtable, after parsing them. This eliminates any ambiguity resulting from whitespaces.
  • MD5 is used because it's easily available and common.
  • DSA - I'm not very sure, I've been back and forth between RSA or DSA or other - one thing is clear, it should be only one, otherwise it'll be harder to implement and interoperate. DSA seems a default in PGP, and is widely available. I need to do more reading on legal issues, but again since PGP is using it, it is probably ok.
  • 128 bits - that's the least certain thing. It may be better to use 56 bit - because of legal issues ( I think in some countries 128 bits may be illegal, while 56 may be ok ), and also because it increases the computing requirements for sites with a lot of traffic. This is one case where it may be good to allow options.
  • Should it use TYPE as param, or use different header names ?
  • Certificate revocation ?
  • How to document the mechanism of a receiver getting the first key then storing it and using to verify - in the case a CA or key server is not used ? That means the first message will do the key exchange - spammers may send fake certificates hoping they're the first to get in, so we need this to allow manual control.
Posted by costin at May 04, 2004 11:58 PM