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

[Russ Housley <housley@xxxxxxxxxxxx>]

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@xxxxxxx>
> To: IETF/PKIX(Russ Housley <housley@xxxxxxxxxxxx>, Stefan Santesson 
> <stefans@xxxxxxxxxxxxx>)
> Cc: Herbert Bertine <hbertine@xxxxxxxxxxxxxxxxxx>
> <tsbsg17@xxxxxxx>
> <era@xxxxxxxxxx>
> Reponse Contact: Xiaoya YANG <xiaoya.yang@xxxxxxx>
> <tsbsg17@xxxxxxx>
> Technical Contact: <era@xxxxxxxxxx>
> 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.