Top : Open Source : Herbivore : Specification
[ see also: Herbrip ]


Herbivore Specification, v0.2

Specification for the Herbivore email format, version 0.2.

Interspersed through this specification are NOTES, which are not part of the specification, but are comments on it. Notes look like this:

NOTE: this is a note. It is not part of the specification itself.

1. Introduction

The Herbivore email format uses Internet RFC 2822 email as its base protocol; it adds extra headers to email, and encrypts the body (if it can).

Herbivore-compliant emails come in two varieties: encrypted and unencrypted (i.e. plain text). An encrypted email is send when a Herbivore client is sending email to an email address for which it knows there is a Herbivore client at the receiving end, and for which it has the recipient's public key (in practise, these conditions are likely to be both true or both false).

An unencrypted email is sent on all other occasions. Unencrypted email contains header information saying, in effect: ``I'm a Herbivore client, and here's how you send me encrypted email''.

2. Herbivore-awareness headers

These headers are X-Herbivore: and X-Herbivore-Version:. All Herbivore email carries these headers.

X-Herbivore: this header contains a value of either enc or plain, which denotes whether it is encrypted or plain text.

X-Herbivore-Version: is the version of the Herbivore standard that the sending MUA understands.

Example:

X-Herbivore: plain
X-Herbivore-Version: 0.2

Versions of Herbivore less than 1.0 are not guaranteed to be compatible with each other; this is because Herbivore is (before 1.0) still an experimental protocol and subject to change. Versions greater than or equal to 1.0 should be compatible with each other, that is to say, when two Herbivore clients, both understanding a version >= 1.0, communicate with each other, they should be able to send encrypted mail to each other and each decrypt the other's mail.

3. Key information

This header states the sender's public key, so that other Herbivore-compliant MUAs can send encrypted email to the sender. The header is: X-Herbivore-Key:.

X-Herbivore-Key: contains the RSA public key of the sender. It is in Radix-64 format as output by the openssl executable..

NOTE: this is a cop-out. I probably ought to define the key format in detail.

Example:

X-Herbivore-Key: MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDI72GvPw6pF9s/VvJq9FHKCqux
 ryeCiE9qvrk1gRO8UWqEdLXo4T6WWHDVeMM26Wa+/5gcL8KV3sxYtWV7AR40O0ze
 Umky3/HDqV4XlikZP/y7JCSHdn5R8HS8gSVCsqVs9kmLCILZZynQVbqoiyp1FrRt
 +6pTXYonZ45ZXBWqmwIDAQAB 

4. Encrypted email body

This is in two parts. The first is a 128-bit blowfish session key, encrypted with the intended recipient's RSA public key, and radix-64 encoded.

The second part is the actual text of the message, encrypted with blowfish algorith and the session key, and then radix-64 encoded.

The two parts have a separator between them, consisting of a line containing "-----". The encrypted message is encased in Herbivore header/footer blocks, as in the example below.

Example:

----- BEGIN HERBIVORE ENCRYPTED -----
LH46/rmN2hjVy1qD54vd9dGH7SZpenZPcnTGyFp9zTX1NnnI+dDPeJKNwOpzxUd8
04oOegcc4Epc/2Ty2h8okANL/92cjo3otMoKGY5ASZKnbAZohfRomOJdOybxwXIQ
75rxG+h9KI9JYB2qrS9RH9Y3NUgAkCCOvCd0H6BwJDk=
-----
NRH/Gr9N5DJiovlp01ZPYRpJqb+WnIZxPGcZgFJCXw1wxnNuAaQUAg==
----- END HERBIVORE ENCRYPTED -----

NOTE: again, this is a cop-out too. The details of how Herbrip interacts with openssl to produce this output are in encwrap.py in the Herbrip package.

5. Possible future improvements

New headers might include: X-Herbivore-Key-URL: for sending a public key and X-Herbivore-Fingerprint: for a key's fingerprint. The idea here is to make man-in-the-middle attacks harder.

X-Herbivore-Key-URL: would contain a URL which contains the sender's public key.

X-Herbivore-Fingerprint: would contain the fingerprint of the sender's public key.

If the email is encrypted, some of the headers from the unencrypted email could be encrypted too. They would be removed from the RFC2822 email header, and put in the email body; then there would be a space between them and the rest of the unencrpyted message body. On decryption, they would be put back in the header. These header lines could be encrypted in this way: Subject:, In-Reply-To:, References:, Keywords:, Comments:.

References

[RFC 2822] Internet message format. Defines the format of email headers. Obsoletes RFC 822.


By Philip Hunt, philh@comuno.freeserve.co.uk
Last altered: 22 Jul 2001.