Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9323.¶

Copyright Notice

Copyright (c) 2022 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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document defines a Cryptographic Message Syntax (CMS) [RFC5652] [RFC6268] protected content type for a general-purpose listing of checksums (a 'checklist'), for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. The CMS protected content type is intended to provide for the creation and validation of an RPKI Signed Checklist (RSC), a checksum listing signed with a specific set of Internet Number Resources. The objective is to allow for the creation of an attestation that, when validated, provides a means to confirm a given Internet resource holder produced the RSC.¶

RPKI Signed Checklists are expected to facilitate inter-domain business use cases that depend on an ability to verify resource holdership. RPKI-based validation processes are expected to become the industry norm for automated Bring Your Own IP (BYOIP) on-boarding or establishment of physical interconnections between Autonomous Systems (ASes).¶

The RSC concept borrows heavily from Resource Tagged Attestation (RTA) [RPKI-RTA], Manifests [RFC9286], and OpenBSD's signify utility [signify]. The main difference between an RSC and RTA is that the RTA profile allows multiple signers to attest a single digital object through a checksum of its content, while the RSC profile allows a single signer to attest the content of multiple digital objects. A single signer profile is considered a simplification for both implementers and operators.¶

2. RSC Profile and Distribution

RSC follows the Signed Object Template for the RPKI [RFC6488] with one exception: because RSCs MUST NOT be distributed through the global RPKI repository system, the Subject Information Access (SIA) extension MUST be omitted from the RSC's X.509 End-Entity (EE) certificate.¶

What constitutes suitable transport for RSC files is deliberately unspecified. For example, it might be a USB stick, a web interface secured with HTTPS, an email signed with Pretty Good Privacy (PGP), a T-shirt printed with a QR code, or a carrier pigeon.¶

3. The RSC eContentType

The eContentType for an RSC is defined as id-ct-signedChecklist, with Object Identifier (OID) 1.2.840.113549.1.9.16.1.48.¶

This OID MUST appear within both the eContentType in the encapContentInfo object and the ContentType signed attribute in the signerInfo object (see [RFC6488]).¶

4. The RSC eContent

The content of an RSC indicates that a checklist for arbitrary digital objects has been signed with a specific set of Internet Number Resources. An RSC is formally defined as follows:¶

RpkiSignedChecklist-2022
  { iso(1) member-body(2) us(840) rsadsi(113549)
    pkcs(1) pkcs9(9) smime(16) mod(0)
    id-mod-rpkiSignedChecklist-2022(73) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  CONTENT-TYPE, Digest, DigestAlgorithmIdentifier
  FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

  IPAddressOrRange, ASIdOrRange
  FROM IPAddrAndASCertExtn -- in [RFC3779]
    { 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) } ;

ct-rpkiSignedChecklist CONTENT-TYPE ::=
  { TYPE RpkiSignedChecklist
    IDENTIFIED BY id-ct-signedChecklist }

id-ct-signedChecklist OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) id-smime(16) id-ct(1) 48 }

RpkiSignedChecklist ::= SEQUENCE {
  version [0]           INTEGER DEFAULT 0,
  resources             ResourceBlock,
  digestAlgorithm       DigestAlgorithmIdentifier,
  checkList             SEQUENCE (SIZE(1..MAX)) OF FileNameAndHash }

FileNameAndHash ::= SEQUENCE {
  fileName              PortableFilename OPTIONAL,
  hash                  Digest }

PortableFilename ::=
  IA5String (FROM("a".."z" | "A".."Z" | "0".."9" | "." | "_" | "-"))

ResourceBlock ::= SEQUENCE {
  asID         [0]      ConstrainedASIdentifiers OPTIONAL,
  ipAddrBlocks [1]      ConstrainedIPAddrBlocks OPTIONAL }
  -- at least one of asID or ipAddrBlocks MUST be present
  ( WITH COMPONENTS { ..., asID PRESENT} |
    WITH COMPONENTS { ..., ipAddrBlocks PRESENT } )

ConstrainedIPAddrBlocks ::=
  SEQUENCE (SIZE(1..MAX)) OF ConstrainedIPAddressFamily

ConstrainedIPAddressFamily ::= SEQUENCE {
  addressFamily         OCTET STRING (SIZE(2)),
  addressesOrRanges     SEQUENCE (SIZE(1..MAX)) OF IPAddressOrRange }

ConstrainedASIdentifiers ::= SEQUENCE {
  asnum [0]             SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange }

END

5. RSC Validation

Before a Relying Party (RP) can use an RSC to validate a set of digital objects, the RP MUST first validate the RSC. To validate an RSC, the RP MUST perform all the validation checks specified in [RFC6488], except for checking for the presence of an SIA extension, which MUST NOT be present in the EE certificate (see Section 2). In addition, the RP MUST perform the following RSC-specific validation steps:¶

1. The contents of the CMS eContent field MUST conform to all of the constraints described in Section 4, including the constraints described in Section 4.4.1.¶
2. If the asID field is present within the contents of the resources field, then the AS identifier delegation extension [RFC3779] MUST be present in the EE certificate contained in the CMS certificates field. The AS identifiers present in the eContent resources field MUST be a subset of those present in the certificate extension. The EE certificate's AS identifier delegation extension MUST NOT contain "inherit" elements.¶
3. If the ipAddrBlocks field is present within the contents of the resources field, then the IP address delegation extension [RFC3779] MUST be present in the EE certificate contained in the CMS certificates field. The IP addresses present in the eContent resources field MUST be a subset of those present in the certificate extension. The EE certificate's IP address delegation extension MUST NOT contain "inherit" elements.¶

8. Security Considerations

RPs are hereby warned that the data in an RSC is self-asserted. When determining the meaning of any data contained in an RSC, RPs MUST NOT make any assumptions about the signer beyond the fact that it had sufficient control of the issuing CA to create the object. These data have not been verified by the Certificate Authority (CA) that issued the CA certificate to the entity that issued the EE certificate used to validate the RSC.¶

RPKI certificates are not bound to real-world identities; see [RFC9255] for an elaboration. RPs can only associate real-world entities to Internet Number Resources by additionally consulting an exogenous authority. RSCs are a tool to communicate assertions signed with Internet Number Resources and do not communicate any other aspect of the resource holder's business operations, such as the identity of the resource holder itself.¶

RSC objects are not distributed through the RPKI repository system. From this, it follows that third parties who do not have a copy of a given RSC may not be aware of the existence of that RSC. Since RSC objects use EE certificates but all other currently defined types of RPKI object profiles are published in public CA repositories, an observer may infer from discrepancies in the repository that RSC object(s) may exist. For example, if a CA does not use random serial numbers for certificates, an observer could detect gaps between the serial numbers of the published EE certificates. Similarly, if the CA includes a serial number on a Certificate Revocation List (CRL) that does not match any published object, an observer could postulate that an RSC EE certificate was revoked.¶

Conversely, a gap in serial numbers does not imply that an RSC exists. Nor does the presence in a CRL of a serial number unknown to the RP imply an RSC object exists: the implicitly referenced object might not be an RSC, it might have never been published, or it may have been revoked before it was visible to RPs. In general, it is not possible to confidently infer the existence or non-existence of RSCs from the repository state without access to a given RSC.¶

While a one-time-use EE certificate must only be used to generate and sign a single RSC object, CAs technically are not restricted from generating and signing multiple different RSC objects with a single key pair. Any RSC objects sharing the same EE certificate cannot be revoked individually.¶

9. IANA Considerations

Acknowledgements

The authors wish to thank George Michaelson, Geoff Huston, Randy Bush, Stephen Kent, Matt Lepinski, Rob Austein, Ted Unangst, and Marc Espie for prior art. The authors thank Russ Housley for reviewing the ASN.1 notation and providing suggestions. The authors would like to thank Nimrod Levy, Tim Bruijnzeels, Alberto Leiva, Ties de Kock, Peter Peele, Claudio Jeker, Theo Buehler, Donald Eastlake 3rd, Erik Kline, Robert Wilton, Roman Danyliw, Éric Vyncke, Lars Eggert, Paul Wouters, and Murray S. Kucherawy for document review and suggestions.¶

Authors' Addresses