Early Review of draft-ietf-sidrops-aspa-profile-27
review-ietf-sidrops-aspa-profile-27-bgpdir-early-sangli-2026-07-14-01

     1  Network Working Group                                        J. Snijders
     2  Internet-Draft                                                       BSD
     3  Intended status: Standards Track                               A. Azimov
     4  Expires: 21 December 2026                                         Yandex
     5                                                                  E. Uskov
     6                                                                   JetLend
     7                                                                   R. Bush
     8                                                 Internet Initiative Japan
     9                                                                R. Housley
    10                                                            Vigil Security
    11                                                               B. Maddison
    12                                                                Workonline
    13                                                              19 June 2026
    14
    15
    16           A Profile for Autonomous System Provider Authorization
    17                     draft-ietf-sidrops-aspa-profile-27
    18
    19  Abstract
    20
    21     This document defines a Cryptographic Message Syntax (CMS) protected
    22     content type for Autonomous System Provider Authorization (ASPA)
    23     objects for use with the Resource Public Key Infrastructure (RPKI).
    24     An ASPA is a digitally signed object through which the issuer (the
    25     holder of an Autonomous System identifier), can authorize one or more
    26     other Autonomous Systems (ASes) as its transit providers.  When
    27     validated, an ASPA's eContent can be used for detection and
    28     mitigation of route leaks.
    29
    30  Requirements Language
    31
    32     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    33     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    34     "OPTIONAL" in this document are to be interpreted as described in BCP
    35     14 [RFC2119] [RFC8174] when, and only when, they appear in all
    36     capitals, as shown here.
    37
    38  Status of This Memo
    39
    40     This Internet-Draft is submitted in full conformance with the
    41     provisions of BCP 78 and BCP 79.
    42
    43     Internet-Drafts are working documents of the Internet Engineering
    44     Task Force (IETF).  Note that other groups may also distribute
    45     working documents as Internet-Drafts.  The list of current Internet-
    46     Drafts is at https://datatracker.ietf.org/drafts/current/.
    47
    48
    49
    50
    51
    52  Snijders, et al.        Expires 21 December 2026                [Page 1]
    53
    54  Internet-Draft              RPKI ASPA Profile                  June 2026
    55
    56
    57     Internet-Drafts are draft documents valid for a maximum of six months
    58     and may be updated, replaced, or obsoleted by other documents at any
    59     time.  It is inappropriate to use Internet-Drafts as reference
    60     material or to cite them other than as "work in progress."
    61
    62     This Internet-Draft will expire on 21 December 2026.
    63
    64  Copyright Notice
    65
    66     Copyright (c) 2026 IETF Trust and the persons identified as the
    67     document authors.  All rights reserved.
    68
    69     This document is subject to BCP 78 and the IETF Trust's Legal
    70     Provisions Relating to IETF Documents (https://trustee.ietf.org/
    71     license-info) in effect on the date of publication of this document.
    72     Please review these documents carefully, as they describe your rights
    73     and restrictions with respect to this document.  Code Components
    74     extracted from this document must include Revised BSD License text as
    75     described in Section 4.e of the Trust Legal Provisions and are
    76     provided without warranty as described in the Revised BSD License.
    77
    78  Table of Contents
    79
    80     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
    81     2.  ASPA Content Type . . . . . . . . . . . . . . . . . . . . . .   4
    82     3.  ASPA eContent . . . . . . . . . . . . . . . . . . . . . . . .   4
    83       3.1.  version . . . . . . . . . . . . . . . . . . . . . . . . .   5
    84       3.2.  customerASID  . . . . . . . . . . . . . . . . . . . . . .   5
    85       3.3.  providers . . . . . . . . . . . . . . . . . . . . . . . .   6
    86     4.  ASPA Validation . . . . . . . . . . . . . . . . . . . . . . .   6
    87     5.  Implementation Considerations . . . . . . . . . . . . . . . .   7
    88       5.1.  One ASPA Object per Customer AS . . . . . . . . . . . . .   7
    89       5.2.  Use of One-Time Use End Entity Certificates . . . . . . .   7
    90       5.3.  ASPA Object Filenames . . . . . . . . . . . . . . . . . .   7
    91       5.4.  Upper Bound on the Number of Providers  . . . . . . . . .   7
    92     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
    93     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
    94     8.  Implementation status . . . . . . . . . . . . . . . . . . . .  10
    95       8.1.  Deployment Status . . . . . . . . . . . . . . . . . . . .  11
    96     9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
    97       9.1.  Contributors  . . . . . . . . . . . . . . . . . . . . . .  11
    98     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
    99       10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
   100       10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   101     Appendix A.  Example ASPA eContent Payload  . . . . . . . . . . .  14
   102     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
   103
   104
   105
   106
   107
   108  Snijders, et al.        Expires 21 December 2026                [Page 2]
   109
   110  Internet-Draft              RPKI ASPA Profile                  June 2026
   111
   112
   113  1.  Introduction
   114
   115     The primary purpose of the Resource Public Key Infrastructure (RPKI)
   116     [RFC6480] is to improve security in the global Internet routing
   117     system.  As part of this infrastructure, a mechanism is needed for
   118     Autonomous Systems (AS) operators, in their capacity as customers, to
   119     designate and authorize other ASes as their Provider(s).  A Provider
   120     AS (PAS) is a network providing connectivity between networks - it
   121     provides transit services to the customer.  That is:
   122
   123     a.  The provider may propagate Border Gateway Protocol (BGP) routes
   124         received from any direction.  For example, routes the provider

Minor comment: It would be clearer if the above statement be clarified on where
these routes are advertised to. Iow, (a) refers to routes advertised *to*
customers. (b) below refers to routes learnt *from* customers.  If this is the
intention of the two points, it would be clearer IMHO.

   125         learned from its own providers, lateral peers, and other
   126         customers.  The provider may also announce a default route to
   127         their customers.
   128
   129     b.  The provider may propagate BGP routes received from the customer
   130         in any direction.  For example, to the provider's providers,
   131         lateral peers, and other customers.
   132
   133     This document specifies a digitally signed Autonomous System Provider
   134     Authorization (ASPA) object profile.  An ASPA object is a
   135     cryptographically verifiable attestation signed by the holder of an
   136     Autonomous System identifier, hereafter called the "Customer AS", or
   137     CAS.  An ASPA object contains a list of one or more Provider ASes
   138     each of which is authorized to be a Provider network for the CAS.
   139
   140     This profile provides the authorization mechanism mentioned above and
   141     can be used to facilitate detection and mitigation of route leaks.
   142     The procedures for verifying AS_PATHs in BGP UPDATE messages using
   143     ASPAs are described in [I-D.ietf-sidrops-aspa-verification].
   144
   145     When the Customer AS makes use of multiple providers, all Provider
   146     ASes are to be listed in the ASPA object, including any non-
   147     transparent Internet Exchange Point (IXP) Route Server (RS) ASes.
   148     Note that the common case for RS ASes at IXPs is to operate
   149     transparently (see Section 2.2.2.1 [RFC7947]), and transparent IXP
   150     Route Servers do not need to be listed as PAS in ASPAs.
   151
   152     This CMS [RFC5652] protected content type definition conforms to the
   153     [RFC6488] template for RPKI signed objects.  In accordance with
   154     Section 4 of [RFC6488], this document defines:
   155
   156     1.  The object identifier (OID) that identifies the ASPA signed
   157         object.  This OID appears in the eContentType field of the
   158         encapContentInfo object as well as the content-type signed
   159         attribute within the signerInfo structure.
   160
   161
   162
   163
   164  Snijders, et al.        Expires 21 December 2026                [Page 3]
   165
   166  Internet-Draft              RPKI ASPA Profile                  June 2026
   167
   168
   169     2.  The ASN.1 syntax for the ASPA content, which is the payload
   170         signed by the CAS.  The ASPA content is encoded using the ASN.1
   171         [X.680] Distinguished Encoding Rules (DER) [X.690].
   172
   173     3.  The steps required to validate an ASPA beyond the validation
   174         steps specified in [RFC6488].
   175
   176     This document also provides implementation guidance in Section 5.
   177
   178  2.  ASPA Content Type
   179
   180     The content-type for an ASPA is defined as id-ct-ASPA, which has the
   181     numerical value of 1.2.840.113549.1.9.16.1.49.  This OID MUST appear
   182     both within the eContentType in the encapContentInfo structure as
   183     well as the content-type signed attribute within the signerInfo
   184     structure (see [RFC6488]).
   185
   186  3.  ASPA eContent
   187
   188     The content of an ASPA identifies the Customer AS (CAS) as well as
   189     the Set of Provider ASes (SPAS) that are authorized by the CAS to be
   190     its Providers.
   191
   192     The eContent of an ASPA is an instance of ASProviderAttestation,
   193     formally defined by the following ASN.1 [X.680] module:
   194
   195
   196
   197
   198
   199
   200
   201
   202
   203
   204
   205
   206
   207
   208
   209
   210
   211
   212
   213
   214
   215
   216
   217
   218
   219
   220  Snijders, et al.        Expires 21 December 2026                [Page 4]
   221
   222  Internet-Draft              RPKI ASPA Profile                  June 2026
   223
   224
   225     RPKI-ASPA-2023
   226       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
   227          pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2023(TBD) }
   228
   229     DEFINITIONS EXPLICIT TAGS ::=
   230     BEGIN
   231
   232     IMPORTS
   233       CONTENT-TYPE
   234       FROM CryptographicMessageSyntax-2010 -- From RFC 6268
   235         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
   236            pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
   237
   238     id-ct-ASPA OBJECT IDENTIFIER ::=
   239       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
   240         pkcs-9(9) id-smime(16) id-ct(1) aspa(49) }
   241
   242     ct-ASPA CONTENT-TYPE ::=
   243       { TYPE ASProviderAttestation IDENTIFIED BY id-ct-ASPA }
   244
   245     ASProviderAttestation ::= SEQUENCE {
   246       version       [0] INTEGER DEFAULT 0,
   247       customerASID      CAS,
   248       providers         ProviderASSet }
   249
   250     CAS ::= INTEGER (1..4294967295)
   251
   252     ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF PAS
   253
   254     PAS ::= INTEGER (0..4294967295)
   255
   256     END
   257
   258     This content appears as the eContent within the encapContentInfo as
   259     specified in [RFC6488].
   260
   261  3.1.  version
   262
   263     The version number of the ASProviderAttestation that complies with
   264     this specification MUST be 1 and MUST be explicitly encoded.
   265
   266  3.2.  customerASID
   267
   268     The customerASID field contains a positive integer that represents

Minor. Is there a reason to call out for "positive" ? The same is not mentioned
in the PAS (below section). IOW, its better to be consistent. How about
referring to rfc3779 about AS number encoding. Its a 32-bit number.

   269     the AS number of the Customer Autonomous System that is the
   270     authorizing entity.
   271
   272
   273
   274
   275
   276  Snijders, et al.        Expires 21 December 2026                [Page 5]
   277
   278  Internet-Draft              RPKI ASPA Profile                  June 2026
   279
   280
   281  3.3.  providers
   282
   283     The providers field contains the listing of ASes that are authorized
   284     as providers.
   285
   286     Each element contained in the providers field is an instance of PAS.
   287     Each PAS element contains the AS number of an AS that has been
   288     authorized by the customer AS as its provider or non-transparent RS.
   289
   290     In addition to the constraints described by the formal ASN.1
   291     definition, the contents of the providers field MUST satisfy the
   292     following constraints:
   293
   294     *  The CustomerASID value MUST NOT appear in any PAS in the providers
   295        field.
   296
   297     *  The elements of providers MUST be ordered in ascending numerical
   298        order.
   299
   300     *  Each value of PAS MUST be unique (with respect to the other
   301        elements of providers).
   302
   303     *  An PAS value of 0 can only be encoded in the providers field as a

Nit. s/An/A/g

   304        single item list, i.e., an element for AS 0 MUST NOT appear
   305        alongside any other elements.
   306
   307  4.  ASPA Validation
   308
   309     Before a relying party can use an ASPA to validate a routing
   310     announcement, the relying party MUST first validate the ASPA object
   311     itself.  To validate an ASPA, the relying party MUST perform all the
   312     validation checks specified in [RFC6488] as well as the following
   313     additional ASPA-specific validation steps:
   314
   315     *  The Autonomous System Identifier Delegation Extension [RFC3779]
   316        MUST be present in the end-entity (EE) certificate (contained
   317        within the ASPA), and the Customer ASID in the ASPA eContent MUST
   318        match the ASId specified by the EE certificate's Autonomous System
   319        Identifier Delegation Extension.
   320
   321     *  The Autonomous System Identifier Delegation Extension MUST contain
   322        exactly one "id" element (Section 3.2.3.6 of [RFC3779]) and MUST
   323        NOT contain any "inherit" elements (Section 3.2.3.3 of [RFC3779])
   324        or "range" elements (Section 3.2.3.7 of [RFC3779]).
   325
   326     *  The IP Address Delegation Extension [RFC3779] MUST be absent.
   327

Major. The validation for provider (section 3.3) is missing. How to handle if
the AS numbers are not sorted for example, or if the Customer ASID is present
in PAS. If the argument is, its the client to deal with it, then I recommend a
pointer to that document to be mentioned here.

   328
   329
   330
   331
   332  Snijders, et al.        Expires 21 December 2026                [Page 6]
   333
   334  Internet-Draft              RPKI ASPA Profile                  June 2026
   335
   336
   337  5.  Implementation Considerations
   338
   339  5.1.  One ASPA Object per Customer AS
   340
   341     For any given Customer AS, only a single ASPA object SHOULD be
   342     maintained which contains all providers (including any non-
   343     transparent RS ASes).  The practice of maintaining a single object
   344     per Customer AS avoids race conditions during ASPA updates that might
   345     impact BGP route propagation.  When an ASPA record is being migrated
   346     between different CA registries, the authorization contents of its
   347     instances at those registries SHOULD be identical (remain unchanged)
   348     for the duration of the migration.  The CA software that maintains
   349     ASPA records SHOULD support enforcement of this recommendation.  See
   350     Section 4 of [I-D.ietf-sidrops-aspa-verification] for all ASPA
   351     registration recommendations.
   352
   353  5.2.  Use of One-Time Use End Entity Certificates
   354
   355     CAs are RECOMMENDED to generate a new key pair for each new ASPA and

Minor. Pls add a reference where CA is defined.

   356     only sign one ASPA with each EE certificate.  This type of EE
   357     certificate is termed a "one-time-use" EE certificate (see Section 3
   358     of [RFC6487]).
   359
   360  5.3.  ASPA Object Filenames
   361
   362     CAs are RECOMMENDED to follow the guidelines for naming ASPA objects
   363     based on Section 2.2 of [RFC6481], i.e., convert the 160-bit hash of
   364     the EE's public key value into a 27-character string using Base 64
   365     Encoding with the URL and Filename Safe Alphabet (see Section 5 of
   366     [RFC4648]).  See Section 7.7 of
   367     [I-D.ietf-sidrops-publication-server-bcp] for more information and
   368     considerations.
   369
   370  5.4.  Upper Bound on the Number of Providers
   371
   372     While the ASN.1 profile specified in Section 3 imposes no limit on
   373     the number of Provider ASes that can be listed for a given CAS,
   374     consideration will need to be given to limitations existing in
   375     validators and elsewhere in the RPKI ecosystem.  For example, the
   376     number of Provider ASes that can be listed in a single RPKI-To-Router
   377     protocol ASPA PDU following the Length field constraints in
   378     Section 5.1 of [I-D.ietf-sidrops-8210bis] is 16,380 providers.  In
   379     addition to protocol limitations in the ecosystem, locally defined
   380     restrictions could exist for the maximum file size of signed objects
   381     a Relying Party implementation is willing to accept.
   382
   383
   384
   385
   386
   387
   388  Snijders, et al.        Expires 21 December 2026                [Page 7]
   389
   390  Internet-Draft              RPKI ASPA Profile                  June 2026
   391
   392
   393     Relying Party implementations are RECOMMENDED to impose an upper
   394     bound on the number of Provider ASes for a given CAS.  An upper bound
   395     value between 4,000 and 10,000 Provider ASes is suggested.  If this
   396     threshold is exceeded, Relying Party implementations SHOULD treat all
   397     ASPA objects related to the CAS invalid; e.g. not emit a partial list
   398     of Provider ASes.  Additionally, an error SHOULD be logged in the
   399     local system, indicating the CAS for which the threshold was
   400     exceeded.  Implementers and operators SHOULD periodically review
   401     whether imposed upper bounds still are reasonable in context of the
   402     global Internet routing system.
   403

Minor. While we understand the list of ASes can grow to 1000s, yet for a
standard, I would think having a definate number is essential. Since the
proposal talks about error conditions and make ASPA objects as invalid, I
recommend to pick a large number as an upper bound.

   404  6.  Security Considerations
   405
   406     The security considerations of [RFC6481], [RFC6485], and [RFC6488]
   407     also apply to ASPAs.
   408

Major. While the above mentioned RFCs state the generic RPKI security
considerations, I think security conderations on usage of AS numbers is
essential, for example, impact and consequence of having wrong AS number in the
provider list, consequence of corrupted ASPA object having Customer ASID, PAS,
etc.

   409  7.  IANA Considerations
   410
   411  7.1.  SMI Security for S/MIME Module Identifier registry
   412
   413     IANA is requested to allocate for id-mod-rpki-aspa-2023 in the "SMI
   414     Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
   415     registry as follows:
   416
   417              +---------+-----------------------+---------------+
   418              | Decimal | Description           | Specification |
   419              +---------+-----------------------+---------------+
   420              | TBD2    | id-mod-rpki-aspa-2023 | [RFC-to-be]   |
   421              +---------+-----------------------+---------------+
   422
   423                                    Table 1
   424
   425  7.2.  SMI Security for S/MIME CMS Content Type registry
   426
   427     IANA is requested to make permanent in the "SMI Security for S/MIME
   428     CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows:
   429
   430                   +---------+-------------+---------------+
   431                   | Decimal | Description | Specification |
   432                   +---------+-------------+---------------+
   433                   | 49      | id-ct-ASPA  | [RFC-to-be]   |
   434                   +---------+-------------+---------------+
   435
   436                                    Table 2
   437
   438
   439
   440
   441
   442
   443
   444  Snijders, et al.        Expires 21 December 2026                [Page 8]
   445
   446  Internet-Draft              RPKI ASPA Profile                  June 2026
   447
   448
   449  7.3.  RPKI Signed Object registry
   450
   451     IANA is requested to make permanent in the "RPKI Signed Object"
   452     registry as follows:
   453
   454       +-----------------+----------------------------+---------------+
   455       | Name            | OID                        | Specification |
   456       +-----------------+----------------------------+---------------+
   457       | Autonomous      | 1.2.840.113549.1.9.16.1.49 | [RFC-to-be]   |
   458       | System Provider |                            |               |
   459       | Authorization   |                            |               |
   460       +-----------------+----------------------------+---------------+
   461
   462                                   Table 3
   463
   464  7.4.  RPKI Repository Name Scheme registry
   465
   466     IANA is requested to make permanent in the "RPKI Repository Name
   467     Scheme" registry [RFC6481] as follows:
   468
   469         +--------------------+------------------------+-------------+
   470         | Filename Extension | RPKI Object            | Reference   |
   471         +--------------------+------------------------+-------------+
   472         | .asa               | Autonomous System      | [RFC-to-be] |
   473         |                    | Provider Authorization |             |
   474         +--------------------+------------------------+-------------+
   475
   476                                    Table 4
   477
   478  7.5.  Media Type registry
   479
   480     The IANA is requested to register the media type application/rpki-
   481     aspa in the "Media Type" registry as follows:
   482
   483
   484
   485
   486
   487
   488
   489
   490
   491
   492
   493
   494
   495
   496
   497
   498
   499
   500  Snijders, et al.        Expires 21 December 2026                [Page 9]
   501
   502  Internet-Draft              RPKI ASPA Profile                  June 2026
   503
   504
   505        Type name: application
   506        Subtype name: rpki-aspa
   507        Required parameters: N/A
   508        Optional parameters: N/A
   509        Encoding considerations: binary
   510        Security considerations: Carries an RPKI ASPA [RFC-to-be].
   511            This media type contains no active content. See
   512            Section 4 of [RFC-to-be] for further information.
   513        Interoperability considerations: None
   514        Published specification: [RFC-to-be]
   515        Applications that use this media type: RPKI operators
   516        Additional information:
   517          Content: This media type is a signed object, as defined
   518              in [RFC6488], which contains a payload of a list of
   519              AS identifers as defined in [RFC-to-be].
   520          Magic number(s): None
   521          File extension(s): .asa
   522          Macintosh file type code(s):
   523        Person & email address to contact for further information:
   524          Job Snijders <job@bsd.nl>
   525        Intended usage: COMMON
   526        Restrictions on usage: None
   527        Change controller: IETF
   528
   529
   530  8.  Implementation status
   531
   532     This section is to be removed before publishing as an RFC.

Nit. I agree.

   533
   534     This section records the status of known implementations of the
   535     protocol defined by this specification at the time of posting of this
   536     Internet-Draft, and is based on a proposal described in RFC 7942.
   537     The description of implementations in this section is intended to
   538     assist the IETF in its decision processes in progressing drafts to
   539     RFCs.  Please note that the listing of any individual implementation
   540     here does not imply endorsement by the IETF.  Furthermore, no effort
   541     has been spent to verify the information presented here that was
   542     supplied by IETF contributors.  This is not intended as, and must not
   543     be construed to be, a catalog of available implementations or their
   544     features.  Readers are advised to note that other implementations may
   545     exist.
   546
   547     According to RFC 7942, "this will allow reviewers and working groups
   548     to assign due consideration to documents that have the benefit of
   549     running code, which may serve as evidence of valuable experimentation
   550     and feedback that have made the implemented protocols more mature.
   551     It is up to the individual working groups to use this information as
   552     they see fit".
   553
   554
   555
   556  Snijders, et al.        Expires 21 December 2026               [Page 10]
   557
   558  Internet-Draft              RPKI ASPA Profile                  June 2026
   559
   560
   561     *  A validator implementation [rpki-client] written in C was provided
   562        by Job Snijders.
   563
   564     *  A validator implementation [routinator] written in Rust was
   565        provided by Martin Hoffman from NLnet Labs.
   566
   567     *  A validator implementation [rpki-prover] written in Haskell was
   568        provided by Mikhail Puzanov.
   569
   570     *  A signer implementation [rpki-aspa-demo] written in Perl was
   571        provided by Tom Harrison from APNIC.
   572
   573     *  A signer implementation [rpki-commons] in Java was reported on by
   574        Ties de Kock from RIPE NCC.
   575
   576     *  A signer implementation [krill] in Rust was reported on by Tim
   577        Bruijnzeels.
   578
   579  8.1.  Deployment Status
   580
   581     As of June 2026, roughly 2,100 ASPA objects have been published in
   582     the global RPKI.  See https://console.rpki-client.org/aspa.html for
   583     an up-to-date overview.
   584
   585  9.  Acknowledgments
   586
   587     The authors would like to thank Keyur Patel for helping kick-start
   588     the ASPA profile project, Ties de Kock & Tim Bruijnzeels for
   589     suggesting that the ProviderASSet be in a canonical form, and Claudio
   590     Jeker, Martin Hoffman, Lancheng Qin, Jeff Haas, Rich Salz for review
   591     and several suggestions for improvements.
   592
   593  9.1.  Contributors
   594
   595     The following people made significant contributions to this document:
   596
   597             Kotikalapudi Sriram
   598             USA National Institute of Standards and Technology
   599             Email: ksriram@nist.gov
   600
   601
   602  10.  References
   603
   604  10.1.  Normative References
   605
   606     [I-D.ietf-sidrops-8210bis]
   607                Bush, R., Austein, R., and T. Harrison, "The Resource
   608                Public Key Infrastructure (RPKI) to Router Protocol,
   609
   610
   611
   612  Snijders, et al.        Expires 21 December 2026               [Page 11]
   613
   614  Internet-Draft              RPKI ASPA Profile                  June 2026
   615
   616
   617                Version 2", Work in Progress, Internet-Draft, draft-ietf-
   618                sidrops-8210bis-25, 2 March 2026,
   619                <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
   620                8210bis-25>.
   621
   622     [I-D.ietf-sidrops-aspa-verification]
   623                Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
   624                J., and K. Sriram, "BGP AS_PATH Verification Based on
   625                Autonomous System Provider Authorization (ASPA) Objects",
   626                Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
   627                verification-25, 19 April 2026,
   628                <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
   629                aspa-verification-25>.
   630
   631     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   632                Requirement Levels", BCP 14, RFC 2119,
   633                DOI 10.17487/RFC2119, March 1997,
   634                <https://www.rfc-editor.org/info/rfc2119>.
   635
   636     [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
   637                Addresses and AS Identifiers", RFC 3779,
   638                DOI 10.17487/RFC3779, June 2004,
   639                <https://www.rfc-editor.org/info/rfc3779>.
   640
   641     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
   642                RFC 5652, DOI 10.17487/RFC5652, September 2009,
   643                <https://www.rfc-editor.org/info/rfc5652>.
   644
   645     [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
   646                Resource Certificate Repository Structure", RFC 6481,
   647                DOI 10.17487/RFC6481, February 2012,
   648                <https://www.rfc-editor.org/info/rfc6481>.
   649
   650     [RFC6485]  Huston, G., "The Profile for Algorithms and Key Sizes for
   651                Use in the Resource Public Key Infrastructure (RPKI)",
   652                RFC 6485, DOI 10.17487/RFC6485, February 2012,
   653                <https://www.rfc-editor.org/info/rfc6485>.
   654
   655     [RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
   656                Template for the Resource Public Key Infrastructure
   657                (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
   658                <https://www.rfc-editor.org/info/rfc6488>.
   659
   660     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
   661                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
   662                May 2017, <https://www.rfc-editor.org/info/rfc8174>.
   663
   664
   665
   666
   667
   668  Snijders, et al.        Expires 21 December 2026               [Page 12]
   669
   670  Internet-Draft              RPKI ASPA Profile                  June 2026
   671
   672
   673     [X.680]    ITU-T, "Information technology - Abstract Syntax Notation
   674                One (ASN.1): Specification of basic notation",
   675                ITU-T Recommendation X.680, 2021.
   676
   677     [X.690]    ITU-T, "Information Technology - ASN.1 encoding rules:
   678                Specification of Basic Encoding Rules (BER), Canonical
   679                Encoding Rules (CER) and Distinguished Encoding Rules
   680                (DER)", ITU-T Recommendation X.690, 2021.
   681
   682  10.2.  Informative References
   683
   684     [I-D.ietf-sidrops-publication-server-bcp]
   685                Bruijnzeels, T., de Kock, T., Hill, F., Harrison, T., and
   686                J. Snijders, "Best Practices for Operating Resource Public
   687                Key Infrastructure (RPKI) Publication Services", Work in
   688                Progress, Internet-Draft, draft-ietf-sidrops-publication-
   689                server-bcp-09, 29 May 2026,
   690                <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
   691                publication-server-bcp-09>.
   692
   693     [krill]    Bruijnzeels, T., "krill", 2023,
   694                <https://mailarchive.ietf.org/arch/msg/sidrops/
   695                RrHCYTmevxDHgebdLC_adRlKH-o/>.
   696
   697     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
   698                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
   699                <https://www.rfc-editor.org/info/rfc4648>.
   700
   701     [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
   702                Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
   703                February 2012, <https://www.rfc-editor.org/info/rfc6480>.
   704
   705     [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
   706                X.509 PKIX Resource Certificates", RFC 6487,
   707                DOI 10.17487/RFC6487, February 2012,
   708                <https://www.rfc-editor.org/info/rfc6487>.
   709
   710     [RFC7947]  Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
   711                "Internet Exchange BGP Route Server", RFC 7947,
   712                DOI 10.17487/RFC7947, September 2016,
   713                <https://www.rfc-editor.org/info/rfc7947>.
   714
   715     [routinator]
   716                Hoffman, M., "routinator", 2023,
   717                <https://github.com/NLnetLabs/rpki-rs/pull/264>.
   718
   719
   720
   721
   722
   723
   724  Snijders, et al.        Expires 21 December 2026               [Page 13]
   725
   726  Internet-Draft              RPKI ASPA Profile                  June 2026
   727
   728
   729     [rpki-aspa-demo]
   730                Harrison, T., "rpki-aspa-demo", 2023,
   731                <https://github.com/APNIC-net/rpki-aspa-demo>.
   732
   733     [rpki-client]
   734                Jeker, C., Snijders, J., Dzonsons, K., and T. Buehler,
   735                "OpenBSD rpki-client", 2023,
   736                <https://www.rpki-client.org/>.
   737
   738     [rpki-commons]
   739                de Kock, T., "rpki-commons", 2023,
   740                <https://mailarchive.ietf.org/arch/msg/sidrops/
   741                nNAmZMrr7t9NMzm12jRXU03ABN4/>.
   742
   743     [rpki-prover]
   744                Puzanov, M., "rpki-prover", 2023,
   745                <https://github.com/lolepezy/rpki-prover/compare/
   746                master...aspa-profile-16>.
   747
   748  Appendix A.  Example ASPA eContent Payload
   749
   750     Below an example of a DER encoded ASPA eContent is provided with
   751     annotation following the '#' character.
   752
   753   $ echo 301DA003020101020300FE633011020300FC00020301000F020500FA56EA00 \
   754     | xxd -r -ps | openssl asn1parse -inform DER -dump -i
   755     0:d=0  hl=2 l=  29 cons: SEQUENCE
   756     2:d=1  hl=2 l=   3 cons:  cont [ 0 ]
   757     4:d=2  hl=2 l=   1 prim:   INTEGER :01       # version
   758     7:d=1  hl=2 l=   3 prim:  INTEGER  :FE63     # CAS 65123
   759    12:d=1  hl=2 l=  17 cons:  SEQUENCE           # ProviderASSet
   760    14:d=2  hl=2 l=   3 prim:   INTEGER :FC00       # PAS 64512
   761    19:d=2  hl=2 l=   3 prim:   INTEGER :01000F     # PAS 65551
   762    24:d=2  hl=2 l=   5 prim:   INTEGER :FA56EA00   # PAS 4200000000
   763
   764
   765     Below is a complete Base64 [RFC4648] encoded RPKI ASPA Signed Object.
   766
   767
   768
   769
   770
   771
   772
   773
   774
   775
   776
   777
   778
   779
   780  Snijders, et al.        Expires 21 December 2026               [Page 14]
   781
   782  Internet-Draft              RPKI ASPA Profile                  June 2026
   783
   784
   785     MIIGLAYJKoZIhvcNAQcCoIIGHTCCBhkCAQMxDTALBglghkgBZQMEAgEwMAYLKoZI
   786     hvcNAQkQATGgIQQfMB2gAwIBAQIDAP5jMBECAwD8AAIDAQAPAgUA+lbqAKCCBCMw
   787     ggQfMIIDB6ADAgECAgEEMA0GCSqGSIb3DQEBCwUAMA8xDTALBgNVBAMTBHJvb3Qw
   788     HhcNMjUwMTA2MTAyNjQ4WhcNMjYwMTA2MTAyNjQ4WjAPMQ0wCwYDVQQDEwRyb290
   789     MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmgjRVMrjafIK81cxs8GB
   790     ehcjlP97o3CdlhceX8ogtUE19C1v3VZQttdzaBG1ViI2+TJiyueHm2M6nq7tl7A9
   791     HfkPWGdvwjTUeF4ynpxNlqqoG5pGPMLuuk6HdVaKbuEeX3ZAYD2daG8qm3zkmmF3
   792     F7e+xPvr6nCTIQX7nr0WQyX74FmLGwlr6TV+6MGdCnp24A5aCXJo3m1vGlQUKdd/
   793     bMszpbfzaX1rxBKA0GSdWx/QEOxFb1BPObjF+P/GpDXOq3i0DoZiDB+omgdUAWDZ
   794     dmskG0l+2EyQaCS/pVCES50Y5zAagTcFabCLKnPvr3qh9tvjD/KlolYc35gNIfoX
   795     7wIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBQrh8dvXu72
   796     IET1KLgskpso1VcyrDAfBgNVHSMEGDAWgBQ2mtAZLGdOeDIizTKFZreUErGPJjAY
   797     BgNVHSABAf8EDjAMMAoGCCsGAQUFBw4CMF8GCCsGAQUFBwEBBFMwUTBPBggrBgEF
   798     BQcwAoZDcnN5bmM6Ly9sb2NhbGhvc3QvcmVwby8zNjlBRDAxOTJDNjc0RTc4MzIy
   799     MkNEMzI4NTY2Qjc5NDEyQjE4RjI2LmNlcjBXBgNVHR8EUDBOMEygSqBIhkZyc3lu
   800     YzovL2xvY2FsaG9zdC9yZXBvL3RhLzM2OUFEMDE5MkM2NzRFNzgzMjIyQ0QzMjg1
   801     NjZCNzk0MTJCMThGMjYuY3JsMD4GCCsGAQUFBwELBDIwMDAuBggrBgEFBQcwC4Yi
   802     cnN5bmM6Ly9sb2NhbGhvc3QvdGEvYW4tb2JqZWN0LmFzYTAaBggrBgEFBQcBCAEB
   803     /wQLMAmgBzAFAgMA/mMwDQYJKoZIhvcNAQELBQADggEBACqgWrD692DUuN1jrriv
   804     SGqI7JqAtbqOSvnwxNGMlPZ6oTkarf4aDMJNcwqMaOUOzZPQ9VXA48h5R8TgvAub
   805     s/HJ263DLtPiScwkWqLZZs6Ius2zFothzDwWOoe/rHKiecCF0YpJqFhaa6dw6vsO
   806     zK77Ze+Gfa1SeeuI1DTwGDjiNBtXCaRxAPmvpYGxSKQmRYCIo6vKPSZlzCPqzEZa
   807     MVCmxdlaDQjVPUuWLbFV/bbZmS4wM1nbikt5WLZEVHMcAyqWOb7a3KO2GIIw0Ak9
   808     O6JgUoex/8y0s6smSWcRe2y9d6kAhT0COW1KvFoNM5lFKSe1rYqTtMFY33XfCI7e
   809     IgsxggGqMIIBpgIBA4AUK4fHb17u9iBE9Si4LJKbKNVXMqwwCwYJYIZIAWUDBAIB
   810     oGswGgYJKoZIhvcNAQkDMQ0GCyqGSIb3DQEJEAExMBwGCSqGSIb3DQEJBTEPFw0y
   811     NTAxMDYxMDI2NDhaMC8GCSqGSIb3DQEJBDEiBCCLMweRYDN5u5auRQYv6+Dx+b9X
   812     m1t5R3gkH9c3aX40gzANBgkqhkiG9w0BAQEFAASCAQATWDI3fYgku2fJPzFXAbnz
   813     IKabFMRvhp9LAhvl8oPkCp0zQu4SyJsdvoWxkpHKnXGwwdgub/d4GF0weoJgauDr
   814     ugUsB2e40aQwFoTyPcVuS/BirhlW5j0NwYovmuJ9GiBe67/sCRBaPC5sBKRBpOIv
   815     IpMpAe2QhaoeDUDc0KYCM42f1kFD+PD8PnlvXRisL3A3OFhB+0LY1Z3xivRAEdtf
   816     qzobZT0Hq6CIlAjNeocG0gMfJj/lFyElLkJdfGHzCWLnVNX2I+9GbDDdYV13cUTG
   817     yk5CFeQWetsX7D7XRNSdKwrrW6qWK/KxGF38SsuGeTyDQiNcOhwqvSfFc388ge/G
   818
   819
   820     The above should decode as following:
   821
   822
   823
   824
   825
   826
   827
   828
   829
   830
   831
   832
   833
   834
   835
   836  Snijders, et al.        Expires 21 December 2026               [Page 15]
   837
   838  Internet-Draft              RPKI ASPA Profile                  June 2026
   839
   840
   841  Object SHA256 hash:        S6B+jKOCFXPlRn7ws6Kd5tgpsSx609tJZpw60CVaf9Y=
   842  EE Subject keyid:          2B87C76F5EEEF62044F528B82C929B28D55732AC
   843  EE Certificate issuer:     /CN=root
   844  EE Certificate serial:     04
   845  EE Authority keyid:        369AD0192C674E783222CD328566B79412B18F26
   846  EE Authority info access:
   847       rsync://localhost/repo/369AD0192C674E783222CD328566B79412B18F26.cer
   848  EE Subject info access:    rsync://localhost/ta/an-object.asa
   849  CMS Signing time:          Mon 06 Jan 2025 10:26:48 +0000
   850  EE notBefore:              Mon 06 Jan 2025 10:26:48 +0000
   851  EE notAfter:               Tue 06 Jan 2026 10:26:48 +0000
   852
   853  ASPA eContent:
   854    customerASID:            65123
   855    providers:               64512, 65551, 4200000000
   856
   857
   858  Authors' Addresses
   859
   860     Job Snijders
   861     BSD Software Development
   862     Amsterdam
   863     Netherlands
   864     Email: job@bsd.nl
   865     URI:   https://www.bsd.nl
   866
   867
   868     Alexander Azimov
   869     Yandex
   870     Email: a.e.azimov@gmail.com
   871
   872
   873     Eugene Uskov
   874     JetLend
   875     Email: eu@jetlend.ru
   876
   877
   878     Randy Bush
   879     Internet Initiative Japan
   880     Email: randy@psg.com
   881
   882
   883     Russ Housley
   884     Vigil Security, LLC
   885     918 Spring Knoll Drive
   886     Herndon, VA 20170
   887     United States of America
   888     Email: housley@vigilsec.com
   889
   890
   891
   892  Snijders, et al.        Expires 21 December 2026               [Page 16]
   893
   894  Internet-Draft              RPKI ASPA Profile                  June 2026
   895
   896
   897     Ben Maddison
   898     Workonline
   899     Cape Town
   900     South Africa
   901     Email: benm@workonline.africa
   902
   903
   904
   905
   906
   907
   908
   909
   910
   911
   912
   913
   914
   915
   916
   917
   918
   919
   920
   921
   922
   923
   924
   925
   926
   927
   928
   929
   930
   931
   932
   933
   934
   935
   936
   937
   938
   939
   940
   941
   942
   943
   944
   945
   946
   947
   948  Snijders, et al.        Expires 21 December 2026               [Page 17]