8.4 PKI-based AAIs

In the previous chapter, we had a look at public key certificates and PKIs. We also discussed why public key certificates that can be used to authenticate users and customers solve only half of the problems related to e-commerce. In addition to authentication, e-commerce providers must have an opportunity to properly authorize users and customers. Consequently, an e-commerce provider must have an opportunity to attain some authorization information about his or her users and customers.

An X.509v3 public key certificate can convey authorization information about its owner. The information can, for example, be encoded in one of the X.509v3 standard or extension fields. Note, however, that there are at least two reasons why caution should be taken in using X.509v3 public key certificates for conveying authorization information:

The authority that is most appropriate for verifying the identity of a person associated with a public key (i.e., a CA) may not be appropriate for certifying the corresponding authorization information. For example, in a company, the corporate security or human resources departments may be the appropriate authorities for verifying the identities of persons holding public keys, whereas the corporate finance office may be the appropriate authority for certifying permissions to sign on behalf of the company.
The dynamics of the two types of certificates may be fundamentally different. For example, the persons authorized to perform a particular function in a company may vary monthly, weekly, or even daily. Contrary to that, public key certificates are typically designed to be valid for a much longer period of time (e.g., one or two years ). If it becomes necessary to revoke and reissue public key certificates frequently because of changing authorizations (which are encoded into the public key certificates), this may have a severe impact on the performance characteristics of the resulting certificate management scheme.

Recognizing that public key certificates are not always the best vehicle to carry authorization information, the U.S. American National Standards Institute (ANSI) X9 committee developed an alternative approach known as attribute certificates . Meanwhile, this approach has been incorporated into both the ANSI X9.57 standard and the X.509-related standards and recommendations of the ITU-T, ISO/IEC, and IETF.

According to RFC 2828 [32], an attribute certificate is ˜ ˜a digital certificate that binds a set of descriptive data items, other than a public key, either directly to a subject name or to the identifier of another certificate that is a public-key certificate. The latest version of the ITU-T recommendation X.509 also specifies the format of an attribute certificate (currently in version 1). An X.509 attribute certificate also has a subject field, but the attribute certificate is a separate data structure from that subject s public key certificate. A subject may have multiple attribute certificates associated with each of its public key certificates, and an attribute certificate may be issued by a different authority (i.e., the AA) than the authority that issued the associated public key certificate (i.e., the CA).

In essence, an attribute certificate binds one or more pieces of additional information to the certificate owner. As such, the attribute certificate may contain group membership, role, clearance, or any other form of authorization or access control-related information associated with its owner. In conjunction with authentication services, attribute certificates may provide the means to securely transport authorization information to applications and application programs. Consequently, attribute certificates are particularly well suited to control access to system resources, and to implement role-based authorization and access controls accordingly [33]. Note that attribute certificates are conceptually similar to PACs used in SESAME and Microsoft s Windows 2000 operating system.

Anyone can define and register attribute types and use them in attribute certificates. The certificate is digitally signed and issued by an AA. AAs, in turn , are assumed to be certified by CAs, so that a single point of trust ” namely, a trusted public key of a root CA ”can eventually be used to validate the certificates of AAs, other CAs, and end users.

An X.509 attribute certificate contains a sequence of data items and has a digital signature that is computed from that sequence. In addition to the digital signature, an attribute certificate contains the following nine pieces of information:

A version number (typically specifying version 1);
A subject (either a DN or a serial number of an X.509 public key certificate);
An issuer (i.e., the DN of the issuing AA);
An object identifier for the algorithm that is used to sign the attribute certificate;
A serial number (i.e., a unique integer assigned by the issuer);
A validity period specified by a pair of time values (i.e., a start time and an expiration time);
A sequence of attributes describing the subject;
An optional field that may be used to identify the issuer if a DN is not sufficient;
An arbitrary number of optional extensions.

Apart from differences in content, an attribute certificate is managed the same way as a public key certificate. For example, if an organization already runs a directory service for public key certificates and related status information, this service can also be used to distribute attribute certificates.

Also similar to public key certificates, attribute certificates can be used in either the push or pull model:

In the push model, the certificates are pushed from the client to the server.
In the pull model, the certificates are pulled by the server from an online network service (either the certificate issuer or a directory service that is fed by the certificate issuer).

A PKI-based AAI that makes use of attribute certificate infrastructure should support both models, because some applications work best when a client pushes the certificates to the server, whereas for other applications it is more convenient for the client simply to authenticate to the server and for the server to request the client s certificates from a corresponding network service or certificate repository.

There exist a number of standards and standardized procedures to issue, manage, and possibly revoke certificates. This is particularly true for public key certificates, but is also becoming true for attribute certificates. With regard to attribute certificates, however, most security protocols must be modified to make use of them. For example, the SSL and TLS protocols are able to handle public key certificates to address authentication and key exchange; they are not yet able to handle attribute certificates to address authorization. Nevertheless, it would be convenient to have an SSL/TLS client submit a list of relevant attribute certificates to access an intranet server. To make this happen, the SSL and TLS protocols must be extended ^[24] and the extended protocols must be implemented and deployed. Consequently, there is still a long way to go until we see attribute certificates deployed in practice.

^[24] There are some preliminary work specifying the use of attribute certificates in the SSL and TLS protocols.