Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07

Rob Austein <> Sat, 11 March 2017 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F626129413; Sat, 11 Mar 2017 14:25:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XUjrflwB9sZ7; Sat, 11 Mar 2017 14:25:27 -0800 (PST)
Received: from ( [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D10A1294A8; Sat, 11 Mar 2017 14:25:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Grunchweather Associates" (not verified)) by (Postfix) with ESMTPS id 8BB8C1398E; Sat, 11 Mar 2017 22:25:26 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 324125ACF21; Sat, 11 Mar 2017 17:25:27 -0500 (EST)
Date: Sat, 11 Mar 2017 17:25:27 -0500
From: Rob Austein <>
To: "Alvaro Retana (aretana)" <>
In-Reply-To: <>
References: <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
Archived-At: <>
Cc: Chris Morrow <>, "" <>, "" <>, "" <>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Mar 2017 22:25:28 -0000

At Thu, 9 Mar 2017 18:44:58 +0000, Alvaro Retana (aretana) wrote:
> I just finished reading this document.  My review is predicated on
> the assumption that the intent of the WG is to define an additional
> validation process, and not amend/change/update/deprecate the
> existing one?yet, which is why there are not only process changes
> specified, but also new OIDs.


I will let the WG chairs and authors speak to intent regarding the
existing validation process.

Speaking as an implementer, I requested, nay, demanded the new OIDs,
for a very simple technical reason: from an implementation standpoint,
the new validation rule is very different from the old one.  More
precisely, it is very close to the same set of checks as the old rule,
but in a very different place in the code.  Given the overall
structure of X.509v3's critical extension mechanism, new OIDs were by
far the simplest means of signalling which rule an RP should use.

So the decision to use new OIDs is orthogonal to the deprecation
discussion: we need the new OIDs in any case for technical reasons.