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