2026年8月6日
引言
电子签名是一个广义概念：通过电子操作表明某人有意签署一份记录。数字签名则是一种具体的技术机制。它利用密码学，并在许多企业签署流程中结合数字证书，把签署人或签署凭证与文件关联起来，同时让后续改动能够被发现。简而言之，数字签名是形成电子签署证据的一种特定方式，并非所有电子签名都会使用数字签名。
这一区别很重要，但不能据此认定某一种方式普遍“更好”。在一种流程中，是否适合采用输入姓名并配合身份认证、同意步骤、路由和详细审计记录的方式，取决于具体要求；在另一种流程中，能够通过密码学验证来检查的证书型数字签名可能更合适。真正需要问的不是哪个名称听起来更有分量，而是签署完成后，复核人员必须验证什么、能使用哪些系统，以及复核时还能够取得哪些证据。
本文只用于知识说明，不构成法律判断。文件类型、司法管辖区、行业规则、交易对方要求、保证目标和留存政策都可能影响签署方式的选择。团队在统一采用某条路径前，应先确认这些要求。
先问清楚要验证什么，不要先看名称
第一步是写明接收方复核人员必须作出什么判断。一个签署流程通常需要回答以下五类问题中的若干项：
- 是否存在能够可靠记录签署意图的操作？ 复核人员可能需要查看已签署记录，以及同意、披露、字段填写或主动签署操作的证据。
- 该操作归属于谁或什么凭证？ 归属判断可能依靠邮件路由、访问码、账户会话、身份验证、证书主体、组织凭证，也可能同时使用多项控制措施。
- 这是否就是当时签署的文件？ 流程需要在参与人的操作与最终文件之间建立可靠关联。某些路径还会提供密码学完整性检查，用于发现后续改动。
- 是否需要复核证书信息？ 如果必须采用证书型签署，复核人员可能需要使用能够同时显示证书信息和签名结果的工具。团队应先界定复核人员必须看见哪些内容。
- 哪些事件必须保持可复核？ 仅有已签署文件可能还不够。时间戳、身份认证事件、路由历史、完成状态和异常情况可能需要随文件一起移交，或继续保存在受控系统中。
先从验证任务出发，可以避免一种常见的采购错误：团队根据功能名称选定方式，最后才发现下游复核人员无法解释产生的证据。这样做也能把经常混在一起的三个问题分开：签署意图、身份保证和文件完整性。
电子签名和数字签名流程如何形成证据？
电子签名流程可以组合多种证据来源。读者看到的签名可能是输入的姓名、手绘标记、点击操作或其他电子操作；与此同时，系统会记录文件如何呈现、使用了哪条收件人路径、进行了什么身份认证、各项操作在何时发生，以及最终生成了哪一份文件。证据价值来自整套流程，不只取决于签名的外观。
因此，看起来简单的电子签名也可能有充分的运营证据支持。复核人员可以查看参与人操作记录、邮箱或手机验证、账户身份认证、文件标识符、时间戳、完成记录和审计记录。具体组合应与交易风险和要求相匹配。
数字签名流程还会增加密码学签署操作。简单来说，签署软件使用私钥，根据文件生成一个值；验证时则使用对应的公钥检查该值。在基于证书的企业流程中，数字证书有助于把公钥与某个人或组织关联起来。数字证书和密码学签署结果不能取代对周边流程的检查，但会增加一层机器可检查的完整性与凭证证据。
美国国家标准与技术研究院数字签名项目说明了两项核心保证：声称的签署人是否签署了相关信息，以及信息在生成签名后是否被修改。这些是技术保证目标，不能直接推导出普遍的法律效力、身份核验强度，也不能说明某种方式适用于所有文件。
证书型流程也会给复核带来额外工作。移交时，应让复核人员能够看懂签名结果、所选工具显示的证书信息，以及检测到的签署后改动。如果还需要作出超出这些项目的判断，应在正式推行前记录额外的判断依据和复核规则。
两者在实际使用中的区别
电子签名描述的是更广泛的签署概念，可以由流程记录提供支持。数字签名描述的是范围更窄的密码学技术，可以增加文件完整性和凭证证据。数字签名可以成为电子签名流程的一部分，而电子签名流程不一定使用数字签名密码学。
按验证任务比较电子签名与数字签名证据
下方的复核人员、系统与证据验证交接矩阵用于支持具体的运营决策。在确定默认方式前，应与未来的复核人员共同填写，而不能只让发起人填写。
这张矩阵特意不把“证据更多”等同于“证据更好”。如果接收方无法查看签名结果或证书显示，这些内容在实际操作中就没有用。反过来，即使原来的签署体验很顺畅，只有发起人才能访问的审计记录也会造成薄弱的交接。证据必须以对方系统能够评估的形式送到负责作出判断的人手中。
根据复核人员和系统能力选择签署方式
选择签署路径时，应以签署后的判断任务为准。下面的顺序有助于把讨论落到具体事项上。
1. 明确依赖证据作出判断的复核人员
先确定谁会在流程完成后评估记录：内部审批人员、合同管理员、安全团队、外部审计人员、监管机构、法院、档案负责人、客户或其他交易对方。“业务部门”太含糊。不同复核人员拥有的访问权限、信任设置、技术工具和证据要求并不相同。
2. 明确要得到什么验证结论
写清楚复核人员最终必须得出什么结论。例如，确认预期收件人主动执行了签署操作，检查已签署信息之后是否被修改，查看随签名呈现的证书信息，或还原一次异常。不要用签署方式的名称代替验证结果。
3. 盘点复核人员可用的系统
确认复核人员实际能够使用哪些文件格式、签名验证工具、审计导出文件、身份记录和长期档案。如果验证必须依赖发起人账户、供查看人使用但接收方没有的专用工具，或未写入文档的人工协助，应在正式推行前记录这项依赖。
4. 设计证据包
明确哪些内容需要与最终文件一起移交。根据签署路径，证据包可以包含最终文件、审计记录、身份认证结果、工具显示的证书信息、签名验证结果和异常备注。为证据包设置稳定的标识符，方便复核人员确认每一项都属于同一笔交易。
5. 规划例外处理与记录留存
团队应事先决定：身份验证失败、无法生成签名结果、文件报告改动，或复核人员无法访问时，该如何处理。还要明确已签署文件、审计记录、验证结果和适用的复核规则需要保持可用多久。缺失的留存流程无法靠密码学补救。
如果所需的保证主要来自签署意图、身份认证、路由和审计历史，而且复核人员能够稳定取得这些记录，日常电子签名路径可能适用。如果复核人员需要密码学修改检查，或需要查看与签名关联的证书信息，证书型数字签名路径可能带来额外价值。这些只是决策模式，并非普遍规则。
在 Nota Sign 中测试一次验证交接
确定政策前，先测试证据交接。Nota Sign 支持包含路由、跟踪、身份认证选项和审计记录的电子签名流程，以及能够形成密码学完整性和证书证据的证书型数字签名流程。具体可用性和适当配置可能取决于市场、信任服务设置、文件和流程。
选一份有代表性且已经获准用于测试的文件，按照团队考虑采用的路径操作。应使用测试数据，不要使用敏感的生产信息。流程完成后，由发起人把已签署文件和计划中的证据包交给一位未参与配置的复核人员。
请这位复核人员在没有发起人指导的情况下完成矩阵：
- 找到签署意图和签署人归属的证据。
- 确认证据包与那一份最终文件准确关联。
- 如果存在数字签名，使用复核人员平时使用的工具检查签名结果、工具显示的证书信息，以及任何报告的文件改动。
- 记录哪些内容结论明确、存在歧义、无法访问或依赖发起人。
- 如果长期复核很重要，可在允许的软件更新、档案移交或有代表性的异常发生后重复测试。
只有当复核人员使用已记录的证据包、系统和政策就能得出所需结论，测试才算通过。如果结论依赖口头说明、隐藏配置或发起人的临时访问权限，应修改流程并重新进行交接测试。
在确定统一的签署方式前，先在 Nota Sign 中完成一次独立复核交接测试。
