Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
Hoyt L Kesterson II <hoytkesterson@earthlink.net> Fri, 05 October 2007 17:28 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 1Idqyr-0008KS-88 for pkix-archive@lists.ietf.org; Fri, 05 Oct 2007 13:28:53 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idqye-0005dK-On for pkix-archive@lists.ietf.org; Fri, 05 Oct 2007 13:28:47 -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 l95GeMXR030157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2007 09:40:22 -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 l95GeMgB030156; Fri, 5 Oct 2007 09:40:22 -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 elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l95GeLxQ030149 for <ietf-pkix@imc.org>; Fri, 5 Oct 2007 09:40:22 -0700 (MST) (envelope-from hoytkesterson@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KZRnCIeQavBrtRsj7ZHiKAVIDkBUH9QYotkVPe11zl+RiGOQ7BpIhNeCDmuzFufY; h=Received:Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [151.118.180.188] (helo=[156.106.219.41]) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1IdqDs-0004J7-OW for ietf-pkix@imc.org; Fri, 05 Oct 2007 12:40:21 -0400
Mime-Version: 1.0
Message-Id: <a06240827c32c0e1933c4@[156.106.219.41]>
In-Reply-To: <200710051351.l95Dpirn015296@balder-227.proper.com>
References: <E1Idm9H-0000PX-7d@ietf.org> <200710051351.l95Dpirn015296@balder-227.proper.com>
Date: Fri, 05 Oct 2007 09:40:08 -0700
To: ietf-pkix@imc.org
From: Hoyt L Kesterson II <hoytkesterson@earthlink.net>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
Content-Type: text/html; charset="us-ascii"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d478ff8b85d7d168df7ae1f7ce53db6ecf5a22d82498bb8304f1350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 151.118.180.188
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.7 (+)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
ub-business-category INTEGER ::= 128
ub-common-name INTEGER ::= 64
ub-content INTEGER ::= 32768
ub-country-code INTEGER ::= 4
ub-description INTEGER ::= 1024
ub-destination-indicator INTEGER ::= 128
ub-directory-string-first-component-match INTEGER ::= 32768
ub-domainLocalID INTEGER ::= 64
ub-international-isdn-number INTEGER ::= 16
ub-knowledge-information INTEGER ::= 32768
ub-labeledURI INTEGER ::= 32768
ub-localeContextSyntax INTEGER ::= 128
ub-locality-name INTEGER ::= 128
ub-match INTEGER ::= 128
ub-name INTEGER ::= 64
ub-organization-name INTEGER ::= 64
ub-organizational-unit-name INTEGER ::= 64
ub-physical-office-name INTEGER ::= 128
ub-post-office-box INTEGER ::= 40
ub-postal-code INTEGER ::= 40
ub-postal-line INTEGER ::= 6
ub-postal-string INTEGER ::= 30
ub-privacy-mark-length INTEGER ::= 128
ub-pseudonym INTEGER ::= 128
ub-saslMechanism INTEGER ::= 64
ub-schema INTEGER ::= 1024
ub-search INTEGER ::= 32768
ub-serial-number INTEGER ::= 64
ub-state-name INTEGER ::= 128
ub-street-address INTEGER ::= 128
ub-surname INTEGER ::= 64
ub-tag INTEGER ::= 64
ub-telephone-number INTEGER ::= 32
ub-teletex-terminal-id INTEGER ::= 1024
ub-telex-number INTEGER ::= 14
ub-title INTEGER ::= 64
ub-user-password INTEGER ::= 128
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>, 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.
- Re: New Liaison Statement, "Liaison to IETF on th… Russ Housley
- FW: New Liaison Statement, "Liaison to IETF on th… Stefan Santesson
- Re: New Liaison Statement, "Liaison to IETF on th… Russ Housley
- Re: New Liaison Statement, "Liaison to IETF on th… Hoyt L Kesterson II
- Re: New Liaison Statement, "Liaison to IETF on th… Stephen Farrell
- RE: New Liaison Statement, "Liaison to IETF on th… Hallam-Baker, Phillip
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.
- Re: New Liaison Statement, "Liaison to IETF on th… Stephen Farrell
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.
- Re: FW: New Liaison Statement, "Liaison to IETF o… Paul Hoffman
- Re: New Liaison Statement, "Liaison to IETF on th… Steven Legg
- Re: FW: New Liaison Statement, "Liaison to IETF o… Steven Legg
- Re: New Liaison Statement, "Liaison to IETF on th… Stephen Farrell
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- Re: New Liaison Statement, "Liaison to IETF on th… Steven Legg
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.
- Re: New Liaison Statement, "Liaison to IETF on th… David Chadwick
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- Re: New Liaison Statement, "Liaison to IETF on th… David A. Cooper
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.