📄 draft-ietf-dnsext-dnssec-records-09.txt
字号:
draft-ietf-dnsext-nsec-rdata-06 (work in progress), May 2004. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.Authors' Addresses Roy Arends Telematica Instituut Drienerlolaan 5 7522 NB Enschede NL EMail: roy.arends@telin.nlArends, et al. Expires January 13, 2005 [Page 27] Internet-Draft DNSSEC Resource Records July 2004 Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA EMail: sra@isc.org Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA EMail: mlarson@verisign.com Dan Massey USC Information Sciences Institute 3811 N. Fairfax Drive Arlington, VA 22203 USA EMail: masseyd@isi.edu Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA EMail: scott.rose@nist.govArends, et al. Expires January 13, 2005 [Page 28] Internet-Draft DNSSEC Resource Records July 2004Appendix A. DNSSEC Algorithm and Digest Types The DNS security extensions are designed to be independent of the underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS resource records all use a DNSSEC Algorithm Number to identify the cryptographic algorithm in use by the resource record. The DS resource record also specifies a Digest Algorithm Number to identify the digest algorithm used to construct the DS record. The currently defined Algorithm and Digest Types are listed below. Additional Algorithm or Digest Types could be added as advances in cryptography warrant. A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms.A.1 DNSSEC Algorithm Types The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify the security algorithm being used. These values are stored in the "Algorithm number" field in the resource record RDATA. Some algorithms are usable only for zone signing (DNSSEC), some only for transaction security mechanisms (SIG(0) and TSIG), and some for both. Those usable for zone signing may appear in DNSKEY, RRSIG, and DS RRs. Those usable for transaction security would be present in SIG(0) and KEY RRs as described in [RFC2931] Zone Value Algorithm [Mnemonic] Signing References Status ----- -------------------- --------- ---------- --------- 0 reserved 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED 2 Diffie-Hellman [DH] n RFC 2539 - 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL 4 Elliptic Curve [ECC] TBA - 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY 252 Indirect [INDIRECT] n - 253 Private [PRIVATEDNS] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL 255 reserved 6 - 251 Available for assignment by IETF Standards Action.A.1.1 Private Algorithm Types Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with a wire encodedArends, et al. Expires January 13, 2005 [Page 29] Internet-Draft DNSSEC Resource Records July 2004 domain name, which MUST NOT be compressed. The domain name indicates the private algorithm to use and the remainder of the public key area is determined by that algorithm. Entities should only use domain names they control to designate their private algorithms. Algorithm number 254 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with an unsigned length byte followed by a BER encoded Object Identifier (ISO OID) of that length. The OID indicates the private algorithm in use and the remainder of the area is whatever is required by that algorithm. Entities should only use OIDs they control to designate their private algorithms.A.2 DNSSEC Digest Types A "Digest Type" field in the DS resource record types identifies the cryptographic digest algorithm used by the resource record. The following table lists the currently defined digest algorithm types. VALUE Algorithm STATUS 0 Reserved - 1 SHA-1 MANDATORY 2-255 Unassigned -Arends, et al. Expires January 13, 2005 [Page 30] Internet-Draft DNSSEC Resource Records July 2004Appendix B. Key Tag Calculation The Key Tag field in the RRSIG and DS resource record types provides a mechanism for selecting a public key efficiently. In most cases, a combination of owner name, algorithm, and key tag can efficiently identify a DNSKEY record. Both the RRSIG and DS resource records have corresponding DNSKEY records. The Key Tag field in the RRSIG and DS records can be used to help select the corresponding DNSKEY RR efficiently when more than one candidate DNSKEY RR is available. However, it is essential to note that the key tag is not a unique identifier. It is theoretically possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm, and the same key tag. The key tag is used to limit the possible candidate keys, but it does not uniquely identify a DNSKEY record. Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR. The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First the RDATA (in wire format) is treated as a series of 2 octet groups, these groups are then added together ignoring any carry bits. A reference implementation of the key tag algorithm is as an ANSI C function is given below with the RDATA portion of the DNSKEY RR is used as input. It is not necessary to use the following reference code verbatim, but the numerical value of the Key Tag MUST be identical to what the reference implementation would generate for the same input. Please note that the algorithm for calculating the Key Tag is almost but not completely identical to the familiar ones complement checksum used in many other Internet protocols. Key Tags MUST be calculated using the algorithm described here rather than the ones complement checksum. The following ANSI C reference implementation calculates the value of a Key Tag. This reference implementation applies to all algorithm types except algorithm 1 (see Appendix B.1). The input is the wire format of the RDATA portion of the DNSKEY RR. The code is written for clarity, not efficiency.Arends, et al. Expires January 13, 2005 [Page 31] Internet-Draft DNSSEC Resource Records July 2004 /* * Assumes that int is at least 16 bits. * First octet of the key tag is the most significant 8 bits of the * return value; * Second octet of the key tag is the least significant 8 bits of the * return value. */ unsigned int keytag ( unsigned char key[], /* the RDATA part of the DNSKEY RR */ unsigned int keysize /* the RDLENGTH */ ) { unsigned long ac; /* assumed to be 32 bits or larger */ int i; /* loop index */ for ( ac = 0, i = 0; i < keysize; ++i ) ac += (i & 1) ? key[i] : key[i] << 8; ac += (ac >> 16) & 0xFFFF; return ac & 0xFFFF; }B.1 Key Tag for Algorithm 1 (RSA/MD5) The key tag for algorithm 1 (RSA/MD5) is defined differently than the key tag for all other algorithms, for historical reasons. For a DNSKEY RR with algorithm 1, the key tag is defined to be the most significant 16 bits of the least significant 24 bits in the public key modulus (in other words, the 4th to last and 3rd to last octets of the public key modulus). Please note that Algorithm 1 is NOT RECOMMENDED.Arends, et al. Expires January 13, 2005 [Page 32] Internet-Draft DNSSEC Resource Records July 2004Intellectual 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 (2004). 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.Arends, et al. Expires January 13, 2005 [Page 33] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -