What are Role-based Certificates and Group Certificates? How are they different from normal certificates? How are they different from each other?
Introduction
Typically, a CA will provide PKI certificates to individuals for individual authentication. In this case, the key and the name are both unique.
However, there are some situations where a certificate with the same name is issued to more than one person. While these use cases are not very common, they are essential for some enterprises.
This article explains what these certificates are, what they are for, and how they are different from a typical single-user certificate. The report also describes how these certificates are different from each other.
The two main types of multi-user certificates are:
- Role-based Certificates
- Group Certificates
The purpose of a certificate is to bind a public key to a name. The name can represent a person, a server, a website, or anything else that can be store or control a private key. By issuing a certificate, a Certificate Authority is vouching for the identity of the person or thing holding the private key.
Figure 1 shows the most common use case. A person holds a private key, and the certificate contains the corresponding public key and a name for the user, plus all the metadata related to the key and certificate.
The simple “one user, one name, one key” pattern addresses the vast majority of enterprise use cases, but this simple formula breaks down in some edge cases.
Role-based Certificates
In a business context, a person’s function is often more important than their name. You need approval from the “VP of Finance” rather than “Joan, that nice lady with the beautiful English Bulldog.”
There may be a group of people filling a single business role in larger organizations or some government contexts. When PKI certificates are used for communication or approval in this context, there are some special requirements:
- The primary identity in the certificate should be the user’s role, not their name, but
- we must identify which specific person was approving or communicating in that role for any interaction.
The Role-based Certificate was devised for this specific use case.
Each user in a role generates a unique private key for that role, distinct from their standard user key. They submit a request, and the CA issues a certificate where the Primary Name of the certificate is the user’s role, not their name. The “Subject Alternative Name” field records the user’s name or other unique identifiers.
Using a Role-based Certificate associates an action or approval with a business role rather than an individual. However, it supports non-reputation for transactions by preserving the identifier of the individual acting in that role at that moment.
Group Certificates
There are circumstances where non-repudiation is not needed or where it is not meaningful. For example, you might want to send information about a network vulnerability to a security operations team. In this case, you don’t care who receives the message, as long as they are members of the appropriate group.
Because non-repudiation isn’t necessary, and because the private key is required to decrypt the message, the users must share the private key. Group certificates meet these requirements. Notably, there is only one certificate for the entire group.
Summary
Typically, a certificate contains the name of an individual who owns a unique private key. Role-based Certificates have the name of a role and a unique public key for that particular user. Group certificates are for cases where a few people have access to a single private key.
Because of the feature of asymmetric cryptography, PKI is best suited for individual authentication of a user or a device, and this is where it is typically deployed. Managing group or role certificates can be challenging compared to other access management techniques such as dynamic role or group management based on identities or attributes. However, in some cases, group or role certificates may be the appropriate choice.
If you have questions about Identity Management and PKI and how it fits into your use cases, contact Credentive Security. We are experts in IAM and PKI, and we can guide you to the right solution for your needs.
External References:
Certificate Policy for the Federal Bridge Certificate Authority
