为什么使用 iTextSharp 对 PDF 进行数字签名会使文件大小增加 9MB
Why does digitally signing PDF with iTextSharp increases file size for 9MB
谁能告诉我为什么当我使用 iTextSharp 库对 PDF 文件进行数字签名时，它的大小会增加 9MB。这是我用来签署文档的部分代码。
MakeSignature.SignDetached(appearance, externalSignature,
chain, crlList, null, null, 0, CryptoStandard.CADES);
如何预防？
您签署 PDF 文档的方式有一些问题。
乍一看，chain 似乎只包含一个证书。它应该包含完整的链，但它只包含您的签名证书（[EMAIL] ...），而它应该包含颁发者的证书（eID EMAIL Issuing CA）和可能的其他一些颁发者直到根证书，但是这不是 PDF 文件变大的原因。
请看一下这个屏幕截图：
签名很大，因为您嵌入了一个巨大的 CRL。一个好的证书颁发机构 aka CA（例如 GlobalSign）将采取预防措施以确保证书吊销列表的长度受到限制。一个好的 CA 将创建中间证书并限制每个中间证书颁发的证书数量。好的 CA 还会从 CRL 中删除所有过期的证书。
我已经通过这个 URL:
下载了您正在使用的 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 消耗更少 space。
您应该询问您的当局如何从他们的服务中获得 OCSP 响应。我尝试阅读 http://www.mpb-ks.org/eID/policies/eID_RKS_CPS.pdf，但它不是 PDF，而是用我不懂的语言为我提供的普通网页。当我点击 "English" 时，它没有给我英文翻译。该页面似乎已损坏：缺少许多图像。
我看到密钥用法允许数字签名，但我不知道您的国家/地区是否允许使用该密钥对 PDF 进行签名。我的意思是：从技术上讲这是可能的，但我读过一条通知说 "E-Mail Signature Certificate"。我假设该证书用于签署电子邮件，而您将其用于其他目的。如果您使用该证书签署 PDF 文档，请与您的当局核实签名在您所在国家/地区是否具有法律约束力。
（作为的附录）
@Bruno 观察到
I see that the Key Usage allows digital signing, but I don't know if your country allows to use that key for signing PDFs. I mean: technically it is possible, but I've read a notice that says "E-Mail Signature Certificate". I assume that the certificate is meant to sign e-mail and you are using it for a different purpose. Please check with your authorities if the signatures are legally binding in your country if you use that certificate for signing PDF documents.
确实，用户证书有一个 Extended Key Usage 扩展名：
如您所见，上面写着 电子邮件保护，没有别的。
此扩展名在 RFC 5280 section 4.2.2.12 中指定，其中特别说明：
If the extension is present, then the certificate MUST only be used
for one of the purposes indicated. If multiple purposes are
indicated the application need not recognize all purposes indicated,
as long as the intended purpose is present.
在手头的案例中，只指明了一个目的，因此证书必须仅用于此目的。
因此，严格来说，证书确实不是用来签署 PDF 的，而只是为了保护电子邮件。
Adobe 的观点
如果你想知道为什么 Adobe Acrobat Reader 不抱怨使用这个证书，这里有一些背景：
自 11.0.09 版 here 以来，Adobe 已通过密钥使用和扩展密钥使用记录了他们对证书的接受。本质上，它们允许这些键用法的任意组合
- 缺席
nonRepudiationsignTransaction（仅限 11.0.09）digitalSignature（11.0.10 及更高版本）
以及这些扩展的密钥用法
- 缺席
emailProtectioncodeSigninganyExtendedKeyUsage1.2.840.113583.1.1.5（Adobe 真实文档信任）
他们解释如下：
RFC 5280, which started as RFC 2459 in 1999, did not include “Document Protection” as a potential EKU. Therefore, Adobe has always had to make certain assumptions regarding a Certificate Authority’s intention for the usage of an issued certificate.
Recently, certificate usage has become more popular in enterprise settings where certificate-based authentication is used to access corporate networks in a variety of ways. Some of these certificates have relatively open KU and EKU configurations, and these have automatically been displayed back to the user within Adobe Reader and Acrobat as potential credentials for digitally signing PDF documents. After a re-evaluation of RFC 5280 and the actual industry practices for digital certificates, Adobe Acrobat and Reader 11.0.09 increase their conformance to RFC 5280 by no longer displaying all available certificates. In some cases, the changes will mean that certificates available for signing in earlier versions will not be displayed.
According to RFC 5280, there are several ways to make sure your credential can be used for digital signing. First, from “4.2.1.3 Key Usage” in RFC 5280:
“The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. The usage restriction might be employed when a key that could be used for more than one operation is to be restricted. For example, when an RSA key should be used only to verify signatures on objects other than public key certificates and CRLs, the digitalSignature and/or nonRepudiation bits would be asserted. Likewise, when an RSA key should be used only for key management, the keyEncipherment bit would be asserted.”
And secondly, from “4.2.1.12 Extended Key Usage” in RFC 5280:
“This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates.”
Further, when both KU and EKU are present, the RFC states:
“If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose.”
在我看来，Adobe 在接受 emailProtection 和 codeSigning 时过于自由 - 这些用法与文档签名明显不同。他们很可能只是想让尽可能多的常用证书可用于 PDF 签名，同时看起来符合 RFC。
谁能告诉我为什么当我使用 iTextSharp 库对 PDF 文件进行数字签名时，它的大小会增加 9MB。这是我用来签署文档的部分代码。
MakeSignature.SignDetached(appearance, externalSignature,
chain, crlList, null, null, 0, CryptoStandard.CADES);
如何预防？
您签署 PDF 文档的方式有一些问题。
乍一看，chain 似乎只包含一个证书。它应该包含完整的链，但它只包含您的签名证书（[EMAIL] ...），而它应该包含颁发者的证书（eID EMAIL Issuing CA）和可能的其他一些颁发者直到根证书，但是这不是 PDF 文件变大的原因。
请看一下这个屏幕截图：
签名很大，因为您嵌入了一个巨大的 CRL。一个好的证书颁发机构 aka CA（例如 GlobalSign）将采取预防措施以确保证书吊销列表的长度受到限制。一个好的 CA 将创建中间证书并限制每个中间证书颁发的证书数量。好的 CA 还会从 CRL 中删除所有过期的证书。
我已经通过这个 URL:
下载了您正在使用的 CRLhttp://ocsp.mpb-ks.org:8080/crls/search.cgi?alias=email
这是结果：
这是一个 4752 KB 的文件。此文件以十六进制字符串形式存储在您的 PDF 中，这意味着 URL 大约需要 9504 KB。
如果您遇到创建大量 CRL 的 CA（科索沃共和国内务部就是这种情况），则不应使用 CRL：而应使用 OCSP。 OCSP 响应的长度是可预测的。您得到的不是完整列表，而是 CRL 中的查找结果。嵌入这样的 OCSP 响应比嵌入完整的 CRL 消耗更少 space。
您应该询问您的当局如何从他们的服务中获得 OCSP 响应。我尝试阅读 http://www.mpb-ks.org/eID/policies/eID_RKS_CPS.pdf，但它不是 PDF，而是用我不懂的语言为我提供的普通网页。当我点击 "English" 时，它没有给我英文翻译。该页面似乎已损坏：缺少许多图像。
我看到密钥用法允许数字签名，但我不知道您的国家/地区是否允许使用该密钥对 PDF 进行签名。我的意思是：从技术上讲这是可能的，但我读过一条通知说 "E-Mail Signature Certificate"。我假设该证书用于签署电子邮件，而您将其用于其他目的。如果您使用该证书签署 PDF 文档，请与您的当局核实签名在您所在国家/地区是否具有法律约束力。
（作为
@Bruno 观察到
I see that the Key Usage allows digital signing, but I don't know if your country allows to use that key for signing PDFs. I mean: technically it is possible, but I've read a notice that says "E-Mail Signature Certificate". I assume that the certificate is meant to sign e-mail and you are using it for a different purpose. Please check with your authorities if the signatures are legally binding in your country if you use that certificate for signing PDF documents.
确实，用户证书有一个 Extended Key Usage 扩展名：
如您所见，上面写着 电子邮件保护，没有别的。
此扩展名在 RFC 5280 section 4.2.2.12 中指定，其中特别说明：
If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present.
在手头的案例中，只指明了一个目的，因此证书必须仅用于此目的。
因此，严格来说，证书确实不是用来签署 PDF 的，而只是为了保护电子邮件。
Adobe 的观点
如果你想知道为什么 Adobe Acrobat Reader 不抱怨使用这个证书，这里有一些背景：
自 11.0.09 版 here 以来，Adobe 已通过密钥使用和扩展密钥使用记录了他们对证书的接受。本质上，它们允许这些键用法的任意组合
- 缺席
nonRepudiationsignTransaction（仅限 11.0.09）digitalSignature（11.0.10 及更高版本）
以及这些扩展的密钥用法
- 缺席
emailProtectioncodeSigninganyExtendedKeyUsage1.2.840.113583.1.1.5（Adobe 真实文档信任）
他们解释如下：
RFC 5280, which started as RFC 2459 in 1999, did not include “Document Protection” as a potential EKU. Therefore, Adobe has always had to make certain assumptions regarding a Certificate Authority’s intention for the usage of an issued certificate.
Recently, certificate usage has become more popular in enterprise settings where certificate-based authentication is used to access corporate networks in a variety of ways. Some of these certificates have relatively open KU and EKU configurations, and these have automatically been displayed back to the user within Adobe Reader and Acrobat as potential credentials for digitally signing PDF documents. After a re-evaluation of RFC 5280 and the actual industry practices for digital certificates, Adobe Acrobat and Reader 11.0.09 increase their conformance to RFC 5280 by no longer displaying all available certificates. In some cases, the changes will mean that certificates available for signing in earlier versions will not be displayed.
According to RFC 5280, there are several ways to make sure your credential can be used for digital signing. First, from “4.2.1.3 Key Usage” in RFC 5280:
“The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. The usage restriction might be employed when a key that could be used for more than one operation is to be restricted. For example, when an RSA key should be used only to verify signatures on objects other than public key certificates and CRLs, the digitalSignature and/or nonRepudiation bits would be asserted. Likewise, when an RSA key should be used only for key management, the keyEncipherment bit would be asserted.”
And secondly, from “4.2.1.12 Extended Key Usage” in RFC 5280:
“This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates.”
Further, when both KU and EKU are present, the RFC states:
“If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose.”
在我看来，Adobe 在接受 emailProtection 和 codeSigning 时过于自由 - 这些用法与文档签名明显不同。他们很可能只是想让尽可能多的常用证书可用于 PDF 签名，同时看起来符合 RFC。