为什么使用iTextSharp对PDF进行数字签名会增加9MB的文件大小

Question

当我用iTextSharp库的数字签名签名时，有谁可以告诉我为什么PDF文件大小会增加9MB。这是我用来签署文档的代码的一部分。

MakeSignature.SignDetached(appearance, externalSignature,
                    chain, crlList, null, null, 0, CryptoStandard.CADES);

如何防止这种情况？

Answer 1

签署PDF文档的方式存在一些问题。

乍一看，好像chain只包含一个证书。它应该包含完整的链，但它只包含您的签名证书（[EMAIL] ...），而它应该包含颁发者的证书（eID EMAIL颁发CA），并且可能包含一些其他发行者，直到根证书，但是这不是PDF增长到巨大文件大小的原因。

请看一下这个屏幕截图：

签名很大，因为你嵌入了一个巨大的CRL。一个好的证书颁发机构CA（例如GlobalSign）将采取预防措施，以确保证书撤销列表的大小有限。一个好的CA将创建中间证书并限制每个中间证书颁发的证书数量。一个好的CA也将删除所有从CRL过期的证书。

我已使用以下网址下载了您正在使用的CRL：

http://ocsp.mpb-ks.org:8080/crls/search.cgi?alias=email

结果如下：

这是一个4752 KB的文件。此文件以十六进制字符串形式存储在PDF中，这意味着URL大约需要9504 KB。

如果您遇到创建大型CRL的CA（如科索沃共和国内政部的情况），则不应使用CRL：您应该使用OCSP。 OCSP响应的长度是可预测的。您可以在CRL中获得查找结果，而不是完整列表。嵌入这样的OCSP响应将比嵌入完整CRL消耗更少的空间。

您应该询问您的当局如何从他们的服务中获得OCSP响应。我试着阅读http://www.mpb-ks.org/eID/policies/eID_RKS_CPS.pdf但不是PDF，而是用一种我不懂的语言给我一个普通的网页。当我点击“英语”时，它不会给我翻译英文。页面似乎破了：很多图片都丢失了。

我看到密钥用法允许数字签名，但我不知道您所在的国家/地区是否允许使用该密钥签署PDF。我的意思是：从技术上说这是可能的，但我已经阅读了一条说“电子邮件签名证书”的通知。我认为证书旨在签署电子邮件，并且您将其用于其他目的。如果您使用该证书签署PDF文档，请与您的当局核实签名是否具有您所在国家/地区的法律约束力。

Answer 2

（作为@Bruno's answer的附录）

@Bruno已观察到

  

我发现密钥用法允许数字签名，但我不知道您所在的国家/地区是否允许使用该密钥签署PDF。我的意思是：从技术上来说这是可能的，但我已经阅读了一份说明“电子邮件签名证书”的通知。我认为证书旨在签署电子邮件，并且您将其用于其他目的。如果您使用该证书签署PDF文档，请与您的当局核实签名是否具有您所在国家/地区的法律约束力。

实际上，用户证书的扩展名为Extended Key Usage：

如您所见，电子邮件保护并没有其他内容。

此扩展名在RFC 5280 section 4.2.2.12中指定，特别是：

  

如果存在扩展名，则必须仅使用证书      出于上述目的之一。如果有多种用途      表示申请无需承认所有指示的用途，      只要预期目的存在。

在目前的情况下，只有一个目的，因此证书必须只用于此目的。

因此，严格来说，证书确实不用于签署PDF，仅用于保护电子邮件。

Adob​​e的观点

如果你想知道为什么Adobe Acrobat Reader不会抱怨使用这个证书，这里有一些背景：

Adob​​e已经记录了自版本11.0.09 here以来密钥使用和扩展密钥使用情况所接受的证书。从本质上讲，它们允许这些关键用法的任意组合

• 不存在
• nonRepudiation
• signTransaction（仅限11.0.09）
• digitalSignature（11.0.10及更高版本）

以及这些扩展的关键用法

• 不存在
• emailProtection
• codeSigning
• anyExtendedKeyUsage
• 1.2.840.113583.1.1.5（Adobe Authentic Documents Trust）

他们解释如下：

  

RFC 5280，于1999年以RFC 2459开始，并未将“文档保护”作为潜在的EKU。因此，Adobe一直不得不对证书颁发机构使用已颁发证书的意图做出某些假设。

     

最近，证书使用在企业设置中变得越来越流行，其中基于证书的身份验证用于以各种方式访问​​公司网络。其中一些证书具有相对开放的KU和EKU配置，并且这些配置已自动在Adobe Reader和Acrobat中显示回用户，作为数字签名PDF文档的潜在凭证。在重新评估RFC 5280和数字证书的实际行业惯例后，Adobe Acrobat和Reader 11.0.09不再显示所有可用证书，从而提高了它们与RFC 5280的一致性。在某些情况下，更改将意味着不会显示可用于在早期版本中签名的证书。

     

根据RFC 5280，有几种方法可以确保您的凭据可用于数字签名。首先，从RFC 5280中的“4.2.1.3密钥用法”：

     

    

“密钥用法扩展名定义了证书中包含的密钥的目的（例如，加密，签名，证书签名）。当要限制可用于多个操作的密钥时，可以使用使用限制。例如，当RSA密钥仅用于验证除公钥证书和CRL之外的对象上的签名时，将断言digitalSignature和/或nonRepudiation位。同样，当RSA密钥仅用于密钥管理时，keyEncipherment位将被置位。“

  

     

其次，来自RFC 5280中的“4.2.1.12扩展密钥用法”：

     

    

“此扩展名表示可以使用经过认证的公钥的一个或多个目的，除了或代替密钥用法扩展中指出的基本用途。通常，此扩展仅出现在最终实体证书中。“

  

     

此外，当KU和EKU都存在时，RFC声明：

     

    

“如果证书包含密钥用法扩展和扩展密钥用法扩展，则两个扩展必须独立处理，并且证书必须仅用于与两个扩展一致的目的。如果没有与两个扩展一致的目的，那么证书绝不能用于任何目的。“

  

在我看来，Adobe在接受emailProtection和codeSigning时过于宽松 - 这些用法明显不同于文档签名。很可能他们只是想让尽可能多的常用证书可用于PDF签名，同时看起来符合RFC。