19.3 ATTRIBUTE CERTIFICATES

Team-Fly

19.3 ATTRIBUTE CERTIFICATES

For many years, the computer and communications industries have argued that the availability of public key certificates is a prerequisite for the evolution and success of electronic commerce. Against this background, many countries have put in place or are about to draft laws and directives for digital or electronic signatures (refer to Section 5.8.3 to get an overview about the legal situation).

Meanwhile, people have started to realize that public key certificates that can be used to properly authenticate users and customers solve only half of the problems related to electronic commerce. In addition to authentication, electronic commerce providers must also have an opportunity to properly authorize users and customers [15]. In fact, one may argue that an electronic commerce provider is generally not interested in authentication information about his or her customers. The only information that is relevant to him or her is whether the customer is authorized to access and make use of the service.[5] Consequently, the electronic commerce provider must have an opportunity to attain some authorization information about his or her users and customers.

As mentioned in Section 19.2, an X.509v3 public key certificate can also 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 [3]:

  1. The authority that is most appropriate for verifying the identity of a person associated with a public key (i.e., the 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.

  2. 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., 1 or 2 years). If it becomes necessary to revoke and reissue public key certificates frequently because of changing authorizations (that 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, 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" [6]. The ITU-T recommendation also specifies X.509 attribute certificates (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 [16]. Note that attribute certificates are conceptually similar to PACs as used in SESAME and Microsoft's Windows 2000 operating system (refer to Section 16.2 for an overview about SESAME and Windows 2000 PACs).

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:

  1. A version number (typically specifying version 1);

  2. A subject (either a DN or a serial number of an X.509 public key certificate);

  3. An issuer (i.e., the DN of the issuing AA);

  4. An object identifier for the algorithm that is used to sign the attribute certificate;

  5. A serial number (i.e., a unique integer assigned by the issuer);

  6. A validity period specified by a pair of time values (i.e., a start time and an expiration time);

  7. A sequence of attributes describing the subject;

  8. An optional field that may be used to identify the issuer if a DN is not sufficient;

  9. 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 on-line network service (either the certificate issuer or a directory service that is fed by the certificate issuer).

A PKI and 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.

[5]Note, however, that authorization requires proper authentication most of the times.


Team-Fly


Internet and Intranet Security
Internet & Intranet Security
ISBN: 1580531660
EAN: 2147483647
Year: 2002
Pages: 144

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net