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

Russ Housley <housley@vigilsec.com> Fri, 05 October 2007 14:33 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 1IdoFa-0004QC-1z for pkix-archive@lists.ietf.org; Fri, 05 Oct 2007 10:33:58 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdoFN-0007uC-Nw for pkix-archive@lists.ietf.org; Fri, 05 Oct 2007 10:33:48 -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 l95Dpjx5015303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2007 06:51:45 -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 l95DpjHA015302; Fri, 5 Oct 2007 06:51:45 -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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l95Dpirn015296 for <ietf-pkix@imc.org>; Fri, 5 Oct 2007 06:51:45 -0700 (MST) (envelope-from housley@vigilsec.com)
Message-Id: <200710051351.l95Dpirn015296@balder-227.proper.com>
Received: (qmail 17743 invoked by uid 0); 5 Oct 2007 13:51:41 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (207.236.147.202) by woodstock.binhost.com with SMTP; 5 Oct 2007 13:51:41 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 05 Oct 2007 09:51:40 -0400
To: ietf-pkix@imc.org
From: Russ Housley <housley@vigilsec.com>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
Cc: hoytkesterson@earthlink.com
In-Reply-To: <E1Idm9H-0000PX-7d@ietf.org>
References: <E1Idm9H-0000PX-7d@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: 1.5 (+)
X-Scan-Signature: 386e0819b1192672467565a524848168

When the upper bound values are embedded in the ASN.1 module, how can 
they be non-normative?

These are the values that appear in RFC 3280:

-- Upper Bounds
ub-name INTEGER ::= 32768
ub-common-name INTEGER ::= 64
ub-locality-name INTEGER ::= 128
ub-state-name INTEGER ::= 128
ub-organization-name INTEGER ::= 64
ub-organizational-unit-name INTEGER ::= 64
ub-title INTEGER ::= 64
ub-serial-number INTEGER ::= 64
ub-match INTEGER ::= 128
ub-emailaddress-length INTEGER ::= 128
ub-common-name-length INTEGER ::= 64
ub-country-name-alpha-length INTEGER ::= 2
ub-country-name-numeric-length INTEGER ::= 3
ub-domain-defined-attributes INTEGER ::= 4
ub-domain-defined-attribute-type-length INTEGER ::= 8
ub-domain-defined-attribute-value-length INTEGER ::= 128
ub-domain-name-length INTEGER ::= 16
ub-extension-attributes INTEGER ::= 256
ub-e163-4-number-length INTEGER ::= 15
ub-e163-4-sub-address-length INTEGER ::= 40
ub-generation-qualifier-length INTEGER ::= 3
ub-given-name-length INTEGER ::= 16
ub-initials-length INTEGER ::= 5
ub-integer-options INTEGER ::= 256
ub-numeric-user-id-length INTEGER ::= 32
ub-organization-name-length INTEGER ::= 64
ub-organizational-unit-name-length INTEGER ::= 32
ub-organizational-units INTEGER ::= 4
ub-pds-name-length INTEGER ::= 16
ub-pds-parameter-length INTEGER ::= 30
ub-pds-physical-address-lines INTEGER ::= 6
ub-postal-code-length INTEGER ::= 16
ub-pseudonym INTEGER ::= 128
ub-surname-length INTEGER ::= 40
ub-terminal-id-length INTEGER ::= 24
ub-unformatted-address-length INTEGER ::= 180
ub-x121-address-length INTEGER ::= 16

At 08:19 AM 10/5/2007, ITU-T SG 17 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: 
>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=376
>Please reply by 2008-03-01
>
>From: Xiaoya Yang(ITU-T SG 17) <tsbsg17@itu.int>
>To: IETF/PKIX(Russ Housley <housley@vigilsec.com>om>, Stefan Santesson 
><stefans@microsoft.com>)
>Cc: Herbert Bertine <hbertine@alcatel-lucent.com>
><tsbsg17@itu.int>
><era@tdcadsl.dk>
>Reponse Contact: Xiaoya YANG <xiaoya.yang@itu.int>
><tsbsg17@itu.int>
>Technical Contact: <era@tdcadsl.dk>
>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.