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

[Russ Housley <[e-mail]>]

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) <[e-mail]>
>To: IETF/PKIX(Russ Housley <[e-mail]>, Stefan Santesson 
><[e-mail]>)
>Cc: Herbert Bertine <[e-mail]>
><[e-mail]>
><[e-mail]>
>Reponse Contact: Xiaoya YANG <[e-mail]>
><[e-mail]>
>Technical Contact: <[e-mail]>
>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.