签发时认证

重建在结构上是脆弱的

在大多数系统中，证明都是在事后重建的。

• 查询日志。
• 导出记录。
• 默认系统应当持续保持可访问。

这种做法会随着时间推移而变得脆弱。系统会变化，数据可能不再可用，访问也并不总能得到保障。

在签发时进行认证

CERTCRYPT 引入了一种不同的模型。认证发生在签发时。

系统不再依赖日后重建证明，而是在相关事件发生时生成认证工件。

由此产生的证书，其验证此后可以依据公共规则被独立复现。

这种转变并不改变验证的工作方式。

它改变的是认证在何时发生，以及在什么条件下被产生。

在那些签发条件本身重要的系统中，认证必须成为系统自身的一部分。

从事件到验证

认证流程遵循一个清晰的顺序：

• 发生相关数字事件
• 在签发时生成认证工件
• 生成证书
• 之后可以独立复现验证

运行层面的影响

现有系统仍然像今天一样运行。

区别在于，相关事件可以在签发时直接生成证书，而不是把证明留给事后重建。

这就不再需要把内部记录当作唯一的证明来源。

认证成为事件流程的一部分

随着系统运行，它们会产生不同形式的证明。

认证成为系统内部的一层运行能力。

每一个相关事件都可以在执行过程中生成证书。

这就在签发时引入了一层可度量的认证层，并与系统的真实活动保持一致。

签发时认证变得必要

这种模型在以下情况下会变得相关：

• 事件之后可能被质疑或复核
• 系统未必能长期保持可访问
• 独立验证是一项要求，而不是默认前提

无需重建的证明

签发时认证改变了证明是如何产生的。

系统不再依赖事后重建，而是在事件发生时生成可验证证书。

验证不再依赖原始系统持续运行。

当认证成为事件流程的一部分时，系统就不再依赖重建。

它们依赖签发。

到了那时，问题不再是证明能否在事后生成。

而是证明是否在事件发生时被正确生成。

基于用例的访问

在授予访问资格之前，会先评估该用例的结构性相关性、它与当前访问标准的匹配情况，以及可能适用的任何条件。

• 确认用例的相关性
• 依据当前访问标准审查用例
• 判断访问是否合适
• 澄清任何必要条件

申请访问

认证能力目前只向部分选定组织开放。

如果您的环境需要签发时认证以及能够随着时间保持独立验证，请申请访问。

申请访问 →