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

Tim Bruijnzeels <> Mon, 13 March 2017 14:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33ACB12969B; Mon, 13 Mar 2017 07:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wSdRO42w7H9S; Mon, 13 Mar 2017 07:25:23 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D72812969A; Mon, 13 Mar 2017 07:25:22 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <>) id 1cnQuS-0000sr-OM; Mon, 13 Mar 2017 15:25:18 +0100
Received: from ([] by with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <>) id 1cnQuS-00071W-IX; Mon, 13 Mar 2017 15:25:16 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Mon, 13 Mar 2017 15:25:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Rob Austein <>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ------
X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071904ba42f6741bbe4d985c57319b0f9116
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: Mon, 13 Mar 2017 14:25:24 -0000

Hi Rob, all,

> On 13 Mar 2017, at 14:11, Rob Austein <> wrote:
> At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote:
>> So, to me it seems that having new OIDs makes perfect sense as long
>> as there is a choice of two validation algorithms. Then having an
>> explicit flag set by CAs tells RPs decide which way to go. Because
>> of this I also do not see an immediate need to have a time line for
>> all CAs to use the new protocol for all its products. It's all
>> explicit.
>> Now, if the ambition is to have reconsidered as the only algorithm
>> for doing RPKI validation, then I think that the RPKI Certificate
>> Policy OID is enough (section 4.8.9 of RCF4587 - which delegates to
>> section 1.2 of RFC6484). I realise that RFC3779 section 2.3 has text
>> on path validation as well, but I think could can recognise that a
>> different algorithm should apply in the context of *RPKI*
>> validation.
>> If I understand Rob's concerns though he feels that this will cause
>> issues, and that therefore the RFC3779 OID cannot be used. Rob, is
>> this correct? Why can't RP/OpenSSL code just make the switch based
>> on the CA certificate profile?
> The problem is that there are one or two things out there besides RPKI
> which use X.509, and it would be nice to avoid breaking them.

I understand that. I meant to say that the switch should be based on the RPKI CA certificate policy qualifier. That is specific to RPKI so, other applications would not break.

Non-RPKI use of RFC3779, would not have this same OID, and therefore would still have the path validation from section 2.3 in RFC3779.

> The OIDs which MUST be changed are the ones labeling the extensions
> themselves.  The semantics of X.509v3 critical extensions says,
> basically, "If you don't understand the meaning of this extension, you
> MUST consider this certificate invalid".  Changing the meaning of the
> extensions while retaining the existing OIDs would break this: there
> is code out there which thinks it does understand the RFC 3779
> extensions, but which would now be incorrect, because the RFC 3779
> OIDs would now be used to label things that are not RFC 3779
> extensions.
> Granted, the probability that some random X.509 CA is going to include
> RFC 3779 extensions in certificates for any purpose other than RPKI is
> fairly low, but it would be nice to avoid creating a situation in
> which users of such certificates got inconsistent results depending on
> which version of a stock library they happened to use.  If this were
> OpenSSL doing something stupid I wouldn't care so much, but this was
> OpenSSL implementing an IETF proposed standard to the best of the
> author's ability, and you're talking about retroactively breaking that
> for gratuitous reasons.  This is irresponsible.  Don't do it.
> I don't understand why we're wasting time debating this (again).  OIDs
> are cheap, and (I thought) this was a done deal.  Can we please just
> admit that we're talking about new extensions with new semantics which
> borrow syntax from the existing extensions, label them accordingly,
> and move on?

The reason why I keep talking about this, is because other people indicated that it could be desirable that validation reconsidered is not a choice (that would need flagging, so OIDs are appropriate) - but should become the default.

In that case it's much simpler to have a switch on the unique RPKI CP OID from section 1.2 of RFC6484. 

The proposed OIDs itself are cheap, and the code changes are simple. The difficulty is that we need a deployment plan:

1= RPs MUST support new OIDs, before
2= CAs MAY use new OIDs

and an open question still is whether there needs to be a later
3= CAs MUST use new OIDs and RPs MUST reject old OIDs

Step 2 has operational impact if operators did not upgrade their RP software. Step 3 has operational impact in case a CA cannot re-issue certain objects.

If we need to end up in a place where 'validation reconsidered' is the default, then these operational impacts can be minimised. It would boil down to deciding a date X by which RPs MUST use reconsidered when they encounter the RPKI CP OID, and a date Y (before X) that these should be available. Operators that don't upgrade before date X could find that they consider certain objects invalid, that would be (partially) valid.

In any case, I know that you know more about how the openssl code works. So if there is a reason why the switch cannot work on the RPKI CP OID without affecting non-RPKI use, or if there is a strong reason for having both algorithms alongside each other, than I am (still) open to the OIDs that I painstakingly added to the document.