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

Rob Austein <sra@hactrn.net> Mon, 13 March 2017 13:11 UTC

Return-Path: <sra@hactrn.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 A6B6C1295F0; Mon, 13 Mar 2017 06:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2cOO2DySyPx; Mon, 13 Mar 2017 06:11:56 -0700 (PDT)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A636F12940B; Mon, 13 Mar 2017 06:11:56 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 08BF71398E; Mon, 13 Mar 2017 13:11:56 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D22115DCF34; Mon, 13 Mar 2017 09:11:55 -0400 (EDT)
Date: Mon, 13 Mar 2017 09:11:55 -0400
From: Rob Austein <sra@hactrn.net>
To: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net>
References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <yj9ok27upcws.wl%morrowc@ops-netman.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net>
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=US-ASCII
Message-Id: <20170313131155.D22115DCF34@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/rkfGDvZ966JOPJKQCuzHr_DNf4U>
Cc: Rob Austein <sra@hactrn.net>, Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" <draft-ietf-sidr-rpki-validation-reconsidered@ietf.org>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07
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: Mon, 13 Mar 2017 13:11:57 -0000

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.

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?