2
$\begingroup$

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)

|improve this question
$\endgroup$

migrated from security.stackexchange.com Apr 8 '15 at 9:55

This question came from our site for information security professionals.

  • $\begingroup$ 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. $\endgroup$ – cpast Apr 7 '15 at 22:50
  • $\begingroup$ The "certificate authority, CA," doesn't "generate a signature S from the file F using" just "the functions above". $\;$ See coast's comment. $\;\;\;\;$ $\endgroup$ – user991 Apr 8 '15 at 10:26
  • $\begingroup$ 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. $\endgroup$ – fgrieu Apr 8 '15 at 10:56
1
$\begingroup$

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.

I hope this answers your question. If not use the comments or edit the question.

|improve this answer
$\endgroup$
  • $\begingroup$ I think the "challenge-response test or something" in step 4 is usually the validation and verification of the CSR. CSR's are signed by the private key generated by the user. Unless you've got a crap CA like DigiNotar that makes it "easy" and performs the private key generation for you of course (sigh). $\endgroup$ – Maarten Bodewes♦ Apr 8 '15 at 16:11
  • $\begingroup$ @MaartenBodewes, Thank you, I wasn't sure if CSRs are signed, so I wrote this, but I'll correct it. $\endgroup$ – SEJPM♦ Apr 8 '15 at 16:17
  • 1
    $\begingroup$ Note also that the hash is not directly over the bytes before the signature. The data that needs to be signed is first singled out and - if the CA software was written correctly - canonicalized. For some of the pitfalls, you can read the aging but brilliant X509 style guide. $\endgroup$ – Maarten Bodewes♦ Apr 8 '15 at 16:31
  • 1
    $\begingroup$ When uncertain, look up the standard: "signature is the result of signing the certification request information with the certification request subject's private key" (section 4.2 of RFC 2986, for which the link is strangely broken) $\endgroup$ – Maarten Bodewes♦ Apr 8 '15 at 22:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy