3 Use Cases

This chapter describe important use cases when certificates stored in DNS can be used, and where DNS provides additional advantages over traditional certificate directories such as LDAP.

3.1 Email Client

Electronic mail on the Internet has been an important form of communication for some years now. Various methods of securing electronic mail have been suggested (see our overview in section 2.5). One of the solutions that has seen commercial success is S/MIME. A major problem in using S/MIME to secure mail is locating certificates. Clients often support several methods to locate certificates, e.g., from LDAP servers or from white-pages on the Internet. Most of these services have the drawback of requiring configuration by the user; configuration of the LDAP server hostname, the address to the whitepage service, of the LDAP base objects, etc.

DNS provides a solution to this problem. DNS is already used as a ubiquitous lookup service to look up mail exchangers and their IP addresses, something all email application need to do. Thus DNS is already an integral part of email applications today. The costs of adding support in the application to be able to look up other data are small. And unlike LDAP, additional configuration by the user will not be required.

We have implemented S/MIME functionality in a email client, with certificate fetching from DNS, as a proof of concept. The implementation is based on the extensible mail client Gnus [90]. The following figures illustrate how a user ``Some One'' might send an encrypted email to ``simon@josefsson.org''. Unlike other applications, no prior configuration of the recipient's certificate, of LDAP servers, or similar parameters are required. Signing is possible, but less complicated, so we omit that description.

Figure 3.1 shows a message window. The user has typed in the recipient's address and some text.

Figure 3.1: A sample message

Now the user wishes to encrypt this message, figure 3.2 shows how the encryption function is chosen from the menu.

Figure 3.2: Selecting security functions from menu

The next step, shown in figure 3.3, illustrates how a user selects what encryption technology to use. One of the few alternatives to S/MIME that are in current use, is PGP/MIME. It might be available as an option here. This step might be removed for novice users.

Figure 3.3: Choosing the secure messaging technology to use

Now the client needs to locate public keys used to encrypt the message. There might be a number of sources available: DNS, an LDAP server, a local file, etc. See figure 3.4. This step might also be removed for novice users, by making the client automatically try various sources in order. First try to locate the certificate in DNS, then from preconfigured LDAP servers (if any), then query the user for a filename, etc.

Figure 3.4: Select certificate source

After selecting DNS as the source for certificates, it is possible to chose whom the message should be encrypted to. Normally, you would encrypt a message to the same person you are sending it to, but there may be situations when you need to use a middle-man. The intended receiver of the encrypted message is queried by the client in figure 3.5. This is also a somewhat esoteric feature. It should be removed for novice users. The recipient of the mail should be used as the receiver of the encrypted message.

Figure 3.5: Select encryption key to use

A message can be encrypted to more than one person, and the client queries the user if she wishes to add more recipients in figure 3.6. Likewise, this could be removed for novice users, only using whatever recipients are in the message.

Figure 3.6: Query for more recipients

By answering ``n'' (for ``no'') to the previous question, the client is finished and inserts tags into the message. The mark-up language is called MIME Meta Language (MML), and is used to mark-up MIME articles. It is an SGML/XML based language. Figure 3.7 shows MML tags added to the message.

Figure 3.7: The original message tagged for encryption

The article is now ready to be sent, encrypted. To illustrate what the encrypted content looks like, it is possible to preview the message. This is done by selecting ``Preview'' from the menu shown in figure 3.2. The resulting display is shown in figure 3.8.

Figure 3.8: Encrypted S/MIME message

3.2 Certificate Publishing

The previous email client retrieved certificates from DNS to secure email. Of course, someone needs to publish certificates in DNS for this to be possible. Traditionally, publishing has often been a service of the trusted third party, where the CA provides an LDAP interface to look up certificates (only issued by that CA, naturally). To publish certificates in DNS we have developed a proof-of-concept PKI utility with the following features.

• Generate cryptographic keys (e.g., RSA), generate PKIX certificate requests and sign PKIX certificates.

• Convert PKIX certificates into the LDAP Data Interchange Format (LDIF). This format is used to represent LDAP data in ASCII format.

• Convert data in LDIF format to the ASCII representation of DNS CERT resource records. This data is read by DNS servers.

This allowed us to experiment with the various elements of a PKI, and specifically to experiment with storing PKIX certificates in DNS. Data in DNS is stored in text files using a special syntax, these files are called ``zone files''. The syntax is a simple textual encoding of the various elements in the DNS protocol (see section 4.4.2). To illustrate how a certificate in LDIF format, figure 3.9, is converted into a DNS resource records for storage in a DNS zone file, we show the output in figure 3.10. The process to convert the data does not require any cryptographic operations, only a Base 64 [51] decoding, insertion of a identifying byte sequence [21, section 2.3], and a Base 64 encoding. One of the three integers in the DNS figure are used to identify the data as being a PKIX certificate (the other two are not used).

Figure 3.9: Sample LDIF data

Figure 3.10: Corresponding DNS data