Storing Certificates in the Domain Name System (DNS)
RFC 4398

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

Network Working Group                                       S. Josefsson
Request for Comments: 4398                                    March 2006
Obsoletes: 2538
Category: Standards Track

          Storing Certificates in the Domain Name System (DNS)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Cryptographic public keys are frequently published, and their
   authenticity is demonstrated by certificates.  A CERT resource record
   (RR) is defined so that such certificates and related certificate
   revocation lists can be stored in the Domain Name System (DNS).

   This document obsoletes RFC 2538.

Josefsson                   Standards Track                     [Page 1]
RFC 4398            Storing Certificates in the DNS        February 2006

Table of Contents

   1. Introduction ....................................................3
   2. The CERT Resource Record ........................................3
      2.1. Certificate Type Values ....................................4
      2.2. Text Representation of CERT RRs ............................6
      2.3. X.509 OIDs .................................................6
   3. Appropriate Owner Names for CERT RRs ............................7
      3.1. Content-Based X.509 CERT RR Names ..........................8
      3.2. Purpose-Based X.509 CERT RR Names ..........................9
      3.3. Content-Based OpenPGP CERT RR Names ........................9
      3.4. Purpose-Based OpenPGP CERT RR Names .......................10
      3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
   4. Performance Considerations .....................................11
   5. Contributors ...................................................11
   6. Acknowledgements ...............................................11
   7. Security Considerations ........................................12
   8. IANA Considerations ............................................12
   9. Changes since RFC 2538 .........................................13
   10. References ....................................................14
      10.1. Normative References .....................................14
      10.2. Informative References ...................................15
   Appendix A.  Copying Conditions ...................................16

Josefsson                   Standards Track                     [Page 2]
RFC 4398            Storing Certificates in the DNS        February 2006

1.  Introduction

   Public keys are frequently published in the form of a certificate,
   and their authenticity is commonly demonstrated by certificates and
   related certificate revocation lists (CRLs).  A certificate is a
   binding, through a cryptographic digital signature, of a public key,
   a validity interval and/or conditions, and identity, authorization,
   or other information.  A certificate revocation list is a list of
   certificates that are revoked, and of incidental information, all
   signed by the signer (issuer) of the revoked certificates.  Examples
   are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
   certificates/revocations used by OpenPGP software.

   Section 2 specifies a CERT resource record (RR) for the storage of
   certificates in the Domain Name System [1] [2].

   Section 3 discusses appropriate owner names for CERT RRs.

   Sections 4, 7, and 8 cover performance, security, and IANA
   considerations, respectively.

   Section 9 explains the changes in this document compared to RFC 2538.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [3].

2.  The CERT Resource Record

   The CERT resource record (RR) has the structure given below.  Its RR
   type code is 37.

                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             type              |             key tag           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   algorithm   |                                               /
   +---------------+            certificate or CRL                 /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

   The type field is the certificate type as defined in Section 2.1
   below.