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

[Tim Bruijnzeels <[e-mail]>]

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 <[e-mail]> wrote:
> 
> ----- Original Message -----
> From: "Sean Turner" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Cc: "Rob Austein" <[e-mail]>; "IETF SIDR" <[e-mail]>
> Sent: Tuesday, August 02, 2016 2:20 PM
> On Aug 02, 2016, at 05:30, t.petch <[e-mail]> 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" <[e-mail]>
>> To: "Rob Austein" <[e-mail]>; "Tim Bruijnzeels" <[e-mail]>;
>> "Russ Housley" <[e-mail]>
>> Cc: "IETF SIDR" <[e-mail]>
>> Sent: Tuesday, August 02, 2016 12:28 AM
>> 
>>> On Jul 21, 2016, at 06:36, Tim Bruijnzeels <[e-mail]> 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 <[e-mail]> wrote:
>>>> 
>>>> 
>>>> On Jul 19, 2016, at 9:14 AM, Rob Austein <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>> 
> 
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr