RFC 8360

Resource Public Key Infrastructure (RPKI) Validation Reconsidered

📅 published April 2018, from ietf

RFC 8360: Resource Public Key Infrastructure (RPKI) Validation Reconsidered 🎀

okay bestie, this one is a whole glow-up for RPKI certificate validation 💅 It's a Standards Track doc from April 2018, and it's the work of Geoff Huston and George Michaelson (APNIC), Carlos Martinez (LACNIC), Tim Bruijnzeels (RIPE NCC), Andrew Newton (ARIN), and Dean Shaw (AFRINIC). It's published under ISSN 2070-1721. The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own 🦋

Resource Public Key Infrastructure (RPKI) Validation Reconsidered

RFC: 8360
ISSN: 2070-1721
Category: Standards Track
Date: April 2018

Abstract ✨

so the abstract basically says: this doc gives you an alternative to the certificate validation procedure from RFC 6487. The goal is to make managing certificates in the Resource Public Key Infrastructure (RPKI) less fragile to run day to day, and it keeps the important security features intact 🔥

Here's the tea. RFC 6487 says a Resource Certificate gets rejected totally if it overclaims any resources that aren't on the issuing certificate. The validation process in this doc is more chill. It lets an issuing Certification Authority (CA) signal that those certificates should still be accepted, but only for the intersection of their resources and the issuing certificate 💖

One thing to keep in mind: this validation process only looks at a single trust anchor (TA) 🧚 Overclaims that happen when multiple configured TAs claim overlapping resources are out of scope for this document, so don't go looking for that here.

The choice gets signaled with a set of alternative Object Identifiers (OIDs), which are defined in "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). Also, if none of these OIDs are used on any certificate under a trust anchor, the validation procedure here gives the same outcome as RFC 6487's procedure. Iconic consistency 👑

The doc also offers alternatives for Route Origin Authorization (ROA) (RFC 6482) validation and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation 🌈

Status of This Memo 📝

this is an Internet Standards Track document 🌸

It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more about Internet Standards, check Section 2 of RFC 7841.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8360 🫶

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💜

Table of Contents 🗺️

1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   4
2.  Certificate Validation in the RPKI  . . . . . . . . . . . . .   4
3.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
4.  An Amended RPKI Certification Validation Process  . . . . . .   7
  4.1.  Verified Resource Sets  . . . . . . . . . . . . . . . . .   7
  4.2.  Differences with Existing Standards . . . . . . . . . . .   7
    4.2.1.  Certificate Policy (CP) for Use with Validation
            Reconsidered in the RPKI  . . . . . . . . . . . . . .   7
    4.2.2.  An Alternative to X.509 Extensions for IP Addresses
            and AS Identifiers (RFC 3779) . . . . . . . . . . . .   8
    4.2.3.  Addendum to RFC 6268  . . . . . . . . . . . . . . . .  12
    4.2.4.  An Alternative to the Profile for X.509 PKIX Resource
            Certificates  . . . . . . . . . . . . . . . . . . . .  14
    4.2.5.  An Alternative ROA Validation . . . . . . . . . . . .  18
    4.2.6.  An Alternative to BGPsec Router Certificate
            Validation  . . . . . . . . . . . . . . . . . . . . .  18
5.  Validation Examples . . . . . . . . . . . . . . . . . . . . .  19
  5.1.  Example 1 -- An RPKI Tree Using the Old OIDs Only . . . .  19
  5.2.  Example 2 -- An RPKI Tree Using the New OIDs Only . . . .  21
  5.3.  Example 3 -- An RPKI Tree Using a Mix of Old and New OIDs  23
6.  Deployment Considerations . . . . . . . . . . . . . . . . . .  25
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  27
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  28
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  28
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1. Overview 🌟

okay so this section sets up the whole vibe. This document is an alternative to the certificate validation procedure in RFC 6487. Where RFC 6487 would have you reject Resource Certificates entirely when they overclaim anything that's not on the issuing certificate, this procedure says they should be accepted for the intersection of their resources and the issuing certificate only 💅

When there are no overclaims, both procedures give the same outcome. The new procedure also can never accept resources that aren't validly held along the path of issuing certificates. That's the security part, and it's non-negotiable 🔒

Here's the upside. If resources stop being validly held along the path of issuing certificates, the impact gets limited to attestations, like Route Origin Authorizations [RFC6482] that only reference those resources. So the damage stays contained instead of spreading everywhere 🦋

1.1. Requirements Notation 📖

Here's the BCP 14 part, bestie. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. So lowercase "must" is just a regular word, but the capitals are the real deal 💜

2. Certificate Validation in the RPKI 🔍

so validation of PKIX certificates that follow the RPKI profile is based on a path validation process. As currently defined in Section 7.2 of [RFC6487], every certificate on the validation path is required to meet the certificate validation criteria 🌈

Those criteria mean that the Internet Number Resources (INRs) of each certificate on the path have to be "encompassed" by the INRs on the issuing certificate. The first certificate on the path is required to be a trust anchor, and its resources are valid by definition 👑

Here's an example sequence:

Certificate 1 (trust anchor):
Issuer TA,
Subject TA,
Resources 192.0.2.0/24, 198.51.100.0/24,
      2001:db8::/32, AS64496-AS64500

Certificate 2:
Issuer TA,
Subject CA1,
Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32

Certificate 3:
Issuer CA1,
Subject CA2,
Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32

ROA 1:
Embedded Certificate 4 (EE certificate):
Issuer CA2,
Subject R1,
Resources 192.0.2.0/24

Prefix 192.0.2.0/24, Max Length 24, ASN 64496

Every certificate in this scenario is valid, since each certificate's INRs are encompassed by those of its issuing certificate ✨ ROA1 is valid because the specified prefix is encompassed by the embedded end entity (EE) certificate, as [RFC6482] requires 🎀

3. Operational Considerations 🛠️

real talk, the allocations recorded in the RPKI change when resources get transferred. For example, the CAs involved in a transfer might change CA certificates in an order that makes some of them "overclaim" for a little while. A certificate is said to "overclaim" if it includes INRs that aren't contained in the INRs of the CA that issued it 😭

It can also happen that a child CA doesn't voluntarily request a shrunk Resource Certificate when the parent transfers or reclaims resources. On top of that, operational errors during management of RPKI databases can create CA certificates that, temporarily, don't encompass all of the INRs of their subordinate certificates. Messy, but real 🙈

Let's look at this sequence:

Certificate 1 (trust anchor):
Issuer TA,
Subject TA,
Resources 192.0.2.0/24, 198.51.100.0/24,
     2001:db8::/32, AS64496-AS64500

Certificate 2:
Issuer TA,
Subject CA1,
Resources 192.0.2.0/24, 2001:db8::/32

Certificate 3 (invalid):
Issuer CA1,
Subject CA2,
Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32

ROA 1 (invalid):
Embedded Certificate 4 (EE certificate, invalid):
Issuer CA2,
Subject R1,
Resources 192.0.2.0/24

Prefix 192.0.2.0/24, Max Length 24, ASN 64496

Here's what happened. TA reissued Certificate 2 to CA1, and the prefix 198.51.100.0/24 got removed. But CA1 never reissued a new Certificate 3 to CA2. So Certificate 3 is now overclaiming and considered invalid. By recursion, the embedded Certificate 4 used for ROA1 is also invalid. ROA1 is invalid too, because the prefix in the ROA is no longer encompassed by a valid embedded EE certificate, as [RFC6482] requires 💀

But here's the plot twist. ROA1 doesn't use any of the address resources that were removed from CA1's certificate. So it would be desirable for ROA1 to still be viewed as valid 🥺 Technically, CA1 should reissue Certificate 3 to CA2 without 198.51.100.0/24, and then ROA1 would be considered valid according to [RFC6482]. But until CA1 takes that action, ROA1 stays invalid. It would be preferable for ROA1 to be considered valid, since the assertion it makes wasn't affected by the reduced scope of CA1's certificate 💖

4. An Amended RPKI Certification Validation Process ✨

4.1. Verified Resource Sets ✨

okay so this problem is kinda low probability rn 🥺 but if an overclaim happened near the apex of the RPKI hierarchy, the impact would be sooo big 😭 because it would invalidate the entire subtree below that point. cannot be me 💀

the changes here to the validation procedure in [RFC6487] don't change how likely this is, but they do limit the damage to just the overclaimed resources 💥 the goal is to stop CA certificates from being treated as totally invalid just because of an overclaim 🫶 and it's designed so the security doesn't get worse. ROAs and router certificates only count as valid if every resource inside them is covered by all superior certificates along the path to a trust anchor 🔐 no shortcuts, periodt.

the way this works conceptually is that each certificate keeps its own Verified Resource Set (VRS), which is separate from the INRs found in the resource extension [RFC3779] in the certificate 🧚

4.2. Differences with Existing Standards 🎀

4.2.1. Certificate Policy (CP) for Use with Validation Reconsidered in the RPKI 🌸

so [RFC6484] has a Section 1.2 that defines the "Certificate Policy (CP) for the Resource PKI (RPKI)" with this OID:

id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
        identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) cp(14) 2 }

and this doc is giving us a brand new OID for an alternative "Certificate Policy (CP) for use with validation reconsidered in the Resource PKI (RPKI)" 👑

id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1)
        identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) cp(14) 3 }

this alternative CP is the same as the one in [RFC6484], except it's the one that drives the decision in Step 8 of the validation procedure described in Section 4.2.4.4 💅

4.2.2. An Alternative to X.509 Extensions for IP Addresses and AS Identifiers (RFC 3779) 🦋

this document is basically an alternative to [RFC3779]. all the specifications and procedures in [RFC3779] still apply, with the notable exceptions in the following subsections 🫶

4.2.2.1. OID for id-pe-ipAddrBlocks-v2 🌈

an OID has been assigned for the extension id-pe-ipAddrBlocks-v2 (id-pe 28). this OID MUST only be used in conjunction with the alternative Certificate Policy OID from Section 4.2.1. no mixing it up, bestie 🙈

this is the amended spec that replaces Section 2.2.1 of [RFC3779].

the OID for this extension is id-pe-ipAddrBlocks-v2.

id-pe-ipAddrBlocks-v2  OBJECT IDENTIFIER ::= { id-pe 28 }

where [RFC5280] defines:

id-pkix  OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
       dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

id-pe    OBJECT IDENTIFIER ::= { id-pkix 1 }

4.2.2.2. Syntax for id-pe-ipAddrBlocks-v2 🍓

here's the syntax, and it's giving very structured ✨

id-pe-ipAddrBlocks-v2      OBJECT IDENTIFIER ::= { id-pe 28 }

IPAddrBlocks        ::= SEQUENCE OF IPAddressFamily

IPAddressFamily     ::= SEQUENCE {    -- AFI & optional SAFI --
addressFamily        OCTET STRING (SIZE (2..3)),
ipAddressChoice      IPAddressChoice }

IPAddressChoice     ::= CHOICE {
inherit              NULL, -- inherit from issuer --
addressesOrRanges    SEQUENCE OF IPAddressOrRange }

IPAddressOrRange    ::= CHOICE {
addressPrefix        IPAddress,
addressRange         IPAddressRange }

IPAddressRange      ::= SEQUENCE {
min                  IPAddress,
max                  IPAddress }

IPAddress           ::= BIT STRING

the descriptions of the objects referenced in the syntax above are defined in Sections 2.2.3.1 through 2.2.3.9 of [RFC3779] 📚

4.2.2.3. OID for id-pe-autonomousSysIds-v2 🧚

an OID has been assigned for the extension id-pe-autonomousSysIds-v2 (id-pe 29). this OID MUST only be used in conjunction with the alternative Certificate Policy OID from Section 4.2.1, same energy as before 💜

this is the amended spec that replaces Section 3.2.1 of [RFC3779].

the OID for this extension is id-pe-autonomousSysIds-v2.

id-pe-autonomousSysIds-v2  OBJECT IDENTIFIER ::= { id-pe 29 }

where [RFC5280] defines:

id-pkix  OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
       dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

id-pe    OBJECT IDENTIFIER ::= { id-pkix 1 }

4.2.2.4. Syntax for id-pe-autonomousSysIds-v2 🌸

id-pe-autonomousSysIds-v2  OBJECT IDENTIFIER ::= { id-pe 29 }

ASIdentifiers       ::= SEQUENCE {
asnum               [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi                 [1] EXPLICIT ASIdentifierChoice OPTIONAL}

ASIdentifierChoice  ::= CHOICE {
inherit              NULL, -- inherit from issuer --
asIdsOrRanges        SEQUENCE OF ASIdOrRange }

ASIdOrRange         ::= CHOICE {
id                  ASId,
range               ASRange }

ASRange             ::= SEQUENCE {
min                 ASId,
max                 ASId }

ASId                ::= INTEGER

4.2.2.5. Amended IP Address Delegation Extension Certification Path Validation 💅

certificate path validation is done exactly as specified in Section 4.2.4.4. easy 🫶

4.2.2.6. Amended Autonomous System Identifier Delegation Extension Certification Path Validation 🦋

same deal here: certificate path validation is done as specified in Section 4.2.4.4 ✨

4.2.2.7. Amended ASN.1 Module 👑

an OID has been assigned for id-mod-ip-addr-and-as-ident-v2, like this:

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(90) }

this is the amended spec that replaces Appendix A of [RFC3779]. it's a normative appendix that describes the extensions for IP address and AS identifier delegation used by conforming PKI components, written in ASN.1 syntax 🎀

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(90) }

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 28 }

-- Validation Reconsidered IP Address Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --

-- Validation Reconsidered Autonomous System Identifier --
--     Delegation Extension OID                         --

id-pe-autonomousSysIds-v2  OBJECT IDENTIFIER ::= { id-pe 29 }

-- Validation Reconsidered Autonomous System Identifier --
--     Delegation Extension Syntax                      --

-- Syntax is imported from RFC 3779 --

END

4.2.3. Addendum to RFC 6268 📮

an OID has been assigned for id-mod-ip-addr-and-as-ident-2v2 as follows:

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(91) }

[RFC6268] is an informational RFC that updates some auxiliary ASN.1 modules so they conform to the 2008 version of ASN.1. the 1988 ASN.1 modules in Section 4.2.2.7 are still the normative version, so don't skip them 🙈

this is the additional module that conforms to the 2008 version of ASN.1, to be used with the extensions defined in Sections 4.2.2.1 and 4.2.2.3 🌈

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(91) }

 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 contain 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 RFC 5280
    --

    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 28 }

    -- Validation Reconsidered IP Address Delegation --
    --      Extension Syntax                         --

    -- Syntax is imported from RFC 6268 --

    -- 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 29 }

 -- Validation Reconsidered Autonomous System Identifier --
 --      Delegation Extension Syntax                     --

 -- Syntax is imported from RFC 6268 --

 END

4.2.4. An Alternative to the Profile for X.509 PKIX Resource Certificates 🫧

this document defines an alternative profile for X.509 PKIX Resource Certificates. it follows all the definitions and procedures in [RFC6487], with the notable exceptions below 💖

4.2.4.1. Amended Certificate Policies 🌟

this is the amended spec used in this profile, in place of Section 4.8.9 of [RFC6487].

this extension MUST be present and MUST be marked critical. it MUST include exactly one policy of type id-cp-ipAddr-asNumber-v2, as specified in the updated RPKI CP in Section 4.2.1. three MUSTs in one paragraph, so this part is not optional, bestie 😭

4.2.4.2. Amended IP Resources 🌸

okay so this is the amended spec, and you use it in this profile instead of Section 4.8.10 of [RFC6487] 💅

Either the IP resources extension or the AS resources extension, or both, MUST be present in all RPKI certificates and MUST be marked critical. no cap, that's a hard rule 🔥

This extension holds the list of IP address resources, as described in Section 4.2.2.1 ✨ It's allowed to use the "inherit" element for a particular Address Family Identifier (AFI) value. For Resource Certificates that describe public number resources for use on the public Internet, the Subsequent AFI (SAFI) value MUST NOT be used 🙈

This extension MUST either list a non-empty set of IP address records, or use the "inherit" setting to say the IP address resource set of this certificate is inherited from the issuer's certificate 🎀

4.2.4.3. Amended AS Resources 🧚

this one's the amended spec that replaces Section 4.8.11 of [RFC6487] 💖

Either the AS resources extension or the IP resources extension, or both, MUST be present in all RPKI certificates and MUST be marked critical 🌈

This extension holds the list of AS number resources as described in Section 4.2.2.3, or it can use the "inherit" element. Routing Domain Identifier (RDI) values are NOT supported in this profile and MUST NOT be used. not for us, bestie 🙅‍♀️

This extension MUST either list a non-empty set of AS number records, or use the "inherit" setting to say the AS number resource set of this certificate is inherited from the issuer's certificate ✨

4.2.4.4. Amended Resource Certificate Path Validation 🦋

this is the amended path validation spec, and it replaces Section 7.2 of [RFC6487] 🫶 It lets you validate BOTH certificates that follow the profile in [RFC6487] AND certificates that follow the profile described above, so it's super flexible 💜

The validation algorithm for CA and EE resource certificates is modeled on the path validation algorithm from [RFC5280], but it's been tweaked so it uses the IP Address Delegation and AS Identifier Delegation extensions from [RFC3779] 🌸

There are two inputs to the algorithm:

  1. a trust anchor
  2. a certificate to be validated

The algorithm starts with two brand-new variables for the RPKI: Verified Resource Set-IP (VRS-IP) and Verified Resource Set-AS (VRS-AS). These sets track the INRs (IP address space and AS numbers) that count as valid for each CA certificate. At the start, the VRS-IP and VRS-AS sets are set to the IP Address Delegation and AS Identifier Delegation values, respectively, from the trust anchor used for validation 👑

This path validation algorithm checks, among other things, that a possible certification path (a sequence of n certificates) meets these conditions:

a. for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate (x + 1);

b. certificate 1 is issued by a trust anchor;

c. certificate n is the certificate to be validated; and

d. for all x in {1, ..., n}, certificate x is valid.

Certificate validation means checking that ALL of the following conditions hold, on top of the certification path validation criteria in Section 6 of [RFC5280] 🔥

  1. The signature of certificate x (x>1) is verified using the public key of the issuer's certificate (x-1), with the signature algorithm specified for that public key (in certificate x-1).
  2. The current time has to fall inside the interval defined by the NotBefore and NotAfter values in the Validity field of certificate x.
  3. The Version, Issuer, and Subject fields of certificate x satisfy the constraints set out in Sections 4.1 to 4.7 of RFC 6487.
  4. If certificate x uses the Certificate Policy defined in Section 4.8.9 of [RFC6487], then the certificate MUST contain all extensions defined in Section 4.8 of [RFC6487] that must be present. The value(s) for each of these extensions MUST satisfy the constraints set for each extension in its own section. Any extension that isn't identified this way MUST NOT appear in certificate x 🙈
  5. If certificate x uses the Certificate Policy defined in Section 4.2.4.1, then all extensions defined in Section 4.8 of [RFC6487], except Sections 4.8.9, 4.8.10, and 4.8.11, MUST be present. The certificate MUST contain an extension as defined in Sections 4.2.4.2 or 4.2.4.3, or both. The value(s) for each of these extensions MUST satisfy the constraints set for each extension in its own section. Any extension that isn't identified this way MUST NOT appear in certificate x 💅
  6. Certificate x MUST NOT have been revoked, i.e., it MUST NOT appear on a Certificate Revocation List (CRL) issued by the CA represented by certificate x-1 💀
  7. Compute the VRS-IP and VRS-AS set values as follows:
    • If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension.
    • If the IP Address Delegation extension is present in certificate x and x>1, set the VRS-IP to the intersection of the resources between this extension and the value of the VRS-IP computed for certificate x-1.
    • If the IP Address Delegation extension is absent in certificate x, set the VRS-IP to NULL.
    • If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension.
    • If the AS Identifier Delegation extension is present in certificate x and x>1, set the VRS-AS to the intersection of the resources between this extension and the value of the VRS-AS computed for certificate x-1.
    • If the AS Identifier Delegation extension is absent in certificate x, set the VRS-AS to NULL.
  8. If there is any difference in resources between the VRS-IP and the IP Address Delegation extension on certificate x, or between the VRS-AS and the AS Identifier Delegation extension on certificate x, then:
    • If certificate x uses the Certificate Policy defined in Section 4.2.4.1, a warning listing the overclaiming resources for certificate x SHOULD be issued.
    • If certificate x uses the Certificate Policy defined in Section 4.8.9 of [RFC6487], then certificate x MUST be rejected.

These rules let a CA certificate hold resources that aren't in (all of) the certificates along the path from the trust anchor to the CA certificate 🌈 If none of the resources in the CA certificate show up in every certificate along the path, then no subordinate certificates could be valid. But the certificate isn't rejected right away, because this might just be a temporary situation 🦋 Not rejecting it immediately doesn't create a security problem, since the associated VRS sets accurately reflect the resources that are validly tied to that certificate ✨

4.2.5. An Alternative ROA Validation 💖

Section 4 of [RFC6482] currently has this text on validating resources on a ROA:

The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension.

If the end entity certificate uses the Certificate Policy defined in Section 4.2.4.1, then the following approach must be used instead.

The amended IP Address Delegation extension described in Section 4.2.4.2 is present in the end entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the VRS-IP set that is specified as an outcome of EE certificate validation described in Section 4.2.4.4.

Note that this makes sure ROAs can only be valid if ALL the IP address prefixes in the ROA are covered by the VRS-IP of every certificate along the path to the trust anchor used to verify it 🔥

Operators MAY issue separate ROAs for each IP address prefix 🌸 That way, if one or more IP address prefixes drop out of the VRS-IP of any certificate along the path to the trust anchor, the authorizations for the other IP address prefixes aren't invalidated 🧚

4.2.6. An Alternative to BGPsec Router Certificate Validation 🍓

If a BGPsec Router Certificate [RFC8209] uses the Certificate Policy defined in Section 4.2.4.1, then, in addition to the BGPsec Router Certificate Validation defined in Section 3.3 of [RFC8209], the following constraint MUST be met:

  • The VRS-AS of BGPsec Router Certificates MUST encompass all Autonomous System Numbers (ASNs) in the AS Resource Identifier Delegation extension. 🫶

Operators MAY issue separate BGPsec Router Certificates for different ASNs 💜 That way, if an ASN drops out of the VRS-AS of any certificate along the path to the trust anchor, the router keys for other ASNs aren't invalidated 🌈

5. Validation Examples ✨

In this section, we're going to show what happens when RPKI validation runs using the algorithm and procedures from Sections 4.2.4.4, 4.2.5, and 4.2.6, under three deployment scenarios 🎀

  • An RPKI tree made up of certificates that use the old OIDs only
  • An RPKI tree made up of certificates that use the new OIDs only
  • An RPKI tree made up of a mix of certificates that use either the old or the new OIDs

Here, we call a certificate one that uses the 'old' OIDs if it uses a combination of the OIDs defined in Section 1.2 of [RFC6484], Section 2.2.1 of [RFC3779], and/or Section 3.2.1 of [RFC3779]. We call a certificate one that uses the 'new' OIDS if it uses a combination of OIDs defined in Sections 4.2.4.1, 4.2.2.1, and/or Section 4.2.2.3 🦋

5.1. Example 1 -- An RPKI Tree Using the Old OIDs Only 🌸

okay so let's walk through a whole RPKI tree that only uses the OLD OIDs 🫶 starting with the trust anchor, the bestie of the whole chain 👑

Certificate 1 (trust anchor):
 Issuer: TA,
 Subject: TA,
 OIDs: OLD,
 Resources: 0/0, ::0, AS0-4294967295 (all resources)

  Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
  Warnings: none

Certificate 2:
 Issuer: TA,
 Subject: CA1,
 OIDs: OLD,
 Resources: 192.0.2.0/24, 2001:db8::/32, AS64496

  Verified Resource Set: 192.0.2.0/24,
                         2001:db8::/32, AS64496
  Warnings: none

Certificate 3 (invalid):
 Issuer: CA1,
 Subject: CA2,
 OIDs: OLD,
 Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496

  Verified Resource Set: 192.0.2.0/24, AS64496

  Certificate 3 is considered invalid because resources
  contains 198.51.100.0/24, which is not found in the
  Verified Resource Set.

ROA 1 (invalid):
 Embedded Certificate 4 (EE certificate invalid):
  Issuer: CA2,
  Subject: R1,
  OIDs: OLD,
  Resources: 192.0.2.0/24
    Prefix 192.0.2.0/24, Max Length 24, ASN 64496

  ROA1 is considered invalid because Certificate 3 is invalid.

ROA 2 (invalid):
 Embedded Certificate 5 (EE certificate invalid):
  Issuer: CA2,
  Subject: R2,
  OIDs: OLD,
  Resources: 198.51.100.0/24
   Prefix 198.51.100.0/24, Max Length 24, ASN 64496

  ROA2 is considered invalid because Certificate 3 is invalid.

BGPsec Certificate 1 (invalid):
 Issuer: CA2,
 Subject: ROUTER-64496,
 OIDs: NEW,
 Resources: AS64496

  BGPsec Certificate 1 is invalid because Certificate 3 is invalid.

BGPsec Certificate 2 (invalid):
 Issuer: CA2,
 Subject: ALL-ROUTERS,
 OIDs: NEW,
 Resources: AS64496-AS64497

  BGPsec Certificate 2 is invalid because Certificate 3 is invalid.

Ngl the drama here is Certificate 3 👀 it claims 198.51.100.0/24, which isn't in its Verified Resource Set, so it's invalid, and that domino effect takes out everything hanging under it 💀 ROA 1 and ROA 2 both go down with it, plus both BGPsec certificates.

5.2. Example 2 -- An RPKI Tree Using the New OIDs Only 💅

now let's see the same vibe but under the amended approach, where every single certificate uses the NEW OIDs 🦋

Certificate 1 (trust anchor):
 Issuer: TA,
 Subject: TA,
 OIDs: NEW,
 Resources: 0/0, ::0, AS0-4294967295 (all resources)

  Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
  Warnings: none

Certificate 2:
 Issuer: TA,
 Subject: CA1,
 OIDs: NEW,
 Resources: 192.0.2.0/24, 2001:db8::/32, AS64496

  Verified Resource Set: 192.0.2.0/24,
                         2001:db8::/32, AS64496
  Warnings: none

Certificate 3:
 Issuer: CA1,
 Subject: CA2,
 OIDs: NEW,
 Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496

  Verified Resource Set: 192.0.2.0/24, AS64496
  Warnings: overclaim for 198.51.100.0/24

ROA 1 (valid):
 Embedded Certificate 4 (EE certificate):
  Issuer: CA2,
  Subject: R1,
  OIDs: NEW,
  Resources: 192.0.2.0/24
   Prefix 192.0.2.0/24, Max Length 24, ASN 64496

   Verified Resource Set: 192.0.2.0/24
   Warnings: none

  ROA1 is considered valid because the prefix matches the Verified
  Resource Set on the embedded EE certificate.

ROA 2 (invalid):
 Embedded Certificate 5 (EE certificate invalid):
  Issuer: CA2,
  Subject: R2,
  OIDs: NEW,
  Resources: 198.51.100.0/24
    Prefix 198.51.100.0/24, Max Length 24, ASN 64496

    Verified Resource Set: none (empty set)
    Warnings: 198.51.100.0/24

  ROA2 is considered invalid because the ROA prefix 198.51.100.0/24
  is not contained in the Verified Resource Set.

BGPsec Certificate 1 (valid):
 Issuer: CA2,
 Subject: ROUTER-64496,
 OIDs: NEW,
 Resources: AS64496

  Verified Resource Set: AS64496
  Warnings: none

BGPsec Certificate 2 (invalid):
 Issuer: CA2,
 Subject: ALL-ROUTERS,
 OIDs: NEW,
 Resources: AS64496-AS64497

   Verified Resource Set: AS64496

  BGPsec Certificate 2 is invalid because not all of its resources
  are contained in the Verified Resource Set.

  Note that this problem can be mitigated by issuing separate
  certificates for each AS number.

The glow-up here is that Certificate 3 only gets a warning for its overclaim 🫠 it doesn't take the whole tree down with it. ROA 1 stays valid because its prefix fits inside its own Verified Resource Set 🎀 ROA 2 and BGPsec Certificate 2 still get marked invalid because their resources don't fit 🙈

5.3. Example 3 -- An RPKI Tree Using a Mix of Old and New OIDs 🧚

this one is my favourite, lowkey 💜 the idea is that the NEW OIDs only show up on the CA certificates where the issuing CA thinks an overclaim could happen, so the damage stays contained to just the resources in question 🍓

Certificate 1 (trust anchor):
 Issuer: TA,
 Subject: TA,
 OIDs: OLD,
 Resources: 0/0, ::0, AS0-4294967295 (all resources)

  Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
  Warnings: none

  Note that a trust anchor certificate cannot be found to
  overclaim.  So, using the new OIDs here would not change
  anything with regards to the validity of this certificate.

Certificate 2:
 Issuer: TA,
 Subject: CA1,
 OIDs: OLD,
 Resources: 192.0.2.0/24, 2001:db8::/32, AS64496

  Verified Resource Set: 192.0.2.0/24,
                         2001:db8::/32, AS64496
  Warnings: none

  Note that since the TA certificate claims all resources, it
  is impossible to issue a certificate below it that could be
  found to be overclaiming.  Therefore, there is no benefit
  in using the new OIDs for Certificate 2.

Certificate 3:
 Issuer: CA1,
 Subject: CA2,
 OIDs: NEW,
 Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496

  Verified Resource Set: 192.0.2.0/24, AS64496
  Warnings: overclaim for 198.51.100.0/24

  Note that CA1 anticipated that it might invalidate Certificate 3
  issued to CA2, if its own resources on Certificate 2 were
  modified and old OIDs were used on Certificate 3.

ROA 1 (valid):
 Embedded Certificate 4 (EE certificate):
  Issuer: CA2,
  Subject: R1,
  OIDs: OLD,
  Resources: 192.0.2.0/24
   Prefix 192.0.2.0/24, Max Length 24, ASN 64496

   Verified Resource Set: 192.0.2.0/24
   Warnings: none

  ROA1 is considered valid because the prefix matches the Verified
  Resource Set on the embedded EE certificate.

ROA 2 (invalid):
 Embedded Certificate 5 (EE certificate invalid):
  Issuer: CA2,
  Subject: R2,
  OIDs: OLD,
  Resources: 198.51.100.0/24
    Prefix 198.51.100.0/24, Max Length 24, ASN 64496

    Verified Resource Set: none (empty set)

  ROA2 is considered invalid because resources on its EE
  certificate contains 198.51.100.0/24, which is not contained
  in its Verified Resource Set.

  Note that if new OIDs were used here (as in example 2), ROA 2
  would be considered invalid because the prefix is not
  contained in the Verified Resource Set.

  So, if there is no difference in the validity outcome, one could
  argue that using old OIDs here is clearest, because any
  overclaim of ROA prefixes MUST result in it being considered
  invalid (as described in Section 4.2.5).

BGPsec Certificate 1 (valid):
 Issuer: CA2,
 Subject: ROUTER-64496,
 OIDs: OLD,
 Resources: AS64496

  Verified Resource Set: AS64496
  Warnings: none

BGPsec Certificate 2 (invalid):
 Issuer: CA2,
 Subject: ALL-ROUTERS,
 OIDs: OLD,
 Resources: AS64496-AS64497

   Verified Resource Set: AS64496

  BGPsec Certificate 2 is considered invalid because resources
  contains AS64497, which is not contained in its Verified Resource
  Set.

  Note that if new OIDs were used here (as in example 2), BGPsec
  Certificate 2 would be considered invalid because the prefix is not
  contained in the Verified Resource Set.

  So, if there is no difference in the validity outcome, one could
  argue that using old OIDs here is the clearest, because any
  overclaim on this certificate MUST result in it being considered
  invalid (as described in Section 4.2.6).

  Also note that, as in example 2, this problem can be mitigated by
  issuing separate certificates for each AS number.

So the big takeaway 🌈 with a mixed tree, you only pay the NEW OIDs tax where an accidental overclaim could actually happen. Everything else can stay on OLD and nothing changes validity-wise, which is so clean 🧼 Also, the phrase "any overclaim of ROA prefixes MUST result in it being considered invalid" is the main rule for the ROA side 💅 and the phrase "any overclaim on this certificate MUST result in it being considered invalid" is the matching rule for BGPsec certs 🔥

6. Deployment Considerations 🚀

okay so this document defines an alternative RPKI validation algorithm, but it doesn't tell you how to actually deploy it 🫠 that's a separate convo that should be had on its own 💬 still, here are some observations that might help get that discussion started ✨

because this document brings in new OIDs and an alternative to the profile for X.509 PKIX Resource Certificates from [RFC6487], any certificates using them in the global RPKI will get rejected by Relying Party tools that don't (yet) support the alternative profile in this document 😭

which means, it's really important that those tools get updated before Certification Authorities start using this specification 🛠️

BUT, here's the good news 🥹 because the OIDs are defined in each RPKI certificate, there's no strict requirement for every Certification Authority, or even every certificate they issue, to switch to the new OIDs at the same time 🎀 Section 5.3 shows a possible rollout where the new OIDs only go into CA certificates where an accidental overclaim might happen 🦋

7. Security Considerations 🔐💀

the authors are confident that the revised validation algorithm doesn't introduce any new security vulnerabilities into the RPKI 🛡️ the reason is that it can't lead to any ROA or router certificate being accepted if it contains resources the issuer doesn't actually hold 🙅‍♀️ so no sneaky overclaims getting through the back door, periodt 🔥

8. IANA Considerations 🧾

IANA has added the following to the "SMI Security for PKIX Certificate Policies" registry:

  Decimal  Description                       References

    3     id-cp-ipAddr-asNumber-v2           Section 4.2.1

IANA has added the following to the "SMI Security for PKIX Certificate Extension" registry:

  Decimal  Description                       References

    28     id-pe-ipAddrBlocks-v2             Section 4.2.2.1
    29     id-pe-autonomousSysIds-v2         Section 4.2.2.3

IANA has added the following to the "SMI Security for PKIX Module Identifier" registry:

  Decimal  Description                       References

    90   id-mod-ip-addr-and-as-ident-v2      Section 4.2.2.7
    91   id-mod-ip-addr-and-as-ident-2v2     Section 4.2.3

9. References 📚

9. References ✨

okay bestie, this is the bibliography section and it's where the receipts live 📚💅 every citation is listed with all its details so nobody can say we didn't show our work 🫶

9.1. Normative References

these are the ones you actually need to read before you can implement anything, so no skipping 🎀

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779,
              DOI 10.17487/RFC3779, June 2004,
              <https://www.rfc-editor.org/info/rfc3779>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,
              <https://www.rfc-editor.org/info/rfc6482>.

   [RFC6484]  Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
              Policy (CP) for the Resource Public Key Infrastructure
              (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February
              2012, <https://www.rfc-editor.org/info/rfc6484>.

   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", RFC 6487,
              DOI 10.17487/RFC6487, February 2012,
              <https://www.rfc-editor.org/info/rfc6487>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8209]  Reynolds, M., Turner, S., and S. Kent, "A Profile for
              BGPsec Router Certificates, Certificate Revocation Lists,
              and Certification Requests", RFC 8209,
              DOI 10.17487/RFC8209, September 2017,
              <https://www.rfc-editor.org/info/rfc8209>.

9.2. Informative References

this one's just for extra context, not required reading, but it's a certified good read 🌸

   [RFC6268]  Schaad, J. and S. Turner, "Additional New ASN.1 Modules
              for the Cryptographic Message Syntax (CMS) and the Public
              Key Infrastructure Using X.509 (PKIX)", RFC 6268,
              DOI 10.17487/RFC6268, July 2011,
              <https://www.rfc-editor.org/info/rfc6268>.

Acknowledgements 🫶

the authors gave a huge shoutout to everyone who helped make this happen, and honestly the group chat deserves it 💜

Stephen Kent reviewed and contributed to the document 🧚

Rob Austein is the reason separate OIDs are used, because he suggested it so Relying Party tools could behave deterministically 👑

Russ Housley, Sean Turner, and Tom Petch helped with the OID and ASN.1 updates 🎀

Tom Harrison gave the whole document a general review 🌈

thank you all, you're literally iconic 💖

Authors' Addresses 💌

here's where you can find the authors, with their phone numbers and emails if you want to slide into their DMs 🦋

Geoff Huston 🌸

Geoff Huston
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD  4101
Australia

Phone: +61 7 3858 3100
Email: gih@apnic.net

George Michaelson 🧚

George Michaelson
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD  4101
Australia

Phone: +61 7 3858 3100
Email: ggm@apnic.net

Carlos M. Martinez 💜

Carlos M. Martinez
Latin American and Caribbean Internet Address Registry
Rambla Mexico 6125
Montevideo  11400
Uruguay

Phone: +598 2604 2222
Email: carlos@lacnic.net

Tim Bruijnzeels 🍓

Tim Bruijnzeels
RIPE Network Coordination Centre
Singel 258
Amsterdam  1016 AB
The Netherlands

Email: tim@ripe.net

Andrew Lee Newton 🦋

Andrew Lee Newton
American Registry for Internet Numbers
3635 Concorde Parkway
Chantilly, VA  20151
United States of America

Email: andy@arin.net

Daniel Shaw ✨

Daniel Shaw
African Network Information Centre (AFRINIC)
11th Floor, Standard Chartered Tower
Cybercity, Ebene
Mauritius

Phone: +230 403 51 00
Email: daniel@afrinic.net

that's the whole thing, bestie, and honestly the RPKI squad slayed 🌈👑💅

📦 where this page comes from