Electronic signatures

Electronic signatures are closely associated with encryption. An electronic signature verifies that the person who originated the data is the author and that no one has tampered with the data. Users can add an electronic signature to mail messages and to fields and sections of documents. A database designer controls whether or not users can sign fields and sections of a database can be signed; individual users can choose to sign mail messages.

Users can sign mail messages sent to other Notes® users or to users of other mail applications that support the S/MIME protocol -- for example, Microsoft™ Outlook Express®. Domino® uses the same keys used for encryption -- the Notes® and Internet public and private keys -- for electronic signatures.

You can also set up Notes® to use separate keys for S/MIME signatures and encryption, by adding two Internet certificates to your Notes® ID file and using one certificate for S/MIME encryption and the other for S/MIME signatures and TLS client authentication. Having dual Internet certificates lets you maintain separate public and private key pairs for encryption and electronic signatures and TLS client authentication.

For information on creating signed fields and sections, see the topic Enabling encryption in a field in HCL Domino® Designer Help.

Notes® signatures

When the sender signs a message with a Notes® signature, all fields of the message are signed.

  1. Notes® generates a "hash" of the data -- that is, a number that represents the data -- and then encrypts the hash with the private key of the author of the data, forming a signature. The hash is also sometimes called a message digest, and has some necessary special properties:
    • It is not possible to guess the original message from looking at the digest.
    • Even a small change in the message changes the digest in an unpredictable way, and produces a completely different value.
  2. Notes® attaches the signature, the signer's public key, and the signer's certificates to the data.
  3. When the reader accesses the signed data, Notes® verifies that the signer has a common certificate or common certificate ancestor from a certifier that the reader trusts. If so, Notes® attempts to decrypt the signature using the public key that corresponds to the private key with which the data was signed.
  4. If decryption is successful, Notes® indicates who signed the message. If decryption is unsuccessful, Notes® indicates that it cannot verify the signature. Unsuccessful decryption and comparison may indicate that the data has been tampered with.
    Note: Certificate trust checking occurs independently of hash decryption and comparison. Decryption and comparison may succeed even if the certificate is not trusted. This might happen, for example, when a user receives mail from a user in another company and that user doesn't have a cross-certificate.

S/MIME signatures

When the sender signs a message with an S/MIME signature, only the body of the message and accompanying attachments are signed.

  1. Notes® generates a hash of the data being signed and then encrypts the hash with the private key of the author of the data, forming a signature.
  2. Notes® attaches a certificate chain -- that is, all certificates in the hierarchy for the certificate -- and the signature to the data.
  3. When the reader accesses the signed data, Notes® or the mail application attempts to decrypt the signature using the public key that corresponds to the private key with which the data was signed. If successful, Notes® or the application verifies that the signer has a common certificate or common certificate ancestor from a certifier that the reader trusts.
    Note: Typically, the Notes® user's organizational certifier issues a cross-certificate to the signer's certificate authority (CA). Trust can also be established if the Notes® user issues a cross-certificate directly to the signer's certificate or to the signer's Certificate Authority. Or, the Notes® user's organizational certifier can issue a cross-certificate directly to the signer's certificate.
  4. Notes® or the mail application compares the decrypted hash with a hash of the message generated by the reader. A match means that the signature is valid.
  5. If the digest comparison is successful, Notes® or the S/MIME mail application indicates who signed the message. If decryption is unsuccessful, the application indicates that it could not verify the signature. Unsuccessful decryption and comparison may indicate that the data has been tampered with.
    Note: Certificate trust checking occurs independently of hash decryption and comparison. Decryption and comparison may succeed even if the certificate is not trusted. This might happen, for example, when a user receives mail from a user in another company and that user doesn't have a cross-certificate.

Signing sent mail

Notes® client users control whether the mail they send is signed. Users can sign individual mail messages or sign all mail messages that they send. When sending signed messages to users of S/MIME mail applications, Notes® users must have an additional set of Internet public and private keys.

For information about signing mail, see the topic Encrypting and digitally signing email messages in HCL Notes® Help.