> On Jul 21, 2016, at 06:36, Tim Bruijnzeels <t...@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 <hous...@vigilsec.com> wrote:
>>
>>
>> On Jul 19, 2016, at 9:14 AM, Rob Austein <s...@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
>>
>> 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
>>
>> 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
