[dnsext] [Technical Errata Reported] RFC4034 (2681)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 05 January 2011 22:16 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247F73A6CD9 for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 14:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.807
X-Spam-Level:
X-Spam-Status: No, score=-99.807 tagged_above=-999 required=5 tests=[AWL=-2.207, BAYES_00=-2.599, GB_SUMOF=5, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwvuSJb3Eq5x for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 14:16:08 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 6FE253A67D6 for <dnsext@ietf.org>; Wed, 5 Jan 2011 14:16:08 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id A7E0FE0701; Wed, 5 Jan 2011 14:18:15 -0800 (PST)
To: roy.arends@telin.nl, sra@isc.org, mlarson@verisign.com, massey@cs.colostate.edu, scott.rose@nist.gov, rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, ajs@shinkuro.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20110105221815.A7E0FE0701@rfc-editor.org>
Date: Wed, 05 Jan 2011 14:18:15 -0800
X-Mailman-Approved-At: Wed, 05 Jan 2011 14:46:53 -0800
Cc: gubailey@microsoft.com, dnsext@ietf.org, rfc-editor@rfc-editor.org
Subject: [dnsext] [Technical Errata Reported] RFC4034 (2681)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2011 22:16:09 -0000

The following errata report has been submitted for RFC4034,
"Resource Records for the DNS Security Extensions".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=2681

--------------------------------------
Type: Technical
Reported by: Guillaume Bailey <gubailey@microsoft.com>

Section: B

Original Text
-------------
   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.


Corrected Text
--------------
   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 with at least 32-bit precision,
   retaining any carry bits. The carry bits are then added to the result,
   and finally, only the lower 16 bits of the result are used as the key 
   tag.



Notes
-----
This change comes from the example implementation. The accumulator, ac, is required ("assumed") to be 32-bits or larger, and the carry bits are added to the accumulator before returning:

    ac += (ac >> 16) & 0xFFFF;

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4034 (draft-ietf-dnsext-dnssec-records-11)
--------------------------------------
Title               : Resource Records for the DNS Security Extensions
Publication Date    : March 2005
Author(s)           : R. Arends, R. Austein, M. Larson, D. Massey, S. Rose
Category            : PROPOSED STANDARD
Source              : DNS Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG