Subject: [pkix] [Technical Errata Reported] RFC3779 (2537)

From: RFC Errata System <[email-masked]>
Date: Thu, 30 Sep 2010 18:24:39 -0700 (PDT)

The following errata report has been submitted for RFC3779,
"X.509 Extensions for IP Addresses and AS Identifiers".

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

--------------------------------------
Type: Technical
Reported by: Jim Schaad <[email-masked]>

Section: 2.2.3.9

Original Text
-------------
   To simplify the comparison of IP address blocks when performing
   certification path validation, a maximum IP address MUST contain at
   least one bit whose value is 1, i.e., the subsequent octets may not
   be omitted nor all zero.

Corrected Text
--------------
Text should be deleted.

Notes
-----
There are a number of different issues relative to this text that need to be addressed.

1.  This text implicitly change the rules for encoding a maximum value.  As an example the address 0.0.0.255 is encoded as 03 03 00 00 00 00 according to the rule " The BIT STRING for the maximum address results from removing all the least-significant one-bits from the maximum address."

2.  The rule in no way simplifies any comparisions of IP address blocks.  If one really wishes to simplify the comparison then one needs to change the rule for maximum addresses to remove all but the last least-signficant one-bit from the address.  However it is not clear that even this would really simplify the comparison in any significant way.

If you look at the example in 2.2.3.9 - tis is not clear how having the one bit at the top of the encoding helps make the comparisons any easier - but it satisfies the requirment that atleast one bit is a 1.  If the maximum value ws encoded as  1000 1   (0x3 0x02 0x03 0x84) - a bitwise comparision routine could make for a simplified a < b comparison (looking at only the top 5 bits of the address to be compared.)

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. 

--------------------------------------
RFC3779 (draft-ietf-pkix-x509-ipaddr-as-extn-03)
--------------------------------------
Title               : X.509 Extensions for IP Addresses and AS Identifiers
Publication Date    : June 2004
Author(s)           : C. Lynn, S. Kent, K. Seo
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Stephen Kent <[email-masked]>
Date: Thu, 21 Oct 2010 18:58:10 -0400

At 6:24 PM -0700 9/30/10, RFC Errata System wrote:
>1.  This text implicitly change the rules for encoding a maximum 
>value.  As an example the address 0.0.0.255 is encoded as 03 03 00 
>00 00 00 according to the rule " The BIT STRING for the maximum 
>address results from removing all the least-significant one-bits 
>from the maximum address."
>
>
>
>2.  The rule in no way simplifies any comparisions of IP address 
>blocks.  If one really wishes to simplify the comparison then one 
>needs to change the rule for maximum addresses to remove all but the 
>last least-signficant one-bit from the address.  However it is not 
>clear that even this would really simplify the comparison in any 
>significant way.
>
>
>
>If you look at the example in 2.2.3.9 - tis is not clear how having 
>the one bit at the top of the encoding helps make the comparisons 
>any easier - but it satisfies the requirment that atleast one bit is 
>a 1.  If the maximum value ws encoded as  1000 1   (0x3 0x02 0x03 
>0x84) - a bitwise comparision routine could make for a simplified a 
>< b comparison (looking at only the top 5 bits of the address to be 
>compared.)
>
>Instructions:
>-------------

I concur with the errata,i.e., the text in question should be removed.

Please note that one of my co-authors, Chales Lynn ([email-masked]), 
is deceased.

Steve