search CA for someone's public key

Question

do CAs offer service wherein an application can request someone's public key?

i am trying to do this but i am unsure if it is correct (suggestions of better ways to do it will be most appreciated):

1. someone with a certificate from a CA and is an authorized user in my application enters data to a web page (in a form)
2. his input data are saved to mysql fields
3. application (thru php and openssl) hashes and signs that data into a signed message digest *edited: 3: application allows submitting user to hash and sign that data into a signed message digest *
4. signed message digest is also saved into same mysql table row of #2 (?into a binary field?)
5. application viewers need to be assured that this row of data came from same person in #1
6. application (thru php and openssl) re-hashes data using the same hashing algorithm used in #3 and #1's public key
7. if hashes don't match, something got tampered and viewer is alerted

questions: should i have another field to accept #1's public key and save it with the data and the signed message digest as well? or can i just ask the CA for the public key of person in #1? (by passing to the CA the certificate serial number which application saved earlier with the data and signed digest)

or should i just save the whole certificate itself (from which the public key can be extracted anyway) even if the data storage requirement will be larger than if the public key alone was saved)? in that case, should i save the certificate to a blob mysql field?

thanks for any feedback or leads.

matsakaw

@thomas: thanks for the clarification on role of CA and on certificate-based-authentication. sorry for my step #3 wording that wrongly implied it will be the application that will sign the data.

@kiBytes and @el viejo: i edited my question.

i was thinking the application will allow the submitting user to hash and sign the data he is submitting into a signed message digest.

i was thinking of the application allowing the execution of these (client-side) commands: to allow logged-user to sign: $ openssl dgst -sha256 -sign logged-user.key -out in.txt.sha256 in.txt

to allow any viewer to verify: $ openssl dgst -sha256 -verify signer-pub.pem -signature in.txt.sha256 in.txt

@el viejo: thanks, i will read on time stamp servers as suggested.

thanks also to everyone else replying. your replies are very much appreciated.

Answer 1

As a general case, no, CA don't let people search for certificates by public key. In fact, they don't let people search for certificates at all, because the point of certificates is precisely to avoid any kind of searching. The CA has been designed to be, possibly, completely offline, thus unreachable by anybody.

When viewers verify a signature, they use the public key, and then gain confidence that the owner of the corresponding private key signed the message. Who is that owner ? That's the job of the certificate to tell that. The certificate is a verifiable assertion that a name and a public key live together.

In your case, from clients' point of view, there is no signature, no hash, nothing; there is only your server which says "this is good" or "this is not good" on a data element which is also provided by your server. How you manage things internally is completely opaque. In that sense, as long as you want things to be that way, then signatures are completely useless. Signatures make sense only if you can, at least potentially, show them to third parties (say, to a judge in case of litigation). And since a signature only proves things with regards to the public key, not anything else, you need to keep the certificates around, because certificates then link public keys to the useful concept of identities (when you sue, you sue somebody, not a public key).

Furthermore, in your description, your server appears to be the one who signs, not the actual certificate owner. So even if you keep a signature around, it would be your signature, not that of the initial user who wrote the data in step 1.

The important concept here is that when your server authenticates a client "with a certificate", this is authentication only. It does not prove to third parties that the said client really wrote the data you store. In fact, even if you keep a complete copy of all involved IP packets, this proves only that at some unspecified past date, that client connected once to your server, but it says nothing about the data which was sent through that connection. Authentication is proof only for who is doing the authentication, i.e. the server, but is not verifiable afterwards. If that point seems unclear to you, then you must read it again, and again, until you grasp it; you cannot do any useful work with certificates if this does not seem obvious to you.

Answer 2

I believe you missed one step, int the step number 3 you need the user to sign the hash with its private key. And I believe that this is a task an user must do by itself (or by using javascript or something alike so that his private key doesn't end up in your platform (or any other).

If you do this, then, it is easier to make the user paste its public key part inside a form in its user profile so you can use it easily ( there are services like bitbucket or github for example than make this ).

Answer 3

You can not generate the signature or any part of it such as the digest. To do so, you must have the user's private key, which would invalidate its privacy.

The user submitting the data must generate the digital signature containing the digest using their private key. The signature will contain the verifiable public portion of the user's certificate.

Anyone viewing the data can authenticate it with two steps: 1) decrypt the digest in the signature using the public key also contained in the signature and compar that result to a digest of the data created by the viewer; 2) Verify the certificate containint the public key was issued by the identified CA to the entity claiming authorship. Several further details can be included in a signature. The strongest signatures contain a timestamp that confirms the signature was created at a certain time and date when the certificate was confirmed as valid by the timestamping server.

The above is the standard description of how to use PKI to disceminate authenticated data.

In your case, I would recomend that the user be prompted to submit a digitally signed file and that your application validate the signature. In attempting to capture the signature in a seperate process as part of your application, you are taking on unnecessasry work and diverging from widely supported norms. Also, you are outside the realm of standard solutions. HTML and JavaScript, for example, provide no assitance. I believe it is possible to build a client-side Java app to accept the data from the user and then prompt for the certificate to perform the signing operation prior to uploading the signed document to your server. Though I have never seen such an implementation, OWASP provides relevant code to utilize the Java Cryptographic Architecture. This is possible, but not the approach I would recomend.

Digitally signing documents using x.509 PKI certificates is supported by many applications including Microsoft Office. In many use cases, requiring that the user first digitally sign a document is not a large burden.

Some third-parties offer solutions that might be useful to you. You may want to look into solutions offered by Adobe or Arx.

Answer 4

This sounds a lot like the LDAP directory services VeriSign (now Symantec) operates for their client ID products where you can retrieve the certificates given the email address or other attributes to search for (at ldap://directory.verisign.com). To reduce the risk of a man-in-the-middle-attack modifying the LDAP responses you would use a TLS secured connection, making sure that the LDAP server cert provided is the expected one.