7.2 Public key certificates


7.2    Public key certificates

There are several types and formats of public key certificates. All of them contain at least the following three pieces of information:

  • A public key;

  • Some naming information;

  • One or more digital signatures.

The public key is the raison d tre for the public key certificate in the first place.

The naming information is used to identify the owner of the public key certificate, such as his or her name. In the past, there has been some confusion about the naming scheme that is appropriate for the global Internet. For example, the ITU-T recommendation X.500 introduced the notion of a distinguished name (DN) that can be used to uniquely identify an entity (i.e., a public key certificate owner) in a globally unique namespace. There are other examples of globally unique namespaces on the Internet, the most prominent being the DNS. The existence and usefulness of globally unique namespaces, however, has also been challenged in the past (e.g., [10]). Most important, the Simple Distributed Security Infrastructure (SDSI) architecture and initiative [11] have evolved from the argument that a globally unique namespace is not appropriate for the global Internet, and that logically linked local namespaces provide a simpler and more realistic model [12]. As such, work on SDSI inspired establishment of a Simple Public Key Infrastructure (SPKI) WG within the IETF. The WG was tasked with producing a certificate infrastructure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple, and extensible a way as possible. It published a pair of experimental RFC documents [13, 14] before its activities were abandoned in 2001.

Finally, the digital signature(s) is (are) used to attest to the fact that the other two items (i.e., the public key and the naming information) actually belong together. This part of a public key certificate turns the certificate into something useful.

As of this writing, there are two practically relevant formats for public key certificates [4] : Certificates used for Pretty Good Privacy (PGP) or OpenPGP (i.e., PGP certificates) and certificates that conform to the ITU-T recommendation X.509 (i.e., X.509 certificates) and are used for many contemporary security protocols and applications. They use different certificate formats and trust models. [5]

7.2.1    PGP certificates

PGP is used and deployed for secure messaging on the Internet. It refers to both a standard and a software package. As mentioned above, PGP uses a special certificate format and a cumulative trust model.

The distinguishing feature of the PGP certificate format is that it allows potentially multiple user identities (user IDs) and signatures per certificate. What this basically means is that a PGP certificate is issued for a public key and that multiple user IDs can be associated with this key. Furthermore, multiple signatures can certify the fact that a specific user ID is associated with the public key. Consequently, there is a one-to-many relationship between the public key of a PGP certificate and the user IDs associated with it, and there is another one-to-many relationship for each of these user IDs and the signatures that are associated with it. Contrary to that, we will see below that the X.509 certificate format is much simpler. It allows only one user ID associated with a public key and one signature that certifies this association. The situation is illustrated in Figure 7.1. The left side illustrates the structure of a PGP certificate, whereas the right side illustrates the structure of an X.509 certificate.

click to expand
Figure 7.1: The structures of PGP and X.509 certificates.

Technically spoken, a PGP certificate is a data structure that includes the following fields:

  • Version number: This field is used to identify which version of PGP was used to create the public key pair (of which the public key is associated with the certificate).

  • Public key: This field is used to hold the public key and a corresponding algorithm identifier (i.e., RSA, Diffie-Hellman, or DSS).

  • Certificate owner information: This field is used to hold identity information about the certificate owner and the holder of the corresponding private key. As discussed above, it may include several identities and signatures.

  • Self-signature: This field is used to hold a self-signature for the certificate. As its name suggests, a self-signature is generated by the certificate owner using the private key that corresponds to the public key associated with the certificate. Note that X.509 certificates normally do not include self-signatures (they include self-signatures only in the case of root CA certificates).

  • Validity period: This field is used to determine the start and expiration date and time of the certificate. As such, it specifies the certificate s validity period or lifetime.

  • Preferred encryption algorithm: This field is used to identify the encryption algorithm of choice for the certificate owner (e.g., CAST, IDEA, or 3DES).

One may think of a PGP certificate as a public key with one or more labels attached to it. For example, several user identifiers (user IDs) may be attached to a PGP certificate or public key, each of which contains different means of identifying the certificate owner (e.g., the certificate owner s name and corporate e-mail address or the certificate owner s first name and private e-mail address). Typically, a user ID includes the name of the user and one of his e-mail addresses put in angle brackets (< >), such as Rolf Oppliger < rolf.oppliger@esecurity.ch > . Also, one or several photographs may be attached to a PGP certificate or public key to simplify visual authentication processes. Again, this is a feature that is not known and does not exist in standard X.509 certificates.

In addition to their specific format, PGP certificates use a cumulative trust model. This basically means that there is no central CA that is trusted by every user, but that every user can decide for himself or herself whom to trust. More specifically , the association of a user ID with a PGP certificate or public key may be testified by one or several people, each of them generating a digital signature that is attached to the corresponding user ID in the PGP certificate. In fact, many people may sign a PGP certificate to attest to their own assurance that the public key included in the certificate actually belongs to the claimed user ID. The more people who sign a certificate, the more likely it will be trusted by somebody else. The resulting certification and trust infrastructure is highly distributed. It is sometimes also called a web of trust . The PGP web of trust is discussed in many references and books, including, for example, Chapter 8 of [4].

7.2.2    X.509 certificates

The ITU-T recommendation X.509 specifies both a certificate format and a certificate distribution scheme [8]. It was first published in 1988 as part of the X.500 directory recommendations. The X.509 version 1 (X.509v1) format was extended in 1993 to incorporate two new fields, resulting in the X.509 version 2 (X.509v2) format. In addition, and as a result of attempting to deploy certificates within the global Internet, X.509v2 was revised to allow for additional extension fields. The resulting X.509 version 3 (X.509v3) specification was officially released in June 1996. Meanwhile, the ITU-T recommendation X.509 has been approved by the ISO/IEC JTC1 [9].

The format of an X.509v3 certificate is specified in abstract syntax notation one (ASN.1 [6] ) and the resulting certificates are encoded according to specific encoding rules [7] to produce a series of bits and bytes suitable for transmission. Anyway, an X.509 public-key certificate contains the following 10 data items:

  1. A version number (identifying version 1, version 2, or version 3);

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

  3. An object identifier (OID) that specifies the signature algorithm that is used to sign the public key certificate;

  4. The DN of the issuer (i.e., the name of the CA that actually signed the certificate);

  5. A validity period that specifies an interval in which the certificate is valid;

  6. The DN of the subject (i.e., the owner of the certificate);

  7. Information related to the public key of the subject (i.e., the key and the OID of the algorithm);

  8. Some optional information related to the issuer (defined for versions 2 and 3 only);

  9. Some optional information related to the subject (defined for versions 2 and 3 only);

  10. Some optional extensions (defined for version 3 only). All three versions of X.509 certificates contain the items 1 through 7 listed. Only version 2 and version 3 certificates may additionally contain items 8 and 9, whereas only version 3 may contain item 10.

The trust model employed by ITU-T X.509 is hierarchical. 8 This basically means that a user must define a number of root CAs and corresponding root certificates (i.e., certificates that are trusted by default) from which trust may extend. Typically, a root certificate is self-signed, meaning that the root CA has issued its own certificate (i.e., the subject and issuer are identical). Note that from a theoretical point of view, self-signed certificates are not particularly useful. Anybody can claim something and issue a certificate for this claim. Consequently, a self-signed certificate basically says here is my public key; trust me.

Having established a number of root CAs and corresponding root certificates, a user can try to find a certification path (or certification chain ) that leads from a root certificate to a leaf certificate (i.e., a certificate that is issued for a user or system). Formally speaking, a certification path or chain is defined in a tree or wood of CAs (root CAs and intermediate CAs) and refers to a sequence of one or more certificates that lead from a root certificate to a leaf certificate. Each certificate certifies the public key of its successor. Finally, the leaf certificate is typically issued for a person or a system. Let s assume that CA root is a root certificate and B is an entity for which a certificate must be verified . In this case, a certification path or chain with n intermediate CAs (i.e., CA 1 , CA 2 , . . ., CA n ) would look as follows :

CA root << CA 1 >>

   CA 1 << CA 2 >>

   CA 2 << CA 3 >>

                           . . .

CA n-1 << CA n >>

       CA n << B >>

The simplest model one may think of is a certification hierarchy representing a tree with a single root CA. However, more general structures and graphs (including mutually certifying CAs, cross-certificates, and multiple root CAs) are possible, as well. A PKI structure or graph among multiple CAs generally provides one or more certification paths between two entities.

ITU-T X.509 can be used in many ways. Consequently, every nontrivial group of users who want to work with X.509 certificates has to produce a profile that nails down the features that are left undefined in X.509. The difference between a specification (i.e., ITU-T X.509) and a profile is that a specification does not generally set any limitations on which combinations can and cannot appear in various certificate types, whereas a profile sets various limitations, for example, by requiring that signing and confidentiality keys be different. Many profiling activities are currently going on with regard to the legislation of digital and electronic signatures. We overview and address the profiling activities of the IETF next .

[4] There are also other certificate formats, such as the format for certificates that conform to the Wireless Transport Layer Security (WTLS) specifications that is used to secure the Wireless Application Protocol (WAP). Due to the uncertain future of WAP and WTLS, we don t look at these certificates in this book.

[5] The term trust model refers to the set of rules a system or application uses to decide whether a certificate is valid. In the direct trust model, for example, a user trusts a public key certificate because he or she knows where it came from and considers this entity as trustworthy. In addition to the direct trust model, there is a cumulative trust model (employed, for example, by PGP certificates) and a hierarchical trust model (employed, for example, by ITU-T X.509 certificates).

[6] ASN.1 is officially specified in ITU-T X.680 and ISO/IEC 8824.

[7] There are three standardized encoding rules, namely the basic encoding rules (BER), the distinguished encoding rules (DER), and the packet encoding rules (PER). Obviously, anybody can specify and use his or her own set of encoding rules.




Security Technologies for the World Wide Web
Security Technologies for the World Wide Web, Second Edition
ISBN: 1580533485
EAN: 2147483647
Year: 2003
Pages: 142
Authors: Rolf Oppliger

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