rfc9582.original.xml   rfc9582.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc sortrefs="yes"?> <!-- draft submitted in xml v3 -->
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc compact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc subcompact="no"?> <!ENTITY nbhy "&#8209;">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie <!ENTITY wj "&#8288;">
tf-sidrops-rfc6482bis-09" ipr="trust200902" xml:lang="en" sortRefs="true" submis ]>
sionType="IETF" consensus="true" obsoletes="6482" version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
docName="draft-ietf-sidrops-rfc6482bis-09"
number="9582"
ipr="trust200902"
xml:lang="en"
sortRefs="true"
submissionType="IETF"
consensus="true"
updates=""
obsoletes="6482"
symRefs="true"
tocInclude="true"
version="3">
<front> <front>
<title abbrev="Route Origin Authorization"> <title abbrev="Route Origin Authorization">A Profile for Route Origin Author
A Profile for Route Origin Authorizations (ROAs) izations (ROAs)
</title> </title>
<seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-rfc6482bis"/> <seriesInfo name="RFC" value="9582"/>
<author fullname="Job Snijders" initials="J." surname="Snijders"> <author fullname="Job Snijders" initials="J." surname="Snijders">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<code/> <code/>
<city>Amsterdam</city> <city>Amsterdam</city>
<country>Netherlands</country> <country>Netherlands</country>
</postal> </postal>
<email>job@fastly.com</email> <email>job@fastly.com</email>
skipping to change at line 41 skipping to change at line 58
<street/> <street/>
<city>Cape Town</city> <city>Cape Town</city>
<country>South Africa</country> <country>South Africa</country>
</postal> </postal>
<email>benm@workonline.africa</email> <email>benm@workonline.africa</email>
</address> </address>
</author> </author>
<author fullname="Matthew Lepinski" initials="M." surname="Lepinski"> <author fullname="Matthew Lepinski" initials="M." surname="Lepinski">
<organization>Carleton College</organization> <organization>Carleton College</organization>
<address> <address>
<postal>
<street/>
<code/>
<city/>
<country/>
</postal>
<email>mlepinski@carleton.edu</email> <email>mlepinski@carleton.edu</email>
</address> </address>
</author> </author>
<author fullname="Derrick Kong" initials="D." surname="Kong"> <author fullname="Derrick Kong" initials="D." surname="Kong">
<organization>Raytheon</organization> <organization>Raytheon</organization>
<address> <address>
<postal>
<street/>
<code/>
<city/>
<country/>
</postal>
<email>derrick.kong@raytheon.com</email> <email>derrick.kong@raytheon.com</email>
</address> </address>
</author> </author>
<author fullname="Stephen Kent" initials="S." surname="Kent"> <author fullname="Stephen Kent" initials="S." surname="Kent">
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<postal>
<street/>
<code/>
<city/>
<country/>
</postal>
<email>kent@alum.mit.edu</email> <email>kent@alum.mit.edu</email>
</address> </address>
</author> </author>
<date year="2024" month="April"/>
<area>Operations and Management Area (OPS)</area>
<workgroup>sidrops</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->
<!-- [rfced] It is not clear to us whether or not Erratum ID 5881
(https://www.rfc-editor.org/errata/eid5881) was addressed in this
document. Please review, and let us know if any changes are needed. -->
<abstract> <abstract>
<t> <t>
This document defines a standard profile for Route Origin Authorization s (ROAs). This document defines a standard profile for Route Origin Authorization s (ROAs).
A ROA is a digitally signed object that provides a means of verifying t hat an IP address block holder has authorized an Autonomous System (AS) to origi nate routes to one or more prefixes within the address block. A ROA is a digitally signed object that provides a means of verifying t hat an IP address block holder has authorized an Autonomous System (AS) to origi nate routes to one or more prefixes within the address block.
This document obsoletes RFC 6482. This document obsoletes RFC 6482.
</t> </t>
</abstract> </abstract>
<note>
<name>Requirements Language</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHO
ULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in t
his document are to be interpreted as described in BCP 14 <xref target="RFC2119"
/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</note>
</front> </front>
<middle> <middle>
<!-- [rfced] Datatracker's idnits yields the following error. Please
let us know if any updates are needed. (If yes, Section 4.3 of
RFC 5952 (using lowercase if "db8" is needed after "2001:") might be
of interest as well.)
== There are 2 instances of lines with non-RFC3849-compliant IPv6
addresses in the document. If these are example addresses, they
should be changed. -->
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
The primary purpose of the Resource Public Key Infrastructure (RPKI) is to improve routing security. The primary purpose of the Resource Public Key Infrastructure (RPKI) is to improve routing security.
(See <xref target="RFC6480"/> for more information.) (See <xref target="RFC6480"/> for more information.)
As part of this system, a mechanism is needed to allow entities to verif As part of this system, a mechanism is needed to allow entities to verif
y that an AS has been given permission by an IP address block holder to advertis y that an Autonomous System (AS) has been given permission by an IP address bloc
e routes to one or more prefixes within that block. k holder to advertise routes to one or more prefixes within that block.
A ROA provides this function. A Route Origin Authorization (ROA) provides this function.
</t> </t>
<t> <t>
The ROA makes use of the template for RPKI digitally signed objects [RFC The ROA makes use of the template for RPKI digitally signed objects <xre
6488], which defines a Crytopgraphic Message Syntax (CMS) <xref target="RFC5652" f target="RFC6488"/>, which defines a Cryptographic Message Syntax (CMS) wrapper
/> wrapper for the ROA content as well as a generic validation procedure for RPK <xref target="RFC5652"/> for the ROA content as well as a generic validation pr
I signed objects. ocedure for RPKI signed objects.
Therefore, to complete the specification of the ROA (see Section 4 of <x Therefore, to complete the specification of the ROA (see <xref target="R
ref target="RFC6488"/>), this document defines: FC6488" section="4" sectionFormat="of"/>), this document defines:
</t> </t>
<ul> <ul>
<li> <li>
The OID that identifies the signed object as being a ROA. The OID that identifies the signed object as being a ROA.
(This OID appears within the eContentType in the encapContentInfo obje ct as well as the content-type signed attribute in the signerInfo object). (This OID appears within the eContentType in the encapContentInfo obje ct as well as the content-type signed attribute in the signerInfo object.)
</li> </li>
<li> <li>
The ASN.1 syntax for the ROA eContent. The ASN.1 syntax for the ROA eContent.
(This is the payload that specifies the AS being authorized to origina te routes as well as the prefixes to which the AS may originate routes.) (This is the payload that specifies the AS being authorized to origina te routes as well as the prefixes to which the AS may originate routes.)
The ROA eContent is ASN.1 encoded using the Distinguished Encoding Rul es (DER) <xref target="X.690"/>. The ROA eContent is ASN.1 encoded using the Distinguished Encoding Rul es (DER) <xref target="X.690"/>.
</li> </li>
<li> <li>
Additional steps required to validate ROAs (in addition to the validat ion steps specified in <xref target="RFC6488"/>). Additional steps required to validate ROAs (in addition to the validat ion steps specified in <xref target="RFC6488"/>).
</li> </li>
</ul> </ul>
<section anchor="reqs-lang">
<name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="Changes"> <section anchor="Changes">
<name>Changes from RFC6482</name> <name>Changes from RFC 6482</name>
<t> <t>
This section summarizes the significant changes between <xref target=" RFC6482"/> and the profile described in this document. This section summarizes the significant changes between <xref target=" RFC6482"/> and the profile described in this document.
</t> </t>
<ul> <ul>
<li>Clarified the requirements for the IP Addresses and AS Identifiers X.509 certificate extensions.</li> <li>Clarified the requirements for the IP address and AS identifier X. 509 certificate extensions.</li>
<li>Strengthened the ASN.1 formal notation and definitions.</li> <li>Strengthened the ASN.1 formal notation and definitions.</li>
<li>Incorporated RFC 6482 Errata.</li> <li>Incorporated errata for RFC 6482.</li>
<li>Added an example ROA eContent payload and an ROA.</li> <li>Added an example ROA eContent payload and a ROA.
<!-- [rfced] Section 1.1: This bullet item reads oddly, in that it
seems to say that this document adds (1) an example ROA eContent
payload and (2) a ROA. If the suggested text is not correct, please
clarify.
Original (we changed "an ROA" to "a ROA" per (with the exception of
RFC 6382) post-6000 published RFCs:
* Added an example ROA eContent payload and an ROA.
Suggested:
* Added an example ROA eContent payload (Appendix A). -->
</li>
<li>Specified a canonicalization procedure for the content of ipAddrBl ocks.</li> <li>Specified a canonicalization procedure for the content of ipAddrBl ocks.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="Related"> <section anchor="Related">
<name>Related Work</name> <name>Related Work</name>
<t> <t>
It is assumed that the reader is familiar with the terms and concepts de scribed in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" <xref target="RFC5280"/> and "X.509 Extensions f or IP Addresses and AS Identifiers" <xref target="RFC3779"/>. It is assumed that the reader is familiar with the terms and concepts de scribed in "<xref target="RFC5280" format="title"/>" <xref target="RFC5280" form at="default"/> and "<xref target="RFC3779" format="title"/>" <xref target="RFC37 79" format="default"/>.
</t> </t>
<t> <t>
Additionally, this document makes use of the RPKI signed object profile <xref target="RFC6488"/>; thus, familiarity with that document is assumed. Additionally, this document makes use of the RPKI signed object profile <xref target="RFC6488"/>; thus, familiarity with that document is assumed.
Note that the RPKI signed object profile makes use of certificates adher ing to the RPKI Resource Certificate Profile <xref target="RFC6487"/>; thus, fam iliarly with that profile is also assumed. Note that the RPKI signed object profile makes use of certificates adher ing to the RPKI resource certificate profile <xref target="RFC6487"/>; thus, fam iliarity with that profile is also assumed.
</t> </t>
</section> </section>
<section anchor="content"> <section anchor="content">
<name>The ROA ContentType</name> <name>The ROA ContentType</name>
<t> <t>
The content-type for a ROA is defined as routeOriginAuthz and has the nu The content-type for a ROA is defined as routeOriginAuthz and has the nu
merical value of 1.2.840.113549.1.9.16.1.24. merical value 1.2.840.113549.1.9.16.1.24.
<!-- [rfced] Sections 3 and 4: We see a different path and string
for "routeOriginAuthz" on <http://www.oid-info.com/cgi-bin/
display?oid=1.2.840.113549.1.9.16.1.24&action=display>.
Should "defined as routeOriginAuthz" be "defined as
id-ct-routeOriginAuthz"? Also, should "id-ct(1) routeOriginAuthz(24)"
be "ct(1) id-ct-routeOriginAuthz(24)"? If not, will these
distinctions be clear to readers?
Original:
The content-type for a ROA is defined as routeOriginAuthz and has the
numerical value of 1.2.840.113549.1.9.16.1.24.
...
id-ct-routeOriginAuthz OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) id-smime(16) id-ct(1) routeOriginAuthz(24) } -->
</t> </t>
<t> <t>
This OID MUST appear both within the eContentType in the encapContentInf o object as well as the ContentType signed attribute in the signerInfo object (s ee <xref target="RFC6488"/>). This OID <bcp14>MUST</bcp14> appear within both the eContentType in the encapContentInfo object and the ContentType signed attribute in the signerInfo o bject (see <xref target="RFC6488"/>).
</t> </t>
</section> </section>
<section anchor="econtent"> <section anchor="econtent">
<name>The ROA eContent</name> <name>The ROA eContent</name>
<t> <t>
The content of a ROA identifies a single AS that has been authorized by the address space holder to originate routes and a list of one or more IP addres s prefixes that will be advertised. The content of a ROA identifies a single AS that has been authorized by the address space holder to originate routes and a list of one or more IP addres s prefixes that will be advertised.
If the address space holder needs to authorize multiple ASes to advertis e the same set of address prefixes, the holder issues multiple ROAs, one per AS number. If the address space holder needs to authorize multiple ASes to advertis e the same set of address prefixes, the holder issues multiple ROAs, one per AS number.
A ROA is formally defined as: A ROA is formally defined as:
</t> </t>
<!-- [rfced] Please review the "type" attribute of the sourcecode
element in the XML file to ensure correctness. If the current list
of preferred values for "type"
(https://www.rfc-editor.org/materials/sourcecode-types.txt)
does not contain an applicable type, please let us know. Also, it is
acceptable to leave the "type" attribute not set.
In addition, review each artwork element. Specifically,
should any artwork element be tagged as sourcecode or another
element? -->
<sourcecode type="asn.1" originalSrc="RouteOriginAttestation-2023.asn">RPK I-ROA-2023 { iso(1) member-body(2) us(840) rsadsi(113549) <sourcecode type="asn.1" originalSrc="RouteOriginAttestation-2023.asn">RPK I-ROA-2023 { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiROA-2023(TBD) } pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiROA-2023(75) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
CONTENT-TYPE CONTENT-TYPE
FROM CryptographicMessageSyntax-2010 -- in [RFC6268] FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
skipping to change at line 202 skipping to change at line 275
{ addressFamilyIPv4 | addressFamilyIPv6 } { addressFamilyIPv4 | addressFamilyIPv6 }
addressFamilyIPv4 ADDRESS-FAMILY ::= addressFamilyIPv4 ADDRESS-FAMILY ::=
{ AFI afi-IPv4 ADDRESSES ROAAddressesIPv4 } { AFI afi-IPv4 ADDRESSES ROAAddressesIPv4 }
addressFamilyIPv6 ADDRESS-FAMILY ::= addressFamilyIPv6 ADDRESS-FAMILY ::=
{ AFI afi-IPv6 ADDRESSES ROAAddressesIPv6 } { AFI afi-IPv6 ADDRESSES ROAAddressesIPv6 }
afi-IPv4 OCTET STRING ::= '0001'H afi-IPv4 OCTET STRING ::= '0001'H
afi-IPv6 OCTET STRING ::= '0002'H afi-IPv6 OCTET STRING ::= '0002'H
ROAAddressesIPv4 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{32} ROAAddressesIPv4 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{ub-IPv4}
ROAAddressesIPv6 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{128} ROAAddressesIPv6 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{ub-IPv6}
ROAIPAddress {INTEGER: len} ::= SEQUENCE { ub-IPv4 INTEGER ::= 32
address BIT STRING (SIZE(0..len)), ub-IPv6 INTEGER ::= 128
maxLength INTEGER (0..len) OPTIONAL }
ROAIPAddress {INTEGER: ub} ::= SEQUENCE {
address BIT STRING (SIZE(0..ub)),
maxLength INTEGER (0..ub) OPTIONAL }
END END
</sourcecode> </sourcecode>
<!-- [rfced] Section 4: We updated the last lines of the formal
ROA definition per <https://github.com/job/draft-rfc6482bis/commit/
40b0bbe353038813ebade17e67c54e0d410154b5>* and emails dated 1/25/2024
and 1/26/2024 from Job, Warren, and Russ. Please review, and let us
know if we missed anything.
* We updated "docName" previously.
Original:
...
ROAAddressesIPv4 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{32}
ROAAddressesIPv6 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{128}
ROAIPAddress {INTEGER: len} ::= SEQUENCE {
address BIT STRING (SIZE(0..len)),
maxLength INTEGER (0..len) OPTIONAL }
END
Currently:
ROAAddressesIPv4 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{ub-IPv4}
ROAAddressesIPv6 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{ub-IPv6}
ub-IPv4 INTEGER ::= 32
ub-IPv6 INTEGER ::= 128
ROAIPAddress {INTEGER: ub} ::= SEQUENCE {
address BIT STRING (SIZE(0..ub)),
maxLength INTEGER (0..ub) OPTIONAL }
END -->
<section> <section>
<name>Element version</name> <name>The version Element</name>
<t> <t>
The version number of the RouteOriginAttestation MUST be 0. The version number of the RouteOriginAttestation entry <bcp14>MUST</bc p14> be 0.
</t> </t>
</section> </section>
<section> <section>
<name>Element asID</name> <name>The asID Element</name>
<t> <t>
The asID element contains the AS number that is authorized to originat e routes to the given IP address prefixes. The asID element contains the AS number that is authorized to originat e routes to the given IP address prefixes.
</t> </t>
</section> </section>
<section> <section>
<name>Element ipAddrBlocks</name> <name>The ipAddrBlocks Element</name>
<t> <t>
The ipAddrBlocks element encodes the set of IP address prefixes to whi ch the AS is authorized to originate routes. The ipAddrBlocks element encodes the set of IP address prefixes to whi ch the AS is authorized to originate routes.
Note that the syntax here is more restrictive than that used in the IP Address Delegation extension defined in <xref target="RFC3779"/>. Note that the syntax here is more restrictive than that used in the IP Address Delegation extension defined in <xref target="RFC3779"/>.
That extension can represent arbitrary address ranges, whereas ROAs ne ed to represent only IP prefixes. That extension can represent arbitrary address ranges, whereas ROAs ne ed to represent only IP prefixes.
</t> </t>
<section> <section>
<name>Type ROAIPAddressFamily</name> <name>Type ROAIPAddressFamily</name>
<t> <t>
Within the ROAIPAddressFamily structure, the addressFamily element c ontains the Address Family Identifier (AFI) of an IP address family. Within the ROAIPAddressFamily structure, the addressFamily element c ontains the Address Family Identifier (AFI) of an IP address family.
This specification only supports IPv4 and IPv6, therefore addressFam This specification only supports IPv4 and IPv6; therefore, addressFa
ily MUST be either 0001 or 0002. mily <bcp14>MUST</bcp14> be either 0001 or 0002.
IPv4 prefixes MUST NOT appear as IPv4-Mapped IPv6 Addresses (section IPv4 prefixes <bcp14>MUST NOT</bcp14> appear as IPv4-mapped IPv6 add
2.5.5.2 of <xref target="RFC4291"/>). resses (<xref target="RFC4291" section="2.5.5.2" sectionFormat="of"/>).
</t> </t>
<t> <t>
There MUST be only one instance of ROAIPAddressFamily per unique AFI There <bcp14>MUST</bcp14> be only one instance of ROAIPAddressFamily
in the ROA. per unique AFI in the ROA.
Thus, the ROAIPAddressFamily structure MUST NOT appear more than twi Thus, the ROAIPAddressFamily structure <bcp14>MUST NOT</bcp14> appea
ce. r more than twice.
</t> </t>
<t> <t>
The addresses element represents IP prefixes as a sequence of type R OAIPAddress. The addresses element represents IP prefixes as a sequence of type R OAIPAddress.
<!-- [rfced] Section 4.3.1: We see what appear to be entries for the
addresses element in the code in Section 4 (under
"ROAIPAddressFamily ::= SEQUENCE {") and the original Appendix B
(the "14:d=3" line), but because "addresses element" isn't mentioned
anywhere in the text but here, will the distinction between the
address element and the addresses element be clear to readers?
Original:
The addresses element represents IP prefixes as a sequence of type
ROAIPAddress. -->
</t> </t>
</section> </section>
<section> <section>
<name>Type ROAIPAddress</name> <name>Type ROAIPAddress</name>
<t> <t>
A ROAIPAddress structure is a sequence containing an address element of type IPAddress and an optional maxLength element of type INTEGER. A ROAIPAddress structure is a sequence containing an address element of type IPAddress and an optional maxLength element of type INTEGER.
See section 2.2.3.8 of <xref target="RFC3779"/> for more details on type IPAddress. See <xref target="RFC3779" section="2.2.3.8" sectionFormat="of"/> fo r more details on type IPAddress.
</t> </t>
<section> <section>
<name>Element address</name> <name>The address Element</name>
<t> <t>
The address element is of type IPAddress and represents a single I P address prefix. The address element is of type IPAddress and represents a single I P address prefix.
</t> </t>
</section> </section>
<section> <section>
<name>Element maxLength</name> <name>The maxLength Element</name>
<t> <t>
When present, the maxLength specifies the maximum length of the IP When present, the maxLength element specifies the maximum length o
address prefix that the AS is authorized to advertise. f the IP address prefix that the AS is authorized to advertise.
The maxLength element SHOULD NOT be encoded if the maximum length The maxLength element <bcp14>SHOULD NOT</bcp14> be encoded if the
is equal to the prefix length. maximum length is equal to the prefix length.
Certification Authorities SHOULD anticipate that future Relying Pa Certification Authorities <bcp14>SHOULD</bcp14> anticipate that fu
rties will become increasingly stringent in considering the presence of superflu ture Relying Parties will become increasingly stringent in considering the prese
ous maxLength elements an encoding error. nce of superfluous maxLength elements an encoding error.
</t> </t>
<t> <t>
If present, the maxLength MUST be: If present, the maxLength element <bcp14>MUST</bcp14> be:
</t> </t>
<ul> <ul>
<li>an integer greater than or equal to the length of the accompan ying prefix, and</li> <li>an integer greater than or equal to the length of the accompan ying prefix, and</li>
<li>less than or equal to the maximum length (in bits) of an IP ad dress in the applicable address family: 32 in case of IPv4 and 128 in case of IP v6.</li> <li>less than or equal to the maximum length (in bits) of an IP ad dress in the applicable address family: 32 in the case of IPv4 and 128 in the ca se of IPv6.</li>
</ul> </ul>
<t> <t>
For example, if the IP address prefix is 203.0.113.0/24 and the ma For example, if the IP address prefix is 203.0.113.0/24 and maxLen
xLength is 26, the AS is authorized to advertise any more specific prefix with a gth is 26, the AS is authorized to advertise any more-specific prefix with a max
maximum length of 26. imum length of 26.
In this example, the AS would be authorized to advertise 203.0.113 In this example, the AS would be authorized to advertise 203.0.113
.0/24, 203.0.113.128/25, or 203.0.113.192/26; but not 203.0.113.0/27. .0/24, 203.0.113.128/25, or 203.0.113.192/26, but not 203.0.113.0/27.
See <xref target="RFC9319"/> for more information on the use of ma xLength. See <xref target="RFC9319"/> for more information on the use of ma xLength.
</t> </t>
<t> <t>
When the maxLength is not present, the AS is only authorized to ad vertise the exact prefix specified in the ROAIPAddress' address element. When the maxLength element is not present, the AS is only authoriz ed to advertise the exact prefix specified in the ROAIPAddress structure's addre ss element.
</t> </t>
</section> </section>
<section> <section>
<name>Note on overlapping or superfluous information encoding</name> <name>Note on Overlapping or Superfluous Information Encoding</name>
<t> <t>
Note that a valid ROA may contain an IP address prefix (within a ROAIPAddress element) that is encompassed by another IP address prefix (within a separate ROAIPAddress element). Note that a valid ROA may contain an IP address prefix (within a ROAIPAddress element) that is encompassed by another IP address prefix (within a separate ROAIPAddress element).
For example, a ROA may contain the prefix 203.0.113.0/24 with ma xLength 26, as well as the prefix 203.0.113.0/28 with maxLength 28. For example, a ROA may contain the prefix 203.0.113.0/24 with ma xLength 26, as well as the prefix 203.0.113.0/28 with maxLength 28.
This ROA would authorize the indicated AS to advertise any prefi x beginning with 203.0.113 with a minimum length of 24 and a maximum length of 2 6, as well as the specific prefix 203.0.113.0/28. This ROA would authorize the indicated AS to advertise any prefi x beginning with 203.0.113 with a minimum length of 24 and a maximum length of 2 6, as well as the specific prefix 203.0.113.0/28.
</t> </t>
<t> <t>
Additionally, a ROA MAY contain two ROAIPAddress elements, where Additionally, a ROA <bcp14>MAY</bcp14> contain two ROAIPAddress
the IP address prefix is identical in both cases. elements, where the IP address prefix is identical in both cases.
However, this is NOT RECOMMENDED as, in such a case, the ROAIPAd However, this is <bcp14>NOT RECOMMENDED</bcp14>, because in such
dress with the shorter maxLength grants no additional privileges to the indicate a case, the ROAIPAddress element with the shorter maxLength grants no additiona
d AS and thus can be omitted without changing the meaning of the ROA. l privileges to the indicated AS and thus can be omitted without changing the me
aning of the ROA.
</t> </t>
</section> </section>
</section> </section>
<section> <section>
<name>Canonical form for ipAddrBlocks</name> <name>Canonical Form for ipAddrBlocks</name>
<t> <t>
As the data structure described by the ROA ASN.1 module allows for many different ways to represent the same set of IP address information, a cano nical form is defined such that every set of IP address information has a unique representation. As the data structure described by the ROA ASN.1 module allows for many different ways to represent the same set of IP address information, a cano nical form is defined such that every set of IP address information has a unique representation.
In order to produce and verify this canonical form, the process de In order to produce and verify this canonical form, the process de
scribed in this section SHOULD be used to ensure information elements are unique scribed in this section <bcp14>SHOULD</bcp14> be used to ensure that information
with respect to one another and sorted in ascending order. elements are unique with respect to one another and sorted in ascending order.
Certification Authorities SHOULD anticipate that future Relying Pa Certification Authorities <bcp14>SHOULD</bcp14> anticipate that fu
rties will impose a strict requirement for the ipAddrBlocks field to be in this ture Relying Parties will impose a strict requirement for the ipAddrBlocks field
canonical form. to be in this canonical form.
This canonicalization procedure builds upon the canonicalization p This canonicalization procedure builds upon the canonicalization p
rocedure specified in section 2.2.3.6 of <xref target="RFC3779"/>. rocedure specified in <xref target="RFC3779" section="2.2.3.6" sectionFormat="of
"/>.
</t> </t>
<t> <t>
In order to semantically compare, sort, and deduplicate the conten ts of the ipAddrBlocks field, each ROAIPAddress element is mapped to an abstract data element composed of four integer values: In order to semantically compare, sort, and deduplicate the conten ts of the ipAddrBlocks field, each ROAIPAddress element is mapped to an abstract data element composed of four integer values:
</t> </t>
<dl> <dl>
<dt>afi</dt> <dt>afi</dt>
<dd>The AFI value appearing in the addressFamily field of the contai ning ROAIPAddressFamily as an integer.</dd> <dd>The AFI value appearing in the addressFamily field of the contai ning ROAIPAddressFamily as an integer.</dd>
<dt>addr</dt> <dt>addr</dt>
<dd>The first IP address of the IP prefix appearing in the ROAIPAddr ess address field, as a 32-bit (IPv4) or 128-bit (IPv6) integer value.</dd> <dd>The first IP address of the IP prefix appearing in the ROAIPAddr ess address field, as a 32-bit (IPv4) or 128-bit (IPv6) integer value.</dd>
<dt>plen</dt> <dt>plen</dt>
<dd>The prefix length of the IP prefix appearing in the ROAIPAddress address field as an integer value.</dd> <dd>The length of the IP prefix appearing in the ROAIPAddress addres s field as an integer value.</dd>
<dt>mlen</dt> <dt>mlen</dt>
<dd>The value appearing in the maxLength field of the ROAIPAddress, <dd>The value appearing in the maxLength field of the ROAIPAddress e
if present, otherwise the above prefix length value.</dd> lement, if present; otherwise, the above prefix length value.</dd>
<!-- [rfced] Section 4.3.3: "ROAIPAddress address field" reads
oddly. Could these be written as "ROAIPAddress field" instead, while
preserving the intended meaning?
Original:
addr The first IP address of the IP prefix appearing in the
ROAIPAddress address field, as a 32-bit (IPv4) or 128-bit (IPv6)
integer value.
plen The prefix length of the IP prefix appearing in the
ROAIPAddress address field as an integer value. -->
</dl> </dl>
<t> <t>
Thus, the equality or relative order of two ROAIPAddress elements can be tested by comparing their abstract representations. Thus, the equality or relative order of two ROAIPAddress elements can be tested by comparing their abstract representations.
</t> </t>
<section> <section>
<name>Comparator</name> <name>Comparator</name>
<t> <t>
The set of ipAddrBlocks is totally ordered. The set of ipAddrBlocks is totally ordered.
The order of two ipAddrBlocks is determined by the first non-equ al comparison in the following list. The order of two ipAddrBlocks is determined by the first non-equ al comparison in the following list.
</t> </t>
skipping to change at line 342 skipping to change at line 476
</li> </li>
<li> <li>
Data elements with a lower mlen value precede data elements wi th a higher mlen value. Data elements with a lower mlen value precede data elements wi th a higher mlen value.
</li> </li>
</ol> </ol>
<t> <t>
Data elements for which all four values compare equal are duplic ates of one another. Data elements for which all four values compare equal are duplic ates of one another.
</t> </t>
</section> </section>
<section> <section>
<name>Example implementations</name> <name>Example Implementations</name>
<t> <ul>
A sorting implementation <xref target="roasort-c"/> in ISO/IEC 9 <li>A sorting implementation <xref target="roasort-c"/> in ISO/I
899:1999 ("ANSI&nbsp;C99"). EC 9899:1999 ("ANSI&nbsp;C99").</li>
</t> <li>A sorting implementation <xref target="roasort-rs"/> in the
<t> Rust 2021 Edition.</li>
A sorting implementation <xref target="roasort-rs"/> in Rust 202
1 Edition. <!-- [rfced] Section 4.3.3.2: We could not find anything about a
</t> "Rust 2021 Edition" on [roasort-rs]. Please confirm that this
citation is correct and will be clear to readers (e.g., is this the
same "Rust" as the 2021 edition discussed on
<https://doc.rust-lang.org/edition-guide/rust-2021/index.html>?).
Original:
A sorting implementation [roasort-rs] in Rust 2021 Edition. -->
</ul>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section> <section>
<name>ROA Validation</name> <name>ROA Validation</name>
<t> <t>
Before a relying party can use a ROA to validate a routing announcemen Before a relying party can use a ROA to validate a routing announcemen
t, the relying party MUST first validate the ROA. t, the relying party <bcp14>MUST</bcp14> first validate the ROA.
To validate a ROA, the relying party MUST perform all the validation c To validate a ROA, the relying party <bcp14>MUST</bcp14> perform all t
hecks specified in <xref target="RFC6488"/> as well as the following additional he validation checks specified in <xref target="RFC6488"/> as well as the follow
ROA-specific validation steps: ing additional ROA-specific validation steps:
</t> </t>
<ul> <ul>
<li> <li>
The IP Address Delegation extension <xref target="RFC3779"/> is pres ent in the end-entity (EE) certificate (contained within the ROA), and every IP address prefix in the ROA payload is contained within the set of IP addresses sp ecified by the EE certificate's IP Address Delegation extension. The IP Address Delegation extension <xref target="RFC3779"/> is pres ent in the end-entity (EE) certificate (contained within the ROA), and every IP address prefix in the ROA payload is contained within the set of IP addresses sp ecified by the EE certificate's IP Address Delegation extension.
</li> </li>
<li> <li>
The EE certificate's IP Address Delegation extension MUST NOT contai n "inherit" elements described in <xref target="RFC3779"/>. The EE certificate's IP Address Delegation extension <bcp14>MUST NOT </bcp14> contain "inherit" elements as described in <xref target="RFC3779"/>.
</li> </li>
<!-- Lynne: If authors want to lowercase the "address delegation
extension" part of "IP address delegation extension" (see
question re. inconsistent usage), change "Autonomous System
Identifier Delegation Extension" to "AS identifier delegation
extension". -->
<li> <li>
The Autonomous System Identifier Delegation Extension described in < xref target="RFC3779"/> is not used in Route Origin Authorizations and MUST NOT be present in the EE certificate. The Autonomous System Identifier Delegation Extension described in < xref target="RFC3779"/> is not used in ROAs and <bcp14>MUST NOT</bcp14> be prese nt in the EE certificate.
</li> </li>
<li> <li>
The ROA content fully conforms with all requirements specified in <x The ROA content fully conforms with all requirements specified in
ref target="content"/> and <xref target="econtent"/>. Sections&nbsp;<xref target="content" format="counter"/> and <xref target="econte
nt" format="counter"/>.
</li> </li>
</ul> </ul>
<t> <t>
If any of the above checks fail, the ROA in its entirety MUST be consi dered invalid and an error SHOULD be logged. If any of the above checks fail, the ROA in its entirety <bcp14>MUST</ bcp14> be considered invalid and an error <bcp14>SHOULD</bcp14> be logged.
</t> </t>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
There is no assumption of confidentiality for the data in a ROA; it is a nticipated that ROAs will be stored in repositories that are accessible to all I SPs, and perhaps to all Internet users. There is no assumption of confidentiality for the data in a ROA; it is a nticipated that ROAs will be stored in repositories that are accessible to all I SPs, and perhaps to all Internet users.
There is no explicit authentication associated with a ROA, since the PKI used for ROA validation provides authorization but not authentication. There is no explicit authentication associated with a ROA, since the PKI used for ROA validation provides authorization but not authentication.
Although the ROA is a signed, application-layer object, there is no inte nt to convey non-repudiation via a ROA. Although the ROA is a signed, application-layer object, there is no inte nt to convey non-repudiation via a ROA.
</t> </t>
<t> <t>
The purpose of a ROA is to convey authorization for an AS to originate a The purpose of a ROA is to convey authorization for an AS to originate a
route to the prefix(es) in the ROA. route to the prefix or prefixes in the ROA.
Thus, the integrity of a ROA MUST be established. Thus, the integrity of a ROA <bcp14>MUST</bcp14> be established.
The ROA specification makes use of the RPKI signed object format; thus, The ROA specification makes use of the RPKI signed object format; thus,
all security considerations in <xref target="RFC6488"/> also apply to ROAs. all security considerations discussed in <xref target="RFC6488"/> also apply to
Additionally, the signed object profile uses the CMS signed message form ROAs.
at for integrity; thus, ROAs inherit all security considerations associated with Additionally, the signed object profile uses the CMS signed message format for i
that data structure. ntegrity; thus, ROAs inherit all security considerations associated with that da
ta structure.
<!-- [rfced] Section 6: It appears that "The ROA specification"
might refer to RFC 6482 and this document. May we clarify the text
as suggested?
Original:
The ROA specification makes use of the
RPKI signed object format; thus, all security considerations in
[RFC6488] also apply to ROAs.
Suggested:
This ROA specification makes use of the
RPKI signed object format; thus, all security considerations
discussed in [RFC6488] also apply to ROAs. -->
</t> </t>
<t> <t>
The right of the ROA signer to authorize the target AS to originate rout The right of the ROA signer to authorize the target AS to originate rout
es to the prefix(es) is established through use of the address space and AS numb es to the prefix or prefixes is established through the use of the address space
er PKI described in <xref target="RFC6480"/>. and AS number PKI as described in <xref target="RFC6480"/>.
Specifically, one MUST verify the signature on the ROA using an X.509 ce Specifically, one <bcp14>MUST</bcp14> verify the signature on the ROA us
rtificate issued under this PKI, and check that the prefix(es) in the ROA are co ing an X.509 certificate issued under this PKI and check that the prefix or pref
ntained within those in the certificate's IP Address Delegation Extension. ixes in the ROA are contained within those in the certificate's IP Address Deleg
ation Extension.
</t> </t>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section> <section>
<name>SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) </name> <name>SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) </name>
<t> <t>
The IANA is requested to update the id-ct-routeOriginAuthz entry in th IANA has updated the id-ct-routeOriginAuthz entry in the "SMI Security
e "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows:
as follows:
</t>
<artwork>
<![CDATA[
Decimal Description References
24 id-ct-routeOriginAuthz [RFC-to-be]
]]>
</artwork>
<t>
Upon publication of this document, IANA is requested to reference the
RFC publication instead of this draft.
</t> </t>
<table anchor="tab1">
<thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>24</td>
<td>id-ct-routeOriginAuthz</td>
<td>RFC 9582</td>
</tr>
</tbody>
</table>
</section> </section>
<section> <section>
<name>RPKI Signed Objects sub-registry</name> <name>RPKI Signed Objects Registry</name>
<t> <t>
The IANA is requested to update the entry for the Route Origination Au thorization in the "RPKI Signed Objects" registry created by <xref target="RFC64 88"/> as follows: IANA has updated the Route Origination Authorization entry in the "RPK I Signed Objects" registry created by <xref target="RFC6488"/> as follows:
</t> </t>
<artwork>
<![CDATA[ <table anchor="tab-2">
Name OID Specification <thead>
Route Origination Authorization 1.2.840.113549.1.9.16.1.24 [RFC-to-be] <tr>
]]> <th>Name</th>
</artwork> <th>OID</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>Route Origination Authorization</td>
<td>1.2.840.113549.1.9.16.1.24</td>
<td>RFC 9582</td>
</tr>
</tbody>
</table>
</section> </section>
<section> <section>
<name>File Extension</name> <name>File Extension</name>
<t> <t>
The IANA is requested to update the entry for the ROA file extension i IANA has updated the entry for the ROA file extension in the "RPKI Rep
n the "RPKI Repository Name Schemes" registry created by <xref target="RFC6481"/ ository Name Schemes" registry created by <xref target="RFC6481"/> as follows:
> as follows:
</t>
<artwork>
<![CDATA[
Filename Extension RPKI Object Reference
.roa Route Origination Authorization [RFC-to-be]
]]>
</artwork>
<t>
Upon publication of this document, IANA is requested to make this addi
tion permanent and to reference the RFC publication instead of this draft.
</t> </t>
<table anchor="tab3">
<thead>
<tr>
<th>Filename Extension</th>
<th>RPKI Object</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>.roa</td>
<td>Route Origination Authorization</td>
<td>RFC 9582</td>
</tr>
</tbody>
</table>
</section> </section>
<section> <section>
<name>SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0 )</name> <name>SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0 )</name>
<t> <t>
The IANA is requested to allocate for this document in the "SMI Securi ty for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry: IANA has allocated the following entry in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:
</t> </t>
<artwork> <table anchor="tab4">
<![CDATA[ <thead>
Decimal Description Reference <tr>
TBD id-mod-rpkiROA-2023 [RFC-to-be] <th>Decimal</th>
]]> <th>Description</th>
</artwork> <th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>75</td>
<td>id-mod-rpkiROA-2023</td>
<td>RFC 9582</td>
</tr>
</tbody>
</table>
</section> </section>
<section> <section>
<name>Media Type</name> <name>Media Type</name>
<t> <t>
The IANA is requested to update the media type application/rpki-roa in the "Media Type" registry as follows: IANA has updated the media type application/rpki-roa in the "Media Typ es" registry as follows:
</t> </t>
<artwork>
<![CDATA[ <dl spacing="normal" newline="false">
Type name: application <dt>Type name:</dt><dd>application</dd>
Subtype name: rpki-roa <dt>Subtype name:</dt><dd>rpki-roa</dd>
Required parameters: N/A <dt>Required parameters:</dt><dd>N/A</dd>
Optional parameters: N/A <dt>Optional parameters:</dt><dd>N/A</dd>
Encoding considerations: binary <dt>Encoding considerations:</dt><dd>binary</dd>
Security considerations: Carries an RPKI ROA [RFC-to-be]. <dt>Security considerations:</dt><dd>Carries an RPKI ROA (RFC 9582).
This media type contains no active content. See This media type contains no active content. See
Section 6 of [RFC-to-be] for further information. Section 6 of RFC 9582 for further information.</dd>
Interoperability considerations: None <dt>Interoperability considerations:</dt><dd>None</dd>
Published specification: [RFC-to-be] <dt>Published specification:</dt><dd>RFC 9582</dd>
Applications that use this media type: RPKI operators <dt>Applications that use this media type:</dt><dd>RPKI operators</dd>
Additional information: <dt>Additional information:</dt>
Content: This media type is a signed object, as defined <dd>
in [RFC6488], which contains a payload of a list of <t><br/></t>
prefixes and an AS identifer as defined in [RFC-to-be]. <dl spacing="compact">
Magic number(s): None <dt>Content:</dt><dd>This media type is a signed object, as defined
File extension(s): .roa in <xref target="RFC6488"/>, which contains a payload of a list of
Macintosh file type code(s): prefixes and an AS identifier as defined in RFC 9582.</dd>
Person & email address to contact for further information: <dt>Magic number(s):</dt><dd>None</dd>
Job Snijders <job@fastly.com> <dt>File extension(s):</dt><dd>.roa</dd>
Intended usage: COMMON <dt>Macintosh file type code(s):</dt><dd></dd>
Restrictions on usage: None </dl>
Change controller: IETF </dd>
]]> <dt>Person &amp; email address to contact for further information:</dt>
</artwork> <dd><br/>Job Snijders &lt;job@fastly.com&gt;</dd>
<dt>Intended usage:</dt><dd>COMMON</dd>
<dt>Restrictions on usage:</dt><dd>None</dd>
<dt>Change controller:</dt><dd>IETF</dd>
</dl>
<!-- [rfced] Section 7.5: Please confirm that the entry for
"Macintosh file type code(s)" should remain empty (i.e., should
not be listed as "N/A" or "None", as is frequently done in published
RFCs).
Original:
...
File extension(s): .roa
Macintosh file type code(s):
Person & email address to contact for further information:
... -->
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.37
le> 79.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42
<date month="March" year="1997"/> 91.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.56
<t>In many standards track documents several words are used to sig 52.xml"/>
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
his document defines these words as they should be interpreted in IETF documents 68.xml"/>
. This document specifies an Internet Best Current Practices for the Internet Co <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
mmunity, and requests discussion and suggestions for improvements.</t> 81.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
</front> 82.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
<seriesInfo name="RFC" value="2119"/> 87.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
</reference> 88.xml"/>
<reference anchor="RFC3779" target="https://www.rfc-editor.org/info/rfc3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
779" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"> 74.xml"/>
<front>
<title>X.509 Extensions for IP Addresses and AS Identifiers</title>
<author fullname="C. Lynn" initials="C." surname="Lynn"/>
<author fullname="S. Kent" initials="S." surname="Kent"/>
<author fullname="K. Seo" initials="K." surname="Seo"/>
<date month="June" year="2004"/>
<abstract>
<t>This document defines two X.509 v3 certificate extensions. The
first binds a list of IP address blocks, or prefixes, to the subject of a certif
icate. The second binds a list of autonomous system identifiers to the subject o
f a certificate. These extensions may be used to convey the authorization of the
subject to use the IP addresses and autonomous system identifiers contained in
the extensions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3779"/>
<seriesInfo name="DOI" value="10.17487/RFC3779"/>
</reference>
<reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4
291" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<date month="February" year="2006"/>
<abstract>
<t>This specification defines the addressing architecture of the I
P Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, te
xt representations of IPv6 addresses, definition of IPv6 unicast addresses, anyc
ast addresses, and multicast addresses, and an IPv6 node's required addresses.</
t>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Arch
itecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
<reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5
652" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="September" year="2009"/>
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS).
This syntax is used to digitally sign, digest, authenticate, or encrypt arbitra
ry message content. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference>
<reference anchor="RFC6268" target="https://www.rfc-editor.org/info/rfc6
268" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml">
<front>
<title>Additional New ASN.1 Modules for the Cryptographic Message Sy
ntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="July" year="2011"/>
<abstract>
<t>The Cryptographic Message Syntax (CMS) format, and many associa
ted formats, are expressed using ASN.1. The current ASN.1 modules conform to the
1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to co
nform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative
version. There are no bits- on-the-wire changes to any of the formats; this is s
imply a change to the syntax. This document is not an Internet Standards Track s
pecification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6268"/>
<seriesInfo name="DOI" value="10.17487/RFC6268"/>
</reference>
<reference anchor="RFC6481" target="https://www.rfc-editor.org/info/rfc6
481" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml">
<front>
<title>A Profile for Resource Certificate Repository Structure</titl
e>
<author fullname="G. Huston" initials="G." surname="Huston"/>
<author fullname="R. Loomans" initials="R." surname="Loomans"/>
<author fullname="G. Michaelson" initials="G." surname="Michaelson"/
>
<date month="February" year="2012"/>
<abstract>
<t>This document defines a profile for the structure of the Resour
ce Public Key Infrastructure (RPKI) distributed repository. Each individual repo
sitory publication point is a directory that contains files that correspond to X
.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects
. This profile defines the object (file) naming scheme, the contents of reposito
ry publication points (directories), and a suggested internal structure of a loc
al repository cache that is intended to facilitate synchronization across a dist
ributed collection of repository publication points and to facilitate certificat
ion path construction. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6481"/>
<seriesInfo name="DOI" value="10.17487/RFC6481"/>
</reference>
<reference anchor="RFC6482" target="https://www.rfc-editor.org/info/rfc6
482" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6482.xml">
<front>
<title>A Profile for Route Origin Authorizations (ROAs)</title>
<author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
<author fullname="S. Kent" initials="S." surname="Kent"/>
<author fullname="D. Kong" initials="D." surname="Kong"/>
<date month="February" year="2012"/>
<abstract>
<t>This document defines a standard profile for Route Origin Autho
rizations (ROAs). A ROA is a digitally signed object that provides a means of ve
rifying that an IP address block holder has authorized an Autonomous System (AS)
to originate routes to one or more prefixes within the address block. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6482"/>
<seriesInfo name="DOI" value="10.17487/RFC6482"/>
</reference>
<reference anchor="RFC6487" target="https://www.rfc-editor.org/info/rfc6
487" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml">
<front>
<title>A Profile for X.509 PKIX Resource Certificates</title>
<author fullname="G. Huston" initials="G." surname="Huston"/>
<author fullname="G. Michaelson" initials="G." surname="Michaelson"/
>
<author fullname="R. Loomans" initials="R." surname="Loomans"/>
<date month="February" year="2012"/>
<abstract>
<t>This document defines a standard profile for X.509 certificates
for the purpose of supporting validation of assertions of "right-of-use" of Int
ernet Number Resources (INRs). The certificates issued under this profile are us
ed to convey the issuer's authorization of the subject to be regarded as the cur
rent holder of a "right-of-use" of the INRs that are described in the certificat
e. This document contains the normative specification of Certificate and Certifi
cate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPK
I). This document also specifies profiles for the format of certificate requests
and specifies the Relying Party RPKI certificate path validation procedure. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6487"/>
<seriesInfo name="DOI" value="10.17487/RFC6487"/>
</reference>
<reference anchor="RFC6488" target="https://www.rfc-editor.org/info/rfc6
488" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml">
<front>
<title>Signed Object Template for the Resource Public Key Infrastruc
ture (RPKI)</title>
<author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
<author fullname="A. Chi" initials="A." surname="Chi"/>
<author fullname="S. Kent" initials="S." surname="Kent"/>
<date month="February" year="2012"/>
<abstract>
<t>This document defines a generic profile for signed objects used
in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects mak
e use of Cryptographic Message Syntax (CMS) as a standard encapsulation format.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6488"/>
<seriesInfo name="DOI" value="10.17487/RFC6488"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="X.690"> <reference anchor="X.690">
<front> <front>
<title>Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2015"/> <date month="February" year="2021"/>
</front> </front>
<seriesInfo name="ITU-T" value="Recommendation X.690"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
</reference> </reference>
<!-- [rfced] Normative References: The 2015 version of [X.690] is
marked "Superseded" on <https://www.itu.int/rec/T-REC-X.690>. We
updated this listing to reflect the current ("In force") February
2021 version. Please let us know any concerns.
Original:
[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, 2015.
Currently:
[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, February 2021. -->
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4
648" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.46
<front> 48.xml"/>
<title>The Base16, Base32, and Base64 Data Encodings</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> 80.xml"/>
<date month="October" year="2006"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
<abstract> 80.xml"/>
<t>This document describes the commonly used base 64, base 32, and <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
base 16 encoding schemes. It also discusses the use of line-feeds in encoded da 19.xml"/>
ta, use of padding in encoded data, use of non-alphabet characters in encoded da
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
280" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC6480" target="https://www.rfc-editor.org/info/rfc6
480" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml">
<front>
<title>An Infrastructure to Support Secure Internet Routing</title>
<author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
<author fullname="S. Kent" initials="S." surname="Kent"/>
<date month="February" year="2012"/>
<abstract>
<t>This document describes an architecture for an infrastructure t
o support improved security of Internet routing. The foundation of this architec
ture is a Resource Public Key Infrastructure (RPKI) that represents the allocati
on hierarchy of IP address space and Autonomous System (AS) numbers; and a distr
ibuted repository system for storing and disseminating the data objects that com
prise the RPKI, as well as other signed objects necessary for improved routing s
ecurity. As an initial application of this architecture, the document describes
how a legitimate holder of IP address space can explicitly and verifiably author
ize one or more ASes to originate routes to that address space. Such verifiable
authorizations could be used, for example, to more securely construct BGP route
filters. This document is not an Internet Standards Track specification; it is p
ublished for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6480"/>
<seriesInfo name="DOI" value="10.17487/RFC6480"/>
</reference>
<reference anchor="RFC9319" target="https://www.rfc-editor.org/info/rfc9
319" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9319.xml">
<front>
<title>The Use of maxLength in the Resource Public Key Infrastructur
e (RPKI)</title>
<author fullname="Y. Gilad" initials="Y." surname="Gilad"/>
<author fullname="S. Goldberg" initials="S." surname="Goldberg"/>
<author fullname="K. Sriram" initials="K." surname="Sriram"/>
<author fullname="J. Snijders" initials="J." surname="Snijders"/>
<author fullname="B. Maddison" initials="B." surname="Maddison"/>
<date month="October" year="2022"/>
<abstract>
<t>This document recommends ways to reduce the forged-origin hijac
k attack surface by prudently limiting the set of IP prefixes that are included
in a Route Origin Authorization (ROA). One recommendation is to avoid using the
maxLength attribute in ROAs except in some specific cases. The recommendations c
omplement and extend those in RFC 7115. This document also discusses the creatio
n of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitig
ation services. Considerations related to ROAs and RPKI-based Route Origin Valid
ation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard
Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filterin
g are also highlighted.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="185"/>
<seriesInfo name="RFC" value="9319"/>
<seriesInfo name="DOI" value="10.17487/RFC9319"/>
</reference>
<reference anchor="roasort-c" target="https://github.com/job/roasort"> <reference anchor="roasort-c" target="https://github.com/job/roasort">
<front> <front>
<title>ROA sorter in C</title> <title>ROA sorter in C</title>
<author initials="J." surname="Snijders"> <author/>
<organization>Fastly</organization> <date month="July" year="2023"/>
</author>
</front> </front>
<refcontent>commit 68969ea</refcontent>
</reference> </reference>
<reference anchor="roasort-rs" target="https://github.com/benmaddison/ro asort"> <reference anchor="roasort-rs" target="https://github.com/benmaddison/ro asort">
<front> <front>
<title>ROA sorter in Rust</title> <title>ROA sorter in Rust</title>
<author initials="B." surname="Maddison"> <author/>
<organization>Workonline</organization> <date month="August" year="2023"/>
</author>
</front> </front>
<refcontent>commit 023e756</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>
The authors wish to thank Theo Buehler, Ties de Kock, Martin Hoffmann, C
harles Gardiner, Russ Housley, Jeffrey Haas, and Bob Beck for their help and con
tributions.
Additionally, the authors thank Jim Fenton, Vijay Gurbani, Haoyu Song, R
ob Austein, Roque Gagliano, Danny McPherson, Sam Weiler, Jasdip Singh, and Murra
y S. Kucherawy for their careful reviews and helpful comments.
</t>
</section>
<section anchor="example"> <section anchor="example">
<name>Example ROA eContent Payload</name> <name>Example ROA eContent Payload</name>
<t> <t>
Below an example of a DER encoded ROA eContent is provided with annotati An example of a DER-encoded ROA eContent is provided below, with annotat
on following the '#' character. ion following the "#" character.
<!-- [rfced] Original Appendix B (now Appendix A): Please note that
xml2rfc outputs the following warnings for line lengths that are too
long. Please let us know where line breaks can be placed so that the
line-length restrictions in the text output can be accommodated.
(180): Warning: Too long line found (L205), 11 characters longer than 72 charact
ers:
addresses ADDRESS-FAMILY.&Addresses ({AddressFamilySet}{@addressFamily}
) }
(707): Warning: Too long line found (L654), 13 characters longer than 72 charact
ers:
$ echo 302402023CCA301E301C04020002301630090307002001067C208C30090307002A0EB2400
000 \
(707): Warning: Too long line found (L657), 8 characters longer than 72 characte
rs:
0:d=0 hl=2 l= 36 cons: SEQUENCE # RouteOriginAttestation
(707): Warning: Too long line found (L660), 5 characters longer than 72 characte
rs:
8:d=2 hl=2 l= 28 cons: SEQUENCE # ROAIPAddressFamily
(707): Warning: Too long line found (L661), 1 characters longer than 72 characte
rs:
10:d=3 hl=2 l= 2 prim: OCTET STRING # addressFamily
(707): Warning: Too long line found (L664), 1 characters longer than 72 characte
rs:
16:d=4 hl=2 l= 9 cons: SEQUENCE # ROAIPAddress
(707): Warning: Too long line found (L666), 9 characters longer than 72 characte
rs:
0000 - 00 20 01 06 7c 20 8c . ..| . # 2001:67c:208c::/4
8
(707): Warning: Too long line found (L667), 1 characters longer than 72 characte
rs:
27:d=4 hl=2 l= 9 cons: SEQUENCE # ROAIPAddress
(707): Warning: Too long line found (L669), 5 characters longer than 72 characte
rs:
0000 - 00 2a 0e b2 40 .*..@ # 2a0e:b240::/48
(770): Warning: Too long line found (L713), 16 characters longer than 72 charact
ers:
SHA256 hash: 13afbad09ed59b315efd8722d38b09fd02962e376e4def32247f9de9
05649b47 -->
</t> </t>
<artwork> <artwork>
<![CDATA[ <![CDATA[
$ echo 302402023CCA301E301C04020002301630090307002001067C208C30090307002A0EB2400 000 \ $ echo 302402023CCA301E301C04020002301630090307002001067C208C30090307002A0EB2400 000 \
| xxd -r -ps \ | xxd -r -ps \
| openssl asn1parse -i -dump -inform DER | openssl asn1parse -i -dump -inform DER
0:d=0 hl=2 l= 36 cons: SEQUENCE # RouteOriginAttestation 0:d=0 hl=2 l= 36 cons: SEQUENCE # RouteOriginAttestation
2:d=1 hl=2 l= 2 prim: INTEGER :3CCA # asID 15562 2:d=1 hl=2 l= 2 prim: INTEGER :3CCA # asID 15562
6:d=1 hl=2 l= 30 cons: SEQUENCE # ipAddrBlocks 6:d=1 hl=2 l= 30 cons: SEQUENCE # ipAddrBlocks
8:d=2 hl=2 l= 28 cons: SEQUENCE # ROAIPAddressFamily 8:d=2 hl=2 l= 28 cons: SEQUENCE # ROAIPAddressFamily
10:d=3 hl=2 l= 2 prim: OCTET STRING # addressFamily 10:d=3 hl=2 l= 2 prim: OCTET STRING # addressFamily
0000 - 00 02 .. # IPv6 0000 - 00 02 .. # IPv6
14:d=3 hl=2 l= 22 cons: SEQUENCE # addresses 14:d=3 hl=2 l= 22 cons: SEQUENCE # addresses
16:d=4 hl=2 l= 9 cons: SEQUENCE # ROAIPAddress 16:d=4 hl=2 l= 9 cons: SEQUENCE # ROAIPAddress
18:d=5 hl=2 l= 7 prim: BIT STRING # address 18:d=5 hl=2 l= 7 prim: BIT STRING # address
0000 - 00 20 01 06 7c 20 8c . ..| . # 2001:67c:208c::/4 8 0000 - 00 20 01 06 7c 20 8c . ..| . # 2001:67c:208c::/4 8
27:d=4 hl=2 l= 9 cons: SEQUENCE # ROAIPAddress 27:d=4 hl=2 l= 9 cons: SEQUENCE # ROAIPAddress
29:d=5 hl=2 l= 7 prim: BIT STRING # address 29:d=5 hl=2 l= 7 prim: BIT STRING # address
0000 - 00 2a 0e b2 40 .*..@ # 2a0e:b240::/48 0000 - 00 2a 0e b2 40 .*..@ # 2a0e:b240::/48
0007 - <SPACES/NULS> 0007 - <SPACES/NULS>
]]> ]]></artwork>
</artwork>
<t> <t>
Below is a complete <xref target="RFC4648">Base64</xref> encoded RPKI RO A Signed Object. Below is a complete RPKI ROA signed object, <xref target="RFC4648">Base6 4 encoded per</xref>.
</t> </t>
<artwork anchor="object"> <artwork anchor="object">
<![CDATA[ <![CDATA[
MIIHCwYJKoZIhvcNAQcCoIIG/DCCBvgCAQMxDTALBglghkgBZQMEAgEwNwYLKoZIhvcNAQkQ MIIHCwYJKoZIhvcNAQcCoIIG/DCCBvgCAQMxDTALBglghkgBZQMEAgEwNwYLKoZIhvcNAQkQ
ARigKAQmMCQCAjzKMB4wHAQCAAIwFjAJAwcAIAEGfCCMMAkDBwAqDrJAAACgggT7MIIE9zCC ARigKAQmMCQCAjzKMB4wHAQCAAIwFjAJAwcAIAEGfCCMMAkDBwAqDrJAAACgggT7MIIE9zCC
A9+gAwIBAgIDAIb5MA0GCSqGSIb3DQEBCwUAMDMxMTAvBgNVBAMTKDM4ZTE0ZjkyZmRjN2Nj A9+gAwIBAgIDAIb5MA0GCSqGSIb3DQEBCwUAMDMxMTAvBgNVBAMTKDM4ZTE0ZjkyZmRjN2Nj
ZmJmYzE4MjM2MTUyM2FlMjdkNjk3ZTk1MmYwHhcNMjIwNjE3MDAyNDIyWhcNMjMwNzAxMDAw ZmJmYzE4MjM2MTUyM2FlMjdkNjk3ZTk1MmYwHhcNMjIwNjE3MDAyNDIyWhcNMjMwNzAxMDAw
MDAwWjAzMTEwLwYDVQQDEyhBM0Q5NjQyNDU3NDlCQjZERDVBQjFGMkU4MzBFMzNBNkM1MTQ2 MDAwWjAzMTEwLwYDVQQDEyhBM0Q5NjQyNDU3NDlCQjZERDVBQjFGMkU4MzBFMzNBNkM1MTQ2
RThGMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4CRG1t04YFLq3fctx2ThNfr6 RThGMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4CRG1t04YFLq3fctx2ThNfr6
Vxsd2wZzcZhQJgUdlvUyfUPISWMwuPfpGjviqtCEzh5aNePGpLopkIES08egzTmJ78Is6+kW Vxsd2wZzcZhQJgUdlvUyfUPISWMwuPfpGjviqtCEzh5aNePGpLopkIES08egzTmJ78Is6+kW
skipping to change at line 793 skipping to change at line 868
Boy1+djlcAkugA92OKLzqjHWfY2iWZkcxXmFDthoeVCGQePkHMOigOyjZPcM8EXumo1rwI7N Boy1+djlcAkugA92OKLzqjHWfY2iWZkcxXmFDthoeVCGQePkHMOigOyjZPcM8EXumo1rwI7N
4CPs0VkmCVCZABYVQ0HJvU08i/Wf6X1VRbNcMYIBqjCCAaYCAQOAFKPZZCRXSbtt1asfLoMO 4CPs0VkmCVCZABYVQ0HJvU08i/Wf6X1VRbNcMYIBqjCCAaYCAQOAFKPZZCRXSbtt1asfLoMO
M6bFFG6PMAsGCWCGSAFlAwQCAaBrMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGDAcBgkq M6bFFG6PMAsGCWCGSAFlAwQCAaBrMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGDAcBgkq
hkiG9w0BCQUxDxcNMjIwNjE3MDAyNDIyWjAvBgkqhkiG9w0BCQQxIgQgyCDmNy5kR2T3NpBX hkiG9w0BCQUxDxcNMjIwNjE3MDAyNDIyWjAvBgkqhkiG9w0BCQQxIgQgyCDmNy5kR2T3NpBX
fNhzFLNQv4PmI8kFb6VIt1kqeRswDQYJKoZIhvcNAQEBBQAEggEAWu1sxXCO/X8voU1zfvL+ fNhzFLNQv4PmI8kFb6VIt1kqeRswDQYJKoZIhvcNAQEBBQAEggEAWu1sxXCO/X8voU1zfvL+
My6KXb5va2CIuKD4dn/cllClWp8YizygIb+tPWfsT6DvaLOp1jE0raQyc8nUexLXSlIBGF7j My6KXb5va2CIuKD4dn/cllClWp8YizygIb+tPWfsT6DvaLOp1jE0raQyc8nUexLXSlIBGF7j
GVWYCy4Oo8mXki+YB3AP1eXiBpx8E4Aa3Rq6/FO80fqrVmUTuywGnv9m6zSIrzEPFujpRIDa GVWYCy4Oo8mXki+YB3AP1eXiBpx8E4Aa3Rq6/FO80fqrVmUTuywGnv9m6zSIrzEPFujpRIDa
QQfDEOktRcLvNPXHfipTBzR4VSLkbZbyJBdigEPFUJVIRcAoI4tZAUVcbwANrHpZElFMBgr6 QQfDEOktRcLvNPXHfipTBzR4VSLkbZbyJBdigEPFUJVIRcAoI4tZAUVcbwANrHpZElFMBgr6
Rpn9l5nu7kUlZqXbV39Mfv8WCzctaUyc+Ag311sfWu5s6XaX3PtT9V4TnQhbSWcvR9NgM+As Rpn9l5nu7kUlZqXbV39Mfv8WCzctaUyc+Ag311sfWu5s6XaX3PtT9V4TnQhbSWcvR9NgM+As
NqelVbdJ/iA2SeNHU/65xf6dDE2zdHDfsw== NqelVbdJ/iA2SeNHU/65xf6dDE2zdHDfsw==
]]> ]]></artwork>
</artwork>
<t> <t>
The object in <xref target="object"/> has the following properties: The object in this appendix has the following properties:
</t> </t>
<artwork align="center"> <artwork align="center">
<![CDATA[ <![CDATA[
Object Object
SHA256 hash: 13afbad09ed59b315efd8722d38b09fd02962e376e4def32247f9de9 05649b47 SHA256 hash: 13afbad09ed59b315efd8722d38b09fd02962e376e4def32247f9de9 05649b47
Size: 1807 octets Size: 1807 octets
CMS signing time: Fri 17 Jun 2022 00:24:22 +0000 CMS signing time: Fri 17 Jun 2022 00:24:22 +0000
X.509 end-entity certificate X.509 end-entity certificate
skipping to change at line 818 skipping to change at line 892
Authority key id: 38E14F92FDC7CCFBFC182361523AE27D697E952F Authority key id: 38E14F92FDC7CCFBFC182361523AE27D697E952F
Issuer: /CN=38e14f92fdc7ccfbfc182361523ae27d697e952f Issuer: /CN=38e14f92fdc7ccfbfc182361523ae27d697e952f
Serial: 86F9 Serial: 86F9
Not before: Fri 17 Jun 2022 00:24:22 +0000 Not before: Fri 17 Jun 2022 00:24:22 +0000
Not after: Sat 01 Jul 2023 00:00:00 +0000 Not after: Sat 01 Jul 2023 00:00:00 +0000
IP address delegation: 2001:67c:208c::/48, 2a0e:b240::/48 IP address delegation: 2001:67c:208c::/48, 2a0e:b240::/48
eContent eContent
asID: 15562 asID: 15562
addresses: 2001:67c:208c::/48, 2a0e:b240::/48 addresses: 2001:67c:208c::/48, 2a0e:b240::/48
]]> ]]></artwork>
</artwork> </section>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>
The authors wish to thank <contact fullname="Theo Buehler"/>, <contact f
ullname="Ties de Kock"/>, <contact fullname="Martin Hoffmann"/>, <contact fullna
me="Charles Gardiner"/>, <contact fullname="Russ Housley"/>, <contact fullname="
Jeffrey Haas"/>, and <contact fullname="Bob Beck"/> for their help and contribut
ions.
Additionally, the authors thank <contact fullname="Jim Fenton"/>, <conta
ct fullname="Vijay Gurbani"/>, <contact fullname="Haoyu Song"/>, <contact fullna
me="Rob Austein"/>, <contact fullname="Roque Gagliano"/>, <contact fullname="Dan
ny McPherson"/>, <contact fullname="Sam Weiler"/>, <contact fullname="Jasdip Sin
gh"/>, and <contact fullname="Murray S. Kucherawy"/> for their careful reviews a
nd helpful comments.
</t>
</section> </section>
</back> </back>
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
<!-- [rfced] The following terms appear to be used inconsistently in
this document. Please let us know which form is preferred.
content-type signed attribute (Section 1 /
ContentType signed attribute (as updated in Section 3 of this new
bis document)
IP Address Delegation extension (4 instances) /
IP Address Delegation Extension (1 instance)
(We see that RFC 3779 consistently uses the lowercase forms
"IP address delegation extension" and
"autonomous system identifier delegation extension"
but RFCs 6494, 8360, and 8897 use "IP Address Delegation
extension".)
Relying Parties (Section 4.3) / relying party (Section 5) -->
</rfc> </rfc>
 End of changes. 87 change blocks. 
546 lines changed or deleted 580 lines changed or added

This html diff was produced by rfcdiff 1.48.