Electronic mail (“e-mail”) messages may be generally encoded using one of a number of known protocols to facilitate secure message communication. The Secure Multiple Internet Mail Extensions (“S/MIME”) protocol, for example, relies on public and private encryption keys to provide confidentiality and integrity, and on a Public Key Infrastructure (PKI) to communicate information that provides authentication and authorization. Data encoded using a private key of a private key/public key pair, can only be decoded using the corresponding public key of the pair, and vice-versa. In S/MIME, the authenticity of public keys used in the encoding of messages may be validated using certificates. Other known standards and protocols may be employed to facilitate secure message communication, such as Pretty Good Privacy™ (PGP) and variants of PGP such as OpenPGP, for example. It is understood that as compared to S/MIME-based systems, PGP-based systems also utilize public and private encryption keys to provide confidentiality and integrity, although the authenticity of public keys used in the encoding of PGP messages are validated in a different manner.
When a user wishes to send a message to be encrypted (e.g. using S/MIME or PGP), message data will be encrypted using the public key of a private key/public key pair associated with the intended recipient of the message, such that the encrypted message data can only be subsequently decrypted by the corresponding private key of the same pair supposedly possessed only by the recipient. In some implementations, a session key is encrypted/decrypted, rather than the message itself. When a user wishes to send a message that is to be digitally signed (e.g. using S/MIME or PGP), a digest generated from the message will be encoded using the private key of a private key/public key pair associated with the user (i.e. the sender of the message in this example) to produce a digital signature, such that the signature can only be successfully verified using the corresponding public key of the same pair.
After a user composes a message and before it is sent, the user can typically decide what encoding, if any, is to be applied to the message. For example, the user may choose to encrypt the message without signing, to sign the message without encrypting, to both encrypt and sign the message, or to send the message unencrypted and unsigned. Some known messaging applications may be adapted to analyze certain data and suggest a security encoding for messages to the user. For example, the messaging application may determine that the composed message is a reply to a received message that has been encoded in a certain way, and suggest to the user that the same security encoding be applied to the composed message. As a further example, the messaging application may be configured to track the security encoding applied to previous messages sent by the user to particular recipients, and suggest to the user that the same security encoding should be applied to the composed message if the message is intended to be sent to one or more of those recipients. In any event, the user is free to select the desired security encoding for any given message that he or she composes.
USPTO Backgrounds
USPTO Backgrounds