IETF Logo Mail Archive

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

Tim Bruijnzeels <tim@ripe.net> Thu, 21 July 2016 10:38 UTC

Return-Path: <tim@ripe.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 9A24712DE07 for <sidr@ietfa.amsl.com>; Thu, 21 Jul 2016 03:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level:
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 9mrF2-zoqeMq for <sidr@ietfa.amsl.com>; Thu, 21 Jul 2016 03:38:38 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [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 ietfa.amsl.com (Postfix) with ESMTPS id 81DE412DCA5 for <sidr@ietf.org>; Thu, 21 Jul 2016 03:36:16 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bQBKt-00007n-3l; Thu, 21 Jul 2016 12:36:14 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-80.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bQBKs-0006kF-Rn; Thu, 21 Jul 2016 12:36:11 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_30A5C3EC-EE89-4A96-A763-166B0735D775"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <A76F3C48-64F0-48A3-938E-D2362A909664@vigilsec.com>
Date: Thu, 21 Jul 2016 12:36:10 +0200
Message-Id: <173EB2A5-1F28-4108-9D91-B3D1C2B3126C@ripe.net>
References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net> <F64A0698-6461-489E-99B9-4A75421C04DA@vigilsec.com> <20160719131456.D0705412C916@minas-ithil.hactrn.net> <A76F3C48-64F0-48A3-938E-D2362A909664@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ----------
X-RIPE-Spam-Report: Spam Total Points: -10.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719494c9d1a0440fb899e62a42b1f4e8b07
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/MyIPJz3Z2eNZv0agpoW4o2DiKHM>
Cc: IETF SIDR <sidr@ietf.org>
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: Thu, 21 Jul 2016 10:38:40 -0000

Hi Russ,

Thank you for the pointers. I am traveling now but I will get back to it.

Thanks
Tim

> On 21 Jul 2016, at 10:56, Russ Housley <housley@vigilsec.com> wrote:
> 
> 
> On Jul 19, 2016, at 9:14 AM, Rob Austein <sra@hactrn.net <mailto:sra@hactrn.net>> wrote:
> 
>> 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.
> 
> During the SIDR session today, there seemed to be some confusion about which OIDs we are taking about.
> 
> The first two are from RFC 3779.  They appear here in the IANA registry:
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 <http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1>
> 
> The two OIDs are: 
> 	1.3.6.1.5.5.7.1.7	id-pe-ipAddrBlocks
> 	1.3.6.1.5.5.7.1.8	id-pe-autonomousSysIds	
> 
> In addition, RFC 6484 assigned an OID for the certificate policy.  It appears here in the IANA registry:
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.14 <http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.14>
> 
> The OID is:
> 	1.3.6.1.5.5.7.14.2	id-cp-ipAddr-asNumber
> 
> I think this is a very good candidate for early IANA code point allocation.  I think that our AD can assist with that.
> 
> Russ
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org <mailto:sidr@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidr <https://www.ietf.org/mailman/listinfo/sidr>

v2.23.0 | Report a Bug | By Email