Storing Certificates in the Domain Name System (DNS)
obsoleted by
- rfc-4398 — Storing Certificates in the Domain Name System (DNS)
Extracted elements (20)
DNS implementations are optimized for small transfers (typically under 512 bytes including overhead). It is advisable to minimize certificate sizes stored in DNS by using fewest optional fields and shortest variable-length field values.
Certificate CERT RRs should be stored under a domain name related to their subject (the entity controlling the corresponding private key); certificate revocation list CERT RRs should be stored under a domain name related to their issuer.
For the URI private certificate type (253), the certificate portion of the CERT RR MUST begin with a null-terminated URI, and the URI SHOULD be such that a retrieval from it will lead to documentation on the format of the certificate.
If the certificate key is not applicable to an algorithm defined for DNS security, the algorithm field MUST BE zero and the tag field is meaningless and SHOULD BE zero.
X.509 certificates conforming to the IETF PKIX profile SHOULD be indicated by the PKIX type (1), not the OID private type (254).
Certificate type values: 0=reserved, 1=PKIX (X.509), 2=SPKI, 3=PGP, 4-252 available for IANA assignment, 253=URI private, 254=OID private, 255-65534 available for IANA assignment, 65535=reserved.
For PGP CERT RRs, if the User ID includes an RFC 822 email address (e.g., 'Leslie Example <Leslie@host.example>'), the CERT should be stored under the standard email-to-domain-name translation (e.g., leslie.host.example).
For X.509 CERT RRs, the recommended owner name priority order is: (1) domain name in the certificate, (2) reverse DNS of IP address, (3) domain name from a URI in the certificate, (4) character string name treated as PGP, (5) DN mapped per RFC 2247.
Four X.500 OIDs are defined for use with PKIX CERT RRs: id-at-userCertificate (0x03 55 04 24), id-at-cACertificate (0x03 55 04 25), id-at-authorityRevocationList (0x03 55 04 26), and id-at-certificateRevocationList (0x03 55 04 27).
The CERT resource record (RR) has RR type code 37 and contains a type field (certificate type), a key tag field (16-bit), an algorithm field (same semantics as in KEY and SIG RRs), and a variable-length certificate or CRL field.
The key tag field is a 16-bit value computed for the key embedded in the certificate as specified in DNSSEC (RFC 2535), used as an efficiency measure to identify which CERT RRs may apply to a particular key. The key must be transformed to KEY RR public key format before computing the tag.
The OID private type (254) indicates a private format certificate specified by an ISO OID prefix. The certificate section starts with a one-byte unsigned OID length followed by a BER-encoded OID indicating the nature of the remainder.
The PKIX certificate type (1) indicates an X.509 certificate conforming to the IETF PKIX profile. The certificate section starts with a one-byte unsigned OID length followed by an X.500 OID indicating the nature of the remainder.
The URI private type (253) requires the certificate portion of the CERT RR to begin with a null-terminated URI (RFC 2396); data after the null is the private format certificate itself.
IANA registry for CERT RR certificate types: values 0x0000-0x00FF and 0xFF00-0xFFFF require IETF standards action; values 0x0100-0xFEFF are assigned through IETF Consensus with RFC documentation. This document assigns types 1-3 (PKIX, SPKI, PGP) and 253-254 (URI, OID private).
CERT RRs are not used in connection with securing the DNS security additions (DNSSEC), so there are no security considerations related to CERT RRs and securing the DNS itself.
Certificates contain their own authenticating signature, so it is reasonable to store and retrieve them from non-secure DNS zones without DNS security checking. Retrieved certificates MAY be trusted if the certificate chain is verified back to a known trusted key consistent with the user's security policy.
If certificates are retrieved from a secure DNS zone with DNS security checking enabled and verified by DNSSEC, the key within the retrieved certificate MAY be trusted without verifying the certificate chain, if this conforms with the user's security policy.
In the text representation of CERT RRs, the certificate/CRL portion is encoded in base 64 and may be split across any number of whitespace-separated substrings that are concatenated to form the full value; substrings can span lines using standard parentheses.
The CERT RR wire format is: 16-bit type, 16-bit key tag, 8-bit algorithm, followed by the certificate or CRL data. Total header is 5 bytes before the certificate payload.