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

Tim Bruijnzeels <tim@ripe.net> Wed, 03 August 2016 18:32 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 4AEF112D1B9 for <sidr@ietfa.amsl.com>; Wed, 3 Aug 2016 11:32:22 -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 gox64vfMtnFI for <sidr@ietfa.amsl.com>; Wed, 3 Aug 2016 11:32:19 -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 DB6E012D0B4 for <sidr@ietf.org>; Wed, 3 Aug 2016 11:32:18 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bV0xg-000CZ1-NO; Wed, 03 Aug 2016 20:32:15 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-11.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bV0xg-0002CK-FT; Wed, 03 Aug 2016 20:32:12 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Tim Bruijnzeels <tim@ripe.net>
X-Priority: 3
In-Reply-To: <00c201d1ecdb$8d45a640$4001a8c0@gateway.2wire.net>
Date: Wed, 3 Aug 2016 20:32:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <69C24BE0-A64B-4E62-B2AE-50B710A6CD7E@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> <173EB2A5-1F28-4108-9D91-B3D1C2B3126C@ripe.net> <2F66A19D-8ADD-496A-A1A6-61D8277DAF4C@sn3rd.com> <00c501d1eca0$8fd24660$4001a8c0@gateway.2wire.net> <89AE2EA7-BF74-4A59-9C6C-9F50595458D8@sn3rd.com> <00c201d1ecdb$8d45a640$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ----------
X-RIPE-Spam-Report: Spam Total Points: -10.6 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 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]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07190d84f72e4ec2e022a7533ed1ee5915e2
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/xIn_3nWyfwV9tnGUdUKY5CoAR6M>
Cc: Rob Austein <sra@hactrn.net>, 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: Wed, 03 Aug 2016 18:32:22 -0000

Hi all,

Just a quick sign of life on this..

Other work intervened but I haven't forgotten. Suggestion are very much appreciated! I hope to edit a new version in the coming weeks.

Tim

> On 02 Aug 2016, at 18:32, t.petch <ietfc@btconnect.com> wrote:
> 
> ----- Original Message -----
> From: "Sean Turner" <sean@sn3rd.com>
> To: "t.petch" <ietfc@btconnect.com>
> Cc: "Rob Austein" <sra@hactrn.net>et>; "IETF SIDR" <sidr@ietf.org>
> Sent: Tuesday, August 02, 2016 2:20 PM
> On Aug 02, 2016, at 05:30, t.petch <ietfc@btconnect.com> wrote:
>> 
>> Sean
>> 
>> I am a fan of giving IANA as little a need to think as possible so
> would
>> prefer the IANA considerations to be more expansive.  With three
>> registries being updated, I would like to see three paragraphs and,
> with
>> five numbers, would like to see TBD1 to TBD5, not TBD times five, e.g.
> 
> I guess I’m not as paranoid as you, but #ing the TBDs would definitely
> make it clearer to IANA and the RFC where the values are supposed to go.
> 
> If “TBD1" is replaces the “TBD" in the 6484 updates section then the 2 &
> 3 are the modules and 4 and 5 are the extensions.  Revised modules
> follow what I think you’re asking for wrt the IANA considerations
> section:
> 
> <tp>
> 
> Sean
> 
> Yes, I am paranoid and yes, this looks good to my eyes,
> 
> Tom Petch
> 
> #.# IANA Considerations
> 
> IANA is to add the following to the SMI Security for PKIX Certificate
> Policies registry:
> 
> Decimal  Description                       References
> 
> TBD1   id-cp-ipAddr-asNumber-v2  [this RFC]
> 
> IANA is to add the following to the SMI Security for PKIX Module
> Identifier registry:
> 
> Decimal  Description                       References
> 
> TBD2   IPAddrAndASCertExtn-v2  [this RFC]
> TBD3   IPAddrAndASCertExtn-2010v2  [this RFC]
> 
> IANA is to add the following to the SMI Security for PKIX Certificate
> Extension registry:
> 
> Decimal  Description                       References
> 
> TBD4   id-pe-ipAddrBlocks-v2  [this RFC]
> TBD5   id-pe-autonomousSysIds-v2  [this RFC]
> 
> #.#  ’88 ASN.1 Module
> 
> IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6)
>            internet(1) security(5) mechanisms(5) pkix(7) mod(0)
>            id-mod-ip-addr-and-as-ident-v2(TBD2) }
> 
>   DEFINITIONS EXPLICIT TAGS ::=
> 
>   BEGIN
> 
>   -- EXPORTS ALL --
> 
>   IMPORTS
> 
>   -- PKIX specific OIDs and arcs --
> 
>       id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
>                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
>                  id-mod(0) id-pkix1-explicit(18) }
> 
>   -- IP Address Block and AS Identifiers Syntax --
> 
> IPAddrBlocks, ASIdentifiers FROM  IPAddrAndASCertExtn { iso(1)
>            identified-organization(3) dod(6) internet(1) security(5)
>            mechanisms(5) pkix(7) mod(0)
> id-mod-ip-addr-and-as-ident(30) }
>    ;
> 
>   -- Validation Reconsidered IP Address Delegation Extension OID --
> 
> id-pe-ipAddrBlocks-v2  OBJECT IDENTIFIER ::= { id-pe TBD4 }
> 
>   -- Validation Reconsidered IP Address Delegation Extension Syntax --
>   -- Syntax is imported from [RFC3779] --
> 
>   -- Validation Reconsidered Autonomous System Identifier Delegation
> Extension OID --
> 
>   id-pe-autonomousSysIds-v2  OBJECT IDENTIFIER ::= { id-pe TBD5 }
> 
>   -- Validation Reconsidered Autonomous System Identifier Delegation
> Extension Syntax --
>   -- Syntax is imported from [RFC3779] --
> 
>   END
> 
> 
> #.#  ’08 ASN.1 Module
> 
> IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6)
>            internet(1) security(5) mechanisms(5) pkix(7) mod(0)
>            id-mod-ip-addr-and-as-ident-2v2(TBD3) }
> 
>   DEFINITIONS EXPLICIT TAGS ::=
> 
>   BEGIN
> 
>      EXPORTS ALL;
>      IMPORTS
> 
>      -- PKIX specific OIDs and arcs —
> 
>      id-pe
>      FROM PKIX1Explicit-2009
>        { iso(1) identified-organization(3) dod(6) internet(1)
>          security(5) mechanisms(5) pkix(7) id-mod(0)
>          id-mod-pkix1-explicit-02(51)}
> 
>      EXTENSION
>      FROM PKIX-CommonTypes-2009
>        { iso(1) identified-organization(3) dod(6) internet(1)
>          security(5) mechanisms(5) pkix(7) id-mod(0)
>          id-mod-pkixCommon-02(57)}
> 
>   -- IP Address Block and AS Identifiers Syntax --
> 
>      IPAddrBlocks, ASIdentifiers
>      FROM IPAddrAndASCertExtn-2010
>         { iso(1) identified-organization(3) dod(6)
>           internet(1) security(5) mechanisms(5) pkix(7) mod(0)
>           id-mod-ip-addr-and-as-ident-2(72) }
>      ;
> 
>      --
>      -- Extensions contains the set of extensions defined in this
>      -- module
>      --
>      -- These are intended to be placed in public key certificates
>      -- and thus should be added to the CertExtensions extension
>      -- set in PKIXImplicit-2009 defined for [RFC5280]
>      --
> 
>      Extensions EXTENSION ::= {
>         ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2
>      }
> 
>      -- Validation Reconsidered IP Address Delegation Extension OID —
> 
>      ext-pe-ipAddrBlocks-v2 EXTENSION ::= {
>        SYNTAX IPAddrBlocks
>        IDENTIFIED BY id-pe-ipAddrBlocks-v2
>      }
> 
>      id-pe-ipAddrBlocks-v2  OBJECT IDENTIFIER ::= { id-pe TBD4 }
> 
>      -- IP Address Delegation Extension Syntax —
>      -- Syntax is imported from [RFC6268] —
> 
>      -- Validation Reconsidered Autonomous System Identifier Delegation
> Extension OID —
> 
>      ext-pe-autonomousSysIds-v2 EXTENSION ::= {
>        SYNTAX ASIdentifiers
>        IDENTIFIED BY id-pe-autonomousSysIds-v2
>      }
> 
>      id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe TBD5 }
> 
>   -- Validation Reconsidered Autonomous System Identifier Delegation
> Extension Syntax --
>   -- Syntax is imported from [RFC6268] --
> 
>   END
> 
> 
>> ----- Original Message -----
>> From: "Sean Turner" <sean@sn3rd.com>
>> To: "Rob Austein" <sra@hactrn.net>et>; "Tim Bruijnzeels" <tim@ripe.net>et>;
>> "Russ Housley" <housley@vigilsec.com>
>> Cc: "IETF SIDR" <sidr@ietf.org>
>> Sent: Tuesday, August 02, 2016 12:28 AM
>> 
>>> On Jul 21, 2016, at 06:36, Tim Bruijnzeels <tim@ripe.net> wrote:
>>> 
>>> 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> 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-number
>> s-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-number
>> s-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
>> 
>> To make sure I’m following along, to address the "Updates: 3779, 6484,
>> 6487 (if approved)" changes would the follow changes work:
>> 
>> 0) RFC6484-related changes
>> 
>> If we’re going with two OIDs (one for the original “strict" validation
>> and one for new “relaxed” validation), then I’m hoping that we can
> just
>> define a new OID in s1.2 of RFC 6484 and be done with it (i.e., I hope
>> we don’t also have to update s4.1.1, s4.5.1, and s4.7.1 where RFC 3779
>> is mentioned).  Here’s some text for a new section:
>> 
>> #.#  Updates to RFC 6484
>> 
>> This section replaces s1.2 of [RFC6484] with the following:
>> 
>> The name of this document is "Certificate Policy (CP) for the Resource
>> PKI (RPKI)”.
>> 
>> This policy has been assigned the following two OIDs:
>> 
>>  id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
>>                        identified-organization(3) dod(6) internet(1)
>>                        security(5) mechanisms(5) pkix(7) cp(14) 2 }
>> 
>>  id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1)
>>                        identified-organization(3) dod(6) internet(1)
>>                        security(5) mechanisms(5) pkix(7) cp(14) TBD }
>> 
>> id-cp-ipAddr-asNumber and the extensions defined in [RFC3779] indicate
>> that the original certification path validation rules are to be used.
>> id-cp-ipAddr-asNumber-v2 and the extensions defined in [this document]
>> indicate that the validation reconsidered certification path
> validation
>> rules defined in [this document] are to be used.
>> 
>> 
>> 1) IANA registrations
>> 
>> We need to register some OIDs with IANA.  Here’s an IANA
> considerations
>> section (assumes we’re registering a new CP OID - [] references will
> be
>> to whatever section # it ends up being):
>> 
>> 6. IANA Considerations
>> 
>> IANA is to register the following five OIDs:
>> 
>> - id-cp-ipAddr-asNumber-v2 from [insert Section and #] in the SMI
>> Security for PKIX Certificate Policies registry.
>> 
>> - id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 from [insert
>> Section and #] in the SMI Security for PKIX Certificate Extension
>> registry.
>> 
>> - IPAddrAndASCertExtn-v2 and IPAddrAndASCertExtn-2010v2 from [insert
>> Section and #] in the SMI Security for PKIX Module Identifier
> registry.
>> 
>> RFC EDITOR: There are two ASN.1 modules both include the same
>> assignments for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2,
>> i.e., the assignments are made by IANA once and the values are
> included
>> in the two modules.  Please delete this prior to publication.
>> 
>> 
>> 2) RFC3799-related changes
>> 
>> As far as RFC 3779 updates go, we probably need to update s2.3 and
> s3.3
>> as well as add new ASN.1 modules.
>> 
>> 
>> 2.1) I haven’t got text off the top of my head for the s2.3 and s3.3
>> changes.
>> 
>> 
>> 2.2) As far as the ASN.1-related changes go here’s two ASN.1
> module(s).
>> The modules define the new OIDs and imports the syntax from
>> RFC3779/RFC6268.  The basic idea is to keep the modules as short as
>> possible.  The 2nd module is for the ’08 ASN.1 that was defined in RFC
>> 6268 to be used with RFC5911/5912.
>> 
>> #.#  ’88 ASN.1 Module
>> 
>> IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6)
>>           internet(1) security(5) mechanisms(5) pkix(7) mod(0)
>>           id-mod-ip-addr-and-as-ident-v2(TBD) }
>> 
>>  DEFINITIONS EXPLICIT TAGS ::=
>> 
>>  BEGIN
>> 
>>  -- EXPORTS ALL --
>> 
>>  IMPORTS
>> 
>>  -- PKIX specific OIDs and arcs --
>> 
>>      id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
>>                 dod(6) internet(1) security(5) mechanisms(5) pkix(7)
>>                 id-mod(0) id-pkix1-explicit(18) }
>> 
>>  -- IP Address Block and AS Identifiers Syntax --
>> 
>> IPAddrBlocks, ASIdentifiers FROM  IPAddrAndASCertExtn { iso(1)
>>           identified-organization(3) dod(6) internet(1) security(5)
>>           mechanisms(5) pkix(7) mod(0)
>> id-mod-ip-addr-and-as-ident(30) }
>>   ;
>> 
>>  -- Validation Reconsidered IP Address Delegation Extension OID --
>> 
>> id-pe-ipAddrBlocks-v2  OBJECT IDENTIFIER ::= { id-pe TBD }
>> 
>>  -- Validation Reconsidered IP Address Delegation Extension Syntax --
>>  -- Syntax is imported from [RFC3779] --
>> 
>>  -- Validation Reconsidered Autonomous System Identifier Delegation
>> Extension OID --
>> 
>>  id-pe-autonomousSysIds-v2  OBJECT IDENTIFIER ::= { id-pe TBD }
>> 
>>  -- Validation Reconsidered Autonomous System Identifier Delegation
>> Extension Syntax --
>>  -- Syntax is imported from [RFC3779] --
>> 
>>  END
>> 
>> 
>> #.#  ’08 ASN.1 Module
>> 
>> IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6)
>>           internet(1) security(5) mechanisms(5) pkix(7) mod(0)
>>           id-mod-ip-addr-and-as-ident-2v2(TBD) }
>> 
>>  DEFINITIONS EXPLICIT TAGS ::=
>> 
>>  BEGIN
>> 
>>     EXPORTS ALL;
>>     IMPORTS
>> 
>>     -- PKIX specific OIDs and arcs —
>> 
>>     id-pe
>>     FROM PKIX1Explicit-2009
>>       { iso(1) identified-organization(3) dod(6) internet(1)
>>         security(5) mechanisms(5) pkix(7) id-mod(0)
>>         id-mod-pkix1-explicit-02(51)}
>> 
>>     EXTENSION
>>     FROM PKIX-CommonTypes-2009
>>       { iso(1) identified-organization(3) dod(6) internet(1)
>>         security(5) mechanisms(5) pkix(7) id-mod(0)
>>         id-mod-pkixCommon-02(57)}
>> 
>>  -- IP Address Block and AS Identifiers Syntax --
>> 
>>     IPAddrBlocks, ASIdentifiers
>>     FROM IPAddrAndASCertExtn-2010
>>        { iso(1) identified-organization(3) dod(6)
>>          internet(1) security(5) mechanisms(5) pkix(7) mod(0)
>>          id-mod-ip-addr-and-as-ident-2(72) }
>>     ;
>> 
>>     --
>>     -- Extensions contains the set of extensions defined in this
>>     -- module
>>     --
>>     -- These are intended to be placed in public key certificates
>>     -- and thus should be added to the CertExtensions extension
>>     -- set in PKIXImplicit-2009 defined for [RFC5280
>> <https://tools.ietf.org/html/rfc5280>]
>>     --
>> 
>>     Extensions EXTENSION ::= {
>>        ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2
>>     }
>> 
>>     -- Validation Reconsidered IP Address Delegation Extension OID —
>> 
>>     ext-pe-ipAddrBlocks-v2 EXTENSION ::= {
>>       SYNTAX IPAddrBlocks
>>       IDENTIFIED BY id-pe-ipAddrBlocks-v2
>>     }
>> 
>>     id-pe-ipAddrBlocks-v2  OBJECT IDENTIFIER ::= { id-pe TBD }
>> 
>>     -- IP Address Delegation Extension Syntax —
>>     -- Syntax is imported from [RFC6268] —
>> 
>>     -- Validation Reconsidered Autonomous System Identifier
> Delegation
>> Extension OID —
>> 
>>     ext-pe-autonomousSysIds-v2 EXTENSION ::= {
>>       SYNTAX ASIdentifiers
>>       IDENTIFIED BY id-pe-autonomousSysIds-v2
>>     }
>> 
>>     id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe TBD }
>>  -- Validation Reconsidered Autonomous System Identifier Delegation
>> Extension Syntax --
>>  -- Syntax is imported from [RFC6268] --
>> 
>>  END
>> 
>> 2.3) If we want to be really ambitious, then right after the ASN.1
>> modules are included in the draft we could request the WG chairs start
>> an early IANA allocation request for these OID ;)
>> 
>> Cheers,
>> 
>> spt
>> 
>> 
>> 
>> 
>> ----------------------------------------------------------------------
> --
>> --------
>> 
>> 
>>> _______________________________________________
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr