Subject: Upper Bounds for X.509

From: "Erik Andersen" <[email-masked]>
Date: Fri, 19 Oct 2007 16:19:41 +0200

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: [email-masked]

http://www.x500standard.com/

http://home20.inet.tele.dk/era/me

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Oct 2007 13:06:46 -0400

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?

Russ

At 10:19 AM 10/19/2007, Erik Andersen wrote:

Hi Folks,

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: [email-masked]

---

From: Steven Legg <[email-masked]>
Date: Mon, 22 Oct 2007 13:32:21 +1000

Russ,

> contexts, but is it going to help interoperability to remove the bounds 

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

>> 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.
>>  
>> 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: [email-masked] <mailto:[email-masked]>