1

ユーザーの証明書を作成するアプリケーションを作成しています。後で次のカテゴリでWindowsユーザー証明書ストアで検索できるように、これらの証明書に何らかの方法でマークを付けたいと思います。

  • アプリケーションGUID（または名前-この証明書が自分のアプリケーション用であることを知りたい）
  • 証明書の役割（管理証明書またはユーザー証明書）
  • ユーザーのメール

最後の1つには、「E=J.Doe@mail.com」またはOID番号「1.2.840.113549.1.9.1=J.Doe@mail.com」を使用する必要があることはわかっていますが、どのOIDを使用するかわかりません。アプリケーションGUIDと証明書の役割を選択します。

または、「KeyUsage」フィールドを使用する必要がありますか？

それが重要かどうかはわかりませんが、証明書はアプリケーションの認証とデータベース内のデータの復号化に使用されます。

それを行うための標準的な方法はありますか？

4

3 に答える 3

0

うーん...私が考えているのは、ユーザーごとに証明書を発行し、アプリケーションごとに異なる証明書を作成することを計画しているということです。したがって、10 人のユーザーがそれぞれ 3 つのアプリケーションを使用している場合、30 の証明書を作成することになります。

また、証明書には、アプリケーション内でのユーザーの役割と、ユーザーの電子メールも記述されています。

実を言うと、私はこのすべての情報を証明書に入れるつもりはありません。PKI のプロビジョニングは困難です。一般に、ユーザーは証明書の設定に苦労し、証明書の再発行は面倒です。一般に、PKI 展開戦略では、発行する必要がある証明書の数を最小限に抑え、リスクとのバランスを取ろうとします。

私が見た最も典型的なシナリオは、ユーザーが自分自身を識別するために使用する単一の証明書を与えられるというものです。証明書には、ユーザーの名前と電子メールが含まれています。ただし、通常、ユーザーの役割や特定のアプリケーションは含まれません。代わりに、この情報はアクセス制御サーバーで管理され、ユーザーがシステムにアクセスするときに照会されます。これにより、証明書を再発行することなく、ユーザーが使用できる役割とアプリケーションを変更できます。Active Directory や Select Access などの製品は、この種のことを行います。

用途ごとに個別の証明書に分ける理由は、特定の種類のリスクを具体的に制御するためです。たとえば、1 人のユーザーが 1 つのマシンで高リスクの操作を実行し、別の潜在的に危険なマシンで低リスクの操作を実行している場合、2 つの証明書 (各マシンに 1 つ) を持っている場合があるため、証明書を取り消すことができます。リスクの高い機能を無効にすることなく、リスクの低い証明書を削除します。すべての証明書を同じマシンに保存する場合は、ユーザーごとに証明書を 1 つだけ配布する方が簡単です。

とはいえ、ロールごとにアプリケーションごとにユーザーごとに1つの証明書を発行する必要がある場合は、アプリケーションのGUID、ロール、および電子メールを識別名に詰め込む方法を見つけることをお勧めします.

キー使用法または拡張キー使用法から多くのマイレージを取得することはできません-これらには非常に具体的な価値があり、説明したい情報を伝えるとは思えません. また、それらは他のさまざまなアプリケーションによって特定の方法で使用されるため、他のものと統合する必要がある場合は、注意が必要です.

于 2009-07-24T21:21:43.890 に答える
0

あなたの仕事は非常に複雑な仕事です。それを解決する最善の方法は、openssl を使用して社内の認証局を少し動かすことです。あなたが参照したエンティティに割り当てられた PKI は、次のルールに基づいていることに注意してください。

  1. 識別名: 証明書を発行するユーザーまたはエンティティを識別するために使用されます。1 つの証明書内の 2 つの異なるエンティティ (ユーザーとアプリケーション) を識別するためにこれを使用するのは適切ではありません。2 つのエンティティは、2 つの異なる場所で識別される必要があります。

  2. Key Usage は、キーの使用法を定義する 8 桁のビット フィールドです。すべてのビットにはあらかじめ定義された意味があり、他の目的に使用することはできません。

次のことをお勧めします。

  1. アプリケーション GUID を x509 拡張子として配置します。その拡張機能に個人用の OID を割り当てて、クエリを実行できます。OID が内部で使用されている場合は、任意の値を使用できます。証明書を配布する予定がある場合は、IANA から独自の OID を取得できます。

  2. PKI で提案されているように、代替メールの件名フィールドにメールを入れます。

  3. 管理者またはユーザーの場合、2 番目の x509 拡張機能を追加するか、証明書のツリーを作成できます。メイン CA 証明書、管理 CA 証明書、およびユーザー CA 証明書。管理者用のすべての証明書は管理者 CA によって署名され、すべてのユーザー証明書はユーザー CA によって署名されます。

于 2009-09-27T06:36:51.610 に答える
0

OK、数時間後、私はこのようなものを手に入れました.

すべての証明書は、サブジェクト フィールドによって認識されます。管理者証明書の場合、次のようになります。

CN=<My application Name> Administrator,OU=Administrator,OU=<My application Name>,O=<My company Name>

そしてユーザーのために

E=<User email>,CN=<User email>,OU=User,OU=<My application Name>,O=<My company Name>

誰かがより良いアイデアを持っている場合、私は提案を受け付けています:-)

于 2009-07-23T07:12:10.963 に答える