According to RFC 2828, a public key certificate is "a digital certificate that binds a system entity's identity to a public key value, and possibly to additional data items" [6]. As such, it is a digitally signed data structure that attests to the ownership of a public key.

There are several types and formats of public key certificates, but 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 piece of information for which the public key certificate has been issued at first place. Without a public key, a public key certificate does not make a lot of sense (unless it is used to carry some other attributes associated with the certificate owner).

The naming information is used to identify the owner of the public key certificate, such as his or her name (e.g., "Rolf Oppliger"). 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 a globally unique namespace, however, has also been challenged in a couple of research papers (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 the 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 early in 2001.

Finally, the digital signatures 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[2]: PGP certificates and X.509 certificates. A 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 its user IDs, 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, the X.509 certificate format is much simpler. In general, it allows only one user ID associated with a public key[3] and one signature that attests to and certifies this association. The situation is illustrated in Figure 19.1. The left side illustrates the structure of a PGP certificate, whereas the right side illustrates the comparably simpler structure of an X.509 certificate. Note that the X.509 certificate format can be considered to be special case of a PGP certificate, namely, one with one user ID and one signature.

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

As of this writing, ITU-T X.509 public key certificates are widely deployed on the Internet. In fact, 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 the abstract syntax notation one (ASN.1) and the resulting certificates are typically encoded according to specific encoding rules[4] to produce a series of bits and bytes suitable for transmission in computer networks and distributed systems. An X.509 public-key certificate contains a sequence of data items and has a digital signature computed by a CA on that sequence. In addition to the signature, all three versions contain items 1 through 7 listed below. Only version 2 and version 3 certificates may additionally contain items 8 and 9, whereas only version 3 may contain item 10:

  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 specifying 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).

ITU-T X.509 can be used in many ways. Consequently, every nontrivial group of users who want to work with X.509 public key certificates has to produce a profile which nails down many features which 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 what 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.

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

[3]Multiple user IDs can be simulated using the AltSubjectName field that can be used to hold alternative naming information related to the subject.

[4]There are many encoding rules. Examples include the basic encoding rules (BER) and the distinguished encoding rules (DER).


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

Similar book on Amazon

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