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

[Hoyt L Kesterson II <hoytkesterson@xxxxxxxxxxxxx>]

Title: Re: New Liaison Statement, "Liaison to IETF on the removal

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?
> 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.