=head1 The Passive Privacy System Specification B B> B B =head2 Introduction 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: =over 5 =item 1 Make encryption so transparent that all users are willing to encrypt their mail all the time. =item 2 Provide hooks so that advanced users can enhance security when required. =back 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. =head3 Back-Ends 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. =head2 Header Namespace There are five headers that a PPS mailer might set: =over 5 =item C This header MUST be set in every message, and consists of two fields: C 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 I of the optional items listed below, but MAY not choose to produce headers with some of them): =over 5 =item C The version number of this specification being used (e.g. C<1.2>). Versions of the specification with the same major version number (e.g. C<1.2> and C<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. C<1.2> and C<2.0>). =item C The underlying encryption software being used (e.g. C). MAY optionally have a C to indicate software version (e.g. C). This field MAY specify multiple applications. In which case, each software specification will be joined with a comma ("C<,>"). For this reason, commas MUST NOT appear elsewhere in this field (e.g. "C" indicates that this MUA understands all PGP versions, GPG version 1.0.4 and all muskrat versions). =back =item C 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 C<"KEYID/FINGERPRINT"> in order to include the KEYID in requests (which will make fetching the key easier). A special value for the fingerprint is "C". 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. =item C 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 C 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. =item C This header MUST be set by the sender in response to an C. 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: =over 5 =item Code: C<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 C (see L<"MIME Types">). That attachment will contain the public key in an encryption-software-specific format. =item Code: C<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). =item Code: C<400> The specified key does not exist. The message is suitable for presentation to the user. =item Code: C<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. =back Further codes may be added at a future date, according to the following scheme: Any code C= 200> and C 300> is a success (though it may be qualified, the expected result MUST also be available, e.g. a key attachment). Any code C= 300> and C 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 C= 400> and C 500> indicates that the request cannot be serviced at any time. Any code C= 500> and C 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 C header that the implementation produces, but are within the above ranges. =back =head2 Key Exchange =head3 Initialization 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. C<$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 I encrypt email. This goal is subverted if PPS introduces I 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 C far more people will use PPS given this requirement and C no security is lost for those who wish to configure a password/passphrase for their private key. =head3 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. =head3 Triggering Key Exchange When a message arrives, the MUA MUST scan it for PPS headers. If C and C are not present, the MUA MUST NOT perform any further PPS processing. One exception to this is when the message contains I PPS headers I the subject header includes the string "C". This string may appear anywhere in the subject and is case sensitive. If it is found, the MUA should behave as if the C header were found and contained the "C" keyword, and I 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 C header, then a note MUST be kept (L<"Platform Specific Issues">, below) indicating that the next message to this user MUST include the appropriate C. It is possible that there will be multiple C headers. In this case, either one C header MUST be generated for each request I a single C header of code 201 MUST be generated indicating the one key that the local system was able to provide. If there is an C 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 C headers MAY be generated in a single message, but there MUST NOT be more than one success per message. Any additional C headers would indicate failed key requests (perhaps for requests that were aimed at other users). If the C header references a key which is not in the local key-ring, then a note MUST be kept indicating that the next message I this user will include a request for his/her key. If the C 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. =head3 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. =head3 Encryption 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 C (see L<"MIME Types">). =head2 Message Structure 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: =head3 Preamble 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. =head3 MIME Types There are two MIME types used by PPS: =over 5 =item C This type is used for enclosures which contain public keys referenced from an C header. =item C This type is used for enclosing the entire body of the original message (including original MIME headers) in an encrypted form. =back Obviously, both of these types will enclose data which is encryption-software specific. Because the C 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 C is used to specify this information, e.g.: Content-type: application/x-pps-encrypted; software=GPG This identifier MUST appear in the C header. The C attribute MUST NOT specify more than one application to use, though the C 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. =head3 MIME Conventions The boundary string and other MIME conventions such as C of attachments are implementation-dependant. The requirements only include: the C type of the overall message; C preamble for encrypted messages and the PPS MIME types for PPS-readable attachments. =head2 User Interface Issues =head3 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 C 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. =head3 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: =over 5 =item 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. =item 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. =back =head2 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. =head3 UNIX Under UNIX systems, a "C<.pps>" directory MUST be created in the user's home directory. It will contain the key files as well as a file called "C". 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: [:fingerprint][/[: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: =over 5 =item code: C<1> The specified key has been requested. =item code: C<2> The specified key fingerprint was not recognized, and a new key MUST be requested. =back When an entry is acted upon, it MUST be be deleted from the notes file. =head2 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 C header. However, should such a lookup fail or yield a key which does not match the C, then an C header MUST be generated as normal. Other forms of key exchange might include: =over 5 =item * The C program, which can be used to check the target user's "plan" file for a public key. =item * Manual key exchange is almost certain to work as a by-product of PPS, but specifically supporting it in the MUA would be convenient. =item * MUAs are the default place to implement PPS, but mailing list software might also act as a "man in the middle" for sake of negotiating key exchange. The goal, of course, would be to facilitate key exchange between users by caching their keys, but it is easy to see how this would be abused. =back =head2 Examples Here are some example exchanges. Only the C, C and PPS-related headers have been included. =head3 The Simple Case 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 "C", which would contain each of the user's public keys. =head3 New Addresses Assuming the above exchange between foo and biz, let's see what happens when biz also uses the address C: 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. =head3 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 C and C 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 =head2 Related Documents For more information, please see the following documents: =over 5 =item Standard for the Format of ARPA Internet Text Messages RFC822, David H. Crocker, 1982, ftp://ftp.isi.edu/in-notes/rfc822.txt =item Simple Mail Transfer Protocol RFC821, Jonathan B. Postel, 1982, ftp://ftp.isi.edu/in-notes/rfc821.txt =item Multipurpose Internet Mail Extensions RFC2045, N. Freed, N. Borenstein, 1996, ftp://ftp.isi.edu/in-notes/rfc2045.txt =item Key words for use in RFCs to Indicate Requirement Levels RFC2119, S. Bradner, 1997, ftp://ftp.isi.edu/in-notes/rfc2119.txt =item The GNU Privacy Guard The Free Software Foundation, 2001, http://www.gnupg.org/ =back =cut