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

Sean Turner <sean@sn3rd.com> Tue, 02 August 2016 13:28 UTC

Return-Path: <sean@sn3rd.com>
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 8BCCA12D59B for <sidr@ietfa.amsl.com>; Tue, 2 Aug 2016 06:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 BNqa6unn2Cbs for <sidr@ietfa.amsl.com>; Tue, 2 Aug 2016 06:28:14 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAE912D5B5 for <sidr@ietf.org>; Tue, 2 Aug 2016 06:20:17 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id v123so41280309qkh.3 for <sidr@ietf.org>; Tue, 02 Aug 2016 06:20:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VDL08e6kGReCJ0hHI9sq2lalBPREG9rIqkZ/Edo0U9o=; b=mix6NSh+OoYZ6WvqY+nqfFeaVnBcZdyC7pwnVvVgrkjQhbAllQUUrULO9Qef18+/xe iY452389hIM6qZILy0y7jJFCWr/3+zS6wkpXkPpcr/SCP2fYcYw1wJQpLzfFuhrWIGJG yqFhgJoV8A6Jgc649PRw3mhJ7gUP6fqWhZ/DE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VDL08e6kGReCJ0hHI9sq2lalBPREG9rIqkZ/Edo0U9o=; b=RWE8U3uSzD2swDRVWH4Ea8n+SbJoLqAhL9dAPK02rRHIkFh+JlCArZOT4R1VmkssMZ XJ1iZGK5lcVrge7oBP6TGG8yhw8ziUqJJpD0CfozWX7PODisOKHbJ6H54/7pmAZepeZa /+ur902jqetLw8E9+FBWrc+ByYJZGDqPh76sw1l/ttGoL3VpkqI32mKsk01VGqy08Bda SiJOPX56ZLIOYEGZLM9NmDI9TwJONtJrsf0fVuTaTzCMxl2Spfa06p4w9JLza+dJHudo Y4Tic4mW6RJZ+3B7qL4TZhcfelRxXADCnxAVgsf4QhlYMG1jEbFBIJVa3TbQgpwqzpFA KeiA==
X-Gm-Message-State: AEkooutYyGr6o83CzxjFkltu6oCkjEm8cAh9W0b5E5uQypODQJvAsXtM31c/mqf+w0JzaQ==
X-Received: by 10.55.180.2 with SMTP id d2mr75675351qkf.69.1470144016334; Tue, 02 Aug 2016 06:20:16 -0700 (PDT)
Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id 50sm1322823qts.11.2016.08.02.06.20.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Aug 2016 06:20:15 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Sean Turner <sean@sn3rd.com>
X-Priority: 3
In-Reply-To: <00c501d1eca0$8fd24660$4001a8c0@gateway.2wire.net>
Date: Tue, 2 Aug 2016 09:20:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <89AE2EA7-BF74-4A59-9C6C-9F50595458D8@sn3rd.com>
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>
To: "t.petch" <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/AQZf6A2K_Fg9PmshivTr9-261k4>
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: Tue, 02 Aug 2016 13:28:16 -0000

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:

#.# 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
>> 
>