Re: Upper Bounds for X.509

[Steven Legg <steven.legg@xxxxxxxxxxx>]

Russ,

Russ Housley wrote:
> I understand that an unbounded directory string may be useful in many 
> contexts, but is it going to help interoperability to remove the bounds 
> on naming attributes?

As I recall, it was an upper bound on a naming attribute that we first
bumped up against, and which prompted us to ignore all the upper bounds.
Ignoring the upper bounds also allows us to claim conformance with LDAP,
which imposes no upper bounds. Clearly there is the potential for
interoperability problems if we interwork with an implementation that
imposes upper bounds. To the best of my knowledge such problems haven't
arisen with respect to our implementation. I assume that in each instance
of interworking the other system also ignores the upper bounds, or else
the shared data happen to be within that other system's upper bounds.
Nonetheless, the potential for interoperability problems diminishes if
the upper bounds are discarded.

Regards,
Steven

> Russ
>
> At 10:19 AM 10/19/2007, Erik Andersen wrote:
> > Hi Folks,
> >  
> > As mentioned in a liaison statement from the directory meeting, 
> > September 2007 in Geneva, we have decided to remove the Upper Bounds 
> > from any occurrence. A majority of those are on DirectoryString, which 
> > is also specified for many attribute types.
> >  
> > At one type we were considering removing the Upper Bound by the Defect 
> > Report procedure, but found the change to heavy for that procedure. By 
> > the Defect Report procedure we corrected a inconsistency in the Upper 
> > Bounds and expressed that Upper Bounds are only provided as examples.
> >  
> > It is our intention to remove the Upper Bound from the sixth edition 
> > of the Directory Specification. We gave a possible approach in the 
> > liaison statement, but that may not be the final solution. Be assured 
> > that whatever we do, it will be valid ASN.1. The example we came up 
> > with is actual valid ASN.1 by using parameterized specification. 
> > However, we are faced with the problem that directory object class 
> > definitions will be parameterized. This does not change the definition 
> > as such, but only the ASN.1 appearance. This could be a problem for 
> > implementations parsing such object class definitions to set-up the 
> > directory schema.
> >  
> > Our fall-back solution is to define a new variant of DirectoryString 
> > that is unbounded.
> >  
> > Erik Andersen
> > Andersen's L-Service
> > Mobile: +45 20 97 14 90
> > e-mail: era@xxxxxxxxxx <mailto:era@xxxxxxxxxx>
> > http://www.x500standard.com/
> > http://home20.inet.tele.dk/era/me
> >