署名とIDに個別のエンドユーザー証明書が必要な実際のシナリオは何ですか？
この質問に基づいて 、私は署名と認証の証明書を別々に維持するという考えをサポートする合理的な議論に興味があります。
従来のロジックと知恵では、IDと署名の証明書を分離する必要はないと述べていますが、私はそれとは反対の合理的な理由（悪魔の支持者）を探しています。
IT運用、リスク管理、または懸念の分離の基礎となる可能性のあるいくつかの架空の例を次に示します。別のキーを正当化するこれらの理由のいずれかを検証する（または独自の理由を考え出す）ことを期待します。
可能な例：
- 認証と証明書の署名の有効期間/有効期限を変える必要はありますか？
- 各証明書の保証レベルを変える必要はありますか？ （異なるCA？）
- どちらか一方を取り消す必要があり、もう一方を取り消す必要はないでしょうか？どうして？
- 自動操作を妨げる主要な使用法（EKU）に基づいて、異なるソフトウェアワークフローはありますか？ （ウイルスによる認証や署名を防止する）
- 将来的にこのような分離を必要とする可能性のある、技術的に精通していない法律から守る必要がありますか？ （防犯劇場）
- 複数のデバイスに対して異なるストレージ要件（スマートカード、信頼できるデバイス、DPAPIなど）がありますか？ （電話、PC、iPadで同じまたは異なる証明書が必要ですか？）
- 複数の有効な署名およびID証明書が一度に「アクティブ」である場合、それは誤用のリスクを分離および分割するのに役立ちますか（すべての問題のある使用法を含むことができます）？
- ...？
これらは、さまざまな署名キーを維持する必要性を正当化する可能性があると考えることができるいくつかのアイデアですが、それらがどれほど現実的であるか（私が考えていなかったものも含む）はわかりません。
技術的な観点から、これらのために別のキーが必要になることを想像できます（そしておそらく他の理由）
- アルゴリズムRSAとECCの制限
- キーの長さ
- 内部互換性（SHA1/SHA2/SHA3）
[〜＃〜] ebics [〜＃〜] 金融プロトコル（ SwiftNet のヨーロッパの代替案）は、適切な実例です。認証、署名、暗号化にそれぞれ3つの証明書を使用します。
ほとんど（すべてではない）の銀行が3つの異なる証明書を使用しています。ただし、 公式プロトコル仕様 では、認証と暗号化に同じ証明書を使用できますが、署名専用の別の証明書を使用する必要があります。
EBICSでは、サブスクライバーごとに3つの異なる鍵ペアを使用できます。これを行う際、EBICSはサブスクライバーごとに少なくとも2つの異なる鍵ペアの使用を促進します。
- 1つのキーペアは、銀行の電子署名にのみ使用されます。
- 単一の鍵ペアの使用は、銀行システムによる加入者の識別と認証およびトランザクション鍵の解読に許可されています。
これにより、認証と署名の証明書が関連付けられ、次の目標を達成できます。
- 認証は、要求の一意の送信者として機能するエンティティを識別します。このエンティティは、物理的なエンティティである場合も、抽象的なエンティティ（企業やビジネスエンティティなど）である場合もありますが、問題ではありません。
- 銀行に送られるリクエストの場合、リクエストは銀行によって考慮されるために、1人または複数の物理的な人物（いくつかの基準に応じて）によって署名される必要があります。これらの人物が送信者として機能しない可能性があります。
- 認証証明書は、ソフトウェア構成ファイルまたはそのデータベースとともに、ディスクに格納できます。これにより、アカウントの残高、最後のトランザクションのステータスなどを取得するなどの自動処理が可能になります（これらのリクエストには認証が必要なので、認証証明書の使用も必要です）
- ただし、実際の人物を識別する署名証明書は、この人物が所持しているPINコードを使用する必要がある）物理トークン（暗号化USBキーまたはスマートカード）に保存する必要があります。
あなたの主張のほとんどは有効だと思います。通常、署名に使用される証明書には、「否認防止」などの異なる鍵の使用法があります。デジタル署名には、法廷などで有効でなければならない場合、多くの法的要件（EUなどのさまざまな国で）が存在します。これらの要件は、認証証明書には存在しません。あなたが1、2、3、4、5、6と言っていることはすべて有効なポイントです。
当然、それは常に特定のユースケースに依存します。また、企業環境では、それは完全に意味がないかもしれませんが、政府環境では難しい要件です。