1 files changed, 392 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
new file mode 100644
index 0000000..390420a
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
@@ -0,0 +1,392 @@
+
+
+
+DNS Extensions working group                                   J. Jansen
+Internet-Draft                                                NLnet Labs
+Expires: July 5, 2006                                       January 2006
+
+
+     Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
+                 draft-ietf-dnsext-dnssec-rsasha256-00
+
+Status of this Memo
+
+   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 becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 5, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
+   resource records for use in the Domain Name System Security
+   Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 1]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
+   3.  RSA/SHA-256 RRSIG Resource Records  . . . . . . . . . . . . . . 3
+   4.  Implementation Considerations . . . . . . . . . . . . . . . . . 4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 2]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Addressing.  The DNS has been extended to use
+   digital signatures and cryptographic keys for the verification of
+   data.  RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
+   Security Extensions.
+
+   RFC4034 describes how to store DNSKEY and RRSIG resource records, and
+   specifies a list of cryptographic algorithms to use.  This document
+   extends that list with the algorithm RSA/SHA-256, and specifies how
+   to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
+   resource records.
+
+   Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
+   this document.
+
+
+2.  RSA/SHA-256 DNSKEY Resource Records
+
+   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
+   resource records (RRs) with the algorithm number [TBA].
+
+   The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
+   [6].
+
+
+3.  RSA/SHA-256 RRSIG Resource Records
+
+   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
+   records (RRs) with algorithm number [TBA].
+
+   The value of the signature field in the RRSIG RR is calculated as
+   follows.  The values for the fields that precede the signature data
+   are specified in RFC4034 [2].
+
+   hash = SHA-256(data)
+
+   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+   Where SHA-256 is the message digest algorithm as specified in FIPS
+   180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
+   corresponding hexadecimal value, "e" is the private exponent of the
+   signing RSA key, and "n" is the public modulus of the signing key.
+   The FF octet MUST be repeated the maximum number of times so that the
+   total length of the signature equals the length of the modulus of the
+   signer's public key ("n"). "data" is the data of the resource record
+   set that is signed, as specified in RFC4034 [2].
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 3]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+   The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
+   specified in PKCS 2.1 [4]:
+
+   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
+
+   This prefix should make the use of standard cryptographic libraries
+   easier.  These specifications are taken directly from PKCS #1 v2.1
+   section 9.2 [4].
+
+
+4.  Implementation Considerations
+
+   DNSSEC aware implementations MUST be able to support RRSIG resource
+   records with the RSA/SHA-256 algorithm.
+
+   If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
+   available for a certain rrset, with a secure path to their keys, the
+   validator SHOULD ignore the SHA-1 signature.  If the RSA/SHA-256
+   signature does not verify the data, and the RSA/SHA-1 does, the
+   validator SHOULD mark the data with the security status from the RSA/
+   SHA-256 signature.
+
+
+5.  IANA Considerations
+
+   IANA has not yet assigned an algorithm number for RSA/SHA-256.
+
+   The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
+   following entry:
+
+                                   Zone
+   Value Algorithm    [Mnemonic] Signing  References   Status
+   ----- ----------- ----------- -------- ----------  ---------
+   [tba] RSA/SHA-256 [RSASHA256]      y        [TBA]  MANDATORY
+
+
+6.  Security Considerations
+
+   Recently, weaknesses have been discovered in the SHA-1 hashing
+   algorithm.  It is therefore strongly encouraged to deploy SHA-256
+   where SHA-1 is used now, as soon as the DNS software supports it.
+
+   SHA-256 is considered sufficiently strong for the immediate future,
+   but predictions about future development in cryptography and
+   cryptanalysis are beyond the scope of this document.
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 4]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+7.  Acknowledgments
+
+   This document is a minor extension to RFC4034 [2].  Also, we try to
+   follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
+   [8] for consistency.  The authors of and contributors to these
+   documents are gratefully acknowledged for their hard work.
+
+   The following people provided additional feedback and text: Jaap
+   Akkerhuis, Miek Gieben and Wouter Wijngaards.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
+        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
+        RFC 3447, February 2003.
+
+   [5]  National Institute of Standards and Technology, "Secure Hash
+        Standard", FIPS PUB 180-2, August 2002.
+
+   [6]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+        System (DNS)", RFC 3110, May 2001.
+
+8.2.  Informative References
+
+   [7]  Schneier, B., "Applied Cryptography Second Edition: protocols,
+        algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
+        11709-9, 1996.
+
+   [8]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+        Resource Records (RRs)", Work in Progress Feb 2006.
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 5]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+Author's Address
+
+   Jelte Jansen
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098VA
+   NL
+
+   Email: jelte@NLnetLabs.nl
+   URI:   http://www.nlnetlabs.nl/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 6]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+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 (2006).  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.
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 7]
+