问如果我有证书，如何将PKCS#1转换为PKCS7？

EN

你的问题有点过于简单化了。

关于PKCS#7 <-> PKCS#1：

是的，PKCS#7签名容器包含SignerInfo对象，这些对象分别包含PKCS#1样式签名和一些属性。但是这种PKCS#1风格的签名通常不仅仅是对文档数据进行签名，而是对所谓的“已签名属性”的结构进行签名。其中一个是文档散列，其他可以是签名时间、到签名者证书的链接和其他信息；这些额外的信息在许多用例中都是必需的。只有最原始构建的SignerInfo结构直接对文档数据进行签名。

因此，通常情况下，如果您简单地将某些数据的PKCS#1签名包装在PKCS#7容器中，该签名容器将不会被接受。

有关详情，请参阅RFC 3852。

关于集成的PDF签名：

你对未来实现的描述有些含糊。您似乎认为要签名的文档散列是原始PDF的散列。在集成PDF签名的情况下，这是错误的:为了创建集成PDF签名，您首先通过一些数据扩展PDF，这些数据封装了PKCS#7签名容器(规范推荐的)或要集成的PKCS#1签名的占位符。然后，除了占位符之外，您需要对这个扩展的PDF进行散列。(根据当前的PDF规范，您可以使用比此更小的散列，但这不会被当前的Adobe Acrobat/Reader接受，也不应该被任何严肃的验证器接受)。

有关详细信息，请参阅ISO 32000-1:2008 as published by Adobe

根据法律要求，您可能还需要考虑ETSI指定的PDF Advanced Electronic Signature (PAdES)。ETSI standard for EU-compliant electronic signatures。这些将成为ISO 32000-2的一部分，也就是PDF 2.0。

那么，您是否仍然确定您的用例允许您脑海中的那些非常简单的PKCS#7签名，并且您的PKCS#1源签名是为正确的文档创建的吗？在这种情况下，构建这些容器很容易，只需查看RFC 3852。

无论如何，你应该看看Bruno Lowagie (iText软件)的白皮书Digital Signatures for PDF documents。

查看RFC 3852 > 5.4。消息摘要计算流程

只要其中没有带符号的属性，就可以简单地将PKCS#1转换为PKCS#7。如果有，那么您将陷入困境，因为PKCS#1只隐藏内容的散列，而具有构造中间结构所需的已签名属性的PKCS#7和该结构的散列将被签名。