XAdES 指向の電子署名ソフトウェア ソリューションよりも CAdES 指向の電子署名ソフトウェア ソリューションを実装することを好む理由を見つけることができませんでした。
インターネット上には、XAdES のオープン ライブラリや実装事例、サンプルが数多くありますが、それが CAdES よりも XAdES を使用する理由になるとは思えません。
XAdES は XML 指向であり、ソフトウェア開発者は XML 関連のものを好む傾向があるためでしょうか? XAdES よりも CAdES を使用するのが最適なオプションであるというシナリオはありますか?
参考のため：
CAdES の利点の 1 つは、XML-DSig 標準ではXSLT、XPointer Framework、XML 正規化などの多くのオプションが許可されているため、一般的に相互運用性の問題が少ないことです。厳密に DER でエンコードされた署名のみを処理する場合、CAdES の要件はそれほど厳しくありません (BER エンコードを処理する必要がある場合は状況が変わります)。
CAdES は、大きなデータ チャンクに「添付された」署名を生成する必要があるシナリオで XAdES よりも優れています (結果は、元のデータと署名の両方を含む 1 つのデータ チャンクにする必要があります)。添付された CAdES 署名 (元の入力データは CMS 構造の EncapContentInfo 要素に格納されます) に相当するものは、エンベロープ署名です。このような種類の署名を作成する必要がある場合、XAdES 実装が DOM ベース (私が知っているもの) である場合、大量の入力データを処理するときに問題が発生する可能性が高くなります。最終的にマシンが不足します。メモリの。
パフォーマンスは、CAdES が支持されるもう 1 つの議論です。CAdES のメッセージ ダイジェスト計算は、通常、入力データの未加工のバイトに対して直接行われます。XML ドキュメントで計算される XML 署名には、XPath 式の評価、XSLT 変換、Base64 エンコーディング/デコーディング、正規化など、多くのオーバーヘッドが伴います。潜在的にいくつかの Transform 要素。
多くの署名が保存されている署名の長期検証用のアーカイブ システムを構築している場合は、テキストの XAdES 形式と比較してコンパクトであるため、CAdES が推奨される形式です。