Certificate issuance proceeds as follows. Alice generates her own key
pair and sends the public key to an appropriate CA with some proof of
her identification. The CA checks the identification and takes any
other steps necessary to assure itself that the request really did come
from Alice, and then sends her a certificate attesting to the binding
between Alice and her public key, along with a hierarchy of
certificates verifying the CA's public key. Alice can present this
certificate chain whenever desired in order to demonstrate the
legitimacy of her public key.
Since the CA must check for proper identification, organizations will
find it convenient to act as a CA for its own members and employees.
There will also be CAs that issue certificates to unaffiliated
Different CAs may issue certificates with varying levels of
identification requirements. One CA may insist on seeing a driver's
license, another may want the certificate request form to be notarized,
yet another may want fingerprints of anyone requesting a certificate.
Each CA should publish its own identification requirements and
standards, so that verifiers can attach the appropriate level of
confidence in the certified name-key bindings.
An example of a certificate-issuing protocol is Apple Computer's Open Collaborative Environment (OCE). Apple OCE users can generate a key pair and then request and receive a certificate for the public key; the certificate request must be notarized.