A UA process supporting PEM must protect the private component of its associated entity (e.g., a human user or a mailing list) from disclosure, though the means by which this is effected is a local matter. It is essential that the user take all available precautions to protect his private component as the secrecy of this value is central to the security offered by PEM to that user. For example, the private component might be stored in encrypted form, protected with a locally managed symmetric encryption key (e.g., using DES). The user would supply a password or passphrase which would be employed as a symmetric key to decrypt the private component when required for PEM processing (either on a per message or per session basis). Alternatively, the private component might be stored on a diskette which would be inserted by the user whenever he originated or received PEM messages. Explicit zeroing of memory locations where this component transiently resides could provide further protection. Other precautions, based on local operating system security facilities, also should be employed.
It is recommended that each user employ ancillary software (not otherwise associated with normal UA operation) or hardware to generate his personal public-key component pair. Software for generating user component pairs will be available as part of the reference implementation of PEM distributed freely in the U.S. portion of the Internet. It is critically important that the component pair generation procedure be effected in as secure a fashion as possible, to ensure that the resulting private component is unpredictable. Introduction of adequate randomness into the component pair generation procedure is potentially the most difficult aspect of this process and the user is advised to pay particular attention to this aspect. (Component pairs employed in public-key cryptosystems tend to be large integers which must be "randomly" selected subject to mathematical constraints imposed by the cryptosystem. Input(s) used to seed the component pair generation process must be as unpredictable as possible. An example of a poor random number selection technique is one in which a pseudo-random number generator is seeded solely with the current date and time. An attacker who could determine approximately when a component pair was generated could easily regenerate candidate component pairs and compare the public component to the user's public component to detect when the corresponding private component had been found.)
There is no requirement imposed by this architecture that anyone other than the user, including any certification authority, have access to the user's private component. Thus a user may retain his component pair even if his certificate changes, e.g., due to rollover in the validity interval or because of a change of certifying authority. Even if a user is issued a certificate in the context of his employment, there is generally no requirement that the employer have access to the user's private component. The rationale is that any messages signed by the user are verifiable using his public component. In the event that the corresponding private component becomes unavailable, any ENCRYPTED messages directed to the user would be indecipherable and would require retransmission.
Note that if the user stores messages in ENCRYPTED form, these messages also would become indecipherable in the event that the private component is lost or changed. To minimize the potential for loss of data in such circumstances messages can be transformed into MIC-ONLY or MIC-CLEAR form if cryptographically-enforced confidentiality is not required for the messages stored within the user's computer. Alternatively, these transformed messages might be forwarded in ENCRYPTED form to a (trivial) distribution list which serves in a backup capacity and for which the user's employer holds the private component.
A user may possess multiple certificates which may embody the same or different public components. For example, these certificates might represent a current and a former organizational user identity and a residential user identity. It is recommended that a PEM UA be capable of supporting a user who possess multiple certificates, irrespective of whether the certificates associated with the user contain the same or different DNs or public components.