I'm trying to implement a short scale electronic voting application in a domain comprised of no more than 100 clients. System administrator is able to create new election instances and each client is able to cast his vote once for each election.

I do believe that a PKI (e.g. OpenSSL) is necessary here in order to issue a X.509 certificate for each client. Upon registration client will provide a unique identification code to the system so an obvious choice is to store this value in the "subject unique identifier" field which is possible in version 3.

What I'm trying to understand is how will the CA conserves the uniqueness of this field? Does it compare the value supplied for a new certificate with each certificate previously issued? Is this even a logical solution for this problem?


In a typical X.509 PKI implementation, the CA is somewhat heavyweight. Far more than just a special CA certification, running a CA typically implies running a web service to service certificate requests, perhaps an OCSP responder, publishing CRLs regularly, perhaps an SCEP server... This heavyweight notion works well for large enterprises, but somewhat less well for small deployments like your own. Suck it up, though, because there really isn't a good solution for lightweight deployments.

What I'm trying to say is that yes, the "correct" solution in this case is for the CA to check to make sure it hasn't issued a certificate to that user before issuing a new one. This is a fairly annoying extra requirement for a small deployment, but an utterly trivial task next to all the other crazy things a "standard" X.509 deployment is expected to do. I feel your pain, and I know it's not very elegant, but the easiest solution in this case is to just keep a list of all the ID codes served so far and fail if one is resubmitted.

In an ideal world, you'd be able to map the unique identifier you're talking about to a unique key, so re-issues wouldn't be a problem. However, that's not doable with X.509.

PS: I'm assuming here that you in fact want to do what the question title says: assign only a single certificate to each user. If, instead, you only need to prevent double-voting during the election, you could just record the subject unique ID of everyone who's voted already, which would make having more than one certificate for the same unique ID useless. Changing the logic of your voting application is probably easier than changing the logic of whatever CA service issues the certificates.

| improve this answer | |
  • $\begingroup$ Thanks for your response. The ultimate goal is to prevent double voting so your suggestion to change the application logic would have been appropriate if I was able to do it. My problem relates to a course I'm taking titled "Data and Network Security" and we are expected to make use of PKIs. Just to be sure, the "subject unique identifier" is just a title and CA won't check the uniqueness of values associated to this field when issuing a new certificate? $\endgroup$ – mdoust Jan 12 '15 at 22:25
  • $\begingroup$ "The CA" is just a keypair and some flat files. It's nothing without an application that uses that info to sign CSRs. If that application checks the SUI field, that's awesome. If not, well, it's just another number, and the math will work on it just fine, and issue perfectly valid certificates that contain perfectly valid lies. It's all up to whatever application is doing the work. $\endgroup$ – Reid Rankin Jan 12 '15 at 23:03
  • $\begingroup$ If you're talking about using just the openssl command line utility as that system, by default, it requires unique subject fields, even without the use of the special field, but there are no cryptographic guarantees of that, and it's easily disabled in the config file. $\endgroup$ – Reid Rankin Jan 12 '15 at 23:11

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.