RFC 2538
Storing Certificates in the Domain Name System (DNS)
Storing Certificates in the Domain Name System (DNS) 🎀
Okay bestie, let's dive into RFC 2538 🦋 It's a Request for Comments from the Network Working Group, dated March 1999. The authors are D. Eastlake (IBM) and O. Gudmundsson (TIS Labs), and it's a Standards Track document, so it's an actual Internet protocol spec and not just a vibe 💅 The title block doesn't list anything it obsoletes or updates, so no drama there 🙈
(Part 1 of 2: Sections 1 through 2.3. More coming, so stay tuned 🧚)
Status of This Memo ✨
This doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice 🔒
Copyright (C) The Internet Society (1999). All Rights Reserved. 💜
Abstract 🍓
Cryptographic public keys get published all the time, and their authenticity is shown with certificates, which is iconic 👑 This doc defines a CERT resource record (RR) so those certificates and related certificate revocation lists can live in the Domain Name System (DNS) 🔥
Table of Contents 📑
Abstract...................................................1
1. Introduction............................................2
2. The CERT Resource Record................................2
2.1 Certificate Type Values................................3
2.2 Text Representation of CERT RRs........................4
2.3 X.509 OIDs.............................................4
3. Appropriate Owner Names for CERT RRs....................5
3.1 X.509 CERT RR Names....................................5
3.2 PGP CERT RR Names......................................6
4. Performance Considerations..............................6
5. IANA Considerations.....................................7
6. Security Considerations.................................7
References.................................................8
Authors' Addresses.........................................9
Full Copyright Notice.....................................101. Introduction 🌸
Okay so public keys are usually published as a certificate, and people trust them because of certificates and related certificate revocation lists (CRLs) 💖 A certificate is a binding, made with a cryptographic digital signature, of a public key, a validity interval and/or conditions, and identity, authorization, or other info. A certificate revocation list is a list of certificates that have been revoked, plus some incidental info, all signed by the signer (issuer) of the revoked certificates. Examples are X.509 certificates and CRLs in the X.500 directory system, or PGP certificates and revocations used by PGP software ✨
Section 2 is where the CERT resource record (RR) gets specified, for storing certificates in the Domain Name System 🦋
Section 3 talks about appropriate owner names for CERT RRs 🧚
Sections 4, 5, and 6 cover performance, IANA, and security considerations, respectively 🔐
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 [RFC2119]. Those key words are the real rules, so read them carefully 🎀
2. The CERT Resource Record 🔥
The CERT resource record (RR) has the structure shown below, and 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 💜
The algorithm field has the same meaning as the algorithm field in KEY and SIG RRs [RFC 2535], with one twist: a zero algorithm field means the algorithm is unknown to a secure DNS. That might just be because the algorithm wasn't standardized for secure DNS yet 🙈
The key tag field is the 16 bit value computed for the key embedded in the certificate, as specified in the DNSSEC Standard [RFC 2535] 🔑 It's an efficiency measure for picking which CERT RRs might apply to a particular key. You can calculate the key tag for the key you care about, and then only CERT RRs with that same key tag need to be examined. Bestie, though, the key must always be transformed into the format it would have as the public key portion of a KEY RR before the key tag gets computed. That's only possible if the key is applicable to an algorithm (and its limits, like key size limits) defined for DNS security. If it isn't, the algorithm field MUST BE zero, and the tag field is meaningless and SHOULD BE zero 🚫
2.1 Certificate Type Values 🎀
The following values are defined or reserved:
Value Mnemonic Certificate Type
----- -------- ----------- ----
0 reserved
1 PKIX X.509 as per PKIX
2 SPKI SPKI cert
3 PGP PGP cert
4-252 available for IANA assignment
253 URI URI private
254 OID OID private
255-65534 available for IANA assignment
65535 reservedHere's the tea on each type 🫖
- PKIX is reserved for an X.509 certificate that conforms to the profile being defined by the IETF PKIX working group 👑 The certificate section starts with a one byte unsigned OID length, followed by an X.500 OID that indicates the nature of the rest of the certificate section (see 2.3 below). (NOTE: X.509 certificates do not include their X.500 directory type designating OID as a prefix.)
- SPKI is reserved for a certificate formatted the way the IETF SPKI working group specifies 🦋
- PGP means a Pretty Good Privacy certificate, as described in RFC 2440 and its extensions and successors 🌈
- URI private means the certificate format is defined by an absolute URI 🔗 The certificate portion of the CERT RR MUST begin with a null terminated URI [RFC 2396], and the data after the null is the private format certificate itself. The URI SHOULD be set up so that retrieving it leads to documentation on the certificate's format. Recognizing private certificate types doesn't need to rely on URI equality, though. You can use various forms of pattern matching, so that things like subtype or version info can also be encoded into the URI ✨
- OID private means 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 that indicates the nature of the rest of the certificate section. This can be an X.509 certificate format or some other format. X.509 certificates that conform to the IETF PKIX profile SHOULD be indicated by the PKIX type, not the OID private type 🙅 Recognizing private certificate types doesn't need to rely on OID equality either. Pattern matching, like matching an OID prefix, works too 💅
2.2 Text Representation of CERT RRs 📝
In the RDATA portion of a CERT RR, the type field is an unsigned integer or a mnemonic symbol from section 2.1 above 🌸
The key tag field is represented as an unsigned integer 🔢
The algorithm field is represented as an unsigned integer or a mnemonic symbol, as listed in [RFC 2535] 🧮
The certificate / CRL portion is represented in base 64. It can be split up into any number of white space separated substrings, all the way down to single base 64 digits, and those get concatenated to get the full signature. These substrings can span lines using the standard parenthesis 🌀
Heads up, though: the certificate / CRL portion can have internal sub-fields, but those don't show up in the master file representation. For example, with type 254, there's an OID size, an OID, and then the certificate / CRL proper. But only a single logical base 64 string appears in the text representation 🫶
2.3 X.509 OIDs 🌈
OIDs have been defined in connection with the X.500 directory for user certificates, certification authority certificates, revocations of certification authority, and revocations of user certificates 👑 The table below lists the OIDs, their BER encoding, and their length prefixed hex format, for use in CERT RRs 💖
id-at-userCertificate
= { joint-iso-ccitt(2) ds(5) at(4) 36 }
== 0x 03 55 04 24
id-at-cACertificate
= { joint-iso-ccitt(2) ds(5) at(4) 37 }
== 0x 03 55 04 25
id-at-authorityRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 38 }
== 0x 03 55 04 26
id-at-certificateRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 39 }
== 0x 03 55 04 273.1 X.509 CERT RR Names ✨
Okay bestie, so some X.509 versions let a cert have multiple names for its subjects and issuers, through "Subject Alternate Name" and "Issuer Alternate Name" 🫶. x.509v3 defines these Alternate Names with this ASN.1 spec:
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] EXPLICIT OR-ADDRESS.&Type,
directoryName [4] EXPLICIT Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER
}Now, where should the CERT get stored? The recommended spots come in priority order 💅
- (1) If a domain name is included in the identification in the certificate or CRL, use that one.
- (2) If there's no domain name but there is an IP address, translate that IP address into the matching inverse domain name and use that.
- (3) If neither of the above is used but there's a URI with a domain name in it, use that domain name.
- (4) If none of the above is included but there's a character string name, treat it the way the PGP names are treated in 3.2 below.
- (5) If none of the above apply, map the distinguished name (DN) into a domain name as specified in RFC 2247 🌸
Example 1: Say an X.509v3 certificate is issued to /CN=John Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative names of (a) the string "John (the Man) Doe", (b) the domain name john-doe.com, and (c) the URI <https://www.secure.john-doe.com:8080/>. Then the storage locations, in priority order, would be:
- (1) john-doe.com
- (2) www.secure.john-doe.com
- (3) Doe.com.xy
Example 2: Say an X.509v3 certificate is issued to /CN=James Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) the domain name widget.foo.example, (b) the IPv4 address 10.251.13.201, and (c) the string "James Hacker <hacker@mail.widget.foo.example>". Then the storage locations, in priority order, would be:
- (1) widget.foo.example
- (2) 201.13.251.10.in-addr.arpa
- (3) hacker.mail.widget.foo.example
3.2 PGP CERT RR Names 🦋
PGP signed keys (certificates) use a general character string User ID [RFC 2440]. PGP itself recommends that these names include the RFC 822 email address of the party, like Leslie Example <Leslie@host.example>. If you use that format, the CERT should go under the standard translation of the email address into a domain name, which in this case would be leslie.host.example 💖 If no RFC 822 name can be pulled out of the string name, no specific domain name is recommended.
4. Performance Considerations 🚀
Okay, so current Domain Name System (DNS) implementations are tuned for small transfers, usually not more than 512 bytes including overhead 📦 Bigger transfers still work correctly, and work is underway to make them more efficient. Even so, it's still advisable right now to make every reasonable effort to keep the certificates stored in the DNS small. Some things you can do include using the fewest possible optional or extensions fields, and using short field values for the variable length fields you have to include 🎀
5. IANA Considerations 🌈
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can only be assigned by an IETF standards action [RFC 2434]. This document assigns 0x0001 through 0x0003, 0x00FD and 0x00FE. Certificate types 0x0100 through 0xFEFF are assigned through IETF Consensus [RFC 2434], based on RFC documentation of the certificate type. The private types under 0x00FD and 0x00FE should cover most proprietary or private type needs 💜
6. Security Considerations 🔥
Please pay attention to this part, bestie 🥺 By definition, certificates contain their own authenticating signature. So it's reasonable to store certificates in non-secure DNS zones, or to retrieve them from DNS with DNS security checking not implemented or deferred for efficiency. The results MAY be trusted if the certificate chain is verified back to a known trusted key, and this conforms with the user's security policy.
Alternatively, if certificates are retrieved from a secure DNS zone with DNS security checking enabled and verified by DNS security, the key within the retrieved certificate MAY be trusted without verifying the certificate chain, if this conforms with the user's security policy.
CERT RRs aren't used in connection with the DNS security additions, so there are no security considerations related to CERT RRs and securing the DNS itself 💀
References 📚
RFC 1034: Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
RFC 1035: Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
RFC 2119: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2247: Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, January 1998.
RFC 2396: Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
RFC 2440: Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2240, November 1998.
RFC 2434: Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
RFC 2535: Eastlake, D., "Domain Name System (DNS) Security Extensions", RFC 2535, March 1999.
RFC 2459: Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
Authors' Addresses 🦋
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
RR#1
Carmel, NY 10512 USA
Phone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
Fax: +1-914-784-3833 (w-fax)
EMail: dee3@us.ibm.comOlafur Gudmundsson
TIS Labs at Network Associates
3060 Washington Rd, Route 97
Glenwood MD 21738
Phone: +1 443-259-2389
EMail: ogud@tislabs.comFull Copyright Statement 💜
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ✨
📦 where this page comes from
- ietf: rfc2538 1999-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms