 1/draftietfdnsextrsa00.txt 20060204 23:12:32.000000000 +0100
+++ 2/draftietfdnsextrsa01.txt 20060204 23:12:32.000000000 +0100
@@ 1,17 +1,17 @@
INTERNETDRAFT RSA SIGs and KEYs in the DNS
OBSOLETES RFC 2537 August 2000
 Expires February 2001
+OBSOLETES RFC 2537 September 2000
+ Expires March 2001
RSA/SHA1 SIGs and RSA KEYs in the Domain Name System (DNS)
          

+
D. Eastlake 3rd
Status of This Document
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNS extensions mailing list or to
the author.
This document is an InternetDraft and is in full conformance with
@@ 36,37 +36,48 @@
Since the adoption of a Proposed Standard for RSA signatures in the
DNS [RFC 2537], advances in hashing have been made. A new DNS
signature algorithm is defined to make these advances available in
SIG resource records (RRs). The use of the previously specified
weaker mechanism is deprecated. The algorithm number of the RSA KEY
RR is changed to correspond to this new SIG algorithm. No other
changes are made to DNS security.
INTERNETDRAFT RSA/SHA1 in the DNS
+Acknowledgements
+
+ Material and comments from the following have been incorporated and
+ are gratefully acknowledged:
+
+ Olafur Gudmundsson
+
+ Charlie Kaufman
+
Table of Contents
Status of This Document....................................1
Abstract...................................................1
+ Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
2. RSA Public KEY Resource Records.........................3
3. RSA/SHA1 SIG Resource Records...........................4
4. Performance Considerations..............................5
5. IANA Considerations.....................................6
6. Security Considerations.................................6
References.................................................7
Author's Address...........................................8
+ Changes from last draft....................................8
Expiration and File Name...................................8
INTERNETDRAFT RSA/SHA1 in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information [RFC 1034, 1035, etc.]. The DNS has been extended
to include digital signatures and cryptographic keys as described in
@@ 129,56 +140,57 @@
prohibited in the exponent and modulus.
Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
algorithm number (rather than the algorithm number specified in the
obsoleted [RFC 2537]).
[Note: This changes the algorithm number for RSA KEY RRs to be the
same as the new algorithm number for RSA/SHA1 SIGs. Or, from another
point of view, adds a new KEY RR with a new algorithm number that is
otherwise identical to the RSA KEY RR defined in RFC 2537. In fact,
 RSA KEYs do not depend on selection of hash algorihtm. An
+ RSA KEYs do not depend on selection of hash algorithm. An
alternative would be to leave RSA KEY RRs unchanged and indicated by
algorithm 1.]
3. RSA/SHA1 SIG Resource Records
RSA/SHA1 signatures are stored in the DNS using SIG resource records
(RRs) with algorithm number (TBD, 5 suggested).
The signature portion of the SIG RR RDATA area, when using the
RSA/SHA1 algorithm, is calculated as shown below. The data signed is
determined as specified in [RFC 2535]. See [RFC 2535] for fields in
the SIG RR RDATA which precede the signature itself.
hash = SHA1 ( data )
signature = ( 01  FF*  00  prefix  hash ) ** e (mod n)
+INTERNETDRAFT RSA/SHA1 in the DNS
+
where SHA1 is the message digest algorithm documented in [RFC 1321],
"" is concatenation, "e" is the private key exponent of the signer,
and "n" is the modulus of the signer's public key. 01, FF, and 00
are fixed octets of the corresponding hexadecimal value. "prefix" is
the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC
2437], that is,
INTERNETDRAFT RSA/SHA1 in the DNS

 hex (to be supplied).
+ hex 30 21 30 1F 06 05 2B 0E 03 02 1A 05 00 04 14
This prefix is included to make it easier to use standard
cryptographic libraries. The FF octet MUST be repeated the maximum
number of times such that the value of the quantity being
exponentiated is one octet shorter than the value of n.
(The above specifications are identical to the corresponding part of
 Public Key Cryptographic Standard #1 [RFC 2437].)
+ Public Key Cryptographic Standard #1 [RFC 2437]. The value for
+ prefix was provided by Charlie Kaufman.)
The size of "n", including most and least significant bits (which
will be 1) MUST be not less than 512 bits and not more than 4096
bits. "n" and "e" SHOULD be chosen such that the public exponent is
small. These are protocol limits. For a discussion of key size see
[RFC 2541].
Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
A public exponent of 3 minimizes the effort needed to verify a
@@ 196,27 +208,28 @@
generation with DSA is faster than RSA. Key generation is also
faster for DSA. However, signature verification is an order of
magnitude slower with DSA when the RSA public exponent is chosen to
be small as is recommended for KEY RRs used in domain name system
(DNS) data authentication.
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient, it
+
+INTERNETDRAFT RSA/SHA1 in the DNS
+
is still advisable at this time to make reasonable efforts to
minimize the size of KEY RR sets stored within the DNS consistent
with adequate security. Keep in mind that in a secure zone, at least
one authenticating SIG RR will also be returned.
INTERNETDRAFT RSA/SHA1 in the DNS

5. IANA Considerations
The DNSSEC algorithm number (TBD, 5 suggested) is allocated for
RSA/SHA1 SIG RRs and RSA KEY RRs.
6. Security Considerations
Many of the general security consideration in [RFC 2535] apply. Keys
retrieved from the DNS should not be trusted unless (1) they have
been securely obtained from a secure resolver or independently
@@ 281,15 +294,19 @@
Donald E. Eastlake 3rd
Motorola
140 Forest Avenue
Hudson, MA 01749 USA
Telephone: +19785622827 (h)
+15082615434 (w)
FAX: +15082614777 (w)
EMail: Donald.Eastlake@motorola.com
+Changes from last draft
+
+ Add acknowledgements and hex value for signature "prefix".
+
Expiration and File Name
 This draft expires in February 2001.
+ This draft expires in March 2001.
 Its file name is drafteastlakednsextrsa00.txt.
+ Its file name is draftietfdnsextrsa01.txt.