Creating a Certificate Authority
When you create your Certificate Authority certificates you will get
ca.key files. The .crt file is the self-signed public key, and the .key file is the private key file. It's not quite as simple as this. Both files are base64 encoded, and the data underneath is DER encoded. Since you are likely generating X.509 certificates.
Really all you need to understand is that you have a self-signed certificate whose public portion is stored in
ca.crt and the private portion is stored in
ca.key. Remember that you need to keep
ca.key secret All of the big primes, GCD operations and what not is all taken care of by whatever you're using to generate the certificate.
dh2048.pem is not a key, it is the Diffie Hellman parameters for the server. These have nothing to do with your RSA keys, and are only used for when Diffie Hellman is used to connect to your server rather than RSA. The difference between the two can be found in the Key Exchange section of How does SSL/TLS Work? These should have nothing to do with PKI.
crl.pem is generated to be your Certificate Revocation List. Any certificates that you revoke that have been signed with your CA are added to this file. In your OpenSSL configuration (I'm assuming you're configuring OpenSSL, but the idea applies to any configuration) this CRL file will be pointed to. That way it will know where to check for revoked certificates.
Now that you have a Certificate Authority you can begin signing certificates of users for your system. Users do this by generating their own RSA keys
client.key. These keys should be generated whenever a new user is introduced to the system. Again, the .crt is the public portion of the key, and the .key is the private portion. The
client.key must be kept secret by the new user..
To sign the certificate of a new user a Certificate Signing Request (CSR) is made. There is a command in OpenSSL to do this. The request contains the public key of the user to be added, and some other public information needed by the request. The client's certificate will be added to the appropriate authorized lists on the server, and a new signed certificate will be produced. This is what the user will have to import into their browser to visit PKI enabled pages.
There's a great tutorial about Public Key Infrastructure on OpenSSL's site for future reference.
Hopefully this clears some things up. Each variable you've mentioned in the RSA algorithm is generated when you create a certificate. Public certificates don't contain them all, but the private portions generally do. For implementation purposes you won't need to worry about them. Just remember that there is a public and private key pair.
To Answer your 1st Edit
The exchange of CSRs and the resulting certificate is generally performed using some type of secure copy (scp). The server and client must be in communication with each other. The statement that "the client and server authenticate each other" is not really correct. The client wants to be a part of the infrastructure so it must prove its identity to the signing server. As the Certificate Authority, it is its responsibility to verify the identity of the client before processing the CSR. The CSR itself should have all the information needed to verify the identity of the client to be added.
To Answer your 2nd Edit
RSA is only the public key algorithm used for key generation, encryption/decryption, and signing. Public Key Infrastructure is a collection of standards and services required to implement a secure infrastructure. A trusted timing service is most likely one of many requirements. Much like a Certificate Authority is a requirement.