Authorization certificate

Last updated

In computer security, an attribute certificate, or authorization certificate (AC) is a digital document containing attributes associated to the holder by the issuer. [1] 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.

Contents

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. [2]

Comparison of attribute and public key certificates

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.

Usage

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.

Contents of a typical attribute certificate

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.

Benefits

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.

See also

Related Research Articles

X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 was first approved in 1988. The directory services were developed to support requirements of X.400 electronic mail exchange and name lookup. The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) were partners in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO/IEC identification.

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

<span class="mw-page-title-main">Certificate revocation list</span> A list of revoked digital certificates

In cryptography, a certificate revocation list (CRL) is "a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted". CRLs are no longer required by the CA/Browser forum, as alternate certificate revocation technologies are increasingly used instead. Nevertheless, CRLs are still widely used by the CAs.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

The Domain Name System Security Extensions (DNSSEC) are a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

<span class="mw-page-title-main">Hardware security module</span> Physical computing device

A hardware security module (HSM) is a physical computing device that safeguards and manages secrets, performs encryption and decryption functions for digital signatures, strong authentication and other cryptographic functions. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server. A hardware security module contains one or more secure cryptoprocessor chips.

Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed. The process employs the use of a cryptographic hash to validate authenticity and integrity. Code signing was invented in 1995 by Michael Doyle, as part of the Eolas WebWish browser plug-in, which enabled the use of public-key cryptography to sign downloadable Web app program code using a secret key, so the plug-in code interpreter could then use the corresponding public key to authenticate the code before allowing it access to the code interpreter's APIs.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

Simple Certificate Enrollment Protocol (SCEP) is described by the informational RFC 8894. Older versions of this protocol became a de facto industrial standard for pragmatic provisioning of digital certificates mostly for network equipment.

In cryptography Privilege Management is the process of managing user authorisations based on the ITU-T Recommendation X.509. The 2001 edition of X.509 specifies most of the components of a Privilege Management Infrastructure (PMI), based on X.509 attribute certificates (ACs). Later editions of X.509 have added further components to the PMI, including a delegation service and interdomain authorisation.

Resource Public Key Infrastructure (RPKI), also known as Resource Certification, is a specialized public key infrastructure (PKI) framework to support improved security for the Internet's BGP routing infrastructure.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

JSON Web Token is a proposed Internet standard for creating data with optional signature and/or optional encryption whose payload holds JSON that asserts some number of claims. The tokens are signed either using a private secret or a public/private key.

References

  1. ↑ R. Shirey (August 2007). Internet Security Glossary, Version 2. Network Working Group. doi: 10.17487/RFC4949 . RFC 4949.Informational.
  2. ↑ Farrell, S.; Housley, R. "An Internet Attribute Certificate Profile or Authorization". RFC 3281.{{cite journal}}: Cite journal requires |journal= (help)
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.