Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"

Steven Legg <steven.legg@eb2bcom.com> Fri, 12 October 2007 02:55 UTC

Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAgV-0004NU-Gf for pkix-archive@lists.ietf.org; Thu, 11 Oct 2007 22:55:31 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgAgL-00006p-87 for pkix-archive@lists.ietf.org; Thu, 11 Oct 2007 22:55:27 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9C11p0M087302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 18:01:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9C11pAw087301; Thu, 11 Oct 2007 18:01:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9C11mMB087287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Thu, 11 Oct 2007 18:01:50 -0700 (MST) (envelope-from steven.legg@eb2bcom.com)
Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from <steven.legg@eb2bcom.com>) id 1Ig8uN-0003gB-V6; Fri, 12 Oct 2007 11:01:44 +1000
Message-ID: <470EC778.500@eb2bcom.com>
Date: Fri, 12 Oct 2007 11:01:44 +1000
From: Steven Legg <steven.legg@eb2bcom.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
CC: ietf-pkix@imc.org
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
References: <4707E6DA.1070703@cs.tcd.ie> <2788466ED3E31C418E9ACC5C316615570536E1@mou1wnexmb09.vcorp.ad.vrsn.com> <FA998122A677CF4390C1E291BFCF59890849839E@EXCH.missi.ncsc.mil> <470BB253.3030703@cs.tcd.ie> <FA998122A677CF4390C1E291BFCF598908498416@EXCH.missi.ncsc.mil> <470C1C32.70603@eb2bcom.com> <E75F200AF1718F45B2024A88C3141A1D06437A82F3@EA-EXMSG-C320.europe.corp.micr osoft.com> <p0624082cc331ad9846db@[192.168.1.100]> <470C1FA3.40000@eb2bcom.com> <p06240801c332913ed8ad@[192.168.1.3]>
In-Reply-To: <p06240801c332913ed8ad@[192.168.1.3]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source:
X-Source-Args:
X-Source-Dir:
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43


Paul,

Paul Hoffman wrote:
> 
> At 10:26 AM +1000 10/10/07, Steven Legg wrote:
>> The way out of this dilemma is for PKIX, LDAP and X.500 to agree
>> on the upper bounds. The consensus in the X.500 working group is
>> to completely remove the (non-normative) upper bounds, rather than
>> rejigging them.
> 
> Has the X.500 working group communicated that to the PKIX WG, or the IETF?

Yes, in the liaison statement where it says "We plan to remove the
upper bounds specified in the standard". The example change to X.520
suggests that "the standard" means more than just X.509.

> 
> At 10:41 AM +1000 10/10/07, Steven Legg wrote:
>>> - Do we object to the ITU making the upper bound on DirectoryString 
>>> optional
>>
>> They've been optional since the second edition of X.500. The defect
>> resolution will make that clearer, as well as steering away from
>> any specific suggestions for the upper bounds.
> 
> We disagree that this DR "will make it clearer". What was sent to the 
> PKIX WG said:
> 
> In relation to resolve a Defect Report, it appears to majority within 
> the X.500 community to remove hard-coded length restriction whenever a 
> DirectoryString is used.
> . . .
> We plan to remove the upper bounds specified in the standard. In 
> particular we intend to eliminate the Upper Bounds for DirectoryString.
> 
> That does not sound anything like "They've been optional since the 
> second edition of X.500."

It has been established on this list that the upper bounds in X.500
have been non-normative since the second edition. If they are
non-normative, then an implementation can set the upper bounds to
whatever it wants, including the largest number anyone has ever thought
of, effectively making the upper bounds optional.

> 
> Could you get the X.500 working group to make it clear if they are 
> considering, or have already, removed the upper bounds on all the 
> X.500-related strings that Russ listed?

I had a closer look at RFC 3280. Some of the upper bounds originate
from X.500, but there is a bunch of upper bounds constraining
component parts of ORAddress that come from X.400, primarily the
upper bounds with names ending with "-length". The former are in
scope for the change contemplated by the X.500 working group, but
the latter are not.

I've prodded some ITU-T folks to publicly confirm the situation.

> 
>>> - Should we do anything to draft-ietf-pkix-rfc3280bis to reflect that
>>>
>>> The answer to the first should be "no, we don't". Russ gave a list 
>>> that shows the the ITU has a *long* way to go before it gets rid of 
>>> the silly maximum lengths in X.509.
>>
>> The defect resolution will throw them all out at the same time.
> 
> Where does it say that? The DR listed exactly one string type, 
> DirectoryString. Again, having this be clearer would help us out a lot.

The liaison statement said "We plan to remove the upper bounds specified
in the standard". The following sentence beginning "In particular"
suggests to me that DirectoryString is a pertinent case, but by no means
the only case.

By the way, the liaison statement is not the defect resolution, and in any
case I've been informed there has been a change in strategy. The upper bounds
will be removed via an extension to X.500 rather than through a defect
resolution. I will leave it to someone from the ITU-T to confirm.

Regards,
Steven

> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
>