The Passive Privacy System Specification

Maintainer: Aaron Sherman

Specification Version: 2.0 / $Revision: 2.5 $

Specification Status: Draft

Last Modified: $Date: 2001/03/27 18:06:55 $


The Passive Privacy System (PPS) is designed to provide a means for email software (MUAs) to passively provide key exchange and encryption using existing public-key cryptography software.

There are two overriding goals of this specification:

  1. Make encryption so transparent that all users are willing to encrypt their mail all the time.

  2. Provide hooks so that advanced users can enhance security when required.

PPS does not specify the public-key cryptography system to be used. Any software which allows for the creation of a public and private key, and which can represent a hash of the public key should be usable.

The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and ``OPTIONAL'' in this document are to be interpreted as described in RFC 2119.


Since this specification does not detail what public-key cryptography system to use, the format of some fields are software-dependent. For this reason, later specifications will outline the format of those fields and their specific interpretations on a package-by-package basis.

Header Namespace

There are five headers that a PPS mailer might set:

This header MUST be set in every message, and consists of two fields: SPEC/SOFTWARE

Beyond the restrictions placed on headers by RFC 822, each of these fields MUST not contain whitespace and the SPEC field may contain only digits and periods.

These are the meanings of each of the fields (note: compliant MUAs MUST understand all of the optional items listed below, but MAY not choose to produce headers with some of them):

The version number of this specification being used (e.g. 1.2). Versions of the specification with the same major version number (e.g. 1.2 and 1.3) should be forward- and backward-compatible with each-other, insofar as they should be able to perform key-exchange and encryption under all conditions supported by the lower of the two version numbers.

This compatibility is desirable, but not dictated between major revisions (e.g. 1.2 and 2.0).

The underlying encryption software being used (e.g. GPG). MAY optionally have a / to indicate software version (e.g. GPG/1.0.4).

This field MAY specify multiple applications. In which case, each software specification will be joined with a comma (``,''). For this reason, commas MUST NOT appear elsewhere in this field (e.g. ``PGP,GPG/1.0.4,muskrat'' indicates that this MUA understands all PGP versions, GPG version 1.0.4 and all muskrat versions).

This header MUST be set in every message, and consists of the software-specific ``fingerprint'' or hash of the sending user's public key. This will be used for several purposes including: determining when to request an updated key; inclusion in the X-PPS-Request header; and manual key-verification.

This field is free-form and constrained only by RFC822, but applications which use PGP-like systems for encryptions MAY choose to use the convention of "KEYID/FINGERPRINT" in order to include the KEYID in requests (which will make fetching the key easier).

A special value for the fingerprint is ``VOID''. If this value is sent, the MUA MUST warn the user (and MAY allow the user to cancel the operation) and then dump all active public keys for the sender.

This header is set by the sender to indicate that a key is being requested. The contents of the header are the target key's fingerprint as seen in a previous X-PPS-Fingerprint header. Thus, this header MUST NOT be set in every message. Instead, it is only set when a previous message from a recipient of the current message indicated that PPS compliance was in place.

This header MUST be set by the sender in response to an X-PPS-Request. It is in two parts: a numeric code (ala SMTP or HTTP) and a string message. The message is interpreted according to the code, which MUST be one of the following:
Code: 200
The request was successful, and the message portion is a filename.

The message MUST contain a MIME attachment with the given filename of type application/x-pps-key (see MIME Types). That attachment will contain the public key in an encryption-software-specific format.

Code: 201
Same as 200, except multiple requests were received, and only this key was available. This is almost certainly the result of a conservative MUA sending only one set of headers to multiple users. This is valid, and the receiving MUA MUST return any keys for which it is authoritative (i.e. public keys for which it possesses the secret key).

Code: 400
The specified key does not exist. The message is suitable for presentation to the user.

Code: 500
An error was encountered while processing the request. Further attempts to request the key may be successful. The message is suitable for presentation to the user.

Further codes may be added at a future date, according to the following scheme:

Any code >= 200 and < 300 is a success (though it may be qualified, the expected result MUST also be available, e.g. a key attachment).

Any code >= 300 and < 400 indicates that the requested resource has been moved. Because of some privacy concerns no such codes are currently in the spec. [NOTE: under consideration is the use of 300 codes for indicating key expiration]

Any code >= 400 and < 500 indicates that the request cannot be serviced at any time.

Any code >= 500 and < 600 indicates an error.

Thus, compliant implementations SHOULD interpret, but MUST NOT produce error codes which are not explicitly in the specification version indicated by the X-PPS-Version header that the implementation produces, but are within the above ranges.

Key Exchange


When a user first runs a PPS-compliant MUA, a new public/private key MUST be generated with the user's email address (and optionally name) associated with it. This key pair MUST be stored in an area which is common to all PPS applications, not the mailer or the encryption program (e.g. $HOME/.pps under UNIX and UNIX-like systems).

By default, accessing the private key SHOULD not require any user interaction. This means that no passphrase or other authentication SHOULD be required, although a compliant MUA MAY provide a way to enable such security if the user desires it.

It is important that the reasons for this decision be clarified. Recall that one of the goals of PPS is to ensure that all encryption is transparent by default so that the largest number of target users will encrypt email. This goal is subverted if PPS introduces any complexity into a user's environment. While the argument could be made that less than ideal security is mandated by this requirement, it is also true that a) far more people will use PPS given this requirement and b) no security is lost for those who wish to configure a password/passphrase for their private key.

Key Management

The MUA MUST generate a new public/private key on a periodic basis. To be compliant with the specification, this period SHOULD be no longer than one year and no shorter than one month, but MAY be user-configurable outside of these ranges. MUAs are directed to consider a default of six months, but adherence to this recommendation is OPTIONAL.

New keys SHOULD be signed by the previous key. Note: some systems will not support signatures; this feature is only optional when using such a system for the back-end encryption. Old keys MUST be kept to decrypt messages sent with obsolete keys. A mechanism MAY be provided to allow the user to clean out old keys.

Triggering Key Exchange

When a message arrives, the MUA MUST scan it for PPS headers. If X-PPS-Version and X-PPS-Fingerprint are not present, the MUA MUST NOT perform any further PPS processing. One exception to this is when the message contains no PPS headers and the subject header includes the string ``PPS-Void-Key''. This string may appear anywhere in the subject and is case sensitive. If it is found, the MUA should behave as if the X-PPS-Fingerprint header were found and contained the ``VOID'' keyword, and then processing of the message ends.

If the message body is encrypted, it MAY now be decrypted before further action is taken, or at any time during the following steps.

If there is an X-PPS-Request header, then a note MUST be kept (Platform Specific Issues, below) indicating that the next message to this user MUST include the appropriate X-PPS-Response.

It is possible that there will be multiple X-PPS-Request headers. In this case, either one X-PPS-Response header MUST be generated for each request or a single X-PPS-Response header of code 201 MUST be generated indicating the one key that the local system was able to provide.

If there is an X-PPS-Response header, then the message MUST be scanned for the indicated public key, and that key is then stored. The MUA MAY remove the public key from the message, as long as the MIME structure of the message is preserved.

Multiple X-PPS-Response headers MAY be generated in a single message, but there MUST NOT be more than one success per message. Any additional X-PPS-Response headers would indicate failed key requests (perhaps for requests that were aimed at other users).

If the X-PPS-Fingerprint header references a key which is not in the local key-ring, then a note MUST be kept indicating that the next message to this user will include a request for his/her key.

If the X-PPS-Fingerprint header references a key in the local-key ring which is associated with a different address, the sender's address should now be associated with that key as well.

Sending Mail

When a message is to be sent, two things MUST be checked: the local list of public keys and the notes file which contains a list of users for which action is pending.

Any action indicated in the notes file MUST be taken, which can result in additional headers being attached and/or a MIME attachment added with the current public key for this user.


If a key exists for the user to whom mail is being sent (even if the notes file indicates that it is obsolete), the message body MUST be encrypted, including any public key. Note: a compliant MUA MAY allow the user to override this encryption on a global, per-message or more complex basis.

The encrypted message MUST be placed in a MIME attachment of type application/x-pps-encrypted (see MIME Types).

Message Structure

Here is a sample encrypted message:

  Subject: Sample message
  X-PPS-Version: 2.0/GPG
  X-PPS-Fingerprint: 2676CEAB/6DC1 F67A B9FB 2FBA D04C  619E FC35 5712 2676 CEAB
  MIME-Version: 1.0
  Content-Type: multipart/mixed; boundary="----ABC"
  This mail message is encrypted so that only the intended recipient can
  read it.
  Content-Type: text/plain; charset=us-ascii
  Content-Transfer-Encoding: 7bit
  This mail message is encrypted so that only the intended recipient can
  read it. If you are seeing this, it is probably because you have
  switched to a mail program that does not know how to "decrypt" the
  Either switch back to your old mail program; find out how to enable
  "PPS" in your new mail program or reply to this mail, and add
  "PPS-Void-Key" in the subject line to prevent further mail from being
  sent securely.
  Content-Type: application/x-pps-encrypted; software=GPG
  Content-Transfer-Encoding: 7bit
  Version: GnuPG v1.0.4 (GNU/Linux)
  Comment: For info see
  -----END PGP MESSAGE-----

There are several things to note about this message, and each will be taken in turn, below:


The plain text preamble MUST be stripped by the MUA and not shown to the user. It's content is implementation-dependant, but SHOULD indicate to anyone reading it that they are not using a PPS-compliant MUA and provide them with suggestions on what to do about that.

MIME Types

There are two MIME types used by PPS:

This type is used for enclosures which contain public keys referenced from an X-PPS-Response header.

This type is used for enclosing the entire body of the original message (including original MIME headers) in an encrypted form.

Obviously, both of these types will enclose data which is encryption-software specific. Because the X-PPS-Version header can contain multiple available back-end software options, the content type must indicate which back-end to use when decoding this data. The attribute software is used to specify this information, e.g.:

  Content-type: application/x-pps-encrypted; software=GPG

This identifier MUST appear in the X-PPS-Version header. The software attribute MUST NOT specify more than one application to use, though the X-PPS-Version header may specify an arbitrary number.

A PPS MIME type has been chosen instead of using the MIME type appropriate for the underlying encryption because of Web-based mailers. In this case, incoming mail will be seen in its encrypted form by the user, but because the MIME type of the encrypted data is associated with PPS, the local system should be able to determine what to do with it. If the MIME type were associated with the encryption software, PPS configuration information might be lost.

MIME Conventions

The boundary string and other MIME conventions such as Content-Transfer-Encoding of attachments are implementation-dependant. The requirements only include: the multipart/mixed type of the overall message; text/plain preamble for encrypted messages and the PPS MIME types for PPS-readable attachments.

User Interface Issues

Sending Mail

When composing a message, the MUA SHOULD indicate in some way (e.g. by color coding, placing an icon near the name, underlining, etc) the current key status of each intended recipient.

Also, a mechanism MAY be provided (for the user) to force a message to contain his or her public key and an X-PPS-Response header, even if it was not requested. This allows the user to shorten the number of messages which must be sent in order to exchange keys.

When the mail is sent, a separately encrypted copy of the message MUST be generated for each recipient for which a public key is available. This encrypted message is sent in place of the plain text.

Reporting Status

Keeping in mind that the goal is transparency, messages provided to the user SHOULD be minimal by default. Errors SHOULD only be reported if they indicate an exceptional error (e.g. a message cannot be decrypted).

Some cases MUST result in a message to the user, however:

Receipt of a new key
Every time a key is received which would replace and existing key, a message MUST be presented to the user. Optionally, the MUA MAY ask the user if they wish to accept this key. The username and fingerprint MUST be presented.

The reason for this is that a man-in-the-middle attack can happen after key fingerprint verification, and without alerting the user, he/she does not know to re-verify the key.

New key generation
Since new key generation may be slow, the user MUST be presented with some indication that it is being performed. Ideally, the MUA SHOULD provide progress status, but this may not be practical.

Platform Specific Issues

One key to PPS is that it needs to work across MUA implementations so that the user can safely use multiple mail systems and still perform key-exchange and encryption correctly.

In order to further this goal, operating-specific conventions are laid out in the following sub-sections. Any PPS implementation on one of the described platforms MUST comply with these conventions. Implementations on other platforms SHOULD attempt to use whichever of these conventions most closely matches their system (e.g. Linux implementations SHOULD follow the UNIX guidelines), but MAY tailor them to the specifics of the local feature-set.


Under UNIX systems, a ``.pps'' directory MUST be created in the user's home directory. It will contain the key files as well as a file called ``notes''. The notes file SHOULD ideally be a Berkeley DB file, but if DB is not available on the system, NDBM MUST be used. The file contains keys which are email addresses and values which are of the form:


In other words, the value is a list of entries (separated by slashes) which consist of a number and an optional fingerprint (the number and fingerprint to be separated by a colon). The entry MUST be nul-terminated.

The numbers are codes for:

code: 1
The specified key has been requested.

code: 2
The specified key fingerprint was not recognized, and a new key MUST be requested.

When an entry is acted upon, it MUST be be deleted from the notes file.

Alternate Key Exchange

MUAs MAY explore alternate methods of key exchange as long as the basic PPS key exchange protocol is also supported.

For example, an MUA MAY choose to check with an Internet key server to find a new user's public key. If this check works, there is no reason to request the key via an X-PPS-Request header. However, should such a lookup fail or yield a key which does not match the X-PPS-Fingerprint, then an X-PPS-Request header MUST be generated as normal.

Other forms of key exchange might include:


Here are some example exchanges. Only the From, To and PPS-related headers have been included.

The Simple Case

The first user, foo, sends mail to his friend, biz:

  X-PPS-Version: 2.0/GPG
  X-PPS-Fingerprint: 2676CEAB/6DC1 F67A B9FB 2FBA D04C  619E FC35 5712 2676 CEAB

biz notices the PPS headers, and replies with a request for foo's key:

  X-PPS-Version: 2.1/GPG
  X-PPS-Fingerprint: 12345678/1234 5678 9ABC DEF0 1234  5678 9ABC DEF0 1234 5678
  X-PPS-Request: 2676CEAB/6DC1 F67A B9FB 2FBA D04C  619E FC35 5712 2676 CEAB

foo responds with his key, and returns a request for biz's key:

  X-PPS-Version: 2.0/GPG
  X-PPS-Fingerprint: 2676CEAB/6DC1 F67A B9FB 2FBA D04C  619E FC35 5712 2676 CEAB
  X-PPS-Request: 12345678/1234 5678 9ABC DEF0 1234  5678 9ABC DEF0 1234 5678
  X-PPS-Response: 200 key.asc

biz responds with his key:

  X-PPS-Version: 2.1/GPG
  X-PPS-Fingerprint: 12345678/1234 5678 9ABC DEF0 1234  5678 9ABC DEF0 1234 5678
  X-PPS-Response: 200 key.asc

Two things to note: First, message 4 and every message thereafter between these two will be encrypted. Also, the keys have not been shown, but messages 3 and 4 would contain attachments called ``key.asc'', which would contain each of the user's public keys.

New Addresses

Assuming the above exchange between foo and biz, let's see what happens when biz also uses the address

  X-PPS-Version: 2.1/GPG
  X-PPS-Fingerprint: 12345678/1234 5678 9ABC DEF0 1234  5678 9ABC DEF0 1234 5678

Since foo already knows this key, he simply records the additional address for which it can be used. This key exchange is complete.

Mail To Multiple Recipients

When sending mail to multiple users, the MUA is required to generate one unique message for each target user that a key is known for or any headers other than X-PPS-Version and X-PPS-Fingerprint are being included. However, any other messages MAY be accommodated with the same headers:

  X-PPS-Version: 2.0/GPG
  X-PPS-Fingerprint: 2676CEAB/6DC1 F67A B9FB 2FBA D04C  619E FC35 5712 2676 CEAB

Related Documents

For more information, please see the following documents:

Standard for the Format of ARPA Internet Text Messages
RFC822, David H. Crocker, 1982,

Simple Mail Transfer Protocol
RFC821, Jonathan B. Postel, 1982,

Multipurpose Internet Mail Extensions
RFC2045, N. Freed, N. Borenstein, 1996,

Key words for use in RFCs to Indicate Requirement Levels
RFC2119, S. Bradner, 1997,

The GNU Privacy Guard
The Free Software Foundation, 2001,