Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
Steven Legg <steven.legg@eb2bcom.com> Wed, 10 October 2007 01:10 UTC
Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfQ6D-0002m2-ES for pkix-archive@lists.ietf.org; Tue, 09 Oct 2007 21:10:57 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfQ5y-00037U-EP for pkix-archive@lists.ietf.org; Tue, 09 Oct 2007 21:10:48 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9A0QZvT029019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 17:26:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9A0QZTr029018; Tue, 9 Oct 2007 17:26:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9A0QXVn029007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Tue, 9 Oct 2007 17:26:34 -0700 (MST) (envelope-from steven.legg@eb2bcom.com)
Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from <steven.legg@eb2bcom.com>) id 1IfPPC-0003sG-OW; Wed, 10 Oct 2007 10:26:32 +1000
Message-ID: <470C1C32.70603@eb2bcom.com>
Date: Wed, 10 Oct 2007 10:26:26 +1000
From: Steven Legg <steven.legg@eb2bcom.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Kemp, David P." <DPKemp@missi.ncsc.mil>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, ietf-pkix@imc.org
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
References: <4707E6DA.1070703@cs.tcd.ie> <2788466ED3E31C418E9ACC5C316615570536E1@mou1wnexmb09.vcorp.ad.vrsn.com> <FA998122A677CF4390C1E291BFCF59890849839E@EXCH.missi.ncsc.mil> <470BB253.3030703@cs.tcd.ie> <FA998122A677CF4390C1E291BFCF598908498416@EXCH.missi.ncsc.mil>
In-Reply-To: <FA998122A677CF4390C1E291BFCF598908498416@EXCH.missi.ncsc.mil>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source:
X-Source-Args:
X-Source-Dir:
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Kemp, David P. wrote: > 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 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 > > 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:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, October 09, 2007 12:55 PM > To: Kemp, David P. > Cc: Hallam-Baker, Phillip; Russ Housley; ietf-pkix@imc.org > Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of > upper bound in X.509" > > > Kemp, David P. wrote: >> A normative upper bound has the undesirable effect of requiring >> 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 >> upper bound provides guidance to CAs on maximizing interoperability, > > 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. > > >
- Re: New Liaison Statement, "Liaison to IETF on th… Russ Housley
- FW: New Liaison Statement, "Liaison to IETF on th… Stefan Santesson
- Re: New Liaison Statement, "Liaison to IETF on th… Russ Housley
- Re: New Liaison Statement, "Liaison to IETF on th… Hoyt L Kesterson II
- Re: New Liaison Statement, "Liaison to IETF on th… Stephen Farrell
- RE: New Liaison Statement, "Liaison to IETF on th… Hallam-Baker, Phillip
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.
- Re: New Liaison Statement, "Liaison to IETF on th… Stephen Farrell
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.
- Re: FW: New Liaison Statement, "Liaison to IETF o… Paul Hoffman
- Re: New Liaison Statement, "Liaison to IETF on th… Steven Legg
- Re: FW: New Liaison Statement, "Liaison to IETF o… Steven Legg
- Re: New Liaison Statement, "Liaison to IETF on th… Stephen Farrell
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- Re: New Liaison Statement, "Liaison to IETF on th… Steven Legg
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.
- Re: New Liaison Statement, "Liaison to IETF on th… David Chadwick
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- Re: New Liaison Statement, "Liaison to IETF on th… David A. Cooper
- RE: New Liaison Statement, "Liaison to IETF on th… Kemp, David P.