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

Rob Austein <sra@hactrn.net> Tue, 19 July 2016 13:46 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 693B512E2BF for <sidr@ietfa.amsl.com>; Tue, 19 Jul 2016 06:46:37 -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 GbQGyjU3797f for <sidr@ietfa.amsl.com>; Tue, 19 Jul 2016 06:46:32 -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 462B512D6AE for <sidr@ietf.org>; Tue, 19 Jul 2016 06:14:56 -0700 (PDT)
Received: from minas-ithil.hactrn.net (dhcp-b3d9.meeting.ietf.org [31.133.179.217]) (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 1EFCA1398E for <sidr@ietf.org>; Tue, 19 Jul 2016 13:14:55 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D0705412C916 for <sidr@ietf.org>; Tue, 19 Jul 2016 15:14:56 +0200 (CEST)
Date: Tue, 19 Jul 2016 15:14:56 +0200
From: Rob Austein <sra@hactrn.net>
To: IETF SIDR <sidr@ietf.org>
In-Reply-To: <F64A0698-6461-489E-99B9-4A75421C04DA@vigilsec.com>
References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net> <F64A0698-6461-489E-99B9-4A75421C04DA@vigilsec.com>
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: <20160719131456.D0705412C916@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/LGTBkukF_IbCueQZ7hbCQqkMm3A>
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 13:46:37 -0000

At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote:
> 
> Does this apply to the Certificate Policy OID too?  If memory is
> correct, the current CP has a normative pinter to RFC 3779.

Good catch.

Not sure a policy OID change is necessary, although might be simplest.
If there's a reference, we either need to change the OID or change the
definition of what the OID means.

IIRC, the OpenSSL library code doesn't do anything RFC-3779-specific
for the policy OID, it just follows the usual rules; it's the RP code
built on top of the library that demands that particular policy OID.
So at least in the OpenSSL case, changing the policy OID may not have
any noticeable effect on correctness of software behavior.