使OCSP響應唯一

Question

我使用PADES LTV Profile簽署文檔。 Signer庫是基於Pdfbox庫編寫的。

我有一個問題。

在PADES LTV配置文件中，必須在線檢查最終修訂版（這意味着此修訂版的OCSP響應，CRLS和證書不得在文檔安全存儲區（DSS）中）。

爲了測試，我在文檔中添加了12個修訂版本。

當我添加新修訂每次，我做不添加證書，這當前修訂的DSS的OCSP響應。我將以前的版本證書和ocsp響應添加到DSS。我這樣做是因爲上次修訂版必須在線登記。所以我不能將最後一次修訂的OCSP響應添加到DSS。我這樣做，但有時Adobe Reader認爲最後一次修訂版本有嵌入式 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個版本，一切都可能是沒事的......我不不知道，有時候會發生......當我進行測試時，當我創建很多修訂時，問題就會發生...... 最後的修訂讓我想起OCSP對以前版本的反應是它自己的！

Answer 1

在PADES LTV輪廓，最終的修訂必須在在線

號

的PAdES進行檢查，即ETSI TS 102 778，在part 4 (PAdES-LTV Profile)僅僅建議這樣的：

4.3驗證過程

建議該驗證過程如下：

1）「最新」文件時間戳應在當前時間在當前時間收集的驗證數據進行驗證。

字應該表示建議，以及之前句話其實拼出來。

但是讓我們假設您想要遵循該建議。您的解釋

（這意味着此修訂版的OCSP響應，CRLS和證書不得在文檔安全存儲（DSS）中）。

仍然不正確：文檔中可能存在與驗證相關的信息（OCSP響應，CRL，證書）（視爲獨立信息）適用於外部時間戳或簽名。如果您使用相同的時間戳服務短時間連續兩次爲您的文檔添加時間戳，併爲之間的第一個時間戳中使用的證書添加CRL，那麼外部時間戳可能涉及此CRL涵蓋的證書， CRL指示的有效時間間隔。

不，如果驗證者選擇遵循上面引用的PAdES-LTV建議，驗證者不應使用這些信息的責任。

Adob​​e Reader確實不是聲稱遵循此建議（至少據我所知）。因此，如果您使用Adobe Reader驗證簽名和時間戳，也可以使用文檔中包含的信息來驗證外部時間戳。

實際上，Adobe最初非常喜歡先檢索驗證相關信息並簽名和時間戳所有信息的概念，其中包括之後的所有信息。

問題可能在於以下幾點：

每個OCSP響應必須即使當我們生成它們使用相同的證書是唯一的。換句話說，如果我們要求ocsp對象兩次，它們必須是唯一的。

不是。儘管使用隨機數是一種很好的風格，但您的觀察與他們無關。

爲什麼ADOBE READER 有時（和只是有時）利用已經嵌入信息驗證外簽名/時間戳的原因是，OCSP響應和CRL已有效性區間由他們thisUpdate和nextUpdate領域定義了有時（如果您通過相同的TSA添加多個時間戳記），儘管已嵌入驗證舊時間戳記仍然包含新添加的時間戳記（因此也用於其驗證）。

如果您想防止這種情況發生，您必須檢查PDF中已經包含的OCSP響應和CRL，或者您現在剛添加的OCSP響應和CRL，檢查那些其各自的有效間隔尚未結束的用戶，標記到證書可以與其一起驗證的文檔上。