Chapter 7: Certificate Management and Public Key Infrastructures

In Chapter 4, we introduced public key cryptography and the notion of public key certificates. In Chapters 5 and 6, we then used these certificates in cryptographic security protocols without addressing the question on how to manage them and how to establish and operate a public key infrastructure (PKI). These questions are addressed in this chapter. More specifically , we introduce the topic in Section 7.1, focus on public key certificates in Section 7.2, overview and discuss the work of the relevant IETF Working Group (i.e., IETF PKIX WG) in Section 7.3, address certificate revocation in Section 7.4, elaborate on certificates for the WWW in Section 7.5, and conclude with some final remarks in Section 7.6. Further information about the topic can be found in [1 “ 3], Chapter 13 of [4], and Chapter 19 of [5]. Also, note that the topic is very dynamic and that you are invited to use the sources for further information mentioned throughout the chapter to update yourself periodically.

7.1  Introduction

According to RFC 2828 [6], the term certificate refers to ˜ ˜a document that attests to the truth of something or the ownership of something. Historically, the term was coined and first used by Loren M. Kohnfelder to refer to a digitally signed record holding a name and a public key [7]. As such, the certificate attests to the legitimate ownership of a public key and attributes a public key to a principal, such as a person, a hardware device, or any other entity. As discussed in Chapter 4, the resulting certificates are called public key certificates. They are used by many cryptographic security protocols, such as IPsec and IKE, SSL/TLS, and S/MIME. According to RFC 2828 [6], a public key certificate is a special type of digital certificate, namely, one ˜ ˜that binds a system entity s identity to a public key value, and possibly to additional data items. As such, it is a digitally signed data structure that attests to the ownership of a public key.

More generally and in accordance with RFC 2828, a certificate can be used not only to attest to the legitimate ownership of a public key (in the case of a public key certificate), but also to attest to the truth of any property attributable to a certificate owner. This more general class of certificates is commonly referred to as attribute certificates and will be discussed in the following chapter. In short, the major difference between a public key certificate and an attribute certificate is that the former includes a public key (i.e., the public key that is certified), whereas the latter includes a list of attributes (i.e., the attributes that are certified). In either case, the certificates are issued (and possibly revoked ) by authorities that are recognized and trusted by some community of users. In the case of public key certificates, these authorities are called certification authorities (CAs). ^[1] In the case of attribute certificates, however, these authorities are called attribute authorities (AAs).

In short, a PKI consists of one (or several) CA(s). According to RFC 2828 [6], a PKI is ˜ ˜a system of CAs that perform some set of certificate management, archive management, key management, and token management functions for a community of users that employ public key cryptography. ^[2] Another way to look at a PKI is as an infrastructure that can be used to issue, validate, and revoke public keys and public key certificates. As such, a PKI comprises a set of agreed-upon standards, CAs, structures among multiple CAs, methods to discover and validate certification paths, operational and management protocols, interoperable tools, and supporting legislation. In the past couple of years , PKIs have experienced a hype and many companies and organizations have announced their intentions to provide certification services to the general public. Unfortunately, only a few of these companies and organizations have succeeded and actually provide such services that can be taken seriously.

Many standardization bodies are working in the field of public key certificates and PKIs. Most importantly, the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) has released and is periodically updating a recommendation that is commonly referred to as ITU-T X.509 [8], or X.509 in short. Meanwhile, the ITU-T recommendation X.509 has also been adopted by many other standardization bodies, including, for example, the ISO/IEC JTC1 [9]. Furthermore, many standardization bodies work in the field of profiling ITU-T X.509 for specific application environments. ^[3] For example, there is an IETF WG (i.e., the IETF PKIX WG) that is chartered to profile the use of ITU-T X.509 on the Internet. Due to the existence of this IETF WG, the W3C is not actively working in this field.

^[1] In the past, CAs were often called trusted third parties (TTPs). This is particularly true for CAs that are operated by government bodies.

^[2] The last part of the sentence is particularly important, because in the past many people felt like having to enter the field of PKIs without having a legitimate reason to do so (if, for example, they are not using public key cryptography in the first place).

^[3] To profile ITU-T X.509 ”or any general standard or recommendation ”basically means to fix the details with regard to a specific application environment. The result is a profile that elaborates on how to use and deploy ITU-T X.509 in the environment.