File formats:

Status:

PROPOSED STANDARD

Authors:

G. Huston
G. Michaelson
C. Martinez
T. Bruijnzeels
A. Newton
D. Shaw

Stream:

IETF

Source:

sidr (rtg)

Cite this RFC: TXT  |  XML  |   BibTeX

DOI:  https://doi.org/10.17487/RFC8360

Discuss this RFC: Send questions or comments to the mailing list sidr@ietf.org

Other actions: View Errata  |  Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 8360

Abstract

This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.

The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.

It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.

This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.

Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.