Re: Upper Bounds for X.509

[Hoyt L Kesterson II <hoytkesterson@xxxxxxxxxxxxx>]

I had hoped that the LDAP people would join this conversation. Unless I misunderstood, I was told that LDAP never utilized these bounds and that it did not cause interoperability problems.

Another option is to keep the bounds as we have them and have the IETF standard mandate the bounds, choosing any values you like.

Does anyone out there test conformance to these limits? If exceeded, what error is generated? Does certificate generating software enforce the bounds? Does relying party software validate the bounds in received certificate?

    hoyt


-----Original Message-----
>From: Russ Housley <housley@xxxxxxxxxxxx>
>Sent: Oct 19, 2007 10:06 AM
>To: Erik Andersen <era@xxxxxxxxxx>, PKIX <ietf-pkix@xxxxxxx>
>Subject: Re: Upper Bounds for X.509
>
>I understand that an unbounded directory string may be useful in manycontexts, but is it going to help interoperability to remove the boundson naming attributes?
>
>Russ
>
>At 10:19 AM 10/19/2007, Erik Andersen wrote:
>Hi Folks,
> 
>As mentioned in a liaison statement from the directory meeting, September2007 in Geneva, we have decided to remove the Upper Bounds from anyoccurrence. A majority of those are on DirectoryString, which is alsospecified for many attribute types.
> 
>At one type we were considering removing the Upper Bound by the DefectReport procedure, but found the change to heavy for that procedure. Bythe Defect Report procedure we corrected a inconsistency in the UpperBounds and expressed that Upper Bounds are only provided asexamples.
> 
>It is our intention to remove the Upper Bound from the sixth edition ofthe Directory Specification. We gave a possible approach in the liaisonstatement, but that may not be the final solution. Be assured thatwhatever we do, it will be valid ASN.1. The example we came up with isactual valid ASN.1 by using parameterized specification. However, we arefaced with the problem that directory object class definitions will beparameterized. This does not change the definition as such, but only theASN.1 appearance. This could be a problem for implementations parsingsuch object class definitions to set-up the directory schema.
> 
>Our fall-back solution is to define a new variant of DirectoryString thatis unbounded.
> 
>Erik Andersen
>Andersen's L-Service
>Mobile: +45 20 97 14 90
>e-mail: era@xxxxxxxxxx
>http://www.x500standard.com/
>http://home20.inet.tele.dk/era/me
>