セルフサービスの証明書の更新、取り消し、または取り消しの取り消しには、どのような考慮事項を適用する必要がありますか？
証明書を更新、失効、および失効解除するためのセルフサービスポータルを設計する必要があり、次のルールを考え出しました*。
リニューアル
証明書の有効期間は短期であり、迅速に更新する必要があるため、ほとんどの更新は自動的に承認されます。 CAが更新を発行するには、ゼロ知識証明で十分です。
CAには、Xの更新後にパスワードを要求するか、短期間に過度の更新を要求するオプションがあります。
失効
以前に割り当てられたパスワードを使用して証明書を取り消すことができるのは、証明書の許可された所有者のみです。
別のユーザーが所有している証明書を紛失した場合は、「良いサマリア人」の取り消しを許可します。そのユーザがゼロ知識証明を失効サービスに提示した場合、CAは証明書を失効させます
失効すると、同じ公開鍵を持つすべての証明書が自動的に失効します（同じ公開鍵の有無にかかわらず、鍵を更新することができます）。
失効解除
証明書が「優れたサマリア人」ではなくユーザーによって取り消された場合は、以前に取り消されたものと同じポータルユーザー名とパスワードを使用して取り消すことができます。
「良いサマリア人」の取り消しは許可されません。
質問
上記の証明書管理のこれら3つの側面について、このプロセスに対する他のプロセスフロー、脅威、またはリスクを考慮する必要がありますか？
*注：これはnot X509ベースのシステムの場合、さまざまな暗号プリミティブと機能が適用されます。いくつかの概念はおそらく譲渡可能ですが
「 ゼロ知識証明 」という表現を使用していますが、それはあなたがそれが意味すると信じていることを意味するものではありません。
ZKP証明は、ProverがVerifierにシークレット値の特定のプロパティを示す一種の暗号プロトコルです。検証者に追加情報を漏らさない場合、証明は「ゼロ知識」です。たとえば、秘密の整数xと、公に知られている値gがあるとします。バツmodp既知の整数p（大きな素数）およびg。証明者は、xに関する知識を示したいと考えています。彼は単にxを検証者に表示することでそれを行うことができますが、それはxを検証者に漏らします。 「ゼロ知識」。 ウィキペディアのページ で説明されているプロトコルは、目的の結果を達成するZKプロトコルです。
したがって、「ゼロ知識証明」は、より弱い種類の証明ではありません。それは実際にはより強力です（または、検証者のなりすましに抵抗するという点で少なくとも「より良い」）。あなたは、何らかの方法で「より強力」または「より認証的」であると想定する、より単純な「パスワードを表示」の種類の認証でZKPに反対しているようです。その点であなたはひどく間違っています。したがって、あなたが「ゼロ知識」について話しているとき、あなたは実際には、通常「ゼロ知識」によって指定されているものと実際には類似していない何かについて考えていると思います。
証明書の更新は、以前の証明書と同じ公開鍵、または新しい証明書を使用できます。同じキーと名前が使用されている場合、実際に証明書の所有者と話すことなく、CA側から操作を実行できます。これにより、ユーザーの名前と公開キーの間の関連付けが自動的に拡張されます。
X.509で使用されている失効システムは、実際には、CA側で自動的に更新される非常に短命の証明書と同等です。 「真のX.509」形式では、ユーザーの証明書は実際には証明書自体と十分に新しいCRLまたはOCSP応答の組み合わせであり、CAはそれ自体で後者を「更新」します。
新しい別個の公開鍵で証明書を更新する場合は、新しい公開鍵が実際にユーザーによって所有されていることを確認する必要があります。次に、明示的または暗黙的な認証が必要になります。これは、パスワードを表示するプロトコルにすることができます。これは、以前の証明書で署名された更新要求である可能性があります。多くの可能性があります。このような手順に伴うリスクは通常と同じです。つまり、攻撃者によるなりすましです。
以前の秘密鍵で署名された要求に基づいて新しい証明書を発行すると、攻撃者が以前の秘密鍵を盗んだ場合、それを使用して自分の鍵ペアで新しい証明書を取得できるため、人々は緊張します。アクセス。これは本当になぜあなたが「更新」しているのか、そしてあなたがそのような行動から本当に何を期待しているのかという疑問を投げかけます。一般に、ユーザーは以前のキーペアにアクセスできなくなったか、暗号解読の進歩に関して弱くなりすぎたため、キーペアを変更する必要があります。その場合、ユーザーは、定義上、以前の秘密鍵に関する知識以外の何かで再度認証される必要があります。
失効は、潜在的な秘密鍵の盗難に起因する損害を封じ込めることを目的とした緊急メカニズムです。上で説明したように、失効と更新は同じことの2つの側面です。失効は、更新を拒否することと同じです。そのため、異常な状況が原因で発生することはまれです。ユーザーにとって複雑にしたくない場合は、キーの盗難を報告しません。 特に、失効には費用がかかる、および/またはユーザーに何らかのブラックマークやその他の否定的な評判が付けられるとは言わないでください。そうでなければ、誰も潜在的な鍵の盗難を報告することはなく、事態はさらに悪化します。
したがって、失効の主なリスクは過少報告です。ただし、誰かが他の誰かの証明書の失効をトリガーできる場合は、過大報告も問題になる可能性があります。 DoS の可能性があります。通常のトリックは、レポーターに責任を持たせ、大規模な攻撃をヒューリスティックに処理することです。
- 秘密鍵の盗難が報告された場合は、報告を行う人が署名し、監査証跡を残してください。
- 短時間に多くの盗難が報告された場合は、アラームをトリガーし、sysadminを起動して、危機管理モードに入ります。
いずれにせよ、秘密鍵が（潜在的に）盗まれた場合、現在の日付でまだ有効であり、対応する公開鍵を含むすべての証明書を取り消す必要があります。期限切れの証明書を取り消す必要はありません。それは確かに期限切れのポイントです：失効情報を小さく保つこと。
失効解除：まあ、そうしないでください。確実に機能しないか、まったく機能しません。あなたは更新することができます：それをするだけです。秘密鍵が実際には盗まれていないという結論に達することができれば、同じ公開鍵で更新することができます。いずれにせよ、失効は緊急メカニズムであり、私たちは調査モードにあります。
（あなたの説明から、あなたは一種の承認メカニズムとして失効を使おうとしているようです。これがうまく終了することはめったにありません。）