7. Example User Interface and Implementation (original) (raw)

Connected: An Internet Encyclopedia
7. Example User Interface and Implementation

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1421

Prev: 6. User Naming
Next: 8. Minimum Essential Requirements

7. Example User Interface and Implementation

In order to place the mechanisms and approaches discussed in this RFC into context, this section presents an overview of a hypothetical prototype implementation. This implementation is a standalone program which is invoked by a user, and lies above the existing UA sublayer. In the UNIX system, and possibly in other environments as well, such a program can be invoked as a "filter" within an electronic mail UA or a text editor, simplifying the sequence of operations which must be performed by the user. This form of integration offers the advantage that the program can be used in conjunction with a range of UA programs, rather than being compatible only with a particular UA.

When a user wishes to apply privacy enhancements to an outgoing message, the user prepares the message's text and invokes the standalone program, which in turn generates output suitable for transmission via the UA. When a user receives a PEM message, the UA delivers the message in encrypted form, suitable for decryption and associated processing by the standalone program.

In this prototype implementation, a cache of IK components is maintained in a local file, with entries managed manually based on information provided by originators and recipients. For the asymmetric key management case, certificates are acquired for a user's PEM correspondents; in advance and/or in addition to retrieval of certificates from directories, they can be extracted from the "Originator-Certificate:" fields of received PEM messages.

The IK/certificate cache is, effectively, a simple database indexed by mailbox names. IK components are selected for transmitted messages based on the originator's identity and on recipient names, and corresponding Originator-ID, "Originator-Certificate:", and Recipient-ID fields are placed into the message's encapsulated header. When a message is received, these fields are used as a basis for a lookup in the database, yielding the appropriate IK component entries. DEKs and cryptographic parameters (e.g., IVs) are generated dynamically within the program.

Options and destination addresses are selected by command line arguments to the standalone program. The function of specifying destination addresses to the privacy enhancement program is logically distinct from the function of specifying the corresponding addresses to the UA for use by the MTS. This separation results from the fact that, in many cases, the local form of an address as specified to a UA differs from the Internet global form as used in "Originator-ID- Symmetric:" and "Recipient-ID-Symmetric:" fields.

Next: 8. Minimum Essential Requirements

Connected: An Internet Encyclopedia
7. Example User Interface and Implementation