包括的な方法論は、欠陥領域を隔離するために署名パイプラインを検証パイプラインから分離することから始まります。テスターは、OpenSSLコマンドラインツールを使用して暗号化検証を実行し、PDFビューワーに依存せずにCMS（暗号メッセージ構文）の構造の整合性を確認する必要があります。視覚的回帰テストは、Adobe Acrobat、FirefoxのPDF.js、ChromeのPDFium、およびモバイルiOSのPDFKitレンダラー全体で署名外観ウィジェットをキャプチャし、座標系の誤解を検出する必要があります。時間的検証では、システムクロックを操作して証明書の有効期限を過ぎた日付に設定し、埋め込まれたOCSP応答とTSAトークンを通じてPAdES-LTVチェーンが有効性を維持することを確認します。
法律技術会社で、eIDAS適格信頼サービスプロバイダーからのECDSA P-256証明書を使用した契約実行プラットフォームを展開しました。重要な欠陥は、macOSで署名された文書がPreviewとAdobe Acrobatでは有効な署名を表示したが、ChromeのネイティブPDF.jsビューワーが「署名の有効性は不明」と報告したことに起因しました。
三つの異なる修正アプローチを評価しました。最初のアプローチは、古いPDFパーサーとの広範な互換性を提供するRSA 2048暗号鍵に移行することでしたが、これにより署名バイトサイズが約40％増加し、計算リソースが限られたモバイルデバイスでのパフォーマンスが大幅に低下しました。二番目のアプローチは、文書構造を単純化し、パースの複雑さを減らすためにLTV埋め込みを無効にすることを検討しましたが、これにより証明書の有効期限後に署名が無効になり、法律的文脈での10年間の文書保持期間の規制要件に違反することになります。三番目のアプローチは、ファイルの線形化においてByteRange参照の前にOCSP応答配列を配置するようにDSS（文書セキュリティストア）辞書を再構築することに焦点を当て、PDF.jsの線形パース要件を満たし、ファイルサイズを増加させず、耐久性を損なうことなく、複雑な低レベルのPDFオブジェクトの操作が必要とされました。
我々は、PDF.jsが線形パース順序要件を厳格に強制する一方で、Adobe Acrobatがより許容的なランダムアクセスパースモデルを採用しているため、三番目の解決策を選択しました。この実装により、プラットフォーム間の有効性の不一致が解消され、すべての対象プラットフォームで一貫した「署名有効」インジケーターを達成しつつ、厳密なPDF/A-3準拠とPAdES-LTV耐久性を長期的なアーカイブコンプライアンスのために維持しました。
PDF/A準拠レベルはデジタル署名の可視性と検証メカニズムにどのように影響しますか？
多くのテスターは、PDF/A準拠を二項状態として扱う誤りを犯します。PDF/A-1bは視覚的再現性のみを保証しますが、PDF/A-2aはタグ付き構造とUnicode文字マップを義務付けます。署名の作成中に、外観ストリームは文書のDA（デフォルト外観）文字列に埋め込まれたフォントを利用する必要があります。署名サービスが元の文書のフォントサブセットに存在しないシステムフォントを挿入すると、署名後にPDF/A検証が失敗し、暗号署名自体が数学的に有効である場合でも失敗します。テスターは、署名ウィジェットの生成中にフォントサブセットが発生しており、/DR（デフォルトリソース）辞書がシステムフォント名ではなく、事前に埋め込まれたフォントストリームのみを参照していることを確認する必要があります。
埋め込まれたOCSP応答が暗号的に正しいにもかかわらずLTV（長期検証）ステータスを確立できない場合があるのはなぜですか？
候補者はしばしば、DSS辞書内にOCSP応答バイトが存在することだけを確認し、検証チェーンの完全性をチェックしません。LTVの確立には、OCSP応答者証明書、タイムスタンプトークン、およびタイムスタンプ認証局証明書を含む完全な信頼アンカーチェーンが必要です。OCSP応答が自らの失効チェックを必要とする証明書で署名され、Certs配列内に応答者のための埋め込まれたOCSP応答がない場合、Adobe AcrobatはLTVモードを有効にすることを拒否します。テスターは、DSS内のCerts配列がルートCAを除き、すべての中間証明書を含んでいることを確認し、各タイムスタンプが署名とOCSP応答の両方をカバーして、PAdES-Tレベルのコンプライアンス最低限を達成する必要があります。
Adobe AcrobatとモバイルPDFビューワ間で署名外観の不整合が生じる原因は何ですか？
署名ウィジェットの位置を定義するRect（長方形）配列は、異なるビューワーが異なって解釈するページ座標系を使用します。Adobe Acrobatは座標を左下の原点から計算します（標準PDF座標空間）、一方、iOSのPDFKitのような一部のモバイルビューワーは、Rotateエントリが存在する場合に左上の原点からCropBox計算を適用します。署名ウィジェットが負の座標を使用するか、MediaBoxの境界を超える場合、デスクトップビューワーはモバイル実装とは異なる方法で外観をクリップする可能性があります。テスターは、座標がCropBoxおよびArtBoxの境界に対して検証され、ページ辞書内のRotationエントリが外観XObjectに変換行列を適用することによって尊重されていることを確認する必要があります。