diff --git a/doc/draft/draft-ietf-dnsext-nsec3-00.txt b/doc/draft/draft-ietf-dnsext-nsec3-00.txt new file mode 100644 index 0000000000..2b4ac79ec2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsec3-00.txt @@ -0,0 +1,840 @@ + +Network Working Group B. Laurie +Internet-Draft G. Sisson +Expires: July 2, 2005 Nominet + R. Arends + Telematica Instituut + january 2005 + + DNSSEC Hash Authenticated Denial of Existence + draft-ietf-dnsext-nsec3-00 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 2, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be + used to provide authenticated denial of existence of DNS ownernames + and types; however, it permits any user to traverse a zone and obtain + a listing of all ownernames. + + +Laurie, et al. Expires July 2, 2005 [Page 1] +Internet-Draft nsec3 january 2005 + + A complete zone file can be used either directly as a source of + probable e-mail addresses for spam, or indirectly as a key for + multiple WHOIS queries to reveal registrant data which many + registries (particularly in Europe) may be under strict legal + obligations to protect. Many registries therefore prohibit copying + of their zone file; however the use of NSEC RRs makes renders + policies unenforceable. + + This document proposes a scheme which obscures original ownernames + while permitting authenticated denial of existence of non-existent + names. Non-authoritative delegation point NS RR types may be + excluded. + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires July 2, 2005 [Page 2] +Internet-Draft nsec3 january 2005 + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 + 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6 + 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6 + 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 6 + 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 6 + 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 6 + 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7 + 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 7 + 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8 + 3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9 + 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9 + 5. Special Considerations . . . . . . . . . . . . . . . . . . . . 9 + 5.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 + 5.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 10 + 5.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 + 5.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 11 + 5.4.1 Avoiding Hash Collisions during generation . . . . . . 11 + 5.4.2 Second Preimage Requirement Analysis . . . . . . . . . 11 + 5.4.3 Possible Hash Value Truncation Method . . . . . . . . 12 + 6. Performance Considerations . . . . . . . . . . . . . . . . . . 12 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 9. Requirements notation . . . . . . . . . . . . . . . . . . . . 13 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 13 + A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 + Intellectual Property and Copyright Statements . . . . . . . . 17 + + + + + + + +Laurie, et al. Expires July 2, 2005 [Page 3] +Internet-Draft nsec3 january 2005 + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduced the NSEC Resource + Record (RR) for Authenticated Denial of Existence. This document + introduces a new RR as an alternative to NSEC that provides measures + against zone traversal and allows for gradual expansion of + delegation-centric zones. + +1.1 Rationale + + The DNS Security Extensions included the NSEC RR to provide + authenticated denial of existence. Though the NSEC RR meets the + requirements for authenticated denial of Existence, it introduced a + side-effect in that the contents of a zone can be enumerated. This + property introduces undesired policy issues. + + A second requirement was that the existence of all record types in a + zone -including delegation point NS record types- can be accounted + for, despite the fact that delegation point NS RRsets are not + authoritative and not signed. This requirement has a side-effect + that the overhead of delegation centric signed zones is not related + to the increase in security of subzones. This requirement does not + allow delegation centric zones size to grow in relation to the growth + of signed subzones. + + In the past, solutions have been proposed as a measure against these + side effects but at the time were regarded as secondary over the need + to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) + a graceful transition path to future enhancements is introduced, + while current DNSSEC deployment can continue. This document + accumulates measures against the side effects introduced by NSEC, and + presents the NSEC3 Resource Record. + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs + that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 + [RFC2308]. + +1.2 Reserved Words + + 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 RFC 2119 [RFC2119]. + +1.3 Terminology + + In this document the term "original ownername" refers to a standard + ownername. Because this proposal uses the result of a hash function + + +Laurie, et al. Expires July 2, 2005 [Page 4] +Internet-Draft nsec3 january 2005 + + over the original (unmodified) ownername, this result is refered to + as "hashed ownername". + +2. The NSEC3 Resource Record + + The NSEC3 RR provides Authenticated Denial of Existence for DNS + Resource Record Sets. + + The NSEC3 Resource Record lists RR types present at the NSEC3 RR's + original ownername. It includes the next hashed ownername in the + canonical ordering of the zone. The complete set of NSEC3 RRs in a + zone indicates which RRsets exist for the original ownername of the + RRset and form a chain of hashed ownernames in the zone. This + information is used to provide authenticated denial of existence for + DNS data, as described in RFC 2535 [RFC2535]. Unsigned delegation + point NS RR sets can optionally be excluded. To provide protection + against zone traversal, the ownernames used in the NSEC3 RR are + cryptographic hash-value prepended to the name of the zone. The + NSEC3 RR record indicates which Hash Function is used to construct to + hash, which Salt is used, and how many iterations of the Hash + Function are performed over the original ownername. + + The type value for the NSEC3 RR is XX. + + The NSEC3 RR RDATA format is class independent. + + The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +2.1 NSEC3 RDATA Wire Format + + The RDATA of the NSEC3 RR is as shown below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|Hash Function| Iterations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Salt Length | Salt / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Hashed Ownername / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Laurie, et al. Expires July 2, 2005 [Page 5] +Internet-Draft nsec3 january 2005 + +2.1.1 The Authoritative Only Flag Field + + The Authoritative Only Flag field indicates whether the Type Bit Maps + include delegation point NS record types. + + If the flag is set to 1, the NS RR type bit for a delegation point + ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR + type bit MUST be ignored during processing of the NSEC3 RR. The NS + RR type bit has no meaning in this context (it is not authoritative), + hence the NSEC3 does not contest the existence of a NS RR type record + for this ownername. When a delegation is not secured, there exist no + DS RR type nor any other authoritative types for this delegation, + hence the unsecured delegation has no NSEC3 record associated. + Please see the Special Consideration section for implications for + unsigned delegations. + + If the flag is set to 0, the NS RR type bit for a delegation point + ownername MUST be set if the NSEC3 covers a delegation, even though + the NS RR itself is not authoritative. This implies that all + delegations, signed or unsigned, have an NSEC3 record associated. + This behavior is identical to NSEC behavior. + +2.1.2 The Hash Function Field + + The Hash Function field identifies the cryptographic hash function + used to construct the hash-value. + + This document defines Value 1 for SHA-1 and Value 127 for + Experimental. All other values are reserved. + + On reception, a resolver MUST discard an NSEC3 RR with an unknown + Hash Function value. + +2.1.3 The Iterations Field + + The Iterations field defines the number of times the hash has been + iterated. More iterations results in greater resiliency of the hash + value against dictionary attacks, but at a higher cost for both the + server and resolver. + +2.1.4 The Salt Length Field + + The Salt Length Field defines the length of the salt in octets. + +2.1.5 The Salt Field + + The salt field is not present when the Salt Length Field has a value + of 0. + + +Laurie, et al. Expires July 2, 2005 [Page 6] +Internet-Draft nsec3 january 2005 + + The salt field is prepended to the original ownername before hashing + in order to defend against precalculated dictionary attacks. + + The salt is not prepended during iterations of the hash function. + + The Salt field value MUST be identical for all NSEC3 RRs generated + for the zone. If the salt were different for each NSEC3 RR, + collisions could occur where an NSEC3 denies the existence of + existing RRs due to the application of different salt values. + +2.1.6 The Next Hashed Ownername Field + + The Next Hashed Ownername Field contains the hash of the ownername of + the next RR in the canonical ordering of the hashed ownernames of the + zone. The value of the Next Hashed Ownername Field in the last NSEC3 + record in the zone is the same as the ownername of the first NSEC3 RR + in the zone in canonical order. + + A sender MUST NOT use DNS name compression on the Next Hashed + Ownername field when transmitting an NSEC3 RR. + + Hashed ownernames of RRsets not authoritative for the given zone + (such as glue records) MUST NOT be listed in the Hash of Next Domain + Name unless at least one authoritative RRset exists at the same owner + name. + +2.1.7 The list of Type Bit Map(s) Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC3 RR's ownername. + + The Type bit for the NSEC3 and RRSIG MUST be set during generation, + and MUST be ignored during processing. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC3 RR RDATA in increasing numerical + order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + +Laurie, et al. Expires July 2, 2005 [Page 7] +Internet-Draft nsec3 january 2005 + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC3 + RR's ownername. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC3 RR's ownername. + + The RR type 2 (NS) is authoritative at the apex of a zone and is not + authoritative at delegation points. If the Authoritative Only Flag + is set to 1, the delegation point NS RR type MUST NOT be included in + the type bit maps. If the Authoritative Only Flag is set to 0, the + NS RR type at a delegation point MUST be included in the type bit + maps. + + Since bit 0 in window block 0 refers to the non-existing RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4] + (section 3.1) or within the range reserved for assignment only to + QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in + zone data. If encountered, they must be ignored upon reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC3 RR's actual ownername. Trailing zero octets not specified MUST + be interpretted as zero octets. + +2.2 The NSEC3 RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Authoritative Only Field is represented as an unsigned decimal + integer. The value are either 0 or 1. + + The Hash field is presented as the name of the hash or as an unsigned + decimal integer. The value has a maximum of 127. + + The Iterations field is presented as an unsigned decimal integer. + + The Salt Length field is not presented. + + The Salt field is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is not allowed within the sequence. + + +Laurie, et al. Expires July 2, 2005 [Page 8] +Internet-Draft nsec3 january 2005 + + The Salt Field is represented as 00 when the Salt Length field has + value 0. + + The Hash of Next Domain Name field is represented as a sequence of + case-insensitive base32 digits. Whitespace is allowed within the + sequence. + + The List of Type Bit Map(s) Field is represented as a sequence of RR + type mnemonics. When the mnemonic is not known, the TYPE + representation as described in RFC 3597 [5] (section 5) MUST be used. + +3. Creating Additional NSEC3 RR for Empty Non Terminals + + In order to prove the nonexistence of a record that might be covered + by a wildcard, it is necessary to prove the existence of its closest + encloser. A closest encloser might be an Empty Non Terminal. + + Additional NSEC3 RRs cover every existing intermediate label level. + Additional NSEC3 RRs are identical in format to NSEC3 RRs that cover + existing RRs in the zone. The difference is that the type-bit-maps + only indicate the existence of an NSEC3 RR and a RRSIG type. + +4. Calculation of the Hash + + Define H(x) to be the hash of x using the hash function selected by + the NSEC3 record and || to indicate concatenation. Then define: + + IH(salt,x,0)=H(x || salt) + + IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 + + Then the calculated hash of an ownername is + IH(salt,ownername,iterations-1), where the ownername is the canonical + form. + + The canonical form of the ownername is the wire format of the + ownername where: + 1. The ownername is fully expanded (no DNS name compression) and + fully qualified; + 2. All uppercase US-ASCII letters are replaced by the corresponding + lowercase US-ASCII letters; + 3. If the ownername is a wildcard name, the ownername is in its + original unexpanded form, including the "*" label (no wildcard + substitution); + +5. Special Considerations + + The following paragraphs clarify specific behavior explain special + + +Laurie, et al. Expires July 2, 2005 [Page 9] +Internet-Draft nsec3 january 2005 + + considerations for implementations. + +5.1 delegation points + + This proposal introduces the Authoritative Only Flag which indicates + whether non authoritative delegation point NS records are included in + the type bit Maps. As discussed in paragraph 2.1.1, a flag value of + 0 indicates that the interpretation of the type bit maps is identical + to NSEC records. + + The following subsections describe behavior when the flag value is 1. + +5.1.1 Unsigned Delegations + + Delegation point NS records are not authoritative. They are + authoritative in the delegated zone. No other data exists at the + ownername of an unsigned delegation point. + + Since no authoritative data exist at this ownername, it is excluded + from the NSEC3 chain. This is an optimization since it relieves the + zone of including an NSEC3 record and its associated signature for + this name. + + An NSEC3 that denies existence of ownernames between X and X' with + the Authoritative Only Flag set to 1 can not be used to proof + presence nor absence of the delegation point NS records for unsigned + delegations in the interval X, X'. The Authoritative Only Flag + effectively states No Contest on the presence of delegation point NS + resource records. + + Since proof is absent, there exists a new attack vector. Unsigned + delegation point NS records can be deleted during a man in the middle + attack, effectively denying existence of the delegation. This is a + form of Denial of Service, where the victim has no information it is + under attack, since all signatures are valid and the fabricated + response form is a known type of response. + + The only possible mitigation is to either not use this method, hence + proving existence or absence of unsigned delegations, or signing the + delegated zone, changing the unsigned delegation into a signed + delegation. + + A second attack vector exists in that an adversary is able to + successfully fabricate a response claiming a not existent delegation + to exist, though unsigned. + + The only possible mitigation is to either not use this method, hence + proving absence of unsigned delegations. + + +Laurie, et al. Expires July 2, 2005 [Page 10] +Internet-Draft nsec3 january 2005 + +5.2 Additional Complexity Caused by Wildcards + + If a wildcard ownername appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated in the same way as any + other ownername for purposes of generating NSEC3 RRs. RFC 2535 + [RFC2525] describes the impact of wildcards on authenticated denial + of existence. + + In order to prove there are no wildcards for a domain, as well as no + RRs that match directly, an RR must be shown for the closest + encloser, and nonexistence must be shown for all enclosers that could + be closer. + +5.3 Salting + + Augmenting original ownernames with salt before hashing increases the + cost of a dictionary of pre-generated hash-values. For every bit of + salt, the cost of the dictionary doubles. The NSEC3 RR can use + maximum 2040 bits of salt, multiplying the cost by 2^2040. + + The salt value for each NSEC3 RR MUST be equal for a single version + of the zone. + +5.4 Hash Collision + + Hash collisions occur when different messages have the same hash + value. The expected number of domain names needed to give a 1 in 2 + chance of a single collision is about 2^80. Though this probability + is extremely low, the following paragraphs deal with avoiding + collisions and assessing possible damage in the event of an attack + using Hash collisions. + +5.4.1 Avoiding Hash Collisions during generation + + During generation of NSEC3 RRs, hash values are supposedly unique. + In the (academic) case of a collision occuring, an alternative salt + SHOULD be chosen and all hash values SHOULD be regenerated. + + If hash values are not regenerated on collision, the NSEC3 RR MUST + list all authoritative RR types that exist for both owners, to avoid + a replay attack, spoofing an existing type as non-existent. + +5.4.2 Second Preimage Requirement Analysis + + A collision resistant hash function has a second-preimage resistance + property. The second-preimage resistance property means that it is + computationally infeasible to find another message with the same hash + value as a given message, i.e. given preimage X, to find a second + + +Laurie, et al. Expires July 2, 2005 [Page 11] +Internet-Draft nsec3 january 2005 + + preimage X' <> X such that hash(X) = hash(X'). The probability of + finding a second preimage is 1 in 2^160 for SHA-1 on average. To + mount an attack using an existing NSEC3 RR, an adversary needs to + find a second preimage. + + Assuming an adversary is capable of mounting such an extreme attack, + the actual damage is that a response message can be generated which + claims that a certain QNAME (i.e. the second pre-image) does exist, + while in reality QNAME does not exist (a false positive), which will + either cause a security aware resolver to re-query for the + non-existent name, or to fail the initial query. Note that the + adversary can't mount this attack on an existing name but only on a + name that the adversary can't choose and does not yet exist. + +5.4.3 Possible Hash Value Truncation Method + + The previous sections outlined the low probability and low impact of + a second-preimage attack. When impact and probability are low, while + space in a DNS message is costly, truncation is tempting. Truncation + might be considered to allow for shorter ownernames and rdata for + hashed labels. In general, if a cryptographic hash is truncated to n + bits, then the expected number of domains required to give a 1 in 2 + probability of a single collision is approximately 2^(n/2) and the + work factor to produce a second preimage resistance is 2^n. + + An extreme hash value truncation would be truncating to the shortest + possible unique label value. Considering that hash values are + presented in base32, which represents 5 bits per label character, + truncation must be done on a 5 bit boundary. This would be unwise, + since the work factor to produce collisions would then approximate + the size of the zone. + + Though the mentioned truncation can be maximized to a certain + extreme, the probability of collision increases exponentially for + every truncated bit. Given the low impact of hash value collisions + and limited space in DNS messages, the balance between truncation + profit and collision damage may be determined by local policy. + +6. Performance Considerations + + Iterated hashes will obviously impose a performance penalty on both + authoritative servers and resolvers. Therefore, the number of + iterations should be carefully chosen. + +7. IANA Considerations + + IANA has to create a new registry for NSEC3 Hash Functions. The + range for this registry is 0-127. Value 1 is marked as SHA-1. + + +Laurie, et al. Expires July 2, 2005 [Page 12] +Internet-Draft nsec3 january 2005 + + Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is + marked as Experimental. + +8. Security Considerations + + The NSEC3 records are still susceptible to dictionary attacks (i.e. + the attacker retrieves all the NSEC3 records, then calculates the + hashes of all likely domain names, comparing against the hashes found + in the NSEC3 records, and thus enumerating the zone). These are + substantially more expensive than traversing the original NSEC + records would have been, and in any case, such an attack could also + be used directly against the name server itself by performing queries + for all likely names. The expense of this attack can be chosen by + setting the iterations in the NSEC3 RR. + + High-value domains are also susceptible to a precalculated dictionary + attack - that is, a list of hashes for all likely names is computed + once, then NSEC3 is scanned periodically and compared against the + precomputed hashes. This attack is prevented by changing the salt on + a regular basis. + + Walking the NSEC3 RRs will reveal the total number of records in the + zone, and also what types they are. This could be mitigated by + adding dummy entries, but certainly an upper limit can always be + found. + + Hash collisions may occur. If they do, it will be impossible to + prove the nonexistence of the colliding domain - however, this is + fantastically unlikely, and, in any case, DNSSEC already relies on + SHA-1 to not collide. + +9. Requirements notation + + 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]. + +10. Security Considerations + +Appendix A. Example Zone + + This is a zone showing its NSEC3 records. They can also be used as + test vectors for the hash algorithm. RRSIG records have been elided. + + + + +Laurie, et al. Expires July 2, 2005 [Page 13] +Internet-Draft nsec3 january 2005 + + example.com. 1000 IN SOA localhost. + postmaster.localhost.example.com. ( + 1 ; serial + 3600 ; refresh (1 hour) + 1800 ; retry (30 minutes) + 604800 ; expire (1 week) + 3600 ; minimum (1 hour) + ) + 1000 NS ns1.example.com. + 1000 NS ns2.example.com. + f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \ + NS SOA RRSIG DNSKEY NSEC3 + a.example.com. 1000 IN A 1.2.3.4 + 1000 IN A 1.2.3.5 + 1000 TXT "An example" + bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \ + A TXT RRSIG NSEC3 + b.example.com. 1000 IN A 1.2.3.7 + 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \ + A RRSIG NSEC3 + a.b.c.example.com. 1000 IN A 1.2.3.6 + a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ + A RRSIG NSEC3 + ns1.example.com. 1000 IN A 1.2.3.8 + 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \ + A RRSIG NSEC3 + ns2.example.com. 1000 IN A 1.2.3.9 + 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ + A RRSIG NSEC3 + +11. References + +11.1 Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + + +Laurie, et al. Expires July 2, 2005 [Page 14] +Internet-Draft nsec3 january 2005 + + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + +11.2 Informative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + [rollover] + Ihren, J., Kolkman, O. and B. Manning, "An In-Band + Rollover Algorithm and a Out-Of-Band Priming Method for + DNS Trust Anchors.", July 2004. + +Authors' Addresses + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + Phone: +44 (20) 8735 0686 + EMail: ben@algroup.co.uk + + Geoffrey Sisson + Nominet + + + + +Laurie, et al. Expires July 2, 2005 [Page 15] +Internet-Draft nsec3 january 2005 + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + The Netherlands + + Phone: +31 (53) 485 0485 + EMail: roy.arends@telin.nl + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires July 2, 2005 [Page 16] +Internet-Draft nsec3 january 2005 + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + +Laurie, et al. Expires July 2, 2005 [Page 17] diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt new file mode 100644 index 0000000000..8cd32e316b --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt @@ -0,0 +1,728 @@ + +Network Working Group S. Josefsson +Internet-Draft January 24, 2005 +Expires: July 25, 2005 + + + Storing Certificates in the Domain Name System (DNS) + draft-ietf-dnsext-rfc2538bis-00 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 25, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Cryptographic public key are frequently published and their + authenticity 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). + + + + + + + +Josefsson Expires July 25, 2005 [Page 1] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +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 . . . . . . . . . . . . . 5 + 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 + 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 + 3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 + 3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8 + 3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 4. Performance Considerations . . . . . . . . . . . . . . . . . . 9 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 + A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . 13 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires July 25, 2005 [Page 2] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +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 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 below specifies a CERT resource record (RR) for the storage + of certificates in the Domain Name System. + + Section 3 discusses appropriate owner names for CERT RRs. + + Sections 4, 5, and 6 below 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 [10]. + +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 define in section 2.1 + below. + + The algorithm field has the same meaning as the algorithm field in + DNSKEY and RRSIG RRs [9] except that a zero algorithm field indicates + the algorithm is unknown to a secure DNS, which may simply be the + result of the algorithm not having been standardized for DNSSEC. + + + + +Josefsson Expires July 25, 2005 [Page 3] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + The key tag field is the 16 bit value computed for the key embedded + in the certificate, using the RRSIG Key Tag Algorithm described in + Appendix B of [9]. This field is used as an efficiency measure to + pick which CERT RRs may be applicable to a particular key. The key + tag can be calculated for the key in question and then only CERT RRs + with the same key tag need be examined. However, the key must always + be transformed to the format it would have as the public key portion + of a DNSKEY RR before the key tag is computed. This is only possible + if the key is applicable to an algorithm (and limits such as key size + limits) defined for DNS security. If it is not, 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 certificate + 3 PGP OpenPGP packet + 4-252 available for IANA assignment + 253 URI URI private + 254 OID OID private + 255-65534 available for IANA assignment + 65535 reserved + + The PKIX type is reserved to indicate an X.509 certificate conforming + to the profile being defined by the IETF PKIX working group. The + certificate section will start with a one byte unsigned OID length + and then an X.500 OID indicating the nature of the remainder 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.) + + The SPKI type is reserved to indicate a certificate formated as to be + specified by the IETF SPKI working group. + + The PGP type indicates an OpenPGP packet as described in [5] and its + extensions and successors. Two uses are to transfer public key + material and revocation signatures. The data is binary, and MUST NOT + be encoded into an ASCII armor. An implementation SHOULD process + transferable public keys as described in section 10.1 of [5], but it + MAY handle additional OpenPGP packets. + + The URI private type indicates a certificate format defined by an + absolute URI. The certificate portion of the CERT RR MUST begin with + a null terminated URI [4] and the data after the null is the private + + + +Josefsson Expires July 25, 2005 [Page 4] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + format certificate itself. The URI SHOULD be such that a retrieval + from it will lead to documentation on the format of the certificate. + Recognition of private certificate types need not be based on URI + equality but can use various forms of pattern matching so that, for + example, subtype or version information can also be encoded into the + URI. + + The OID private type indicates a private format certificate specified + by a an ISO OID prefix. The certificate section will start with a + one byte unsigned OID length and then a BER encoded OID indicating + the nature of the remainder 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. Recognition of private certificate + types need not be based on OID equality but can use various forms of + pattern matching such as OID prefix. + +2.2 Text Representation of CERT RRs + + The RDATA portion of a CERT RR has the type field as an unsigned + decimal integer or as a mnemonic symbol as listed in section 2.1 + above. + + The key tag field is represented as an unsigned decimal integer. + + The algorithm field is represented as an unsigned decimal integer or + a mnemonic symbol as listed in [9]. + + The certificate / CRL portion is represented in base 64 [11] and may + be divided up into any number of white space separated substrings, + down to single base 64 digits, which are concatenated to obtain the + full signature. These substrings can span lines using the standard + parenthesis. + + Note that the certificate / CRL portion may have internal sub-fields + but these do not appear in the master file representation. For + example, with type 254, there will be an OID size, an OID, and then + the certificate / CRL proper. But only a single logical base 64 + string will appear 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 following table lists the OIDs, their BER encoding, and their + length prefixed hex format for use in CERT RRs: + + + + +Josefsson Expires July 25, 2005 [Page 5] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + 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 27 + + +3. Appropriate Owner Names for CERT RRs + + It is recommended that certificate CERT RRs be stored under a domain + name related to their subject, i.e., the name of the entity intended + to control the private key corresponding to the public key being + certified. It is recommended that certificate revocation list CERT + RRs be stored under a domain name related to their issuer. + + Following some of the guidelines below may result in the use in DNS + names of characters that require DNS quoting which is to use a + backslash followed by the octal representation of the ASCII code for + the character such as \000 for NULL. + + The choice of name under which CERT RRs are stored is important to + clients that perform CERT queries. In some situations, the client + may not know all information about the CERT RR object it wishes to + retrieve. For example, a client may not know the subject name of an + X.509 certificate, or the e-mail address of the owner of an OpenPGP + key. Further, the client might only know the hostname of a service + that uses X.509 certificates or the Key ID of an OpenPGP key. + + This motivate describing two different owner name guidelines. We + call the two rules content-based owner names and purpose-based owner + names. A content-based owner name is derived from the content of the + CERT RR data; for example the Subject field in an X.509 certificate + or the User ID field in OpenPGP keys. A purpose-based owner name is + selected to be a name that clients that wishes to retrieve CERT RRs + are expected to know; for example the host name of a X.509 protected + service or a Key ID of an OpenPGP key. Note that in some situations, + the content-based and purpose-based owner name can be the same; for + example when a client look up keys based on e-mail addresses for + incoming e-mail. + + Implementations SHOULD use the purpose-based owner name guidelines + + + +Josefsson Expires July 25, 2005 [Page 6] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + described in this document, and MAY use CNAMEs at content-based owner + names (or other names), pointing to the purpose-based owner name. + +3.1 Content-based X.509 CERT RR Names + + Some X.509 versions permit multiple names to be associated with + subjects and issuers under "Subject Alternate Name" and "Issuer + Alternate Name". For example, x.509v3 has such Alternate Names with + an ASN.1 specification as follows: + + 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 + } + + The recommended locations of CERT storage are as follows, in priority + order: + 1. If a domain name is included in the identification in the + certificate or CRL, that should be used. + 2. If a domain name is not included but an IP address is included, + then the translation of that IP address into the appropriate + inverse domain name should be used. + 3. If neither of the above it used but a URI containing a domain + name is present, that domain name should be used. + 4. If none of the above is included but a character string name is + included, then it should be treated as described for PGP names + below. + 5. If none of the above apply, then the distinguished name (DN) + should be mapped into a domain name as specified in [3]. + + Example 1: Assume that 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) string "John (the Man) Doe", (b) domain name john- + doe.com, and (c) uri . Then + the storage locations recommended, in priority order, would be + 1. john-doe.com, + 2. www.secure.john-doe.com, and + 3. Doe.com.xy. + + Example 2: Assume that an X.509v3 certificate is issued to /CN=James + Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names + + + +Josefsson Expires July 25, 2005 [Page 7] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + of (a) domain name widget.foo.example, (b) IPv4 address + 10.251.13.201, and (c) string "James Hacker + ". Then the storage locations + recommended, in priority order, would be + 1. widget.foo.example, + 2. 201.13.251.10.in-addr.arpa, and + 3. hacker.mail.widget.foo.example. + +3.2 Purpose-based X.509 CERT RR Names + + It is difficult for clients that do not already posses a certificate + to reconstruct the content-based owner name that should be used to + retrieve the certificate. For this reason, purpose-based owner names + are recommended in this section. Because purpose-based owner names + by nature depend on the specific scenario, or purpose, for which the + certificate will be used, there are more than one recommendation. + The following table summarize the purpose-based X.509 CERT RR owner + name guidelines. + + Scenario Owner name + ------------------------------------------------------------------- + S/MIME Certificate Standard translation of RFC 822 email address. + Example: A S/MIME certificate for + "postmaster@example.org" will use a standard + hostname translation of the owner name, + i.e. "postmaster.example.org". + + SSL Certificate Hostname of the SSL server. + + IPSEC Certificate Hostname of the IPSEC machine, and/or + for the in-addr.arpa reverse lookup IP address. + + CRLs Hostname of the issuing CA. + + +3.3 Content-based OpenPGP CERT RR Names + + OpenPGP signed keys (certificates) use a general character string + User ID [5]. However, it is recommended by OpenPGP that such names + include the RFC 2822 [7] email address of the party, as in "Leslie + Example ". If such a format is used, the CERT + should be under the standard translation of the email address into a + domain name, which would be leslie.host.example in this case. If no + RFC 2822 name can be extracted from the string name no specific + domain name is recommended. + + If a user has more than one email address, the CNAME type can be used + to reduce the amount of data stored in the DNS. For example: + + + +Josefsson Expires July 25, 2005 [Page 8] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + $ORIGIN example.org. + smith IN CERT PGP 0 0 + john.smith IN CNAME smith + js IN CNAME smith + + +3.4 Purpose-based OpenPGP CERT RR Names + + Applications that receive an OpenPGP packet but do not know the email + address of the sender will have difficulties constructing the correct + owner name, and cannot use the content-based owner name guidelines. + However, these clients commonly know the key fingerprint or the Key + ID. The key ID is found in OpenPGP packets, and the key fingerprint + is commonly found in auxilliary data that may be available. For + these situations, it is recommended to use an owner name identical to + the key fingerprint and key ID expressed in hexadecimal [11]. For + example: + + $ORIGIN example.org. + 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... + F835EDA21E94B565716F IN CERT PGP ... + B565716F IN CERT PGP ... + + If the same key material is stored at several owner names, the use of + CNAME may be used to avoid data duplication. Note that CNAME is not + always applicable, because it map an owner names to the other for all + purposes, and this may be sub-optimal when two keys with the same Key + ID are stored. + +4. Performance Considerations + + Current Domain Name System (DNS) implementations are optimized for + small transfers, typically not more than 512 bytes including + overhead. While larger transfers will perform correctly and work is + underway to make larger transfers more efficient, it is still + advisable at this time to make every reasonable effort to minimize + the size of certificates stored within the DNS. Steps that can be + taken may include using the fewest possible optional or extensions + fields and using short field values for variable length fields that + must be included. + + The RDATA field in the DNS protocol may only hold data of size 65535 + octets (64kb) or less. This means that each CERT RR cannot contain + more than 64kb worth of payload, even if the corresponding + certificate or certificate revocation list is larger. This document + do not address this limitation. + + + + + +Josefsson Expires July 25, 2005 [Page 9] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +5. Acknowledgements + + The majority of this document is copied verbatim from RFC 2538, by + Donald Eastlake 3rd and Olafur Gudmundsson. + + The author wishes to thank David Shaw and Michael Graff for their + contributions to the earlier work that motivated this revised + document. + + Florian Weimer suggested to clarify wording regarding what data can + be stored in RRDATA portion of OpenPGP CERT RRs, and that the URI + type may include hashes to secure the indirection. Olivier Dubuisson + confirmed that the X.509 OID were indeed correct. + +6. Security Considerations + + By definition, certificates contain their own authenticating + signature. Thus it is reasonable to store certificates in non-secure + DNS zones or to retrieve certificates 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 are 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. + + When the URI type is used, it should be understood that is introduce + an additional indirection that may allow for a new attack vector. + One method to secure that indirection is to include a hash of the + certificate in the URI itself. + + CERT RRs are not used in connection with securing the DNS security + additions so there are no security considerations related to CERT RRs + and securing the DNS itself. + +7. IANA Considerations + + Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can + only be assigned by an IETF standards action [6]. This document + assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE. Certificate + types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] + based on RFC documentation of the certificate type. The availability + of private types under 0x00FD and 0x00FE should satisfy most + requirements for proprietary or private types. + + + + +Josefsson Expires July 25, 2005 [Page 10] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +8. Changes since RFC 2538 + + 1. Editorial changes to conform with new document requirements, + including splitting reference section into two parts and updating + the references to point at latest versions, and to add some + additional references. + 2. Improve terminology. For example replace "PGP" with "OpenPGP", + to align with RFC 2440. + 3. In section 2.1, clarify that OpenPGP public key data are binary, + not the ASCII armored format, and reference 10.1 in RFC 2440 on + how to deal with OpenPGP keys, and acknowledge that + implementations may handle additional packet types. + 4. Clarify that integers in the representation format are decimal. + 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis + terminology. Improve reference for Key Tag Algorithm + calculations. + 6. Add examples that suggest use of CNAME to reduce bandwidth. + 7. In section 3, appended the last paragraphs that discuss + "content-based" vs "purpose-based" owner names. Add section 3.2 + for purpose-based X.509 CERT owner names, and section 3.4 for + purpose-based OpenPGP CERT owner names. + 8. Added size considerations. + +9. References + +9.1 Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, + "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, + January 1998. + + [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP + Message Format", RFC 2440, November 1998. + + [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + + + +Josefsson Expires July 25, 2005 [Page 11] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [9] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + +9.2 Informative References + + [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + +Author's Address + + Simon Josefsson + + EMail: simon@josefsson.org + +Appendix A. Copying conditions + + Regarding the portion of this document that was written by Simon + Josefsson ("the author", for the remainder of this section), the + author makes no guarantees and is not responsible for any damage + resulting from its use. The author grants irrevocable permission to + anyone to use, modify, and distribute it in any way that does not + diminish the rights of anyone else to use, modify, and distribute it, + provided that redistributed derivative works do not contain + misleading author or version information. Derivative works need not + be licensed under similar terms. + + + + + + + + + + + + + + + + +Josefsson Expires July 25, 2005 [Page 12] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Josefsson Expires July 25, 2005 [Page 13] + +