私はデジタル署名用のJavaAPIを理解しようとしています。カスタム暗号プロバイダーを使用してデジタル署名を作成する必要があります。このCSPを使用してドキュメントに署名し、切り離された署名を取得する方法を知っています。次に、この署名にタイムスタンプと証明書のステータスを追加する必要があります（政府当局が署名を有効にするため）。これらのことは、TSPとOCSPを使用して行われます。質問：
TSP クライアントはどこで入手できますか?
CMS、TSP、および OCSP を使用するには、Bouncy Castleをチェックしてください。これらは、メイン パッケージのすべてと、補足の CMS および TSP パッケージをサポートしています。
証明書の検証に組み込みの Java OCSP サポートを使用するだけで十分であるというのは正しいですか?
標準の PKIX 証明書検証メカニズムは OCSP をサポートしていますが、カスタムPKIXCertPathCheckerの形式で Bouncy Castle OCSP コードなどを統合することは理にかなっています。既存の検証の上に追加するか、本格的な代替品にすることができます。手順については、こちらを参照してください。プロキシ経由で接続するときに組み込みの OCSP サポートを使用すると問題が発生したため、過去にこの手法を使用してデフォルトを置き換えました。
tsp と検証情報は何らかの形で CMS に接続されていますか?
TSP サーバーが送信するタイムスタンプ応答は、別の CMS SignedData にすぎないため、それ自体が一種の署名です。無数の個別のファイルを回避するために通常行うことは、CMS の署名されていないプロパティ機能を使用して、元の署名自体にタイムスタンプを含めることです。タイムスタンプを署名されていない署名プロパティとして SignerInfo の ussignedAttrs フィールドに追加するだけで、個別のファイルを 1 つだけに最小限に抑えることができます。これは、signedAttrs フィールドと unsignedAttrs フィールド内にすべての追加情報を埋め込む署名自体です。
最後で最も興味深い: タイムスタンプ情報と証明書検証情報をどうすればよいですか: それは切り離されたファイルですか、それとも署名の一部ですか??
タイムスタンプについては既に説明しました。CRL や OCSP 応答などの検証情報は、SignedData の「crls」フィールドに埋め込むことができます。これらは、実際の署名を壊さずにいつでも追加できます。これらのコンテンツと署名されていないプロパティは、署名の生成または検証で考慮されません。
CMS (RFC 5652) だけを使用して情報を埋め込むと、かなり独自のスキームになってしまうことになります。ニーズによっては、これで十分かもしれません。ただし、より相互運用可能なものが必要な場合は、http://pda.etsi.orgからダウンロードできる無料の ETSI 標準である CAdES (ETSI TS 101 733) を調べることをお勧めします。その標準は、タイムスタンプや失効情報などの追加の署名データを適切に埋め込む方法に関する詳細情報を提供します。
プロバイダーに関連する Java 暗号化を検討している場合は、BouncyCastle (http://www.bouncycastle.org/java.html) を使用することをお勧めします。
そのウェブサイトからの引用：