Version 1
The Passive Privacy System (PPS) is designed to provide a means for email software (MUAs) to passively provide key exchange and encryption using public-key encryption.
There are two overriding goals of this specification:
PPS does not specify the public-key cryptography system to be used, but this document will assume the use of GPG. 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.
In the course of this specification, the terms must and should are used denote the features which a comliant implementation can have. If a feature ``must'' be included, then an implementation is not compliant without it. If a feature ``should'' be included, then an implementation should only not contain that feature if extenuating circumstances prevent it (e.g. UI issues, platform compatibility, etc). Features which are totally optional are called out as such.
There are four headers that a PPS mailer might set:
X-PPS-VersionMUA/SPEC.VERSION/SOFTWARE
Beyond the restrictions placed on headers by RFC 822, each of these fields
must not contain slashes (``/''), spaces or tab characters. The VERSION field
is the only one that may contain a period.
These are the meanings of each of the fields:
MUAMozilla).
SPEC1).
VERSIONSOFTWAREGPG)
X-PPS-FingerprintX-PPS-RequestX-PPS-Fingerprint header.
X-PPS-ResponseX-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:
200400500Further codes may be added.
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.
Any code >= 400 and < 500 indicates that the request cannot
be serviced at any time.
Any code >= 500 and < 600 indicates an error.
When a user first runs a PPS-compliant MUA, a new public/private
key should be generated with the user's email address (and optionally name)
associated with it. This should be 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 should provide a way to enable such security if the user desires it.
The MUA should 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.
New keys should be signed by the previous key. Old keys should be kept to decrypt messages sent with obsolete keys. A mechanism may be provided to allow the user to clean out old keys.
When a message arrives, the MUA should scan it for PPS headers. If
X-PPS-Version and X-PPS-Fingerprint are not present, the MUA
should not perform any further PPS processing.
If the message is encrypted, it must now be decrypted before further action can be taken.
If there is an X-PPS-Request header, then a note should be kept
(Notes, below) indicating that the next message to this user
should include the appropriate response.
If there is an X-PPS-Response header, then the message should be
scanned for the indicated public key, and that key should be stored.
The MUA should feel free to remove the public key from the message,
as long as the MIME structure of the message is preserved.
If the X-PPS-Fingerprint header references a key, which is not in
the local key-ring, then a note should be kept
indicating that the next message to this user should include a
request for his/her key.
When a message is to be sent, two things should be checked: the local key-ring and the notes file which contains a list of users for which action is pending.
Any action indicated in the notes file should 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 this user (even if the notes file indicates that it is obsolete), the message body should be encrypted, including any public key.
The encrypted message should be placed in a MIME document of a type
consistent with the underlying encryption application (e.g.
application/pgp-encrypted).
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 should 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, each recipient for which a public key is available should have a separately encrypted copy of the message generated, and sent instead of the plain-text.
A means of disabling encryption on a message-by-message basis should be provided. Disabling encryption on a user-by-user basis is optional.
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 things should result in a message to the user, however:
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.
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.
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 can be used. The file
contains keys which are email addresses and values which
are of the form:
<number>[:fingerprint][/<number>[:fingerprint]...]
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:
12When an entry is acted upon, it must be be deleted from the notes file.