While there are some well-defined implicit certificate schemes, the purpose of this section is to provide a general overview of the participants and processes involved in such schemes.
The first step involved in the implicit certificate scheme is for CA, U and V to use the setup procedure to establish which options to use the scheme with (that is, which elliptic curve parameters to use).
U must generate an ephemeral key pair which is referred to as the private and public key request data.
The CA uses the key deployment procedure to select a key pair, which the CA’s public key (QCA) is then distributed to U and V.
U requests an implicit certificate from the CA. The CA uses the key pair created in the setup phase along with U’s public key request data to create an implicit certificate ICU. The implicit certificate contains public key reconstruction data, which is used later by V during certificate processing. The CA also creates private key reconstruction data, which is used by U to create U’s private key.
The CA sends ICU to U to complete the certificate generation process. U may now convey his public key to V by sending ICU to V.
When V receives ICU, he derives QU′ by using the public key reconstruction data contained in ICU combined with the CA’s public key QCA. With a traditional, explicit certificate, there would now be a validation phase, where QU′ would be compared to QU. Instead, the public key QU′ is considered to be implicitly authenticated, and V can use it to communicate with U.