私は現在、ユニクラスの認証局をプログラミングしています。現在、証明書を作成するという概念に苦労しています。
CA は通常、証明書をエンティティに提供する必要があるかどうかをどのように決定しますか?エンティティが公開キーの所有者であることを証明するには、秘密キーで証明書要求に署名するだけで十分ですか?
そうでない場合、エンティティが信頼できるかどうかを CA は通常どのように判断しますか?
ありがとう、
私は現在、ユニクラスの認証局をプログラミングしています。現在、証明書を作成するという概念に苦労しています。
CA は通常、証明書をエンティティに提供する必要があるかどうかをどのように決定しますか?エンティティが公開キーの所有者であることを証明するには、秘密キーで証明書要求に署名するだけで十分ですか?
そうでない場合、エンティティが信頼できるかどうかを CA は通常どのように判断しますか?
ありがとう、
あなたの質問が深刻な誤解を示唆しているのではないかと心配しています。
秘密鍵を使用して証明書要求に署名することにより、エンティティが公開鍵の所有者であることを証明するだけで十分ですか?
エンティティに秘密鍵で何かに署名させるだけでは確かに十分ではありません。CAは、署名の検証に使用する公開鍵をどのように知るのでしょうか。それを提供するためにエンティティを信頼する必要があります。したがって、誰でもCAに連絡して、次のように言うことができます。
「私はmicrosoft.comです。ここでは、秘密鍵を使用して署名しました。公開鍵を使用して確認することもできます。この公開鍵がmicrosoft.comに属していることを証明できますか?」 1000ドル払うよ!」
(実際、この手順は必要ですが、十分ではありません。秘密鍵で何かに署名しなかった場合は、Microsoftの公開鍵も含めてCAに送信し、自分のものであることを証明するように依頼することができます。 Microsoftによって署名されたもの(おそらく特許出願)が実際に私によって署名されたと主張することができます!したがって、CAは、証明書に公開鍵を認証する前に、対応する秘密鍵があることを確認します。)
したがって、問題は、証明書を要求している人の身元を確認するためにCAが何ができるかということです。CAの誰も、これまでこのエンティティについて聞いたことがありません。
CA側で完全に自動化できる簡単なオプションは、エンティティが電子メールアドレスを提供することです。CAは、その電子メールアドレスにチャレンジ(長い乱数を含むCA Webサイトの特別なURLなど)を送信します。誰かがそのURLを使用してサーバーにリクエストを送信した場合、その電子メールアドレスを所有またはアクセスできるのはおそらくその人です。
Verisignにアクセスして、無料の試用版SSL証明書を要求する場合は、これを自分で試すことができます。
制限は、この証明書が証明できる唯一の関係が公開鍵と電子メールアドレスの間であるということです。一部の人にとってはそれで十分かもしれませんが、すべての人にとっては十分ではありません。
特定の証明書(またはその中の公開鍵)が、たとえばエルボニアのXYZ Incに属していることを確信したい場合は、機密性の高いビジネスの詳細を送信しようとしているので、単なる電子メールアドレス以上のものが必要です。CAがいくつかの深刻な調査を行ったことを確認したいと思います。CAはレターヘッドでリクエストを受信する必要があります。電話帳の電話番号を使用して会社に連絡する必要があります。(詐欺師も電話関係者をだます必要があります。)CAは、XYZ Incがこの住所に登録されていることを確認するために、商号登録事務所に確認する必要があります。登録された住所に(長い乱数を含む)文書を投稿する必要があります。(つまり、なりすまし者もメールを傍受する必要があります。
これらのIDチェックはすべて、時間と費用がかかります。CAは、そのようなサービスに対してエンティティに課金します。ただし、エンティティが、この公開鍵が実際にXYZ Incに属しているという高いレベルの信頼性をクライアントに提供したい場合は、それを実行する必要があります。
Iain Collinsが示唆したように、CAは、わずかなID検証しか必要としない人には安価なサービスを提供し、他の人には高価なサービスを提供できます。CAが提供する証明書には、行われたID検証のレベルの指標が含まれます。証明書を使用したトランザクションを検討している人は、CAの認証実践ステートメントを見て、このレベルの意味と、実行されたIDチェックのタイプを理解できます。
最後に、CAはエンティティの信頼性について何の主張もしていません。証明書は公開鍵とIDの間のリンクであることを忘れないでください。CAが行うチェックは、公開鍵が実際にそのエンティティに関連付けられていることを確認するだけであり、そのエンティティになりすましている人ではありません。実体はかなり邪悪かもしれません!
要約すると、証明書が発行されるまで、公開鍵暗号を使用して誰かのIDを判別することはできません。証明書には、CAが他の形式のIDチェックを使用しており、他の人がそのチェックに依存できることが示されています。
エンティティの識別の決定は、認証されるエンティティのタイプにかなり主観的です。私の経験では、www.stackoverflow.comなどのドメイン名の証明書を要求する場合、CAは通常whoisに記載されている技術担当者に連絡します。
あるいは、CAは、CSRで提供するために信頼できるエンティティにPKCS#9パスフレーズを提供する場合があります。次に、CAはリストに対してパスフレーズを検査し、要求されたエンティティがそのエンティティに対して合法であるかどうかを判断できます。
さまざまなタイプの証明書に関連付けられたさまざまなレベルの信頼があります。
基本 SSL 証明書:
たとえば、Web サイトの基本的な SSL 証明書は、多くの場合、自動化されたプロセスであり、有効期限が切れた一意の URL (またはオンライン フォームに入力する必要があるコード) を送信して、ドメインの WHOIS レコードに関連付けられた電子メール アドレスを検証します。
拡張検証の場合:
より強力な検証 (最新のブラウザーで緑色のアドレス バーが表示される SSL の「拡張検証」の場合など) のために、複数の情報源を関連付けることによって所有者の正当性を確立することが一般的です。公共料金の請求書/設立証明書/登録された企業の詳細 (例: Dun and Bradstreet/Companies House Registration (UK) または同等のもの) およびドメインの whois 情報は、それらがすべて同じ住所および会社名と正確に一致することを確認します。
個人の証明書の場合、写真付きの運転免許証またはパスポートのコピーが必要になることがよくあります。
注文が正当であることを確認するために、識別された電話を介して折り返し電話をかけることも一般的です。電話番号の正当性は、通常、WHOIS 情報の 1 つ、または公益事業会社から提供された電話請求書に記載されている番号に基づいています。
Extended Validation 証明書のプロセスは、コード署名証明書のプロセスと同じではないにしても、通常は非常に似ています (レコードの電子メール連絡先として使用されるドメインは、多くの場合、WHOIS 情報を管理する必要があるドメインとみなされます)。
それはレジストラごとにわずかに異なり、少し非公式でアドホックな場合もあります (小規模な会社にとっては簡単に提供できるものでも、大規模な会社では入手が難しいものや、その逆の場合があるため)。複数の代替方法が受け入れられる)。
私見、実際に最も重要なことは、CAのサブスクライバー(つまり、証明書を検証している人)がCAが何をしているのかを理解し、証明書に適切な信頼を置くことができること、および証明書が同じIDを再発行しないことです。 2 つの異なるエンティティに。
証明書の名前が客観的なものである場合、ユーザーの身元を精査することが重要です。たとえば、特定のドメイン/ホスト名 (例: www.example.com) を含む Web サーバー証明書の場合、証明書の所有者がドメイン名を所有していることを確認する必要があります。