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

From: Russ Housley <[email-masked]>
Date: Fri, 05 Oct 2007 09:51:40 -0400

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

---

From: Hoyt L Kesterson II <[email-masked]>
Date: Fri, 5 Oct 2007 09:40:08 -0700

Annex C (and Annex B) of X.520 | 9594-6 contains the following
line just below the Title Line of the Annex:  (This annex does not form an
integral part of this Recommendation | International
Standard)

This is standardeeze for informative, i.e. not required to
conform.

These values initially came from the OSI workshops of long ago.
They wanted them in the standard; I argued they were somewhat
arbitrary and should instead be agreements within specific communities
(who was I to deny the right to name someone Throckmorton P.
Gildersleeve VIII).

I felt that many values were set not to ease the implementation
effort but because the group felt that the limits reflected real
limits. I suggested they agree on a what they felt to be a practical
number and then double it but the group stood firm. Realize that some
of those people felt AE-title was too long and wanted OIDs for
directory names.

We compromised by putting the limits in the standard but making
the annex, and thus the values, informative instead of normative. We
felt that if a value needed to be changed, an implementor's group
could do it faster than the two years it would take to make a
non-error-driven change to the standard.

We recently had a discussion of this on the directory email list
where several LDAP people said that such limits were not useful.

We did know that some developers have interpreted the values as
fixed maximums while others have adjusted them to meet the need.

This difference of understanding has caused interworking problems
in the past. (A similar problem arose from the diagram in Annex B of
X.521 | 9594-7 Selected Object Classes. Even though the same
"not form an integral part" appears and the title of the
Annex is Suggested Name Forms and DIT Structures, we still saw
developers refer to the X.500 standardized name.

In the discussions in Geneva we thought it might be a good idea
to get rid of the problem entirely by removing bounds. We felt such a
change to the ASN.1 wouldn't change the "bits on the wire"
but might change the receiver's code. Hence the liaison to PKIX.

For information, here are the suggested values from that
annex in X.520.

ub-answerback
INTEGER    ::=    8

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

ub-x121-address
INTEGER    ::=    15

hoyt

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

-- Upper Bounds

ub-title INTEGER ::= 64

ub-match INTEGER ::= 128

Title: Liaison to IETF on the removal of
upper bound in X.509

To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan
Santesson <[email-masked]>)

<[email-masked]>

<[email-masked]>

<[email-masked]>

Purpose: For action

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

WITH

EQUALITY MATCHING
RULE                  caseIgnoreMatch

SUBSTRINGS MATCHING
RULE                caseIgnoreSubstringsMatch

ID id-at-streetAddress
}

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.