Diff: rfc9582.original.xml

	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 " ">
	<?rfc compact="yes"?>	<!ENTITY zwsp "">
	<?rfc subcompact="no"?>	<!ENTITY nbhy "‑">
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie	<!ENTITY wj "⁠">
	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/>	<postalLine>Amsterdam</postalLine>
	<code/>	<postalLine>The Netherlands</postalLine>
	<city>Amsterdam</city>
	<country>Netherlands</country>
	</postal>	</postal>
	<email>job@fastly.com</email>	<email>job@fastly.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Ben Maddison" initials="B" surname="Maddison">	<author fullname="Ben Maddison" initials="B" surname="Maddison">
	<organization abbrev="Workonline">Workonline</organization>	<organization abbrev="Workonline">Workonline</organization>
	<address>	<address>
	<postal>	<postal>
	<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="May"/>

		<area>Operations and Management Area (OPS)</area>
		<workgroup>sidrops</workgroup>

		<keyword>RPKI</keyword>
		<keyword>Routing Security</keyword>
		<keyword>BGP</keyword>

	<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>


	<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 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 complete ROA (Appendi
		x 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 Content Type</name>
	<t>	<t>

	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.	The content-type for a ROA is defined as id-ct-routeOriginAuthz and has the numerical value 1.2.840.113549.1.9.16.1.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 content-type signed attribute in the signerInfo object (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>

	<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">
	pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiROA-2023(TBD) }	RPKI-ROA-2023
		{ iso(1) member-body(2) us(840) rsadsi(113549)
		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 184 ¶	skipping to change at line 202 ¶

	RouteOriginAttestation ::= SEQUENCE {	RouteOriginAttestation ::= SEQUENCE {
	version [0] INTEGER DEFAULT 0,	version [0] INTEGER DEFAULT 0,
	asID ASID,	asID ASID,
	ipAddrBlocks SEQUENCE (SIZE(1..2)) OF ROAIPAddressFamily }	ipAddrBlocks SEQUENCE (SIZE(1..2)) OF ROAIPAddressFamily }

	ASID ::= INTEGER (0..4294967295)	ASID ::= INTEGER (0..4294967295)

	ROAIPAddressFamily ::= SEQUENCE {	ROAIPAddressFamily ::= SEQUENCE {
	addressFamily ADDRESS-FAMILY.&afi ({AddressFamilySet}),	addressFamily ADDRESS-FAMILY.&afi ({AddressFamilySet}),

	addresses ADDRESS-FAMILY.&Addresses ({AddressFamilySet}{@addressFamily	addresses ADDRESS-FAMILY.&Addresses
	}) }	({AddressFamilySet}{@addressFamily}) }

	ADDRESS-FAMILY ::= CLASS {	ADDRESS-FAMILY ::= CLASS {
	&afi OCTET STRING (SIZE(2)) UNIQUE,	&afi OCTET STRING (SIZE(2)) UNIQUE,
	&Addresses	&Addresses
	} WITH SYNTAX { AFI &afi ADDRESSES &Addresses }	} WITH SYNTAX { AFI &afi ADDRESSES &Addresses }

	AddressFamilySet ADDRESS-FAMILY ::=	AddressFamilySet ADDRESS-FAMILY ::=
	{ 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>


	<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 field contains IP prefixes as a sequence of type ROAIP Address.
	</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	A ROAIPAddress structure is a sequence containing an address element
	of type IPAddress and an optional maxLength element of type INTEGER.	of type BIT STRING and an optional maxLength element of type INTEGER.
	See section 2.2.3.8 of <xref target="RFC3779"/> for 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	The address element is of type BIT STRING and represents a single
	P address prefix.	IP address prefix. This field uses the same representation of an IP address pref
		ix as a
		BIT STRING as the IPAddress type defined in <xref target="RFC3779" sectionFormat
		="of" section="2.2.3.8"/>.
	</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, if present, otherwise the above prefix length value.</dd>	<dd>The value appearing in the maxLength field of the ROAIPAddress e lement, if present; otherwise, the above prefix length value.</dd>
	</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 365 ¶
	</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 C99").	EC 9899:1999 ("ANSI 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	</ul>
	1 Edition.
	</t>
	</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>
	<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 <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,	This 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.
	</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&wj;/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&wj;/ 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>None</dd>
	Restrictions on usage: None	</dl>
	Change controller: IETF	</dd>
	]]>	<dt>Person & email address to contact for further information:</dt>
	</artwork>	<dd><br/>Job Snijders <job@fastly.com></dd>
		<dt>Intended usage:</dt><dd>COMMON</dd>
		<dt>Restrictions on usage:</dt><dd>None</dd>
		<dt>Change controller:</dt><dd>IETF</dd>
		</dl>

	</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>
	</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 fullname="Job Snijders"/>
	<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 fullname="Ben Maddison"/>
	<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 on following the '#' character.	An example of a DER-encoded ROA eContent is provided below, with annotat ion following the "#" character.
	</t>	</t>

	<artwork>	<sourcecode>
	<![CDATA[	<![CDATA[

	$ echo 302402023CCA301E301C04020002301630090307002001067C208C30090307002A0EB2400	$ echo 16i 301802030100003011300F040200023009300703050020010DB8 P \
	000 \	\| dc \| openssl asn1parse -inform DER -i -dump
	\| xxd -r -ps \	0:d=0 hl=2 l= 24 cons: SEQUENCE # RouteOriginAttestation
	\| openssl asn1parse -i -dump -inform DER	2:d=1 hl=2 l= 3 prim: INTEGER :010000 # asID 65536
	0:d=0 hl=2 l= 36 cons: SEQUENCE # RouteOriginAttestation	7:d=1 hl=2 l= 17 cons: SEQUENCE # ipAddrBlocks
	2:d=1 hl=2 l= 2 prim: INTEGER :3CCA # asID 15562	9:d=2 hl=2 l= 15 cons: SEQUENCE # ROAIPAddressFamily
	6:d=1 hl=2 l= 30 cons: SEQUENCE # ipAddrBlocks	11:d=3 hl=2 l= 2 prim: OCTET STRING # addressFamily
	8:d=2 hl=2 l= 28 cons: SEQUENCE # ROAIPAddressFamily	0000 - 00 02 # IPv6
	10:d=3 hl=2 l= 2 prim: OCTET STRING # addressFamily	15:d=3 hl=2 l= 9 cons: SEQUENCE # addresses
	0000 - 00 02 .. # IPv6	17:d=4 hl=2 l= 7 cons: SEQUENCE # ROAIPAddress
	14:d=3 hl=2 l= 22 cons: SEQUENCE # addresses	19:d=5 hl=2 l= 5 prim: BIT STRING # 2001:db8::/32
	16:d=4 hl=2 l= 9 cons: SEQUENCE # ROAIPAddress	0000 - 00 20 01 0d b8
	18:d=5 hl=2 l= 7 prim: BIT STRING # address	]]></sourcecode>
	0000 - 00 20 01 06 7c 20 8c . ..\| . # 2001:67c:208c::/4
	8
	27:d=4 hl=2 l= 9 cons: SEQUENCE # ROAIPAddress
	29:d=5 hl=2 l= 7 prim: BIT STRING # address
	0000 - 00 2a 0e b2 40 .*..@ # 2a0e:b240::/48
	0007 - <SPACES/NULS>
	]]>
	</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">	<sourcecode anchor="object">
	<![CDATA[	<![CDATA[

	MIIHCwYJKoZIhvcNAQcCoIIG/DCCBvgCAQMxDTALBglghkgBZQMEAgEwNwYLKoZIhvcNAQkQ	MIIGgAYJKoZIhvcNAQcCoIIGcTCCBm0CAQMxDTALBglghkgBZQMEAgEwKwYLKoZI
	ARigKAQmMCQCAjzKMB4wHAQCAAIwFjAJAwcAIAEGfCCMMAkDBwAqDrJAAACgggT7MIIE9zCC	hvcNAQkQARigHAQaMBgCAwEAADARMA8EAgACMAkwBwMFACABDbigggR8MIIEeDCC
	A9+gAwIBAgIDAIb5MA0GCSqGSIb3DQEBCwUAMDMxMTAvBgNVBAMTKDM4ZTE0ZjkyZmRjN2Nj	A2CgAwIBAgIBAzANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyQ4NjUyNWNkNS00
	ZmJmYzE4MjM2MTUyM2FlMjdkNjk3ZTk1MmYwHhcNMjIwNjE3MDAyNDIyWhcNMjMwNzAxMDAw	NGQ3LTRkZjktODA3OS00YTlkY2RmMjY5NDQwHhcNMjQwNTAxMDAzNDEzWhcNMjUw
	MDAwWjAzMTEwLwYDVQQDEyhBM0Q5NjQyNDU3NDlCQjZERDVBQjFGMkU4MzBFMzNBNkM1MTQ2	NTAxMDAzNDEzWjAvMS0wKwYDVQQDEyRlYjg3NmJmMC1lYTlkLTRiMjItYTExZS0y
	RThGMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4CRG1t04YFLq3fctx2ThNfr6	YmNhZDA4MzliMTMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsPSYD
	Vxsd2wZzcZhQJgUdlvUyfUPISWMwuPfpGjviqtCEzh5aNePGpLopkIES08egzTmJ78Is6+kW	JnGOFRSHUZuVxibx2TQfWWoPIHNKgQAwYn1Kz88HaGgVf63G1mJd/cxBNMj5AfNQ
	LXwy9CcwT7gmP9qOTSEi8h4qcyajxHbAwDEjROVNSujhLGeB74S9IQTn2Ertp2Et2xPq/kXw	m2zKSAb83UAp97DUXf+lvoKj4F+lxCCjFaBpBeehc7X0XPDpbcbqo1YrzIzxxqou
	+eiBHtOL2h2I7/UOZxHOHuNuHby+VbhFaxgPA7rVfdlUAf9yYxQvyZtB7kHT/EwAR4c9SYWu	GijEwZ4k+BaM2avEFYMBszqWA+ZdneBSuZ3YbHPKp2royn4pJ9a1I5fYdqFQi0eo
	0rvbWNJwWehzlT74V1XaknRXQjkKYHe34Fyyx9FY86uX4uN8rPuIzkd7n6g81pUZRIuk/3tc	VZbAc8pZmwRVOuedYYqQiy9CSRGsbiGlB0fKt2m/zSsuvl4Zit7+NyGL3wAZecjZ
	/DjbHNAD3qWVQ+0aqNdkunoJhQccZwIDAQABo4ICEjCCAg4wHQYDVR0OBBYEFKPZZCRXSbtt	XEInsTtQsjQuy5PeJjLDyfWi/ZFi0qPsNlK0M2lMsi5B7QKaagA1RbRVHZyrkWoe
	1asfLoMOM6bFFG6PMB8GA1UdIwQYMBaAFDjhT5L9x8z7/BgjYVI64n1pfpUvMBgGA1UdIAEB	20l5rfk1bIGMv/plAgMBAAGjggGdMIIBmTAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0O
	/wQOMAwwCgYIKwYBBQUHDgIwZAYDVR0fBF0wWzBZoFegVYZTcnN5bmM6Ly9jaGxvZS5zb2Jv	BBYEFN4UWxk/syCyWnRDVSmMi/fCUj0iMB8GA1UdIwQYMBaAFNZyCOpHDp1t1mVA
	cm5vc3QubmV0L3Jwa2kvUklQRS1ubGpvYnNuaWpkZXJzL09PRlBrdjNIelB2OEdDTmhVanJp	IvVTrcE4mrQ0MBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwWgYIKwYBBQUHAQEE
	ZldsLWxTOC5jcmwwZAYIKwYBBQUHAQEEWDBWMFQGCCsGAQUFBzAChkhyc3luYzovL3Jwa2ku	TjBMMEoGCCsGAQUFBzAChj5yc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwby8x
	cmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL09PRlBrdjNIelB2OEdDTmhVanJpZldsLWxT	bklJNmtjT25XM1daVUFpOVZPdHdUaWF0RFNnLmNlcjBRBgNVHR8ESjBIMEagRKBC
	OC5jZXIwDgYDVR0PAQH/BAQDAgeAMIGoBggrBgEFBQcBCwSBmzCBmDBfBggrBgEFBQcwC4ZT	hkByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwby9BLzFuSUk2a2NPblczV1pV
	cnN5bmM6Ly9jaGxvZS5zb2Jvcm5vc3QubmV0L3Jwa2kvUklQRS1ubGpvYnNuaWpkZXJzL285	QWk5Vk90d1RpYXREU2cuY3JsMFwGCCsGAQUFBwELBFAwTjBMBggrBgEFBQcwC4ZA
	bGtKRmRKdTIzVnF4OHVndzR6cHNVVWJvOC5yb2EwNQYIKwYBBQUHMA2GKWh0dHBzOi8vY2hs	cnN5bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG8vQS8zaFJiR1QteklMSmFkRU5W
	b2Uuc29ib3Jub3N0Lm5ldC9ycGtpL25ld3MueG1sMCsGCCsGAQUFBwEHAQH/BBwwGjAYBAIA	S1l5TDk4SlNQU0tnLnJvYTAgBggrBgEFBQcBBwEB/wQRMA8wDQQCAAIwBwMFACAB
	AjASAwcAIAEGfCCMAwcAKg6yQAAAMA0GCSqGSIb3DQEBCwUAA4IBAQAY4bd+Y1Os1MbxGWLU	DbgwDQYJKoZIhvcNAQELBQADggEBAKFoMax1Gdxb9mvSfKE2Jo+DudqCGjWF3mGv
	d7rNVG0c3e0FOwtUOE/Qprt5gkCHO2L19/R1jnXlAaJPID5VhUNl2y/AiwmP47vhk+fvtEdB	rkhag8CQYi2CBJZLrkpCRha8doBW4PbrL36waWG55A/TdLKvWzAf66/v3iL5QcXo
	wniszL8wCk5b6wwufn1z5/stQ85GRmsqJw5nkOYCyWpTP8k+TUa4w32xNj1dX78FwadDVeSP	Krb0+fp1pu/YVK4xFxwYJhbX4OnL4Gqh9+t4fFXhEDj2QemlgjWZyxvgx2Sra/iK
	yMgJ0860mkXbV1/82/D60zrWQsVAZiYebhni1QAqmpsxZwdZceFRRVY48YDPOZ73ZBZvf0g6	fOt6gxUhie3oIT+FiYjqF//WIUBP/HjTf+E4IRGN8tCr3NDhMZG6c0njq2keW7w4
	Boy1+djlcAkugA92OKLzqjHWfY2iWZkcxXmFDthoeVCGQePkHMOigOyjZPcM8EXumo1rwI7N	wnw1+GqSyDhqu0Rsr0m3XUbivkc+h0ZZBBS9SxPM+GfgdzEDV51VcK1SeMa3G3Ca
	4CPs0VkmCVCZABYVQ0HJvU08i/Wf6X1VRbNcMYIBqjCCAaYCAQOAFKPZZCRXSbtt1asfLoMO	j0cJA99eTM+j52tkNVupftv1Y+4Wt0XGLKmRNKw26XDaphzw3B8xggGqMIIBpgIB
	M6bFFG6PMAsGCWCGSAFlAwQCAaBrMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGDAcBgkq	A4AU3hRbGT+zILJadENVKYyL98JSPSIwCwYJYIZIAWUDBAIBoGswGgYJKoZIhvcN
	hkiG9w0BCQUxDxcNMjIwNjE3MDAyNDIyWjAvBgkqhkiG9w0BCQQxIgQgyCDmNy5kR2T3NpBX	AQkDMQ0GCyqGSIb3DQEJEAEYMBwGCSqGSIb3DQEJBTEPFw0yNDA1MDEwMDM0MTNa
	fNhzFLNQv4PmI8kFb6VIt1kqeRswDQYJKoZIhvcNAQEBBQAEggEAWu1sxXCO/X8voU1zfvL+	MC8GCSqGSIb3DQEJBDEiBCBlz4HExs5A69pxkJqTCbUvc2iTS7C4eDd3aJD4hYJS
	My6KXb5va2CIuKD4dn/cllClWp8YizygIb+tPWfsT6DvaLOp1jE0raQyc8nUexLXSlIBGF7j	wjANBgkqhkiG9w0BAQEFAASCAQBa2wmuDHbcvfnMRIaOJ6m30zpCZtJVBLDELoA0
	GVWYCy4Oo8mXki+YB3AP1eXiBpx8E4Aa3Rq6/FO80fqrVmUTuywGnv9m6zSIrzEPFujpRIDa	2kLb18TfFbxQhUi/jZ9g0hNYksV0n4vOJnCQ3qP6IIfm0ZsKzRnyzZf3f2xegw2p
	QQfDEOktRcLvNPXHfipTBzR4VSLkbZbyJBdigEPFUJVIRcAoI4tZAUVcbwANrHpZElFMBgr6	Wzi9Z8QYlc//eY3+XA3bQ37h+s0r7OZkQH7+KmIwDOCYaLh/YB37wp/7giC7bpvi
	Rpn9l5nu7kUlZqXbV39Mfv8WCzctaUyc+Ag311sfWu5s6XaX3PtT9V4TnQhbSWcvR9NgM+As	c2Fv2illQmctrK7tYDHsNGq+svULTjemUaklqfcRAAJnQTRzTz8So9wKY9SR2VVZ
	NqelVbdJ/iA2SeNHU/65xf6dDE2zdHDfsw==	68DDItTBUx8jPYeNQtvxxoVA6HuW9wyurlYQ9m/cF8CzlizVmsHgxzjO9ifmYJj9
	]]>	YZWMLtjF7Xw1fQZLYMrD5DCZzUw3nv4GyyHxckm2kLF38mze
	</artwork>	]]></sourcecode>
	<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">	<sourcecode>
	<![CDATA[	<![CDATA[

	Object	Object size: 1668 octets
	SHA256 hash: 13afbad09ed59b315efd8722d38b09fd02962e376e4def32247f9de9	Object SHA256 message digest:
	05649b47	3a39e0b652e79ddf6efdd178ad5e3b29e0121b1e593b89f1e0ac18f3ba60d5e7
	Size: 1807 octets


	CMS signing time: Fri 17 Jun 2022 00:24:22 +0000	CMS signing time: Wed 01 May 2024 00:34:13 +0000

	X.509 end-entity certificate	X.509 end-entity certificate

	Subject key id: A3D964245749BB6DD5AB1F2E830E33A6C5146E8F	Subject key id: DE145B193FB320B25A744355298C8BF7C2523D22
	Authority key id: 38E14F92FDC7CCFBFC182361523AE27D697E952F	Authority key id: D67208EA470E9D6DD6654022F553ADC1389AB434
	Issuer: /CN=38e14f92fdc7ccfbfc182361523ae27d697e952f	Issuer: CN=86525cd5-44d7-4df9-8079-4a9dcdf26944
	Serial: 86F9	Serial: 3
	Not before: Fri 17 Jun 2022 00:24:22 +0000	Not before: Wed 01 May 2024 00:34:13 +0000
	Not after: Sat 01 Jul 2023 00:00:00 +0000	Not after: Thu 01 May 2025 00:34:13 +0000
	IP address delegation: 2001:67c:208c::/48, 2a0e:b240::/48	IP address delegation: 2001:db8::/32


	eContent	ROA eContent
	asID: 15562	asID: 65536
	addresses: 2001:67c:208c::/48, 2a0e:b240::/48	addresses: 2001:db8::/32
	]]>	]]></sourcecode>
	</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"/>, <contact fullname="Bob Beck"/>, and <contact fullname="Tom Harr
		ison"/> for their help and contributions.
		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>
	</rfc>	</rfc>

End of changes. 95 change blocks.
	631 lines changed or deleted	419 lines changed or added
This html diff was produced by rfcdiff 1.48.