電子簽名

電子簽名與加密密切相關。電子簽名可驗證資料的創建者是作者，並且沒有人篡改資料。使用者可以將電子簽名新增至郵件訊息以及檔案的欄位和部分。資料庫設計者控制使用者是否可以對欄位和資料庫的部分進行簽署；個人用戶可以選擇對郵件訊息進行簽署。

使用者可以對傳送給其他Notes®使用者或支援 S/MIME 協定的其他郵件應用程式（例如Microsoft ™ Outlook Express® ）的使用者的郵件訊息進行簽署。Domino ®使用與加密相同的金鑰（ Notes ®以及網路公鑰和私鑰）進行電子簽署。

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.

有關建立簽名欄位和部分的信息，請參閱HCL Domino ® Designer 說明中的主題在欄位中啟用加密。

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:
    • 不可能透過查看摘要來猜測原始訊息。
    • 即使訊息中的微小變化也會以不可預測的方式改變摘要，並產生完全不同的值。
  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.
    注意：憑證信任檢查獨立於雜湊解密和比較進行。即使憑證不可信，解密和比較也可能成功。例如，當使用者收到另一家公司的使用者的郵件且該使用者沒有交叉證書時，可能會發生這種情況。

S/MIME signatures

當寄件者使用 S/MIME 簽名對郵件進行簽名時，僅對郵件正文和隨附附件進行簽名。

  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.
    注意：憑證信任檢查獨立於雜湊解密和比較進行。即使憑證不可信，解密和比較也可能成功。例如，當使用者收到另一家公司的使用者的郵件且該使用者沒有交叉證書時，可能會發生這種情況。

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.