Re: Use of private OIDs in WG (standard-track) documents

Nico Williams <nico@cryptonector.com> Mon, 30 March 2015 19:29 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9246B1ACCE9 for <ietf@ietfa.amsl.com>; Mon, 30 Mar 2015 12:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level:
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 HMCr9JmJ0cWs for <ietf@ietfa.amsl.com>; Mon, 30 Mar 2015 12:29:08 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 577091ACCD9 for <ietf@ietf.org>; Mon, 30 Mar 2015 12:29:08 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 28F8C2005D004; Mon, 30 Mar 2015 12:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=iZq1pAdVed85VZaE1m1YG3ORM8I=; b=Ve9AixYcI1H vXXlb0H6viW1gOfj5K1wqMpfUpmJYw6vEhBssBFckADvC/eim0/Kxm8tblrt9SGe sKF3WrJL5Qgmp4CEJkBtVUsUBI/hZLPrJVNgpgYYV8WvE98EQ9kEDJk1ekH9gbDw /f31FesU1hs65j0SA5te0GYrBI2ywObY=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id 92B912005D002; Mon, 30 Mar 2015 12:29:07 -0700 (PDT)
Date: Mon, 30 Mar 2015 14:29:06 -0500
From: Nico Williams <nico@cryptonector.com>
To: Sean Turner <turners@ieca.com>
Subject: Re: Use of private OIDs in WG (standard-track) documents
Message-ID: <20150330192905.GS10960@localhost>
References: <55163324.6030504@openca.org> <20150328211906.GI17637@mournblade.imrryr.org> <89D53DE5-4C92-45EB-9C9C-599D9841EB2D@ieca.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <89D53DE5-4C92-45EB-9C9C-599D9841EB2D@ieca.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/7VvjeXxdKBIEXbFKe7BSdZewzmM>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2015 19:29:09 -0000

On Mon, Mar 30, 2015 at 02:43:40PM -0400, Sean Turner wrote:
> I’m with Victor and don’t see the issue.  We’ve got standards track
> RFCs with OIDs from NIST, Certicom, RSA, and “infosec” and those are
> just the ones I can come up with off the top of head.

I agree.

We also have experience with the effects of changing such protocol
constants at publication time:

 - The Kerberos V GSS-API mechanism (RFCs 1964 and 4121).

   Many implementations still embed old OIDs.  I wasn't around then but
   the transition to the new OIDs must have broken acceptor
   implementations.

 - IPsec NAT traversal (which had a constant that changed with each
   version of the I-D).

and probably others.

As a matter of taste it might be better to use IETF OID space, but that
would effectively require having procedures for *early* IANA assignment
of IETF OID arcs to upcoming Internet-Drafts.  As it is I don't think we
have procedures for that, therefore it should be no surprise that we see
non-IETF OID arc assignment in Internet-Drafts and RFCs.  I see this as
a pre-requisite.  Anyone wanting us to use IANA-assigned OID arcs
exclusively.. should submit, and see through to publication, an
Internet-Draft providing for such early assignment.

Nico
--