Re: [sidr] Validation reconsidered and X.509v3 extension OIDs

Tim Bruijnzeels <tim@ripe.net> Tue, 19 July 2016 14:42 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D035E12D984 for <sidr@ietfa.amsl.com>; Tue, 19 Jul 2016 07:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u9VMcaWuYuD for <sidr@ietfa.amsl.com>; Tue, 19 Jul 2016 07:42:02 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE5A12D894 for <sidr@ietf.org>; Tue, 19 Jul 2016 07:15:03 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bPVnX-0006DX-LM; Tue, 19 Jul 2016 16:15:00 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-233.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bPVnX-0003JS-Fa; Tue, 19 Jul 2016 16:14:59 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <20160719111830.12A97412B25E@minas-ithil.hactrn.net>
Date: Tue, 19 Jul 2016 16:14:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0085B39-B39C-4DF2-990B-4F54254AFD3A@ripe.net>
References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ----------
X-RIPE-Spam-Report: Spam Total Points: -10.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07190e3a8e628e26cacf3a5665bebccd1b80
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/PTOPnTwztHeQMZFAYUxt3nnyQvg>
Cc: sidr@ietf.org
Subject: Re: [sidr] Validation reconsidered and X.509v3 extension OIDs
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2016 14:42:05 -0000

Hi Rob, WG,

I can see how this can help to make the behaviour of RPs consistent. If this is left as local policy then differences can occur w.r.t. RPs using reconsidered, or not and it's unpredictable for CAs to understand how RPs would behave.

I am not sure that I got your and Russ's point entirely correct, but are you suggesting that we update section 4.8.10 (IP resources extension) in RFC6487 (Resource Certificate Profile) so that it doesn't use the normal RFC3779 critical extension with its corresponding OID, but uses essentially the same resource extension with a different OID to indicate that validation should be done differently? If this is not what you meant some more precise pointers to which OID in which RFC and section need updating would be appreciated :)

Other than that I can prepare some text and slide ware to discuss this further, here and Thursday morning.

Thanks,

Tim







> On 19 Jul 2016, at 13:18, Rob Austein <sra@hactrn.net> wrote:
> 
> Reminding the WG of an old issue I raised years ago for validation
> reconsidered which, as far as I know, has not yet been addressed.
> 
> If we change the validation algorithm, we really should also change
> the object identifiers used in the X.509v3 extensions used to convey
> the resources.
> 
> The reason for this is simple: the RFC 3779 validation algorithm has
> shipped, long since.  My implementation has been part of OpenSSL for
> the last decade, and while it's not enabled by default on all
> platforms, it is on some, and is available as a configuration option
> on others.  It is far too late to change this, that ship has sailed.
> 
> So if we're talking about changing the validation algorithm now, we
> need to label the algorithm we're using, so that validation code knows
> which algorithm it's supposed to follow.  Otherwise, we'll get
> different validation results at different sites depending on which
> algorithm they're using this week, different routing decisions as a
> consequence, dogs and cats living together, mass hysteria.
> 
> The solution to this is simple: change the extension OIDs.  X.509's
> "critical extension" mechanism will take care of the rest.
> 
> This will require some kind of phase-in/phase-out process during which
> the new OIDs appear and the old OIDs vanish, and will require RP code
> to implement the new OIDs, but these are trivial issues given that the
> RP behavior has to change in any case, that being the point of the
> entire validation reconsidered exercise.
> 
> Yes, this will be a bit painful, but I view it as in essence exposing
> a problem that already exists, rather than sweeping it under the rug.
> 
> Sorry for reminding the WG of this yet again at what some may consider
> a late date, but I have raised this issue before, I just haven't
> (re)raised it in the last few months.
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr