How does the certificate authority generate a signature F?

E=encrypt(K,M) - is message M encrypted with key K gives encrypted text E

M=decrypt(K,E) - is encrypted text E decrypted with key K gives message M

KCA−pub,KCA−priv - is the private-public key pair for a certificate authority, such as Verisign

D=MD(F) - MD is a message digest function, applied to file F giving digest D

F - is a file containing Bob’s public key, KBob−pub, and email address, EmailBob

How does the certificate authority, CA, generate a signature S from the file F using the functions above, in order to build a certificate for Bob consisting of file F followed by the signature, S?

this is my answer: Firstly, Bob will need to go to a well-known authority (such as Verisign) to prove who he is using a passport or driving license or something to prove it is him. A public-private key is generated paying a fee and receives a certificate consisting of his public key and a statement of his identity (such as name, email, address etc.) all hashed and signed with the private key of the authenticating company.

Anyone can verify his public key belongs to him by comparing it with the signature decoded with the public key of the authenticator.

Signature Encrypt - ED = encrypt (Kca-pub-bob, MD(F)

Decrypt - MD(F) = decrypt (Kca-private-bob, ED)

• I don't get what you're asking. Are you wondering how they sign F? Because they can't do that with the functions you've given; you need a signature algorithm to sign something, and an encryption algorithm does not in general work as a signature algorithm. Commented Apr 7, 2015 at 22:50
• The "certificate authority, CA," doesn't "generate a signature S from the file F using" just "the functions above". $\;$ See coast's comment. $\;\;\;\;$
– user991
Commented Apr 8, 2015 at 10:26
• Question and tentative answer are broken to the point that IMHO they are best abandoned. Some issues: 1) The question is about certificates, which require a signature scheme, which is not achievable by encryption of a hash. $\;$ 2) The two basic steps of proving identity are not distinguished/explained: a) proving tie between identity and public key; b) proving knowledge of the associated private key. $\;$ 3) Certificate authorities typically do not generate a user's public-private key pair; they issue a certificate for a public key.
– fgrieu
Commented Apr 8, 2015 at 10:56

As far as I understand the question, you ask how a (client-)certificate is issued and generated.

Normally this works like this:

1. Get an account at the page of the CA. (this is important in later steps)
2. Validate your identity against the CA, f.ex. using documents like driver-license or passport. Your account will then be listed as "verified as owned by XYZ"
3. Then you'll create a CSR (certificate-signing-request). This is basically an unsigned X.509 certificate, containing all relevant data about you (=name and your public key)
4. You send the CSR over to the CA. They will check the your signature on the CSR to make sure you own the private key associated with the public key. They will also validate that the data in the CSR matches with the data they verified about you.
5. Now they know that this request is valid. So they'll form a X.509 certificate by taking your CSR and adding their data (where to get CRLs from, validility period, the CA-data,...). Now the certificate is signed by them and the certificate is send back to you. The hash is not stored (as far as I know) and just an intermediate value.

As a formula this would look like this: $Cert=F||S_{CA}(SHA256(F))$. Where $S_{CA}(X)$ means the signature of the CA on X.