EICS - External Information Checksum System

• Overview
• Summary
• Background
• Details
• EICS-H: the Email Header type
• EICS-F: the File type
• Feedback

Overview:

EICS, the External Information Checksum System, is a way to put information about external objects into a text file. It is specifically designed to allow a cryptographically-signed mail message to contain information about the envelope used to send it, such as the "From", the "To", and the "Subject".

(Very) Brief Summary

EICS-H: f6a753ee7a514d809bffde90d4bd2080

The above line in an email indicated that the common fields in the header of the email (From, To, and Subject) will create the checksum shown.

Background:

With the introuction of PGP, and especially the open-source program Gnu Privacy Guard (GnuPG), it became possible to cryptographically sign your emails (also called digital signing). This has many advantages, the most important of which was ensuring the integrity and the authenticity of the email message, tasks which the existing Internet mail system cannot do. A signed email ensures that only the person who owns the key wrote the message, and that the message was not changed in transit.

One problem concerning signed email is that only the body of the email can be signed. Important information, such as who the email was sent to and from whom the email was sent, can not be easily included without cumbersome measures such as repeating the information inside of the body of the message.

A solution to this problem is to create a small checksum which, along with some standard characters, can verify the external information. Standard uses include verifying attached files and verifying the subject, sender, date, and/or recipients of an email message.

Details:

The EICS information should be of a form easily parsed from inside a message. The computing of checksums is not something humans can do, so typically the mail program, or a simple script, is used to parse out the EICS message and perform the checks. An EICS line has the following characteristics:

• EICS information is indicated by the uppercase letters EICS, a hyphen, and a single letter indicating the type of external information. This must be followed by a single colon and a single space.
• The unique string (e.g. "EICS-H: ") should appear at or near the start of the line when possible.
• EICS information ends at the end of the line, or when a single space, followed by ":EICS" is encountered. the use of the second form is discouraged and should only be used when necessary.
• After the space, the options for this type of information must be included. Options are one or more characters and are dictated by the type of information. Each option should be preceded by a plus or a minus sign. A lack of sign indicates an implicit plus, but signs should always be included.
• A space must appear after all options to indicate the end of the options. Everything after this point is type dependent, but usually includes at least a checksum.
• Each information has default options that are always in place unless overridden explicitly. For example, the mail header type has an implicit "S" option, which is always used unless "-S" is indicated in the options. Options are read from left to right and may overwrite one another.
• Options defined for a type should be uppercase, and custom options should be lowercase and defined in a policy as explained below.
• User-supplied options, or information types the reader may not be familiar with, should be described with a policy URI. This will always be the first URL in the line. Applications should follow this link to learn how to decipher the EICS if they do not already know how for the particular type and options.
• The preferred type of checksum is SHA1, but MD5 is also acceptable. These are the default checksums for each type, and the program should figure out which by the size of the checksum (SHA1 is 40 characters long and MD5 is 32 characters).
• Multiple EICS lines are permitted, and should all be grouped together when posible.

EICS-H: the Email Header type

The following is the specifications for the email header information type:

• The code shall be the letter "H"; the complete code will thus be EICS-H:
• Each header to be considered is put into a block of text, one header per line, to generate the checksum (see below for details).
• The default headers are the "To:", "From:", and "Subject:"
• The Date field is not included as a default header because a date is normally included as part of a cryptographically signed peice of text. Also, the envelope date is often not known at the time of the message creation. The Date can easily be included by adding a +D in the options area.
• To create the block of text, each header should be made into Studly Caps (capitilize first letter of each section), followed by a colon, a space, and then the content. All headers should be arranged alphabetically (case sensitive), one per line, and have only the newline character at the end of them. Capitilization and whitespace within the content should be preserved. Example:

  
  From: greg@turnstep.com
  Subject: Re: different keys for different machine?
  To: gnupg-users@gnupg.org
  X-PGP-Fingerprint: 2529 DF6A B8F7 9407 E944 45B4 BC9B 9067 1496 4AC8
  

• Each header has an abbreviation which is used in the options section to indicate whether or not it was used to generate the checksum. The default option is therefore "+F+S+T". The current list of header abbreviations is:
  • T - To (default)
  • F - From (default)
  • S - Subject (default)
  • C - CC
  • D - Date
  • B - BCC
  • L - X-Mailer
  • P - X-PGP-Key
  • I - In-Reply-To
  • G - Message-ID
• After the option, a checksum of the type SHA1, generated by the block of text indicated by the options, must appear. A MD5 checksum can also be used, but its use is discouraged.
• Custom header codes should always be lowercase, and a link to a URL explaining the policy should be provided. These URLs should follow the checksum, separated by a single space.
• The page linked to by the policy URL can have any format, as long as somewhere on the page the codes are explained in the following format:
  • For each custom code, one line should be used.
  • The line should start with EICS-H:, followed by a space, the letter used, another space, and the name of the header. Whitespace or end of line indicates the end of this header. Here is an inline example, using <PRE> tags:

    EICS-H: f X-Face
    EICS-H: m Mime-Version
    

Examples of the email header information type:

1. Basic header type with default options and a MD5 checksum:
   EICS-H: f6a753ee7a514d809bffde90d4bd2080
    
2. Header type with an additional "Date" field, using MD5:
   EICS-H: +D f6a753ee7a514d809bffde90d4bd2080
    
3. Header with an additional CC field, using a SHA1 checksum
   EICS-H: +C d62075892d20a26286dde452ff65a846e3c4a333
    
4. Header without the From, with a X-PGP-Key field, using SHA1:
   EICS-H: -F+P f6a753ee7a514d809bffde90d4bd20803e12ca76
    
5. Header with a "Date", a custom field, and a policy URL (MD5)
   EICS-H: +D+b f6a753ee7a514d809bffde90d4bd2080 http://www.biglumber.com/eics.html
    

EICS-F: the File type

The following is the specifications for the attached file information type:

• The code shall be the letter "F"; the complete code will thus be EICS-F:
• Each file should appear on its own line, with the checksum, a single space, and then the name of the file. This name should correspond to the name indicated by the attachment 'header'.
• Each file should be listed in the order that it appears as an attachment.
• No options are currently supported.
• The name of the file may be left out entirely, in which case the order of the EICS lines is assume to match the order of the attached files.

Examples of the file attachment information type:

1. Attached file named "joy.doc" with a SHA1 checksum:
   EICS-F: f6a753ee7a514d809bffde90d4bd208013ed4765 joy.doc
    
2. Three attached text files, using MD5:
   EICS-F: ce4c084cfa1f6a6d9e63782f3a152654 notes.txt
   EICS-F: b3767b6725f958b9f1f91748b14df36c support.txt
   EICS-F: f409b93d94192428d9cc25a9370d160f license.txt

Feedback

Feedback is very welcome and encouraged. Send email to greg at turnstep.com. My PGP key is available and encrypted email is always welcome.