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:
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.
There are five headers that a PPS mailer might set:
X-PPS-VersionSPEC/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):
SPEC1.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).
SOFTWAREGPG). 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).
X-PPS-FingerprintThis 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.
X-PPS-RequestX-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.
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, which MUST be one of
the following:
200The 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.
201400500Further 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.
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.
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.
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.
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).
Here is a sample encrypted message:
From: foo@bar.com To: biz@baz.com 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.
----ABC 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 message.
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.
----ABC Content-Type: application/x-pps-encrypted; software=GPG Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org
hQIOAxe3tAbDp1zJEAgAgifW60WXczo/aAWwZqv4WhNXY4ZUMd7w2MVyZhz/k+52 YitZjhrV8An2f0Y2r2nzXa6yKCyIaIl6EGiTa8gP+8g63rOSFWjtWRPkrWflh/gj omHW8we32GQZblymDTNcnOI42WKDmxTucMO5NAawhXfihkeDd50AKqt4dwGFojDN 7MsyCvvICEBp7hdJnI0+fZxvIJqGjBui344XwZoL2T7BrfSMzhrYYsvTHYzurbDH m9K4HqD86LXats3ao8UfYh7tb6U7tgzI3dhDaiX7ydGkY5J3gSJgWyIGh2WsSJoh g+X7UAtRojUcA17i0ekM7zWGZSB/qvcKuT4enWi05Qf/euEuCyBn8zvM63WgTj0F gBcFt9NGpe9IOQ1fPel5COIb7J2P6gUlBqvL8FCW5P3VU8KVls/QH5nUJgUPZwT0 Jc0A1mIjpK0ZjI8EddQweCpNWHCRPQr18FLG5gfutAHXU+RLgg4z/AWikODaaefa 3JDADSiPK9ggtmRu3NVCMYihONt4b7BgVL41Vpw+O0YcmH+XWrXZJzDp929Wcp1l 4lPt/if3SpOgx/VU2KDoPOFU9d2/XPojlO9FDRLI67lgnnwWSjFKB/3saKGi3UpG o0zDxVfmGmAQc0qKsd+Aw3lTm4j9YVOAtUvf3bfvbvpOWn3jtHFNcELcXzNL1bnP L9JeAU0j2IyUdk/IRW/VTKgRvaDzn6i0CpPM/RHBnS5JcwJ4XGOW8npjV/lIchls aKCjx/pNC0yrRNxmajQt8Pfc2G/lLTcGptVtl2VUfSoOQF47vCP3qF9216D4On/9 Qw== =jTfm -----END PGP MESSAGE-----
----ABC
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.
There are two MIME types used by PPS:
application/x-pps-keyX-PPS-Response header.
application/x-pps-encryptedObviously, 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.
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.
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.
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:
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.
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:
<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.
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:
finger program, which can be used to check the target user's
``plan'' file for a public key.
Here are some example exchanges. Only the From, To and PPS-related
headers have been included.
The first user, foo, sends mail to his friend, biz:
From: foo@bar.com To: biz@baz.com 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:
From: biz@baz.com To: foo@bar.com 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:
From: foo@bar.com To: biz@baz.com 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:
From: biz@baz.com To: foo@bar.com 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.
Assuming the above exchange between foo and biz, let's see what
happens when biz also uses the address biz@biff.com:
From: biz@biff.com To: foo@bar.com 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.
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:
From: foo@bar.com To: biz@baz.com, ihtfp@xyz.org Cc: mmad@abc.gov X-PPS-Version: 2.0/GPG X-PPS-Fingerprint: 2676CEAB/6DC1 F67A B9FB 2FBA D04C 619E FC35 5712 2676 CEAB
For more information, please see the following documents: