私の特定の使用例は、クライアントに保存されているデジタル証明書にアクセスし、それらを使用して、クライアント側とサーバー側で署名、検証、暗号化、および復号化のタスクを実行する必要があることです。後半については、多くの解決策があります。問題は、クライアントに保存されている証明書にアクセスできることです。
「クライアントに保存された証明書」と言っていることに注意してください。これは意図的にあいまいです。システム ストア、ユーザー ストア、ブラウザ ストア、暗号化トークン、Java キー ストアなど、どこにいても考えを制限したくありません。
長年にわたり、私は次の方法を使用しました。それらのそれぞれに沿って、長所と短所を示します。
- CAPICOM/ActiveX。これは最も簡単に操作できましたが、ユーザーは Windows 上の IE に制限されます。さらに悪いことに、現在は推奨されておらず、32 ビットでしか動作しません。
- Java アプレット。これはクロス プラットフォームおよびクロス ブラウザですが、ブラウザの Java は期待ほど一般的ではなく、すぐに消えつつあります (Apple が最近削除したようです)。そのため、ユーザーに JRE をダウンロードしてインストールさせるという追加の手間がかかります。さらに、ユーザーは、署名者が機能するように無制限の強度の暗号拡張を設定するという比較的技術的なタスクを実行する必要があります。
聞いたこと/考えたことはあるが、あまり進んでいないこと
- ほとんどの JavaScript ソリューション。彼らは RSA アルゴリズムを実装していますが、クライアント証明書ストアのデジタル証明書にアクセスする方法がありません。それらのほとんどは、新しいキー ペアを生成します。
- フラッシュ/フレックス。Flash/Flex は、最もユビキタスなクライアント側テクノロジのようです。カメラやマイクなどのクライアント ハードウェアには既にアクセスできます。彼らが証明書ストアにアクセスできれば素晴らしいことです。
- Microsoft Web サイトで提供されている CAPICOM の代替。主に.NETフレームワークを使用して行うCAPICOMの代替手段を規定しています。これは、デスクトップ クライアントに最適です。しかし、「スクリプト」については、「重要な注意事項」で、独自の ActiveX コントロールを作成する必要があると非常に明確に述べています。振り出しに戻ります。
私が探しているのは、クライアント上の証明書ストアにアクセスするという主な問題を乗り越える/回避する方法です。私は、RSA アルゴリズムや、なぜ PKI がばかげているのか、非対称暗号化に代わるもの、Web アプリケーション以外のアーキテクチャの使用、または Apple についての議論を探しているわけではありません。