views:

558

answers:

3

I'm creating application that will create certificates for users. I want to mark somehow those certificates so that later I can search them in windows user certificate store by following categories:

  • application GUID (or name - I want to know that this cert is for my application)
  • certificate role (administrative certificate or user certificate)
  • user email

I know that for the last one I should use "E = [email protected]" or OID number "1.2.840.113549.1.9.1 = [email protected]" But I don't know which OIDs to choose for application GUID and certificate role.

Or maybe I should use "Key Usage" field?

I don't know if it's important, but certificates will be used to authenticate to my application and to decrypt data in database.

Are there any standard ways to do it ?

A: 

OK, after few hours I came with something like this.

All Certificates will be recognized by Subject field. For Administrator certificate it will look like this:

CN=<My application Name> Administrator,OU=Administrator,OU=<My application Name>,O=<My company Name>

and for users

E=<User email>,CN=<User email>,OU=User,OU=<My application Name>,O=<My company Name>

If someone has better idea, I'm open for suggestions :-)

SeeR
A: 

Hmm... so what I'm thinking is that you plan to issue certificates to each user and you plan to make a different certificate for each application. So if you had 10 users using 3 applications each, you'd be making 30 certificates.

And then the certificate also describes the user's role within the application, and the users's email.

To tell you the truth, I wouldn't put all this information in a certificate. PKI is hard to provision - users generally have difficulties setting up certificates, and reissuing certificates is a pain. Generally, PKI deployment strategies try to minimize the number of certificates that must be issued, balancing that with risk.

The most typical scenario I've seen is that a user is given a single certificate which he uses to identify himself. The certificate includes the user's name, and his email. But it doesn't usually include the user's role or the specific application. Instead, this information is managed on an access control server, that is queried when the user accesses the system. That way, the roles and applications available to the user can be changed without having to reissue the certificate. Products like Active Directory, or Select Access do this sort of thing.

The reason to separate into a separate cetificate per usage is to specifically control some type of risk. For example, if a single user where doing a high-risk operation on one machin and a low risk operation on another, more potentially risky machine, there would be a case to have two certificates (one for each machine) so you could revoke the low-risk certificate without disabling the high risk functions. If you plan to store all the certificates on the same machine, it would be easier to only distribute one certificate per user.

That said - if you still see a need to issue 1 cert per user per application per role, I'd recommend finding a way to jam the application GUID, role and email into the Distinguished name.

You won't get much mileage out of Key Usage or Extended Key Usage - these have very specific value and I doubt that they will convey the information you want to describe. Also, they are used in particular ways by various other applications, so if you need to integrate with other things, that could get tricky.

bethlakshmi
Actually we'll have a smart card per each user for few especially sensitive application which have common "administrators" (i.e our finance director). And I have only two type of certificates for admin and for user. All user certificates are signed by administrator. All other roles are defined in database and signed by administrator also.Exactly as you told - there is a great risk of data to be leaked - that's why we are taking those special steps to secure them.
SeeR
This sounds like an extremely unusual set up given the conventions of PKI. Typically a certificate authority (CA) handles all cerificate signing, and high privilege users use their credentials to operate the CA. This is done to limit risk - the CA can be more heavily protected than an admin cert can be. Also, using the PKI standard concepts lets you make use of certificate revocation techniques - like CRLs and OCSP. Traditional PKI is fairly well vetted for risk management, you might be better off not reinventing the wheel.
bethlakshmi
A: 

Your task is a quite complex task. To solve it the best way is to put on work a little internal certification authority with openssl. Keep in mind that PKI assigned to the entities you referred the following rule:

  1. Distinguished name: it is used to identify the user or entity to witch the certificate is issued. It's no properly correct to use it for identify two different entity within a single certificate: your user and the application. The two entities shuold be identify in two distinct place.

  2. Key Usage is a bit field with 8 digit that defines the usage of the key. Every bit has its predefinited meaning and cannot be used for other purpose.

I suggest to you to:

  1. Put the application GUID as x509 extension. You can assign and personal OIDs to that exension and query for it. If you OIDs is use internally you can utilize whatever value you want. If you plan to distribuite your certificat eyou can obtain your own OID from IANA

  2. Put the mail in the fields subject alternative mail, as suggested by PKI.

  3. For the aministrative or user you can add a second x509 extension or create a tree of certificate. The main CA certificate, the admin CA certificate and the user CA certificate. Every certificate for admin will be signed by the admin CA, every user certificate by the user CA.

Matteo Slaviero