[解決済み] OCSP レスポンスを一意にする

質問事項

PADES LTV Profileで文書に署名しています。署名用ライブラリはPdfboxライブラリをベースに作成されています。

一つ問題があります。

PADES LTVプロファイルでは、最終リビジョンはオンラインでチェックする必要があります（このリビジョンのOCSPレスポンス、CRLS、証明書はドキュメントセキュアストア（DSS）に存在してはいけないという意味です）。

テストのために、私の文書に12リビジョンを追加しました。

を追加すると、毎回 新しい リビジョンを作成する際、私は ない 証明書とocspレスポンスの追加 現在 リビジョンをDSSに追加します。以前のリビジョンの証明書と OCSP 応答を DSS に追加します。これを行うのは、最終リビジョン はオンラインでチェックインする必要があります。 . そのため、最終リビジョンのOCSPレスポンスをDSSに追加してはいけないのです。 しかし、Adobe Readerでは、最終リビジョンのOCSPレスポンスがDSSに追加されていると認識されることがある。 埋め込み OCSPレスポンス

問題は、次のようなことかもしれません。

ocsp レスポンスは、たとえ同じ証明書で生成した場合でも、それぞれ一意でなければなりません。言い換えれば、我々は2回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リンクです サンプルPDF

4つのリビジョンを作成し、すべてがうまくいくかもしれない・・・。よくわからないのですが、時々そういうことがあります。 私がテストしていたとき、問題は多くのリビジョンを作成したときに発生しました... 最後のリビジョンは、前のリビジョンのocspレスポンスを自分自身のものだと思い込んでいます。

解決方法は？

<ブロッククオート

PADES LTVプロファイルでは、最終リビジョンをオンラインでチェックする必要があります。

いいえ。

PAdES、すなわちETSI TS 102 778の中の パート4 (PAdES-LTVプロファイル) ただ 推奨する これを

<ブロッククオート

4.3 バリデーションプロセス

その検証プロセスは、以下のようにすることが推奨される。

1) 文書のタイムスタンプは、現在時刻に収集された検証データを用いて、現在時刻に検証されること。

単語 は は推奨を示すものであり、前の文は実際にそれを綴っている。

しかし、その勧告に従いたいとします。あなたの解釈

<ブロッククオート

(このリビジョンのOCSPレスポンス、CRLS、証明書はドキュメントセキュアストア(DSS)にあってはならないという意味です)。

文書には、外側のタイムスタンプや署名に適用される検証関連情報 (OCSPレスポンス、CRL、証明書) が含まれていることがあります (孤立した情報とみなされます)。同じタイムスタンプサービスを使用して文書を2回連続してタイムスタンプし、その間に最初のタイムスタンプで使用された証明書のCRLを追加した場合、外側のタイムスタンプはこのCRLでカバーされる証明書を含み、CRLが示す有効期間内に適用されている可能性があります。

いいえ、それは これらの情報を使用しないことは、検証者の責任です。 もし検証者が上記のPAdES-LTVの勧告に従うことを選択した場合。

Adobe Readerは ない は、この勧告に従うと主張しています（少なくとも私が知る限り）。したがって、Adobe Readerを使って署名とタイムスタンプを検証する場合、文書に含まれる情報が外側のタイムスタンプの検証にも使われる可能性があります。

実はAdobeはもともと、検証関連の情報を最初に取得し、その後にそれらの情報を含むすべてに署名とタイムスタンプを押すというコンセプトが好きだったんですね。

<ブロッククオート

問題は、次のようなことかもしれません。

ocsp レスポンスは、たとえ同じ証明書で生成した場合でも、それぞれ一意でなければなりません。言い換えれば、我々は2回ocspオブジェクトを要求した場合、それらはユニークでなければなりません。

noncesを使用するのは良いスタイルですが、あなたの観察はnoncesとは何の関係もありません。

Adobe Readerの理由 時々 (そして たまにしか は、外部署名/タイムスタンプを検証するために、すでに埋め込まれている情報を利用するため、OCSPレスポンスとCRLは、その thisUpdate と nextUpdate というフィールドがあります。 時々 (同じ TSA による複数のタイムスタンプを追加した場合) 古いタイムスタンプの検証のために埋め込まれたにもかかわらず、新しく追加されたタイムスタンプの時刻を含んでいます (したがって、それらの検証にも使用されます)。

これを防ぐには、PDFにすでに含まれている、あるいは今追加したOCSPレスポンスやCRLをチェックし、それぞれの有効期間がまだ終了していないものを検査し、それらで証明書を検証できる文書には、いかなるタイムスタンプも適用しないようにしなければならないのです。