PKCS#7 CMS - 消息摘要计算过程

Question

我正在研究 RFC 5652，以便确切了解如何编码/解码 PKCS#7 ASN.1 数据。

我不明白当存在“signedAttrs”字段时如何创建签名：

消息摘要计算过程的结果取决于 signedAttrs 字段是否存在。 当该字段不存在时，结果只是如上所述的内容的消息摘要。 但是，当该字段存在时，结果是包含在 signedAttrs 字段中的 SignedAttrs 值的完整 DER 编码的消息摘要。 由于 SignedAttrs 值（如果存在）必须包含 content-type 和 message-digest 属性，因此这些值会间接包含在结果中。

通过阅读上面的文字，我感到困惑： SignedAttrs 字段包含消息摘要和内容类型值，但消息摘要可以在计算后出现，并且必须计算摘要：

eContent OCTET STRING + SignedAttrs 字段的完整 DER 编码（包含消息摘要字段）。

在下面的示例中，有一个 PKCS#7 已签名数据结构，其中正在对信封数据内容字段值 + 已签名属性进行签名。 messageDigest 值究竟来自哪里？

Answer 1

CMS 算法中有两种不同的消息摘要：

• 第一个消息摘要是一个签名属性，它只包含被签名的封装内容的摘要。

• 第二个是通过签名算法进行签名。 此消息摘要包含由特定算法计算的摘要：

  消息摘要算法的输入是Content 。 在缺少签名属性的情况下，当前输入的摘要（当前输入 = 内容）将被创建并作为结果消息摘要返回。 否则，如果存在签名属性，则计算内容的摘要并将其添加到签名属性列表中（作为消息摘要签名属性），然后计算所有签名属性的摘要。 所以内容间接包含在结果中