使 OCSP 响应独一无二

Question

我使用 PADES LTV 个人资料签署文件。 Signer 库是基于 Pdfbox 库编写的。

我有一个问题。

在 PADES LTV 配置文件中，最终修订版必须在线签入（这意味着该修订版的 OCSP 响应、CRLS 和证书不得在文档安全存储 (DSS) 中）。

为了测试，我在我的文档中添加了 12 个修订版。

每当我添加新修订版时，我都会不将这个当前修订版的证书和 ocsp 响应添加到 DSS。我将以前的修订证书和 ocsp 响应添加到 DSS。我这样做是因为上次修订必须在线签入。所以我不能将最新版本的 OCSP 响应添加到 DSS。我这样做了，但有时 Adob​​e 读者认为最新版本在文档中嵌入 OCSP 响应。

问题可能在于：

每个 ocsp 响应必须是唯一的，即使我们使用相同的证书生成它们也是如此。换句话说，如果我们两次请求 ocsp 对象，它们必须是唯一的。

为此，我执行以下操作，但它不起作用：

private OCSPReq buildOcspRequest(X509Certificate issuerCert, BigInteger serialNumber, File inputDocument) {

    InputStream is = new FileInputStream(inputDocument);
    X509CertificateHolder certificateHolder;

    certificateHolder = new X509CertificateHolder(issuerCert.getEncoded());
    CertificateID id = new CertificateID(new BcDigestCalculatorProvider().get(CertificateID.HASH_SHA1), certificateHolder, serialNumber);

    OCSPReqBuilder ocspReqBuilder = new OCSPReqBuilder();
    ocspReqBuilder.addRequest(id);

    DigestCalculatorProvider digestCalculatorProvider;
    JcaDigestCalculatorProviderBuilder digestCalcProvBuilder = new JcaDigestCalculatorProviderBuilder().setProvider("BC");
    digestCalculatorProvider = digestCalcProvBuilder.build();

    // get SHA 256 
    DigestCalculator digest = digestCalculatorProvider.get(AlgorithmIdentifier.getInstance("2.16.840.1.101.3.4.2.1")); 

    OutputStream os = digest.getOutputStream();
    IOUtils.copy(is, os);

    byte[] messageImprint = digest.getDigest();

    BigInteger time = BigInteger.valueOf(System.currentTimeMillis());

    // time + imprint
    byte[] nonce = ArrayUtils.addAll(time.toByteArray(), messageImprint);

    Extension extension = new Extension(OCSPObjectIdentifiers.id_pkix_ocsp_nonce, true, nonce);
    ocspReqBuilder.setRequestExtensions(new Extensions(extension));

    return ocspReqBuilder.build();

}

这是测试pdf链接SAMPLE PDF

我可能会创建 4 个修订版，一切都会好起来的...我不知道，有时会发生...当我在测试时，当我创建许多修订版时会出现问题...最后REVISION 认为 OCSP 对以前的版本的响应是它自己的！

Answer 1

在 PADES LTV 配置文件中，最终修订必须在线签入

没有。

PAdES，即 ETSI TS 102 778，在 part 4 (PAdES-LTV Profile) 中仅推荐这个：

4.3 验证过程

建议验证过程如下：

1) “最新”文档时间戳应在当前时间使用当前时间收集的验证数据进行验证。

should这个词表示推荐，前面的句子实际上是拼出来的。

但让我们假设您想要遵循建议。你的解释

（这意味着此版本的 OCSP 响应、CRLS 和证书不得在文档安全存储 (DSS) 中）。

仍然不正确：文档中可能存在验证相关信息（OCSP 响应、CRL、证书），这些信息（被视为孤立信息）适用于外部时间戳或签名。如果您使用相同的时间戳服务连续两次为您的文档添加时间戳，并在其间为第一个时间戳中使用的证书添加 CRL，则外部时间戳可能涉及此 CRL 涵盖的证书并应用于CRL 指示的有效区间。

不，如果验证者选择遵循上面引用的 PAdES-LTV 建议，则验证者有责任不使用这些信息。

Adobe Reader 确实不声称遵循此建议（至少据我所知）。因此，如果您使用 Adob​​e Reader 验证签名和时间戳，文档中包含的信息也可能用于验证外部时间戳。

实际上，Adobe 最初喜欢首先检索与验证相关的信息，然后对包括这些信息在内的所有内容进行签名和时间戳记的概念。

问题可能在于：

每个 ocsp 响应必须是唯一的，即使我们使用相同的证书生成它们也是如此。换句话说，如果我们两次请求 ocsp 对象，它们必须是唯一的。

没有。虽然使用 nonce 是一种很好的风格，但您的观察与它们无关。

Adobe Reader 有时（并且只是有时）使用已经嵌入的信息来验证外部签名/时间戳的原因是 OCSP 响应和 CRL 具有有效间隔由他们的 thisUpdate 和 nextUpdate 字段定义，这些字段有时（如果您通过同一个 TSA 添加多个时间戳）尽管被嵌入以验证较旧的时间戳仍然包含新添加的（因此也用于验证）。

如果您想防止这种情况发生，您必须检查 PDF 中已包含或您刚刚添加到其中的 OCSP 响应和 CRL，检查其各自的有效间隔尚未结束的那些，并且不应用任何时间戳到可以用它们验证其证书的文档。