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

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

In the 1988 blue book, the Upper Bounds annex and module were normative.
It also limited common name to 64 bytes.

The next edition (1993) contained: "This annex does not form an
integral part of this Recommendation | International
Standard."

The third edition (1997) contains the same text as the second edition.
And, ub-name has the value of 32768.

The fourth edition (2000) is the same as the third. However, ub-name hase
a different value; it is set to 128.

The PKIX WG seems to be using the 1997 upper bound numbers, but they are
normative in RFC 2459 and RFC 3280.

Personally, I missed the subtle change from normative to
informative.  I suspect many others did too.  If the PKIX WG to
make them informative too, then it will have to be done *right
now*.  The 3280bis document has started the approval process.
According to the Data Tracker, Sam Hartman is doing his AD Review right
now.

Russ

At 09:44 AM 10/5/2007, Russ Housley 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) <[email-masked]>

To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson
<[email-masked]>)

Cc: Herbert Bertine <[email-masked]>

<[email-masked]>

<[email-masked]>

Reponse Contact: Xiaoya YANG <[email-masked]>

<[email-masked]>

Technical Contact: <[email-masked]>

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.

Attachment(s):

No document has been attached

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 06 Oct 2007 20:49:46 +0100

Russ Housley wrote:
> Personally, I missed the subtle change from normative to informative.  I 
> suspect many others did too.  If the PKIX WG to make them informative 
> too, then it will have to be done *right now*.  

I see no reason to make such a change at this stage.

S.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 Oct 2007 16:31:32 -0700

How long will it be before I can issue a certificate that does not comply with the old bounds without this resulting in unexpected incompatibilities?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Saturday, October 06, 2007 3:50 PM
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: New Liaison Statement, "Liaison to IETF on the 
> removal of upper bound in X.509"
> 
> 
> 
> 
> Russ Housley wrote:
> informative.  
> > I suspect many others did too.  If the PKIX WG to make them 
> > informative too, then it will have to be done *right now*.
>

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 9 Oct 2007 12:24:35 -0400

A normative upper bound has the undesirable effect of requiring
implementations to be less liberal in what they accept.  An informative
upper bound provides guidance to CAs on maximizing interoperability,
and does not penalize relying applications that can accept much larger
structures.  If five years from now 99% of relying applications
can accept large fields (e.g. up to available memory) and the other
1% never move beyond hard-coded limits, then a CA can *never* exceed
the old bounds without risking unexpected incompatibility.  Nonetheless,
it is desirable to permit a CA to issue oversized certs that are
accepted
by 99% of relying products rather than requiring all relying products
to reject such certs as a condition of PKIX (but not X.509) compliance.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, October 08, 2007 7:32 PM
To: Stephen Farrell; Russ Housley
Cc: [email-masked]
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of
upper bound in X.509"

How long will it be before I can issue a certificate that does not
comply with the old bounds without this resulting in unexpected
incompatibilities?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Oct 2007 17:54:43 +0100

Kemp, David P. wrote:
> implementations to be less liberal in what they accept.  

No it doesn't. An application can, if it so chooses, support
a broader profile than PKIX.

 > An informative

An informative upper bound allows CAs to issue certs that won't be
accepted by implementations that enforce those upper bounds, which
hinders interop.

I would think that if there is real demand for a profile with larger,
or no, uppper bounds, then that'd be a simple I-D to write.

So, I still don't want to see 3280bis change in this respect at this
time.

S.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 9 Oct 2007 13:09:52 -0400

Then I suppose I misunderstand the meaning of compliance
with a normative value contained in an ASN.1 module.

If PKIX specifies
    ub-common-name INTEGER ::= 64

as normative, and profile X specifies
    ub-common-name INTEGER ::= 65

as normative, is an application (e.g. a browser or a CA)
compiled to profile X compliant with PKIX or not?

In particular, under what theory of compliance can a CA that
issues a 65 character common name be called non-PKIX-compliant
while a relying application that accepts a 65 character common
name be called PKIX-compliant while both are operating in
"profile X mode"?

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2007 12:55 PM
To: Kemp, David P.
Cc: Hallam-Baker, Phillip; Russ Housley; [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of
upper bound in X.509"

S.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Oct 2007 18:16:39 -0400

It seems like there are two questions here:

- Do we object to the ITU making the upper bound on DirectoryString optional

- Should we do anything to draft-ietf-pkix-rfc3280bis to reflect that

The answer to the first should be "no, we don't". Russ gave a list 
that shows the the ITU has a *long* way to go before it gets rid of 
the silly maximum lengths in X.509.

For me, the answer to the second question is "no" because of the 
large number of other silly limitations, most notably CommonName 
being 64 characters.

--Paul Hoffman, Director
--VPN Consortium

---

From: Steven Legg <[email-masked]>
Date: Wed, 10 Oct 2007 10:26:26 +1000

> compiled to profile X compliant with PKIX or not?

In the general case, an application could not be simultaneously
compliant with both. The application cannot accept a common name
with 65 characters from a profile X compliant application if there
is any chance that it may have to send that common name to a
PKIX-compliant application.

This situation reflects a dilemma faced by directory vendors in
this issue. We already have customers for which the current upper
bounds are too low and have to be relaxed. LDAP does not impose
upper bounds, so compliance with LDAP means ignoring the upper bounds.
But if the directory is being used by a PKIX-compliant CA, then
the upper bounds of RFC 3280 need to be enforced. These incompatible
requirements mean that a directory server cannot simultaneously
satisfy all PKIX, LDAP and X.500 compliant directory clients.

The way out of this dilemma is for PKIX, LDAP and X.500 to agree
on the upper bounds. The consensus in the X.500 working group is
to completely remove the (non-normative) upper bounds, rather than
rejigging them.

Regards,
Steven

---

From: Steven Legg <[email-masked]>
Date: Wed, 10 Oct 2007 10:41:07 +1000

Paul,

> - Do we object to the ITU making the upper bound on DirectoryString 

They've been optional since the second edition of X.500. The defect
resolution will make that clearer, as well as steering away from
any specific suggestions for the upper bounds.

> The answer to the first should be "no, we don't". Russ gave a list that 
> shows the the ITU has a *long* way to go before it gets rid of the silly 
> maximum lengths in X.509.

The defect resolution will throw them all out at the same time.

> 
> For me, the answer to the second question is "no" because of the large 
> number of other silly limitations, most notably CommonName being 64 
> characters.

Aren't these other silly limitations inherited from the upper bounds
in X.500 ? Alignment with X.500 and LDAP would mean removing these
limitations as well.

Regards,
Steven

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Oct 2007 05:01:09 +0100

I personally don't know that these upper bounds have become
a real issue since WG last call on 3280bis.

If they had, I'd expect a whole bunch of people to have said
so. They didn't, or I missed it.

So I think that we shouldn't change 3280bis, but would have
no problem with someone writing up an I-D that was a delta
on 3280bis that removed or reset those bounds. I reckon we'd
get that done in less than a year...maybe.

S.

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 10 Oct 2007 09:24:17 -0400

I agree that we shouldn't change 3280bis, particularly since
it is recycling as a Proposed Standard.  The next I-D series
leading to Draft Standard is plenty of time to make
this change.

At that time, I'd suggest retaining upper bounds as
informational with accompanying text stating that consumers
SHOULD accept data objects of unspecified size and that
producers MAY conform to the informational upper bounds
for legacy interoperability.

Dave

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2007 12:01 AM
To: Steven Legg
Cc: Kemp, David P.; [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of
upper bound in X.509"

S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Oct 2007 10:35:36 -0400

>to completely remove the (non-normative) upper bounds, rather than

Has the X.500 working group communicated that to the PKIX WG, or the IETF?

>any specific suggestions for the upper bounds.

We disagree that this DR "will make it clearer". What was sent to the 
PKIX WG said:

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.
. . .
We plan to remove the upper bounds specified in the standard. In 
particular we intend to eliminate the Upper Bounds for 
DirectoryString.

That does not sound anything like "They've been optional since the 
second edition of X.500."

Could you get the X.500 working group to make it clear if they are 
considering, or have already, removed the upper bounds on all the 
X.500-related strings that Russ listed?

>The defect resolution will throw them all out at the same time.

Where does it say that? The DR listed exactly one string type, 
DirectoryString. Again, having this be clearer would help us out a 
lot.

--Paul Hoffman, Director
--VPN Consortium

---

From: Steven Legg <[email-masked]>
Date: Fri, 12 Oct 2007 11:01:44 +1000

Paul,

> Has the X.500 working group communicated that to the PKIX WG, or the IETF?

Yes, in the liaison statement where it says "We plan to remove the
upper bounds specified in the standard". The example change to X.520
suggests that "the standard" means more than just X.509.

> the X.500 community to remove hard-coded length restriction whenever a 
> DirectoryString is used.
> . . .
> particular we intend to eliminate the Upper Bounds for DirectoryString.
> 

It has been established on this list that the upper bounds in X.500
have been non-normative since the second edition. If they are
non-normative, then an implementation can set the upper bounds to
whatever it wants, including the largest number anyone has ever thought
of, effectively making the upper bounds optional.

> X.500-related strings that Russ listed?

I had a closer look at RFC 3280. Some of the upper bounds originate
from X.500, but there is a bunch of upper bounds constraining
component parts of ORAddress that come from X.400, primarily the
upper bounds with names ending with "-length". The former are in
scope for the change contemplated by the X.500 working group, but
the latter are not.

I've prodded some ITU-T folks to publicly confirm the situation.

> DirectoryString. Again, having this be clearer would help us out a lot.

The liaison statement said "We plan to remove the upper bounds specified
in the standard". The following sentence beginning "In particular"
suggests to me that DirectoryString is a pertinent case, but by no means
the only case.

By the way, the liaison statement is not the defect resolution, and in any
case I've been informed there has been a change in strategy. The upper bounds
will be removed via an extension to X.500 rather than through a defect
resolution. I will leave it to someone from the ITU-T to confirm.

Regards,
Steven

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Oct 2007 10:29:16 -0400

>suggests that "the standard" means more than just X.509.

With all due respect, "suggests" is not enough here. Further, the 
sentence you quoute is the only one in the whole liaison statement 
that talks about more than just DirectoryString.

Before the PKIX WG acts (such as changing RFC3280bis), we should get 
a clearer liaison statement, hopefully one that says "all upper 
bounds have been removed".

>have been non-normative since the second edition.

You said that in an earlier message. Could you point us to a specific 
section of a specific version of X.500 where that is true? Most of us 
are not X.500 users.

>scope for the change contemplated by the X.500 working group, but

We can probably change things relating to X.400 without fear of 
real-world interop problems.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 12 Oct 2007 14:14:35 -0400

---------- 1993 ---------
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-199311-S!!P
DF-E&type=items

ISO/IEC 9594-6 : 1995 (E)
22 ITU-T Rec. X.520 (1993 E) Superseded by a more recent version
Annex A
Selected attribute types in ASN.1
(This annex forms an integral part of this Recommendation |
International Standard)
This annex includes all of the ASN.1 type and value definitions
contained in this Directory Specification in the form of
the ASN.1 module SelectedAttributeTypes.

---------- 1997 ---------
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-199708-S!!P
DF-E&type=items
 
ISO/IEC 9594-6 : 1998 (E)
ITU-T Rec. X.520 (1997 E) 41
Annex C
Upper bounds
(This annex does not form an integral part of this Recommendation |
International Standard)
This annex includes all of the suggested upper bound value constraints
used in these Directory Specifications, in the form
of the ASN.1 module UpperBounds.

---------- 2001 ---------
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-200102-I!!P
DF-E&type=items

ISO/IEC 9594-6:2001 (E)
ITU-T X.520 (02/2001 E) 61
Annex C
Upper bounds
(This annex does not form an integral part of this Recommendation |
International Standard)
This annex includes all of the suggested upper bound value constraints
used in these Directory Specifications, in the
form of the ASN.1 module UpperBounds.

---------- 2005 ---------
http://www.itu.int/rec/T-REC-X.520-200508-I/dologin.asp?lang=e&id=T-REC-
X.520-200508-I!!PDF-E&type=items

ISO/IEC 9594-6:2005 (E)
60 ITU-T Rec. X.520 (08/2005)
Annex C
Upper bounds
(This annex does not form an integral part of this Recommendation |
International Standard)
This annex includes all of the suggested upper bound value constraints
used in these Directory Specifications, in the form
of the ASN.1 module UpperBounds.

---

From: David Chadwick <[email-masked]>
Date: Mon, 15 Oct 2007 18:20:11 +0100

Hi David

It is written at the start of Annex C of X.521, as copied below

> Annex C
> 
> Upper bounds
> (This annex does not form an integral part of this Recommendation | International Standard)
> This annex includes all of the suggested upper bound value constraints used in these Directory Specifications, in the form of the ASN.1 module UpperBounds.
> 
> UpperBounds {joint-iso-itu-t ds(5) module(1) upperBounds(10) 5}
> DEFINITIONS ::=
> BEGIN

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Oct 2007 10:41:31 -0700

At 6:20 PM +0100 10/15/07, David Chadwick wrote:
>>This annex includes all of the suggested upper bound value 
>>constraints used in these Directory Specifications, in the form of 
>>the ASN.1 module UpperBounds.
>>

Could you show the whole Annex? That is, could we see all the upper 
bounds listed? Or, is there just a blank line and "END"? :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 15 Oct 2007 15:11:22 -0400

Paul,

Here is a web site that contains the ASN.1 modules for "X-Series 
Recommendations":  http://www.itu.int/ITU-T/asn1/database/itu-t/x

It appears that the upper bounds module, which appears in X.520, has 
changed with each edition.  At least, the web site indicates that the 
OID for the module has changed from the 1997 edition to the 2001 
edition, and again with the publication of the 2005 edition.  I didn't 
attempt to compare the modules to see how they changed.

Dave

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 15 Oct 2007 15:23:43 -0400

The links provided will retrieve a PDF copy of the full text of X.520
(1993, 1997, 2001, or 2005 edition).  Unfortunately, some MUAs cannot
grok URLs that span more than 1 line, so instead of clicking on them
they must be copied and pasted manually into a browser address bar.
After entering the URL and retrieving the PDF file, (which due to
web-server-specific brain damage may also need to be renamed from
"xxx.pdf.asp" to "xxx.pdf"), scroll down to Annex C to view the
entire set of upper bounds.

One would think that after nearly 14 years the web would have
achieved point-and-click usability, but apparently not.

(Note that the upper bounds module is included in X.520, not X.521).

---------- X.521 2005 ---------
http://www.itu.int/rec/T-REC-X.521-200508-I/dologin.asp?lang=e&id=T-REC-
X.521-200508-I!!PDF-E&type=items

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul Hoffman
Sent: Monday, October 15, 2007 1:42 PM
To: David Chadwick
Cc: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of
upper bound in X.509"

--Paul Hoffman, Director
--VPN Consortium