私は、CAdES指向の電子署名ソフトウェアソリューションをXAdES指向のものよりも実装したいと思う理由を知ることができませんでした。高度な電子署名にCAdESを使用する理由はありますか？
インターネット上には多くのオープンライブラリと実装例とXAdESの例がありますが、それが人々がCAdESに比べてXAdESを使用することを決定した理由ではないと私は考えています。
XAdESはXML指向であり、ソフトウェア開発者はXML関連の何かを愛する傾向があるのでしょうか？ CAdESがXAdESで使用する最良のオプションであるというシナリオはありますか？
ありがとうございました！参考
：
つ（タイムスタンプをサポートしている）、高度な形でXML-DSIGという利点Cadenceのそれはです。一般には、相互運用性の問題を引き起こしません。ほとんどの場合、XML-DSig標準では、ロットオプション、XSLT、XPointer Framework、およびvarちょうど少数を挙げると、XML正規化の多くの形態があります。厳密にDERエンコードされたシグネチャに対処する必要があるだけであれば、CAdESの要求はそれほど厳しくありません（BERエンコーディングに対処する必要がある場合でも、ピクチャは変更されます）。
CAdES over XAdESのもう1つの利点は、大きなデータチャンクに「添付」署名を生成する必要があるシナリオです。つまり、元のデータと署名の両方を含む単一のデータチャンクを作成する必要があります。添付されたCAdES署名（すなわち、元の入力データがCMS構造のEncapContentInfo要素に格納されている）に相当するものはEnveloping Signatureです。このような種類のシグニチャを生成する必要がある場合、XAdES実装がDOMベースのもの（私が知っているもの）であれば大きな入力データを処理するときに問題に遭う可能性が高い - マシンが最終的に使い果たされるメモリの。
パフォーマンスは、CAdESを優先する別の議論になります。 CAdESのメッセージダイジェスト計算は通常入力データの生のバイトで直接行われますが、XML文書で計算されるXML署名にはXPath式の評価、XSLT変換、Base64エンコード/デコード、正規化などのオーバヘッドがあります...そして理論的には、いくつかのトランスフォーム要素があれば何度もあります。
多くの署名を保存する必要がある署名の長期的な検証のためのアーカイブシステムを構築する場合は、テキスト形式のXAdES形式と比較してコンパクトであるため、CAdESも好ましい形式です。
CADESはBES形式の拡張であり、非常に古いです。それはBERエンコーディングを使用します。 BERビューアを使用してCADESシグネチャの内容を表示できます。
コンパクトで足跡が少ない。 Cのような言語を使って、より高速に解析することもできます。
XADESとPADESの2つの他のフォーマットも使用できます。新しいアプリではXADESが好きですが、CADESを使用して既に作成されている多くの署名があります。
最新のCAdES RFCは2008年2月に、XAdES仕様は2003年2月に発行されました.PAdESはCAdESまたはXAdESをPDFに埋め込むことに関するものです。 – divanov
右のCADESはBES形式の拡張です。これはCADES-BESとも呼ばれます。また、CADES-T、CADES-XLのようなタイムスタンプ付きのバリエーションもあります。私は、より堅牢でコンパクトなXADES XML形式を使用しています。 PADESには、前述の@divanovのようにCADESがPDFに埋め込まれています。 –
あなたの素晴らしい答えをありがとう！私たちはあなたが言及しているさまざまなシナリオについてもっと調べるつもりです。 – ABE