--- /dev/null
+
+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]
--- /dev/null
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <https://www.secure.john-doe.com:8080/>. 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]
+\f
+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
+ <hacker@mail.widget.foo.example>". 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 <Leslie@host.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]
+\f
+Internet-Draft Storing Certificates in the DNS January 2005
+
+
+ $ORIGIN example.org.
+ smith IN CERT PGP 0 0 <OpenPGP binary>
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+
projects / thirdparty / bind9.git / commitdiff
