Network Working Group J. Snijders Internet-Draft BSD Intended status: Standards Track A. Azimov Expires: 14 May 2027 Yandex E. Uskov JetLend R. Bush Internet Initiative Japan R. Housley Vigil Security B. Maddison Workonline 10 November 2026 A Profile for Autonomous System Provider Authorization draft-ietf-sidrops-aspa-profile-31 Abstract This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its transit providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. Requirements Language 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 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Snijders, et al. Expires 14 May 2027 [Page 1] Internet-Draft RPKI ASPA Profile November 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 May 2027. Copyright Notice Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ASPA Content Type . . . . . . . . . . . . . . . . . . . . . . 4 3. ASPA eContent . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. customerASID . . . . . . . . . . . . . . . . . . . . . . 5 3.3. providers . . . . . . . . . . . . . . . . . . . . . . . . 6 4. ASPA Object Validation . . . . . . . . . . . . . . . . . . . 6 5. Implementation Considerations . . . . . . . . . . . . . . . . 7 5.1. One ASPA Object per Customer AS . . . . . . . . . . . . . 7 5.2. Merging of ASPA objects for the same CAS . . . . . . . . 7 5.3. Use of One-Time Use End Entity Certificates . . . . . . . 7 5.4. ASPA Object Filenames . . . . . . . . . . . . . . . . . . 7 5.5. Upper Bound on the Number of Providers per CAS . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Implementation status . . . . . . . . . . . . . . . . . . . . 11 8.1. Deployment Status . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Example ASPA eContent Payload . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Snijders, et al. Expires 14 May 2027 [Page 2] Internet-Draft RPKI ASPA Profile November 2026 1. Introduction The primary purpose of the Resource Public Key Infrastructure (RPKI) [RFC6480] is to improve security in the global Internet routing system. As part of this infrastructure, a mechanism is needed for Autonomous Systems (AS) operators, in their capacity as customers, to designate and authorize other ASes as their provider(s). A Provider AS (PAS) is a network providing connectivity between networks - it provides transit services to customers. That is: a. The provider may propagate Border Gateway Protocol (BGP) [RFC4271] routes received from any direction to their customers. For example, routes that the provider learned from its own providers, lateral peers, and other customers. The provider may also announce a default route to their customers. b. The provider may propagate BGP routes received from a customer in any direction. For example, to the provider's providers, lateral peers, and other customers. This document specifies a digitally signed Autonomous System Provider Authorization (ASPA) object. An ASPA object is a cryptographically verifiable attestation signed by the holder of an Autonomous System identifier, hereafter called the "Customer AS", or CAS. An ASPA object contains a list of one or more Provider ASes each of which is authorized to be a provider network for the Customer AS. This specification provides the authorization mechanism mentioned above and can be used to facilitate detection and mitigation of route leaks (see [RFC7908]). The procedures for verifying AS_PATHs in BGP UPDATE messages using ASPAs are described in [I-D.ietf-sidrops-aspa-verification]. When a Customer AS makes use of multiple providers, all Provider ASes are to be listed in the ASPA object, including any non-transparent Internet Exchange Point (IXP) Route Server (RS) ASes. Note that the common case for RS ASes at IXPs is to operate transparently (see Section 2.2.2.1 of [RFC7947]), and transparent IXP Route Servers do not need to be listed as PAS in ASPAs. When the Customer AS does not use any providers for transit, a PAS value of 0 is used. This CMS-protected [RFC5652] content-type definition conforms to the [RFC6488] template for RPKI signed objects. In accordance with Section 4 of [RFC6488], this document defines: Snijders, et al. Expires 14 May 2027 [Page 3] Internet-Draft RPKI ASPA Profile November 2026 1. The object identifier (OID) that identifies the ASPA signed object. This OID appears in the eContentType field of the encapContentInfo object as well as the content-type signed attribute within the signerInfo structure. 2. The ASN.1 syntax for the ASPA content, which is the payload signed by the CAS. The ASPA content is encoded using the ASN.1 [X.680] Distinguished Encoding Rules (DER) [X.690]. 3. The steps required to validate an ASPA beyond the validation steps specified in [RFC6488]. This document also provides implementation guidance in Section 5. 2. ASPA Content Type The content-type for an ASPA is defined as id-ct-ASPA, which has the numerical value of 1.2.840.113549.1.9.16.1.49. This OID MUST appear both within the eContentType in the encapContentInfo structure as well as the content-type signed attribute within the signerInfo structure (see [RFC6488]). 3. ASPA eContent The content of an ASPA identifies the Customer AS (CAS) as well as the set of Provider ASes (SPAS) that are authorized by the CAS to be its providers. The eContent of an ASPA is an instance of ASProviderAttestation, formally defined by the following ASN.1 [X.680] module: Snijders, et al. Expires 14 May 2027 [Page 4] Internet-Draft RPKI ASPA Profile November 2026 RPKI-ASPA-2026 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2026(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS CONTENT-TYPE FROM CryptographicMessageSyntax-2010 -- From RFC 6268 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; id-ct-ASPA OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) aspa(49) } ct-ASPA CONTENT-TYPE ::= { TYPE ASProviderAttestation IDENTIFIED BY id-ct-ASPA } ASProviderAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, customerASID CAS, providers ProviderASSet } CAS ::= INTEGER (1..4294967295) ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF PAS PAS ::= INTEGER (0..4294967295) END This content appears as the eContent within the encapContentInfo as specified in [RFC6488]. 3.1. version The version number of the ASProviderAttestation that complies with this specification MUST be 1 and MUST be explicitly encoded. 3.2. customerASID The customerASID field contains a positive integer that represents the AS number of the Customer AS that is the authorizing entity. Snijders, et al. Expires 14 May 2027 [Page 5] Internet-Draft RPKI ASPA Profile November 2026 3.3. providers The providers field contains the listing of ASes that are authorized as providers. Each element contained in the providers field is an instance of PAS. Each PAS element contains the AS number of an AS that has been authorized by the Customer AS as its provider or non-transparent RS. In addition to the constraints described by the formal ASN.1 definition, the contents of the providers field MUST satisfy the following constraints: * The customerASID value MUST NOT appear in any PAS in the providers field. * The elements of providers MUST be ordered in ascending numerical order. * Each value of PAS MUST be unique (with respect to the other elements of providers). * A PAS value of 0 can only be encoded in the providers field as a single item list, i.e., an element for AS 0 MUST NOT appear alongside any other elements. 4. ASPA Object Validation Before a Relying Party can use an ASPA to validate a routing announcement, a Relying Party MUST first validate the ASPA object itself. To validate an ASPA, a Relying Party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ASPA-specific validation steps: * The Autonomous System Identifier Delegation Extension (Section 3 of [RFC3779]) MUST be present in the end-entity (EE) certificate (contained within the ASPA), and the Customer AS in the ASPA eContent MUST match the ASId specified by the EE certificate's Autonomous System Identifier Delegation Extension. * The Autonomous System Identifier Delegation Extension MUST contain exactly one "id" element (Section 3.2.3.6 of [RFC3779]) and MUST NOT contain any "inherit" elements (Section 3.2.3.3 of [RFC3779]) or "range" elements (Section 3.2.3.7 of [RFC3779]). * The IP Address Delegation Extension (Section 2 of [RFC3779]) MUST be absent. Snijders, et al. Expires 14 May 2027 [Page 6] Internet-Draft RPKI ASPA Profile November 2026 * The ASPA content fully conforms with all requirements specified in Section 3. 5. Implementation Considerations 5.1. One ASPA Object per Customer AS For any given Customer AS, only a single ASPA object SHOULD be maintained which contains all providers (including any non- transparent RS ASes). The practice of maintaining a single object per Customer AS avoids race conditions during ASPA updates that might impact BGP route propagation. For the same reason, when an ASPA record is being migrated between different Certification Authority registries, the authorization contents of its instances at those registries SHOULD be identical (remain unchanged) for the duration of the migration. See Section 4 of [I-D.ietf-sidrops-aspa-verification] for additional ASPA registration recommendations. 5.2. Merging of ASPA objects for the same CAS Multiple ASPA objects for the same CAS can be merged by combining all SPAS values into a union set of Provider ASes (U-SPAS). If the U-SPAS contains two or more values, and one of those values is AS 0, then AS 0 must be removed from the U-SPAS. In other words, the U-SPAS for a given CAS contains AS 0 if and only if all ASPA objects for that CAS have a SPAS containing only AS 0. See Section 5.1 on avoiding multiple ASPAs for the same CAS. 5.3. Use of One-Time Use End Entity Certificates Certification Authorities are RECOMMENDED to generate a new key pair for each new ASPA and only sign one ASPA with each EE certificate. This type of EE certificate is termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]). The newly generated keypair can be used as entropy for the filename for the new ASPA, see Section 5.4. 5.4. ASPA Object Filenames For optimal ASPA object propagation, Certification Authorities SHOULD follow the guidelines for naming ASPA objects based on Section 2.2 of [RFC6481], i.e., convert the 160-bit hash of the EE's public key value into a 27-character string using Base 64 Encoding with the URL and Filename Safe Alphabet (see Section 5 of [RFC4648]). See Section 5.7 of [I-D.ietf-sidrops-publication-server-bcp] for more information and considerations. Snijders, et al. Expires 14 May 2027 [Page 7] Internet-Draft RPKI ASPA Profile November 2026 5.5. Upper Bound on the Number of Providers per CAS While the ASN.1 profile specified in Section 3 does not imposes any limit on the number of Provider ASes that can be listed for a given CAS, consideration will need to be given to limitations existing in validators and elsewhere in the RPKI ecosystem. For example, the number of Provider ASes that can be listed in a single RPKI-To-Router protocol ASPA PDU following the Length field constraints in Section 5.1 of [I-D.ietf-sidrops-8210bis] is 16,380 providers. In addition to limitations in the various protocols used within the ecosystem, locally defined restrictions could exist for the maximum file size of signed objects a Relying Party implementation is willing to accept as well as limits to the maximum filesize a publication engine is willing to accept. Limiting the number of providers per CAS also is useful to reduce denial-of-service attack vectors aimed at exhausting RPs and BGP routers. For the above reasons, Relying Parties SHOULD support limiting the number of Provider ASes in the U-SPAS for a given CAS. At the time of writing, operational considerations suggest an upper bound value between 4,000 and 10,000 Provider ASes per CAS as default threshold. If this threshold is exceeded for a given CAS, Relying Party implementations MUST treat _all_ ASPA objects related to that CAS as invalid, i.e., not emit a partial list of Provider ASes for that CAS. Additionally, an error SHOULD be logged in the local system, indicating the CAS for which the threshold was exceeded. The recommended threshold range was determined following careful observations on the state at the time of writing and projected state of the global Internet routing system. Specifically, the range is selected to provide ample room for growth, while also reducing the potential for DoS. Implementers and operators are RECOMMENDED to periodically review whether imposed upper bounds are aligned with the growth curve of the global Internet routing system. 6. Security Considerations The purpose of an ASPA is to convey authorization for a Provider AS to provide transit for the Customer AS in the ASPA. Thus, the integrity of an ASPA MUST be established. This ASPA specification makes use of the RPKI signed object format; thus, all security considerations discussed in [RFC6488] also apply to ASPAs. Additionally, the signed object profile uses the CMS signed message format for integrity; thus, ASPAs inherit all security considerations associated with that data structure. The security considerations of [RFC6481] also apply to ASPAs. Snijders, et al. Expires 14 May 2027 [Page 8] Internet-Draft RPKI ASPA Profile November 2026 The right of the ASPA signer to authorize a Provider AS to provide transit to the Customer AS is established through the use of the address space and AS number PKI as described in [RFC6480]. Specifically, a Relying Party MUST verify the signature on the ASPA using an X.509 certificate issued under this PKI and check that the Customer AS in the ASPA is contained in the certificate's Autonomous System Identifier Delegation extension. There is no assumption of confidentiality for the data in an ASPA. There is no explicit authentication associated with an ASPA, since the PKI used for ASPA validation provides authorization but not authentication. Although the ASPA is a signed, application-layer object, there is no intent to convey non-repudiation via an ASPA. Large ASPA objects might cause strain within the ecosystem, therefore relying parties are advised to limit the number of providers per CAS in order to lessen the impact of exhaustion (see Section 5.5). 7. IANA Considerations 7.1. SMI Security for S/MIME Module Identifier registry IANA is requested to allocate for id-mod-rpki-aspa-2026 in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry under the "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry group as follows: +---------+-----------------------+---------------+ | Decimal | Description | Specification | +---------+-----------------------+---------------+ | TBD | id-mod-rpki-aspa-2026 | [RFC-to-be] | +---------+-----------------------+---------------+ Table 1 7.2. SMI Security for S/MIME CMS Content Type registry IANA is requested to make permanent in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry under the "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry group as follows: Snijders, et al. Expires 14 May 2027 [Page 9] Internet-Draft RPKI ASPA Profile November 2026 +---------+-------------+---------------+ | Decimal | Description | Specification | +---------+-------------+---------------+ | 49 | id-ct-ASPA | [RFC-to-be] | +---------+-------------+---------------+ Table 2 7.3. RPKI Signed Object registry IANA is requested to make permanent in the "RPKI Signed Object" registry under the "Resource Public Key Infrastructure (RPKI)" registry group as follows: +-----------------+----------------------------+---------------+ | Name | OID | Specification | +-----------------+----------------------------+---------------+ | Autonomous | 1.2.840.113549.1.9.16.1.49 | [RFC-to-be] | | System Provider | | | | Authorization | | | +-----------------+----------------------------+---------------+ Table 3 7.4. RPKI Repository Name Scheme registry IANA is requested to make permanent in the "RPKI Repository Name Scheme" registry under the "Resource Public Key Infrastructure (RPKI)" registry group as follows: +--------------------+------------------------+-------------+ | Filename Extension | RPKI Object | Reference | +--------------------+------------------------+-------------+ | .asa | Autonomous System | [RFC-to-be] | | | Provider Authorization | | +--------------------+------------------------+-------------+ Table 4 7.5. Media Types registry The IANA is requested to register the media type application/rpki- aspa in the "Media Type" registry as follows: Snijders, et al. Expires 14 May 2027 [Page 10] Internet-Draft RPKI ASPA Profile November 2026 Type name: application Subtype name: rpki-aspa Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: Carries an RPKI ASPA [RFC-to-be]. This media type contains no active content. See Section 4 of [RFC-to-be] for further information. Interoperability considerations: None Published specification: [RFC-to-be] Applications that use this media type: Tools used by RPKI operators. Additional information: Content: This media type is a signed object, as defined in [RFC6488], which contains a payload of a list of AS identifiers as defined in [RFC-to-be]. Magic number(s): None File extension(s): .asa Macintosh file type code(s): Person & email address to contact for further information: Job Snijders Intended usage: COMMON Restrictions on usage: None Change controller: IETF 8. Implementation status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. Snijders, et al. Expires 14 May 2027 [Page 11] Internet-Draft RPKI ASPA Profile November 2026 According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". * A validator implementation [rpki-client] written in C was provided by Job Snijders. * A validator implementation [routinator] written in Rust was provided by Martin Hoffman from NLnet Labs. * A validator implementation [rpki-prover] written in Haskell was provided by Mikhail Puzanov. * A signer implementation [rpki-aspa-demo] written in Perl was provided by Tom Harrison from APNIC. * A signer implementation [rpki-commons] in Java was reported on by Ties de Kock from RIPE NCC. * A signer implementation [krill] in Rust was reported on by Tim Bruijnzeels. 8.1. Deployment Status As of November 2026, roughly 4,000 ASPA objects have been published in the global RPKI. See https://console.rpki-client.org/aspa.html for an up-to-date overview. 9. Acknowledgments The authors would like to thank Keyur Patel for helping kick-start the ASPA profile project, Ties de Kock & Tim Bruijnzeels for suggesting that the ProviderASSet be in a canonical form, and Claudio Jeker, Martin Hoffman, Lancheng Qin, Jeff Haas, Rich Salz, Srihari Sangli, Gavin Brown, Peter Yee, Yangyang Wang, Jia Zhang, Tom Harrison, Luigi Iannone, Loganaden Velvindron, and Mohamed Boucadair, for review and several suggestions for improvements. Contributors The following people made significant contributions to this document: Snijders, et al. Expires 14 May 2027 [Page 12] Internet-Draft RPKI ASPA Profile November 2026 Kotikalapudi Sriram USA National Institute of Standards and Technology Email: ksriram@nist.gov References Normative References [I-D.ietf-sidrops-aspa-verification] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa- verification-29, 16 October 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, . Snijders, et al. Expires 14 May 2027 [Page 13] Internet-Draft RPKI ASPA Profile November 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [X.680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2021. [X.690] ITU-T, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2021. Informative References [I-D.ietf-sidrops-8210bis] Bush, R., Austein, R., and T. Harrison, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Work in Progress, Internet-Draft, draft-ietf- sidrops-8210bis-28, 2 November 2026, . [I-D.ietf-sidrops-publication-server-bcp] Bruijnzeels, T., de Kock, T., Hill, F., Harrison, T., and J. Snijders, "Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services", Work in Progress, Internet-Draft, draft-ietf-sidrops-publication- server-bcp-12, 2 November 2026, . [krill] Bruijnzeels, T., "krill", 2023, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . Snijders, et al. Expires 14 May 2027 [Page 14] Internet-Draft RPKI ASPA Profile November 2026 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, . [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, . [routinator] Hoffman, M., "routinator", 2023, . [rpki-aspa-demo] Harrison, T., "rpki-aspa-demo", 2023, . [rpki-client] Jeker, C., Snijders, J., Dzonsons, K., and T. Buehler, "OpenBSD rpki-client", 2023, . [rpki-commons] de Kock, T., "rpki-commons", 2023, . [rpki-prover] Puzanov, M., "rpki-prover", 2023, . Appendix A. Example ASPA eContent Payload Below an example of a DER encoded ASPA eContent is provided with annotation following the '#' character. Snijders, et al. Expires 14 May 2027 [Page 15] Internet-Draft RPKI ASPA Profile November 2026 $ echo 301BA0030201010203010000300F020300FBF0020300FBFF020301000F \ | xxd -r -ps | openssl asn1parse -inform der -i 0:d=0 hl=2 l= 27 cons: SEQUENCE 2:d=1 hl=2 l= 3 cons: cont [ 0 ] 4:d=2 hl=2 l= 1 prim: INTEGER :01 # version 7:d=1 hl=2 l= 3 prim: INTEGER :010000 # CAS 65536 12:d=1 hl=2 l= 15 cons: SEQUENCE # ProviderASSet 14:d=2 hl=2 l= 3 prim: INTEGER :FBF0 # PAS 64496 19:d=2 hl=2 l= 3 prim: INTEGER :FBFF # PAS 64511 24:d=2 hl=2 l= 3 prim: INTEGER :01000F # PAS 65551 Below is a complete Base64 [RFC4648] encoded RPKI ASPA Signed Object. MIIGKAYJKoZIhvcNAQcCoIIGGTCCBhUCAQMxDTALBglghkgBZQMEAgEwLgYLKoZI hvcNAQkQATGgHwQdMBugAwIBAQIDAQAAMA8CAwD78AIDAPv/AgMBAA+gggQhMIIE HTCCAwWgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAPMQ0wCwYDVQQDEwRyb290MB4X DTI2MTEwODIxNTYyOVoXDTI3MTEwODIxNTYyOVowDTELMAkGA1UEAxMCRUUwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW16IvIu6jdfGR0zw8axhfMwLa 6s5sbEpZiNkcILry51FJ3o9Ykd7H1Td4TOzqzmTuUKu48Nd5mM7LC81C/DkFm3IN Ows7YNPahMNfpe9RZrXMXssAiBNPfLnJgVwP2wNupQMGLkZI8e1EVO+zuzLO8dmc qSVIlQBiLVKA+VUGU6y70/OJfUTMcXwZ39bhcutNQlL1wFeuAikryxO/kWg+FRdc rEgV6b6vOhdlhX4QllswdzIUJTaKfdk9OAu7BLXsZqIVfVVYTfmJKkZa4GY//xOK XYcSdVc305KlkrUcfxnB7qeCWCodRhzV/gB8CV6xhvTboFHQz507rvrrha1BAgMB AAGjggGEMIIBgDAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0OBBYEFHrQKKVUt65mYFAD M3uFS+2S+o1TMB8GA1UdIwQYMBaAFLO4MN+bsg1l86GHFmfCBjOEGpedMBgGA1Ud IAEB/wQOMAwwCgYIKwYBBQUHDgIwVQYIKwYBBQUHAQEESTBHMEUGCCsGAQUFBzAC hjlyc3luYzovL2xvY2FsaG9zdC9yZXBvL3RhL3M3Z3czNXV5RFdYem9ZY1daOElH TTRRYWw1MC5jZXIwSgYDVR0fBEMwQTA/oD2gO4Y5cnN5bmM6Ly9sb2NhbGhvc3Qv cmVwby9jYS9zN2d3MzV1eURXWHpvWWNXWjhJR000UWFsNTAuY3JsMFUGCCsGAQUF BwELBEkwRzBFBggrBgEFBQcwC4Y5cnN5bmM6Ly9sb2NhbGhvc3QvcmVwby9jYS9l dEFvcFZTM3JtWmdVQU16ZTRWTDdaTDZqVk0uYXNhMBoGCCsGAQUFBwEIAQH/BAsw CaAHMAUCAwEAADANBgkqhkiG9w0BAQsFAAOCAQEAbiAIskkSbuzKWhyJug5h6L9B NDX1/UAgWJRxeMeown3maY62kCkKmGypOgifO6r2jVmrLYpBvY2OAP8g3GqHC5UI 4DApy5zvALgmMXsxoClog7lxXonXv7gr5GLNs63cfR1olfctdkxPLZFUsBrQ0YED zGkUtAruLyg/9YzGTGT7K2t1ur1p8jNJ6NVrNrdtRa1iOehMg1BsFlvpZlQxz2fk gmhNplEg3hI6NIDGmX4VoCf/GSFILjhEgu7AuuYEXDAg4sMfBg0kT+zRuHZ9j5uu YMAVjD7bt8j3xJtfOFF/fYgAGIekE8Fdht2Ak7lrQlrsgAzMKfwoNXTzCXCf5TGC AaowggGmAgEDgBR60CilVLeuZmBQAzN7hUvtkvqNUzALBglghkgBZQMEAgGgazAa BgkqhkiG9w0BCQMxDQYLKoZIhvcNAQkQATEwHAYJKoZIhvcNAQkFMQ8XDTI2MTEw ODIxNTYyOVowLwYJKoZIhvcNAQkEMSIEIMGsqdjbYNnedoOQqrXVRnpsKAIyiy0Y l+QLD8GY32ytMA0GCSqGSIb3DQEBAQUABIIBAIb9Zhtm9sXW0gJiVbsjyxSkw+jz ET8yehhvHE9vfyeXUQCA8WkemXwJESu6eU9dXR7ee/GRCRyzQYwTlWlI5Y8YCpzz 4FmYDwMWES2OaMfp3C8C2ZMjub6eDi4pBmgRm0+Nz49crkR0sR8l+5B3OWRV1psq l+vB+NFCpuDK/m7ZKWV62xICepC9YTtWeQw5MDpoSJVFtB/zGfE3GJC75QJdrWlN G05Xiz7FdGjJ2uuhzf4VNx8Mx7TSRQXgSSqhiL0QRdWK8Z42Fvnv95J6/OJu3Wq3 ODQs45DOzZ5UqKhzPPZ5iAMZ3kQddEZ4OX8khoEp6wGX/fJK6C0AUvaht+Q= Snijders, et al. Expires 14 May 2027 [Page 16] Internet-Draft RPKI ASPA Profile November 2026 The above should decode as following: Object SHA256 hash: CnrHR+m70BlSUc8tDBeqWMcHRbCycmPC8DzjHPnJn8E= EE Subject keyid: 7AD028A554B7AE66605003337B854BED92FA8D53 EE Certificate issuer: /CN=root EE Certificate serial: 02 EE Authority keyid: B3B830DF9BB20D65F3A1871667C20633841A979D EE Authority info access: rsync://localhost/repo/ta/s7gw35uyDWXzoYcWZ8IGM4Qal50.cer EE Subject info access: rsync://localhost/repo/ca/etAopVS3rmZgUAMze4VL7ZL6jVM.asa CMS Signing time: Sun 08 Nov 2026 21:56:29 +0000 EE notBefore: Sun 08 Nov 2026 21:56:29 +0000 EE notAfter: Mon 08 Nov 2027 21:56:29 +0000 ASPA eContent: customerASID: 65536 providers: 64496, 64511, 65551 Authors' Addresses Job Snijders BSD Software Development Amsterdam Netherlands Email: job@bsd.nl URI: https://www.bsd.nl Alexander Azimov Yandex Email: a.e.azimov@gmail.com Eugene Uskov JetLend Email: eu@jetlend.ru Randy Bush Internet Initiative Japan Email: randy@psg.com Snijders, et al. Expires 14 May 2027 [Page 17] Internet-Draft RPKI ASPA Profile November 2026 Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States of America Email: housley@vigilsec.com Ben Maddison Workonline Cape Town South Africa Email: benm@workonline.africa Snijders, et al. Expires 14 May 2027 [Page 18]