LTV认证签名 [英] LTV of Certifying Signatures

问题描述

在过去的几周中，我一直在与iText一起在PDF文件上进行数字签名，根据我的理解，有两种方法可以将信息添加到PDF中以使其启用LTV:

I've been working with iText to do digital signatures on PDF files for the past weeks and based on what i've understood that there is two ways to add the information to the PDF to make it LTV enabled:

• 使用iText示例中提供的代码添加信息，此方法要求签名已经存在，因为DSS&它创建的VRI词典引用了签名.

• Adding the information with the code provided in the iText example, this method requires the signature to be already present because the DSS & VRI dictionaries it creates references the signature.

嵌入crl字节&在签名时在签名中加入ocsp响应.

Embedding the crl bytes & ocsp response in the signature at signing time.

尽管第一种方法产生的PDF文件很好且整洁，但问题是它会修改pdf文件以创建/附加条目，从而导致验证签名无效， 第二个可以正常工作，但是它会根据crl列表的大小显着增加pdf大小(这也可能会随着时间的推移而增加).

Eventhough the first method results in a nice and tidy pdf file the problem with is is that it modifies the pdf file to create/append the entries which results in an invalidation of the certifying signature, the second one works fine but it increases the pdf size substantially depending on the size of the crl list (that will also probably increase overtime).

最后，除了将信息嵌入签名本身之外，还有其他方法可以使认证签名LTV启用吗?有什么办法可以在签名时创建dds/vri词典?

Wrapping up, is there any other way to make the certifying signature LTV enabled other than embedding the information in the signature itself? Is there any way to create the dds/vri dictionaries at signing time?

以下是根据评论要求提供的更多信息:

Here's more info as requested on the comments:

用于添加ltv信息的代码:

The code used to add the ltv information:

    public static void processDocumentLtv(String filePath) throws IOException, GeneralSecurityException, DocumentException {

    long startTime = System.currentTimeMillis();

    File original = new File(filePath);
    File temp = new File(filePath + ".ltv");

    PdfReader reader = new PdfReader(filePath);
    PdfStamper stamper = new PdfStamper(reader, new FileOutputStream(temp), '\0', true);

    LtvVerification ltvVerification = stamper.getLtvVerification();
    OcspClient ocspClient = new OcspClientBouncyCastle();
    AcroFields fields = stamper.getAcroFields();
    List<String> signatureNames = fields.getSignatureNames();
    String sigName = signatureNames.get(signatureNames.size() - 1);
    PdfPKCS7 pkcs7 = fields.verifySignature(sigName);
    Certificate[] chain = pkcs7.getSignCertificateChain();
    X509Certificate x509certificate = pkcs7.getSigningCertificate();

    byte[] ocspResponse = ocspClient.getEncoded(x509certificate, CertificateUtils.getParent(x509certificate, chain), null);
    Collection<byte[]> crlBytes = CertificateUtils.fetchCrlBytes(x509certificate, chain);
    Collection<byte[]> ocspBytes = null;

    if (ocspResponse != null) {
        ocspBytes = new ArrayList<>();
        ocspBytes.add(ocspResponse);
    }

    ltvVerification.addVerification(sigName, ocspBytes, crlBytes, null);

    ltvVerification.merge();

    stamper.close();
    reader.close();

    Files.copy(temp.toPath(), original.toPath(), StandardCopyOption.REPLACE_EXISTING);
    temp.delete();

    logger.info("Took {}ms to do add the ltv information to the document.", (System.currentTimeMillis() - startTime));
}

文档样本: 在尝试添加LTV数据之前: https://www.dropbox.com/s/79ll23ndt9mbh3g/pdf-sample-pre-ltv.pdf?dl=0

The document samples: Before trying to add LTV data: https://www.dropbox.com/s/79ll23ndt9mbh3g/pdf-sample-pre-ltv.pdf?dl=0

运行完上面的代码后: https ://www.dropbox.com/s/hjl73es6hrqspi3/pdf-sample-post-ltv.pdf?dl = 0

After running through the code above: https://www.dropbox.com/s/hjl73es6hrqspi3/pdf-sample-post-ltv.pdf?dl=0

我正在使用Adobe Reader DC v15.017.20053作为我的PDF查看器.

I'm using Adobe Reader DC v15.017.20053 as my PDF Viewer.

推荐答案

对示例文件的观察

我用OP的样本PDF进行了一些测试.确实，Adobe Acrobat(阅读器)不喜欢iText生成的PAdES-4 LTV添加到具有无更改允许认证的PDF上，对此有点脑子裂开，

Observations with the sample file

I performed some tests with the OP's sample PDF. Indeed, Adobe Acrobat (Reader) does not like PAdES-4 LTV additions generated by iText to a PDF with no-changes-allowed certification, and it is a bit brain-split about it, saying both

自从应用此签名以来，对此文档所做的某些更改是文档作者所不允许的.

Some of the changes that have been made to this document since this signature was applied are not permitted by the document author.

和

自从应用此签名以来，对此文档没有进行任何更改.

There have been no changes made to this document since this signature was applied.

(按计算修改列表后的Adobe Acrobat签名属性对话框)

(Adobe Acrobat signature properties dialog after pressing Compute Modifications List)

即使我删除了除LTV信息之外的任何更改(iText还会调整文档修改日期元数据)，这种情况仍然存在，我最终甚至删除了添加的扩展名条目 ESIC ( BaseVersion 1.7， ExtensionLevel 5)，它向PDF查看器指示PAdES-4 LTV内容可能存在，只有 DSS 参考和内容保留.

This situation remained even when I removed any change in excess of the addition of the LTV information (iText additionally adjusts the document modification date meta data), I eventually even removed the added Extensions entry ESIC (BaseVersion 1.7, ExtensionLevel 5) which indicates to a PDF viewer that PAdES-4 LTV content may be present, only the DSS reference and contents remained.

因此，Adobe Acrobat违反了要求的PAdES-4规范

Thus, Adobe Acrobat violates the PAdES-4 specification which requires

DocMDP限制(请参见ISO 32000-1 1 条款12.8.2.2)不适用于包含DSS词典以及相关的VRI，证书，CRL和OCSP的PDF文档的增量更新.

DocMDP restrictions (see ISO 32000-1 1 clause 12.8.2.2) shall not apply to incremental updates to a PDF document containing a DSS dictionary and associated VRI, Certs, CRLs and OCSPs.

(ETSI TS 102 778-4 V1.1.2(2009-12)附件A.1文档安全存储)

即使Leonard Rosenthol(当时的Adobe PDF传播者)在iText邮件列表中得到保证

even though Leonard Rosenthol (the Adobe PDF evangelist at the time) assured on the iText mailing list

我检查了我的工程师，他们的确确认了DocMDP/Cert签名完全支持LTV.

I checked with my engineers and they indeed verified that LTV is fully supported on DocMDP/Cert signatures.

()

我还没有检查两个选项，但是，如果认证签名是PAdES-3签名，或者如果已经处于刚刚认证版本的认证文档至少包含一个签名，则Adobe Acrobat可能仅遵守上述PAdES-4要求. 扩展条目 ESIC ( BaseVersion 1.7， ExtensionLevel 5).

I have not checked two options, though, probably Adobe Acrobat only adheres to the PAdES-4 requirement above if the certification signature is a PAdES-3 signature, or if the certified document already in the just certified version at least contains an Extensions entry ESIC (BaseVersion 1.7, ExtensionLevel 5).

手头的文档包含一个旧版ISO 32000-1签名(可以视为PAdES-2签名，但也可以视为不带PAdES的签名)，并指示没有 ESIC 的PDF版本1.3. strong>扩展名条目.

The document at hand contains a legacy ISO 32000-1 signature (which can be regarded a PAdES-2 signature but which can also be regarded a PAdES-unaware signature) and indicates PDF version 1.3 without an ESIC extension entry.

在最终将其称为Adobe Acrobat错误之前，我会尝试使用PAdES-3签名和 ESIC 扩展条目(或根据PAdES定义的 ADBE )进行更改-4第4.4节).

Before finally calling it an Adobe Acrobat bug, I'd try changing using a PAdES-3 signature and the ESIC extension entry (or an ADBE one according to PAdES-4 section 4.4).

最后，除了将信息嵌入签名本身之外，还有其他方法可以使认证签名LTV启用吗?有什么办法可以在签名时创建dds/vri词典?

Wrapping up, is there any other way to make the certifying signature LTV enabled other than embedding the information in the signature itself? Is there any way to create the dds/vri dictionaries at signing time?

PAdES-4的添加被描述为是指文档先前版本中的签名，而不是同一版本中添加的签名.因此，尽管在技术上可以在同一修订版中添加信息，但不能保证符合要求的PDF查看器将使用这些信息.

The PAdES-4 additions are described as referring to signatures in prior revisions of the document, not to signatures added in the same revision. Thus, while it would be technically possible to add the information in the same revision, there is no guarantee they will be used by a conforming PDF viewer.

这篇关于LTV认证签名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！