CISSP試験の準備では、コース資料はCertificate AuthorityとRegistration Authorityの明確な役割を強調しているようです。学習ガイドの説明に従って:
登録機関(RA)は、デジタル証明書を発行する前に、ユーザーの身元を確認する負担でCAを支援します。証明書自体を直接発行するわけではありませんが、認証プロセスにおいて重要な役割を果たし、CAがリモートでユーザーのIDを検証できるようにします。
これはすべて、顧客が実際には見ない内部の機能プロセス/役割ですか? CAベンダーの「Widget Certs、Inc」にアクセスして、Webサイト経由でCSRを送信すると、すべてが単一のエンティティによって処理されるようです。
物事をより混乱させるために...コース資料は後で述べています:
デジタル証明書を取得する場合は、まず何らかの方法でIDをCAに証明する必要があります。このプロセスは登録と呼ばれます。
この登録プロセスは、意図せず混乱を招きます。
多くの場合、RAとCAは同じエンティティです。これを確認する簡単な方法は、一般的なSSL/TLS証明書を使用することです。 Godaddy、Comodo、その他はEV SSL(Extended Validation SSL)証明書を提供します。証明書を提供する企業は、エンドユーザーの情報を検証し、実際に証明書を発行します。
完全な信頼の連鎖を作成するには、RAとCAは別個のエンティティである必要があります。システムではICAOのePassports用のPKIと同様に、このシステムははるかに明白です。文書署名証明書(DSC)、国署名証明書(CSC)、および国内の発行局ごとのサブ証明書(発行者セキュリティ証明書またはISC)があります。 ICAOのPKIで未加工の証明書を検査するときはそれほど明白ではありませんが、一部の国ではこの完全なモデルに従っているようです。
この「完全な」モデルの直接の利点は、失効リストが国の証明書ではなく、特定の発行局の証明書をターゲットにできることです。
ICAOが採用しているPKI構造の詳細については、以下をご覧ください。
https://en.wikipedia.org/wiki/International_Civil_Aviation_Organization_Public_Key_Directory
RAはエンドエンティティ(証明書のサブジェクト)との対話を処理します。これには、IDを確認する物理的なシナリオや、書類の確認が含まれます。彼らは、発行を行うCAに検証ステートメントを提示します。
この違いは、さまざまな古いPKI参照モデルとは異なりますが、通常の自動化されたクラス1 SSL証明書の使用例ではユーザーにはあまりわかりません。企業の設定では、電子パスポートや個人識別カードがこのように分離されていることが一般的です。
いくつかの理由がここに示されています: https://tools.ietf.org/html/rfc4210#page-61
私はあなたのコース資料でCAをCA/RAに置き換え、RAをほとんど技術的ではない影響を持つ組織の分離として理解します。これは、特に登録に関して、ユーザーと対話するCAの一部です。