PDF署名ツールを開発していました。このために、PKCS#1 形式の PDF の署名付き sha256 データとデバイスからの証明書を取得します。これら 2 つを使用して PDF 内に埋め込む必要があります。ほとんどの PDF リーダーは、PKCS#7 署名のみをサポートしています。
(証明書ファイルを使用して) PKCS#1 署名を PKCS#7 署名に変換する方法はありますか?
PKCS#7 = 証明書 + オプションの生データ + PKCS#1 形式の署名であることは知っていました。
PDF署名ツールを開発していました。このために、PKCS#1 形式の PDF の署名付き sha256 データとデバイスからの証明書を取得します。これら 2 つを使用して PDF 内に埋め込む必要があります。ほとんどの PDF リーダーは、PKCS#7 署名のみをサポートしています。
(証明書ファイルを使用して) PKCS#1 署名を PKCS#7 署名に変換する方法はありますか?
PKCS#7 = 証明書 + オプションの生データ + PKCS#1 形式の署名であることは知っていました。
あなたの質問は状況をやや単純化しすぎています。
PKCS#7 <-> PKCS#1 について:
はい、PKCS#7 署名コンテナーには、本質的にそれぞれ PKCS#1 スタイルの署名といくつかの属性を含む SignerInfo オブジェクトが含まれています。しかし、この PKCS#1 スタイルの署名は、通常、ドキュメント データに署名するだけではなく、いわゆる「署名された属性」の構造に署名しています。これらの 1 つはドキュメント ハッシュで、その他は署名時刻、署名者証明書へのリンク、およびその他の情報です。これらの追加情報は、多くのユース ケースで必要になります。最も原始的に構築された SignerInfo 構造のみが、ドキュメント データに直接署名します。
したがって、一般に、一部のデータの PKCS#1 署名を取得して PKCS#7 コンテナーにラップするだけでは、その署名コンテナーは受け入れられません。
詳細については、RFC 3852を参照してください。
統合された PDF 署名について:
実装予定の説明はやや曖昧です。署名するドキュメント ハッシュは、元の PDF のハッシュであると考えているようです。統合された PDF 署名の場合、これは誤りです。統合された PDF 署名を作成するには、まず、PKCS#7 署名コンテナー (仕様で推奨) または PKCS#1 署名のプレースホルダーを囲むデータによって PDF を拡張します。統合するために。次に、プレースホルダーを除いて、この拡張 PDF をハッシュする必要があります。(現在の PDF 仕様では、それよりも少ないハッシュを使用できますが、これは現在の Adobe Acrobat/Reader では受け入れられず、本格的な検証者によって受け入れられるべきではありません)。
詳細については、Adobe が発行した ISO 32000-1:2008 を参照してください。
法的要件によっては、ETSI によって指定された PDF Advanced Electronic Signatures (PAdES) も考慮する必要がある場合があります。EU 準拠の電子署名の ETSI 標準。これらは ISO 32000-2、別名 PDF 2.0 の一部になります。
それで、あなたのユースケースが、あなたが考えている非常に単純な PKCS#7 署名を許可していること、そして PKCS#1 ソース署名が適切なドキュメント用に作成されていることをまだ確信していますか? その場合、これらのコンテナーの構築は、 RFC 3852を参照することで簡単に実行できます。
いずれにせよ、Bruno Lowagie (iText Software) によるホワイトペーパーDigital Signatures for PDF documentsを参照してください。
RFC 3852 > 5.4 を参照してください。メッセージ ダイジェストの計算プロセス
署名された属性が含まれていない限り、PKCS#1 を PKCS#7 に単純に変換することができます。存在する場合、PKCS#1 はコンテンツのハッシュのみを変換し、中間構造を構築するために必要な署名付き属性を持つ PKCS#7 とその構造のハッシュが署名されているため、スタックします。