您的问题实际上有两个不同的方面，一方面您想知道为什么这两个文档（您创建的一个和 Swisscom 提供的一个）在您的 Adobe Reader 中表现不同，另一方面您问如何将 CRL 和 OCSP 嵌入到 pdf 中。
签署文件之间的差异
Adobe Reader 版本问题
首先，您观察到的两个文档的不同 Adobe Reader 行为仅发生在旧的 Adobe Reader 版本上，您在 Adobe Reader DC 中的两个文件都立即验证并带有绿色勾号。
因此，不仅阅读器的行为不再不同，现在开箱即用的签名也被认为是有效的！信任锚是从 Adobe Approved Trust List 获得的。
此外，您可以看到这两个签名都被视为“启用 LTV”。因此，包含 Adobe Reader 验证所需的所有信息，尤其是撤销信息（CRL 和 OCSP 响应）。
不同的签名过滤值
这两种签名的主要区别在于PDF签名的过滤器，
- 5.PDF_1_.pdf 具有签名 Filter 值 ETSI.RFC3161 和
- Reference_Guide-All-in-Signing-Service-en.pdf 具有签名 Filter 值 Adobe.PPKLite。
您签署的文件中的 Filter 值 ETSI.RFC3161 没有意义：此值是保留的 SubFilter 文档值时间戳！ SwissCom 签名的文件中的Filter 值Adobe.PPKLite 确实是一个过滤器名称，它是Adobe 签名处理程序的名称。
根据 PDF 规范 ISO 32000-1 和 ISO 32000-2：
验证此签名时要使用的首选签名处理程序的名称。如果 Prop_Build 条目不存在，它也应该是用于创建签名的签名处理程序的名称。如果 Prop_Build 存在，它可用于确定创建签名的处理程序的名称（通常与 Filter 相同，但不是必须的）。符合要求的阅读器可以在验证签名时替换不同的处理程序，只要它支持指定的 SubFilter 格式。示例签名处理程序是 Adobe.PPKLite、Entrust.PPKEF、CICI.SignIt 和 VeriSign.PPKVS。
Filter 值的含义随着时间的推移而减弱。早期的 Adobe Reader 版本（以及其他签名验证器的版本）仅自动处理具有某些 Filter 值的签名，而现在基本上忽略了 Filter 值。
因此，您观察到不同行为的 Adobe Reader 版本必须是旧版本，它仍然只立即处理具有已知过滤器的签名，并且仅在需要时处理未知过滤器。
您引用 this question 获取您的源代码，其中特别包含
IExternalSignatureContainer external = new ExternalBlankSignatureContainer(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);
PdfSignature external2 = new PdfSignature(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);//ADBE_PKCS7_SHA1);
//as pdf name I tried also PdfName.ETSI_RFC3161
显然，您使用代码创建了您的签名，您也尝试过 PdfName.ETSI_RFC3161...
将 CRL 和 OCSP 嵌入到 pdf 中
您的上下文中的这个问题实际上已成为一个有争议的问题，因为您的签名被识别为 LTV 启用，即特别是包括签名验证器所需的所有撤销信息（CRL、OCSP 响应） Adobe 阅读器。因此，我将仅笼统地介绍它。
基本上有两个地方可以在 PDF 中放置撤销信息：
- 签名容器中的特殊 Adobe 定义属性或
- 一个特殊的 ETSI 定义字典，在以后的增量更新中。
adbe 吊销信息属性
相关属性已在 PDF 规范 ISO 32000-1 中指定：
PKCS#7 对象应包含以下内容：
[...]
- 作为签名属性的吊销信息（PDF 1.6）：此属性可能包括对签名者证书及其颁发者证书执行吊销检查所需的所有吊销信息。由于撤销信息是签名属性，因此必须在计算数字签名之前获取。
[...]
adbe 吊销信息属性：
adbe-revocationInfoArchival OBJECT IDENTIFIER ::=
{ adbe(1.2.840.113583) acrobat(1) security(1) 8 }
吊销信息属性的值可以包括以下任何一种数据类型：
证书撤销列表 (CRL)，在 RFC 3280 中描述（参见参考书目）：CRL 通常很大，因此不应嵌入到 PKCS#7 对象中。
在线证书状态协议 (OCSP) 响应，在 RFC 2560、X.509 互联网公钥基础设施在线证书状态协议 - OCSP（参见参考书目）中描述：这些通常很小且大小恒定，应该PKCS#7 对象中包含的数据类型。
自定义撤销信息：本规范未规定格式，除了将其编码为八位字节字符串。应用程序应该能够通过查看相关的 OBJECT IDENTIFIER 来确定 OCTET STRING 中包含的数据类型。
adbe 的 Revocation Information 属性值有 ASN.1 类型的 RevocationInfoArchival：
RevocationInfoArchival ::= SEQUENCE {
crl [0] EXPLICIT SEQUENCE of CRLs, OPTIONAL
ocsp [1] EXPLICIT SEQUENCE of OCSP Responses, OPTIONAL
otherRevInfo [2] EXPLICIT SEQUENCE of OtherRevInfo, OPTIONAL
}
OtherRevInfo ::= SEQUENCE {
Type OBJECT IDENTIFIER
Value OCTET STRING
}
这种嵌入方式甚至在第一个 ISO PDF 规范 ISO 32000-1 之前就已经为人所知，因此，应该可以用于大多数验证器。缺点是这个属性是有符号的，所以必须尽早检索信息。这可能并不总是可行的。
顺便说一句，这也是这些信息嵌入到您的文档中的方式，SwissCom 会将此属性嵌入到您的签名容器中。
ETSI 文档安全存储 (DSS) 字典
该字典及其处理由 ETSI 指定，例如在 ETSI EN 319 142-1 中，并已复制到 PDF 规范更新 ISO 32000-2：
文档安全存储 (DSS) 应是一个字典，其值应为 DSS 作为文档目录中的键
字典。该字典用于提供一个位置，其中某些或
文件中的所有签名都应该被放置。
DSS 字典（如果存在）应仅包含文档和时间戳的验证相关信息
以 PKCS#7 和 CMS（及其衍生物）格式表示的签名或用于表单签名的 XAdES 签名
动态 XFA [i.7]。
注意：请参阅 ETSI EN 319 142-2 [i.11]，了解签署动态 XFA 的表单的 XAdES 签名规范。
DSS 词典中的条目
类型 名称（可选） 对于文档安全存储应为 DSS
字典。
VRI 字典 （可选） 该字典包含签名 VRI 字典
文件。该字典中每个条目的键是
签名的 base-16 编码（大写）SHA1 摘要
它适用，值是签名 VRI 字典
其中包含与验证相关的信息
签名。
（请参阅附加要求 a、b、c。）。
Certs Array （可选） 对流的间接引用的数组，每个
包含一个 DER 编码的 X.509 证书（应为
在 IETF RFC 5280 [4] 中定义）。此数组包含证书
可用于验证中的任何签名
文件。
OCSPs Array （可选） 对流的间接引用的数组，每个
包含 DER 编码的在线证书状态
协议 (OCSP) 响应（应在 IETF 中定义）
RFC 6960 [5]）。该数组包含可用于
验证文档中的任何签名。
CRLs Array （可选） 对流的间接引用的数组，每个
包含 DER 编码的证书吊销列表 (CRL)
（应在 IETF RFC 5280 [4] 中定义）。这个数组
包含可用于验证任何
文件中的签名。
由于第一个 ISO PDF 规范 ISO 32000-1 中不知道这种嵌入方式，因此许多验证器可能不知道如何处理这些信息。好处是这个字典不需要签名，所以签名后可以检索信息。在某些用例中这可能是必要的。