個人デジタル証明書の確認方法
サーバー証明書のサブジェクトフィールドにはドメイン名が含まれます。個人証明書は、サブジェクトフィールドとしてあなたの名前を持ちます。同じ名前の証明書が2つないことをどのように確認できますか？
例：-暗号化されたデータをuserAに送信する必要があるとします。他の人ではなく、そのuserAであることをどのように確認できますか？証明書の名前を確認しても、中間者攻撃のリスクを取り除くことはできないと思います。
証明書の目的は、公開鍵をエンティティにバインドすることであり、これはPKIのRegistration Authorityの責任で、証明書はキーホルダーエンティティと一致します（たとえば、SSL証明書の場合、エンティティはサーバーであり、IDはドメイン名です）。
この照合がRAによってどのように実行されるかを説明する手順は、PKIによって公開され、 Certificate Policy という名前のパブリックドキュメントにあります。 =。
これは、CPを読み取り、この証明書を発行したCertification Authorityの信頼性を判断する（署名検証の暗号化のための）証明書のユーザーの責任です。です。もちろん、鍵の所有者の電子メールのみが検証されることを宣言する一部のPKIと、正式なIDチェックを使用して、鍵の所有者の手で直接スマートカードに証明書を配信するPKIには、同じ信頼を置きません。ただし、メールを確認するだけで十分な場合もあります。
実際、最も重要な質問は次のとおりです。
- 証明書のどのデータがRAによってチェックされていますか？
- これらのデータは信頼できる方法で収集されましたか？
- あなたのニーズに応じて（メール署名、契約の電子署名...）証明書を信頼できますか？
ユーザーのメールアドレスを識別子として使用してみませんか？
一意の識別子が必要な場合は、証明書のシリアル番号と発行者DNを組み合わせて使用します。これはOCSPが行う方法であり、一意であることが保証されています。 nealmcbが言うように-証明書の説明情報（サブジェクトDN、サブジェクトの代替名など）はRAによって検証され、CAが一意性を管理するビジネスプラクティスを持たない限り、一意である必要はありません。一部のグループは、たとえば、サブジェクトDNに従業員IDを含め、登録プロセスの一部として会社のデータベースと照合します。しかし、そのようなものを実装するには、これを提供するPKIシステムに固執していることを確認する必要があります。