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

"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 09 October 2007 17:08 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 1IfIZJ-0000w8-RG for pkix-archive@lists.ietf.org; Tue, 09 Oct 2007 13:08:29 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfIZB-00057o-Gv for pkix-archive@lists.ietf.org; Tue, 09 Oct 2007 13:08:22 -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 l99GOhAl084703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 09:24:43 -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 l99GOhYQ084702; Tue, 9 Oct 2007 09:24:43 -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 stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l99GOgUS084696 for <ietf-pkix@imc.org>; Tue, 9 Oct 2007 09:24:42 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil)
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l99GOa9h027801; Tue, 9 Oct 2007 12:24:36 -0400 (EDT)
Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Tue, 09 Oct 2007 12:24:35 -0400
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Oct 2007 12:24:35 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
Date: Tue, 09 Oct 2007 12:24:35 -0400
Message-ID: <FA998122A677CF4390C1E291BFCF59890849839E@EXCH.missi.ncsc.mil>
In-Reply-To: <2788466ED3E31C418E9ACC5C316615570536E1@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"
Thread-Index: AcgIXLLxS0ujp4qjR/qIFNlFODJAOwBpALCwACLZgbA=
References: <4707E6DA.1070703@cs.tcd.ie> <2788466ED3E31C418E9ACC5C316615570536E1@mou1wnexmb09.vcorp.ad.vrsn.com>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Russ Housley <housley@vigilsec.com>
Cc: ietf-pkix@imc.org
X-OriginalArrivalTime: 09 Oct 2007 16:24:35.0704 (UTC) FILETIME=[E1A0CF80:01C80A90]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15474000
X-TM-AS-Result: : Yes--10.067900-0-31-1
X-TM-AS-Category-Info: : 31:0.000000
X-TM-AS-MatchedID: : 150567-702726-700104-708159-700654-704994-701576-705882-703517-702485-186035-188198-705861-390078-188121-700006-139006-704287-703829-700473-704425-700604-708179-139010-700075-110462-709291-701236-710207-705450-113922-148039-148050-20042
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l99GOhUS084697
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: 82c9bddb247d9ba4471160a9a865a5f3

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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, October 08, 2007 7:32 PM
To: Stephen Farrell; Russ Housley
Cc: ietf-pkix@imc.org
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?
 

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Farrell
> Sent: Saturday, October 06, 2007 3:50 PM
> To: Russ Housley
> Cc: ietf-pkix@imc.org
> Subject: Re: New Liaison Statement, "Liaison to IETF on the 
> removal of upper bound in X.509"
> 
> 
> 
> 
> 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.
> 
>