I am using SSL with client authentication. I need to send some extra data while sending the client certificate? Can I send it in the certificate? Can I use the extension fields in certificate for that ? The amount of data to be send is very small. Usually an id and some permissions. This something i should send only initially. Is there any other better way?


While you can stuff about everything you can imagine in ad hoc extensions in a certificate, this is rarely a good idea. In particular because the certificate is signed (by the Certification Authority which issued it), so whatever you put in the certificate has to go through the CA first.

Certificates are about authentication and this does not live well with authorization. Certificates are long-lived entities which cannot be altered on a whim; the only way to "modify" a certificate is to revoke it and issue a new one; not only must this be done by the CA, but it is an inherently asynchronous process: it takes at least several hours, more often several days, to propagate revocation information with any kind of reliability (and some clients do not verify revocation at all...). For anything related to permissions, you want a system which reacts quickly, because when you want to remove an access authorization, you want to remove it now, not next week.

If, in your protocol, the server has something to say to the client, then it seems more appropriate to send the data in the SSL tunnel, after the handshake, as part of the inner protocol (in the same way that HTTPS is HTTP within a SSL tunnel).

| improve this answer | |

As @Tom Leek says, the main purpose of the client's public key certificate (PKC) is authentication. In the PKIX world there is the concept of an Attribute Certificate; these are typically short lived certificates that can be used for authorization purposes. There is also SAML that supports the exchange of authorization information. However, these are complicated protocols and require quite a bit of setting up. If it is a simple client server app, perhaps you could store the user's permissions securely at the server. Once the PKC has been used by the server to authenticate the client you can look up their permissions.

| improve this answer | |

In some cases, offline support is needed, therefore you can't rely on server-client communication for authorization. This means that you have to use certificates as your authorization mechanism, which is not necessarily a bad thing, as long as you don't care about the time it takes to propagate. Also, sometimes propagation speed is not critical so this method will be perfect. Just make sure the client validates the signer of the certificate and you are good to go. I won't be bothering with Attribute Certificates as public key is also a necessity in many cases.

| improve this answer | |
  • I'm not sure how this answers any of the questions asked. What is being propagated? In TLS, a core function of the protocol is for the client to verify the certificate, so I'm unclear on why you mention this as an important thing to check. – schroeder Jun 26 at 9:19
  • The user asked about adding custom attributes to x509 for authorization purposes. Authorization by certificate attributes is good enough in many cases, especially when offline support is needed. The classic client-server authorization scheme is great for online. The answer above is about not using certificates for authorization because of slow propagation times, this is why I wrote that slow propagation is valid. – NOP-MOV Jun 26 at 10:23

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.