Subject: Re: Upper Bounds for X.509

From: Hoyt L Kesterson II <[email-masked]>
Date: Fri, 19 Oct 2007 10:49:39 -0700 (GMT-07:00)

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 <[email-masked]>
>Sent: Oct 19, 2007 10:06 AM
>To: Erik Andersen <[email-masked]>, PKIX <[email-masked]>
>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: [email-masked]
>http://www.x500standard.com/
>http://home20.inet.tele.dk/era/me
>

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 21 Oct 2007 01:11:46 +1300

Hoyt L Kesterson II <[email-masked]> writes:

>Does certificate generating software enforce the bounds?
>
>Does relying party software validate the bounds in received certificate?

Yes.  I think there should be some reasonable upper bound (1K perhaps) as a
safety feature to prevent MPEG-of-cat certificates.  People are going to stuff
anything they feel like into certs, aided and abetted by software that hides
the details of what they're doing (dragging an icon to a drop target doesn't
convey the fact that adding a 20MB Flash animation at that location isn't very
sensible).  So making it unbounded is asking for trouble.  Setting a
reasonable upper bound (does anyone really have a common name more than a
thousand characters long?) is a good safety setting.

(Oh, and an aside: When I created the MPEG-of-cat cert, with a (by current
standards) relatively small ~1MB MPEG in there, neither Windows nor Netscape
(the two main cert apps at the time) complained about finding over a million
characters in what should be a short field.  However, both of them performed
very erratically, and in the case of Netscape I had to delete the browser cert
database after a couple of days to restore proper operation to the browser.
So current apps will quite readily accept stupid sizes for these fields, and
nicely DoS themselves in the process.  Another argument for setting upper
limits).

Peter.

---

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

Hoyt,

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

Then directory deployments would have to choose between being nice
to PKIX applications by imposing PKIX's upper bounds, or being
nice to other LDAP applications by not imposing upper bounds.

Regards,
Steven

---

From: Hoyt L Kesterson II <[email-masked]>
Date: Mon, 22 Oct 2007 01:30:50 -0700

Steven, I didn't say it was an attractive option. I have always been against these limits.

Peter Gutmann recommended that "reasonable" upper bounds be set, e.g. thousand characters for a common name. But it appears his concern is about erratic operation when the certificate itself it huge.

It may be more reasonable to set a max size on the entire certificate than on the individual components that comprise it.

   hoyt

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Oct 2007 06:33:38 -0400

Hoyt:

One never knows which non-critical extensions might be put in a 
certificate.  Remember when Bob Jueneman was advocating pictures in 
certificates....

Russ

At 04:30 AM 10/22/2007, Hoyt L Kesterson II wrote:

>Peter Gutmann recommended that "reasonable" upper bounds be set, 
>e.g. thousand characters for a common name. But it appears his 
>concern is about erratic operation when the certificate itself it huge.
>
>It may be more reasonable to set a max size on the entire 
>certificate than on the individual components that comprise it.
>
>    hoyt
>
> >Hoyt,
> >
> >>Another option is to keep the bounds as we have them and have the 
> IETF standard mandate the bounds, choosing any values you like.
> >

---

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

PKIX could impose upper bounds on anything they want without this being
reflected in the ASN.1, but in English text.

Erik Andersen
Andersen's L-Service
Mobile: +45 20 97 14 90
e-mail: [email-masked]

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Russ Housley
> Sent: 22. oktober 2007 11:34
> To: Hoyt L Kesterson II; [email-masked]