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.
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 . The following figures illustrate how a user ``Some One'' might send an encrypted email to ``firstname.lastname@example.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.
Now the user wishes to encrypt this message, figure 3.2 shows how the encryption function is chosen from the 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.
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.
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.
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.
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.
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.
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.
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  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).