In computer security, an attribute certificate, or authorization certificate (AC) is a digital document containing attributes associated to the holder by the issuer. When the associated attributes are mainly used for the purpose of authorization, AC is called authorization certificate. AC is standardized in X.509. RFC 5755 further specifies the usage for authorization purpose in the Internet.
The authorization certificate works in conjunction with a public key certificate (PKC). While the PKC is issued by a certificate authority (CA) and is used as a proof of identity of its holder like a passport, the authorization certificate is issued by an attribute authority (AA) and is used to characterize or entitle its holder like a visa. Because identity information seldom changes and has a long validity time while attribute information frequently changes or has a short validity time, separate certificates with different security rigours, validity times and issuers are necessary.[1]
An AC resembles a PKC but contains no public key because an AC verifier is under the control of the AC issuer, and therefore, trusts the issuer directly by having the public key of the issuer preinstalled. This means that once the AC issuer's private key is compromised, the issuer has to generate a new key pair and replaces the old public key in all verifiers under its control with the new one.
The verification of an AC requires the presence of the PKC that is referred as the AC holder in the AC.
As with a PKC, an AC can be chained to delegate attributions. For example, an authorization certificate issued for Alice authorizes her to use a particular service. Alice can delegate this privilege to her assistant Bob by issuing an AC for Bob's PKC. When Bob wants to use the service, he presents his PKC and a chain of ACs starting from his own AC issued by Alice and then Alice's AC issued by the issuer that the service trusts. In this way, the service can verify that Alice has delegated her privilege to Bob and that Alice has been authorized to use the service by the issuer that controls the service. RFC 3281, however, does not recommend the use of AC chains because of the complexity in administering and processing the chain and there is little use of AC in the Internet.
To use a service or a resource that the issuer of an AC controls, a user presents both the PKC and the AC to a part of the service or resource that functions as an AC verifier. The verifier will first check the identity of the user using the PKC, for example, by asking the user to decrypt a message encrypted by the user's public key in the PKC. If the authentication is successful, the verifier will use the preinstalled public key of the AC issuer to check the validity of the presented AC. If the AC is valid, the verifier will check whether or not the PKC specified in the AC matches the presented PKC. If it matches, the verifier will check the validity period of the AC. If the AC is still valid, the verifier can perform additional checks before offering the user a particular level of service or resource usage in accordance to the attributes contained in the AC.
For example, a software developer that already has a PKC wants to deploy its software in a computing device employing DRM like iPad where software can only be run in the device after the software has been approved by the device manufacturer. The software developer signs the software with the private key of the PKC and sends the signed software to the device manufacturer for approval. After authenticating the developer using the PKC and reviewing the software, the manufacturer may decide to issue an AC granting the software the basic capability to install itself and be executed as well as an additional capability to use the Wi-Fi device following the principle of least privilege. In this example, the AC does not refer to the PKC of the developer as the holder but to the software, for example, by storing the developer's signature of the software in the holder field of the AC. When the software is put into the computing device, the device will verify the integrity of the software using the developer's PKC before checking the validity of the AC and granting the software access to the device functionalities.
A user may also need to obtain several ACs from different issuers to use a particular service. For example, a company gives one of its employees a company-wide AC that specifies engineering department as the work area. To access engineering data, however, the employee also needs a security clearance AC from the head of the engineering department. In this example, the resource of engineering data needs to be preinstalled with the public keys of both the company-wide and the engineering department AC issuers.
Version: the version of the certificate.
Holder: the holder of the certificate.
Issuer: the issuer of the certificate.
Signature algorithm: the algorithm by which the certificate is signed.
Serial number: the unique issuance number given by the issuer.
Validity period: the validity period of the certificate.
Attributes: the attributes associated to the certificate holder.
Signature value: the signature of the issuer over the whole data above.
Using attribute certificate, the service or resource host does not need to maintain an access control list that can potentially be large or to always be connected to a network to access a central server like when using Kerberos. It is similar to the idea of capabilities in which the permission (or permissions) to use a service or resource is not stored in the service or resource itself but in the users using a tamper resistance mechanism.