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

Russ Housley <> Sat, 06 October 2007 14:30 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IeAfU-0002bC-3F for; Sat, 06 Oct 2007 10:30:12 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IeAfJ-0006Re-OZ for; Sat, 06 Oct 2007 10:30:08 -0400
Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id l96DN6pW032041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Oct 2007 06:23:06 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id l96DN6Yj032040; Sat, 6 Oct 2007 06:23:06 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with SMTP id l96DN5qg032032 for <>; Sat, 6 Oct 2007 06:23:05 -0700 (MST) (envelope-from
Message-Id: <>
Received: (qmail 2902 invoked by uid 0); 6 Oct 2007 13:23:02 -0000
Received: from unknown (HELO ( by with SMTP; 6 Oct 2007 13:23:02 -0000
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sat, 06 Oct 2007 09:22:38 -0400
From: Russ Housley <>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>
X-Spam-Score: 3.2 (+++)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1

In the 1988 blue book, the Upper Bounds annex and module were normative. It also limited common name to 64 bytes.

The next edition (1993) contained: "This annex does not form an integral part of this Recommendation | International Standard."

The third edition (1997) contains the same text as the second edition. And, ub-name has the value of 32768.

The fourth edition (2000) is the same as the third. However, ub-name hase a different value; it is set to 128.

The PKIX WG seems to be using the 1997 upper bound numbers, but they are normative in RFC 2459 and RFC 3280.

Personally, I missed the subtle change from normative to informative.  I suspect many others did too.  If the PKIX WG to make them informative too, then it will have to be done *right now*.  The 3280bis document has started the approval process.  According to the Data Tracker, Sam Hartman is doing his AD Review right now.


At 09:44 AM 10/5/2007, Russ Housley wrote:

Title: Liaison to IETF on the removal of upper bound in X.509
Submission Date: 2007-10-05
URL of the IETF Web page:" rel="nofollow">
Please reply by 2008-03-01

From: Xiaoya Yang(ITU-T SG 17) <>
To: IETF/PKIX(Russ Housley <>, Stefan Santesson <>)
Cc: Herbert Bertine <>
Reponse Contact: Xiaoya YANG <>
Technical Contact: <>
Purpose: For action
Body: 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.
In response to developer demand in the early days of the standard X.520 contained a list of maximum lengths for a variety of string types, e.g., organizationalName.  The values specified were non-normative.  However, some implementers treated the values as normative.  This has caused interoperability problem with implementations.
We plan to remove the upper bounds specified in the standard. In particular we intend to eliminate the Upper Bounds for DirectoryString.
The proposal does not change the definition of DirectoryString, but attribute definitions will look slightly different.  As an example, street address may

streetAddress{INTEGER:maxSize}  ATTRIBUTE  ::=  {
        WITH SYNTAX                                         DirectoryString {maxSize}
        EQUALITY MATCHING RULE                    caseIgnoreMatch
        SUBSTRINGS MATCHING RULE                  caseIgnoreSubstringsMatch
        ID                                                              id-at-streetAddress }
That means that at implementation time, the upper limit may be added if wanted. Otherwise an unlimited string may be assumed.
The proposal will not change the bits on the wire and we believe this is in line with what the PXIX group is already doing.  We are forwarding this liaison to ensure that the PKIX group has no problem with this proposal.
Please confirm that you have no objection to our removal of upper bounds.
No document has been attached