Storing Certificates in the Domain Name System (DNS)
RFC 4398
Document | Type |
RFC - Proposed Standard
(March 2006; Errata)
Updated by RFC 6944
Obsoletes RFC 2538
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4398 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Margaret Cullen | ||
Send notices to | okolkman@ripe.net |
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.Show full document text