One document matched: draft-barnes-sidr-tao-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!--
DOCTYPE processing

To use this XML template, the rfc2629.dtd from the xml2rfc distribution should 
be in the local directory. The xml2rfc distribution is available from 
http://xml.resource.org/

The ENTITY clauses create an include of the named XML files, which
contains references written in xml2rfc format.

XML2RFC offers an include feature described in the XML2RFC README
file.  That syntax, however, contradicts the DTD requirements to
have <reference> elements within the <references> element, so an 
XML parser is likely to find your XML file invalid.  It may be
possible that XML2RFC will change their DTD so that the XML file
remains valid when their style of include is used.

Some editors, such as XXE, resolve the ENTITY clauses before displaying the 
document to be edited.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc6492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6492.xml">
<!ENTITY rfc3779 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3779.xml">
<!ENTITY rfc6480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6480.xml">
<!ENTITY rfc6481 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6481.xml">
<!ENTITY rfc6488 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6488.xml">
<!ENTITY xml SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-names-20091208.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc category="std" docName="draft-barnes-sidr-tao-00" ipr="trust200902">
<front>
<title abbrev="Transfer Authorization Object">Resource Public Key Infrastructure (RPKI) Resource Transfer Protocol and Transfer Authorization Object (TAO)</title>

<author fullname="Edric Barnes" initials="E" surname="Barnes">
<organization>BBN Technologies</organization>

<address>
<postal>
<street>10 Moulton St</street>

<city>Cambridge</city>
<region>MA</region>
<country>US</country>
</postal>

<email>ebarnes@bbn.com</email>
</address>
</author>

<date  year="2014" />

<workgroup>Secure Inter-Domain Routing</workgroup>

<!--add additional keywords here for IETF website search engine -->
<abstract>

<t> This document defines an extension to the rpki-updown protocol to provide support for transferring Internet Number Resources from one INR holder to another. Such transfers take place external to the RPKI, using procedures defined within and between RIRs. This protocol facilitates automation of the maintenance of RPKI data in the context of INR transfers. The protocol supports asynchronous transfers of live or unused INRs within an RIR or between RIRs. The scope of this protocol is limited to the transfer of Internet Number Resources within the Resource Public Key Infrastructure. In support of this protocol, this document also defines a new signed object type for the RPKI repository system, the Transfer Authorization Object (TAO).  </t>

</abstract>

</front>

<middle>
<section title="Introduction">
<t> This document defines an extension to the rpki-updown protocol, defined in <xref target="RFC6492"/>, to provide support for transferring Internet Number Resources from one INR holder to another. The protocol supports asynchronous transfers of live or unused INRs. The scope of the protocol is limited to the transfer of Internet Number Resource within the Resource Public Key Infrastructure, defined in <xref target="RFC6480"/>. In support of this protocol, this document also defines a new signed object type, the Transfer Authorization Object (TAO), which makes use of the signed object format defined in <xref target="RFC6488"/>.  </t>
<t>Many of the messages in this protocol are identical to those in <xref target="RFC6488"/>, and the result of the protocol, updated certificates published in the RPKI repository system <xref target="RFC6481"/>, is the same for both protocols. To initiate a transfer, an INR holder, or source, creates a TAO and publishes it in its publication point. The TAO is a declaration of the proposed transfer, signed by the transfer source. The source communicates the location of the TAO to the INR recipient. Both entities then pursue the transfer independently, recursively requesting the transfer from their parents until the lowest common ancestor, the swing point is reached. The swing point acts as the ultimate arbiter of the transfer, although any Certification Authority (CA) involved in the transfer is able to deny the transfer. The protocol assumes that the source of the transfer, and the recipient have gained preliminary approval for the transfer, out-of-band (OOB), prior to publishing the TAO and initiating the protocol.</t>
<section title="Terminology">
<t>
<list style="hanging">
<t hangText="Terms used in this document are:">
</t>
<t hangText='"Internet Number Resource"'>(or "resource" or "INR") used in the context of this document to refer to Autonomous System (AS) numbers and IP version 4 or IP version 6 addresses.</t>
<t hangText='"swing point"'>the lowest common ancestor (Certification Authority) of both the INR source and the INR recipient in the RPKI hierarchy. It is assumed that the swing point is neither the source nor the recipient.</t>
<t hangText='"source"'>(or "INR source") the INR holder that initiates the transfer</t>
<t hangText='"recipient"'>(or "INR recipient") the INR holder that is the destination of the transfer</t>
<t hangText='"live"'>a live INR is a resource that is currently in use</t>
</list>
</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, <xref target="RFC2119"></xref>.</t>
</section>
</section>

<section title="Scope">
<t> This Resource Public Key Infrastructure (RPKI) INR transfer protocol defines a basic set of interactions that allows:
<list style="symbols">
<t>an INR holder to initiate the transfer of Internet Number Resources,</t>
<t>the INR source and INR recipient to pursue the transfer asynchronously, </t>
<t>and each Certification Authority (CA) along the path between the source and recipient (including the swing point) to validate and approve, or deny, any such transfer.</t>
</list>
The resource allocation database and INR transfer policies of each CA along the path are authoritative when determining whether the resources in question may be transferred.</t>

<t>This protocol specification does not encompass:
<list style="symbols">
<t>the specification of interactions with the each CA's resource allocation database, nor the specification of a protocol to manage the publication repository.</t>
<t>transfers where the source or recipient is also the swing point. Both situations are already handled by rpki-updown as explained in <xref target="sec_swing_pt"/>.</t>
</list></t>
</section>

<section title="Protocol Specifications">
<t>The INR source MUST initiate the transfer by creating and publishing the Transfer Authorization Object (TAO, see <xref target="TAO"/>) at its publication point <xref target="RFC6481"/>. The URL of the TAO SHOULD be communicated to the transfer recipient, e.g., via email. Once the TAO is published, and the recipient has received the URL of the TAO, two separate processes begin: the first from the INR source to the swing point, the second from the transfer recipient to the swing point. These two processes proceed independently and recursively. The following steps occur between each parent and child along the specified paths in the hierarchy. </t> 
<t>In both cases, when a CA receives an updated certificate from its immediate parent, it MUST promptly update the certificate for the child involved in the transfer. This certificate is published in its publication point and sent to the child using a transfer_response message (<xref target="transfer_response"/>. If this CA is the INR source or INR recipient, no updates are necessary since receipt of the updated certificate indicates that the parent has updated the end point of the transfer. Similarly, when a CA receives an error message from a parent, the CA MUST forward the message code to its immediate child along the path towards the INR source or INR recipient.</t>
<t>Both the INR source and the INR recipient MUST NOT rekey during a transfer; their SKIs are captured in the TAO and the validity of the TAO requires the SKIs not change during the process. A new key would invalidate the TAO and require restarting the transfer process. To avoid this problem, the source SHOULD NOT initiate a transfer that is expected to take longer than the notAfter date in its, or the recipient's, CA certificate. The source should contact (OOB) the CA's along the path to receive an estimate of the time required to complete a transfer, to aid in making this determination.</t>
<t>The process described below is used for transferring either live or unused INRs. The process is identical for both types of transfers except where otherwise specified.</t>

<section title="INR Source Path">
<t>The source MUST NOT request a transfer of any INRs that are delegated to one of the source's children (i.e., appear in a CA certificate issued by the source). This requirement avoids one way that a TAO that is valid at the beginning of a transfer could become invalid before the end of the transfer. In particular, in the instance where the source of this transfer is the swing point in another transfer, this prevents the swing point from transferring INRs to a different recipient than specified in the first transfer.</t>
<t>Along the path from the INR source to the swing point, with the INR source as the initial "child", the following messages MUST be transmitted in the specified order.
<list style="numbers"> 
<t>The child sends a transfer_request (<xref target="transfer_request"/>) to its parent.</t>
<t>The parent confirms the validity of the transfer_request, responding with an error code 1203 for invalid requests. An invalid request cancels the transfer. A transfer_request is valid if all of the following are true:
<list style="symbols">
<t>The attached TAO is valid. See <xref target="sec_tao_validate"/> for TAO validation steps.</t>
<t>The TAO in the request is identical to the TAO published in the source's publication point.</t>
<t>The transfer is allowed by the transfer policy of the CA</t>
</list></t>
<t>The parent replies with a transfer_response (<xref target="transfer_response"/>). For transfers of unused INRs, the transfer_response contains an updated certificate, which MUST have the same INRs as the certificate it replaces, minus the INRs specified in the TAO. For live transfers, the transfer_response contains an error code 1104 response, indicating that the transfer is valid and being pursued asynchronously.</t>
<t>The parent determines if it (the parent) is the swing point. See <xref target="sec_swing_pt"/> for this procedure. If it is not the swing point, the parent repeats this process from step 1, acting as the child. If the parent is not the swing point but is a self-signed CA, an error code 1401 MUST be returned.</t>
</list>
</t>
<t>If, after an excessive wait, a child does not receive a response from its parent, the child SHOULD return error 1402 indicating a timeout. This error declares cancellation of the transfer request by the child, and MUST be propagated up AND down the path. This informs any parents waiting further up the path that the child is no longer waiting for an updated certificate, and indicates that the parent MUST time out as well. Ultimately, what constitutes an excessive wait is determined by each CA. However, it is RECOMMENDED that each CA not time out a transfer prior to the notAfter value in the TAO.</t>
<t>For live transfers, the source waits until the notAfter value in the TAO expires. If the recipient has successfully received the INRs at that point, the source MUST use the following process to relinquish control of the transferred INRs:
<list style="numbers">
<t>The child sends a transfer_request (<xref target="transfer_request"/>) to the parent.</t>
<t>The parent confirms that the transfer_request matches a previous transfer_request, with the exception that the notAfter MUST be in the past. The parent responds with an error code 1203 for invalid requests. A transfer_request is valid if all of the following are true:
<list style="symbols">
<t>The attached TAO is valid, with the exception of the notAfter value which MUST be in the past. See <xref target="sec_tao_validate"/> for TAO validation steps.</t>
<t>The TAO in the request MUST be identical to the TAO published in the source's publication point.</t>
</list></t>
<t>The parent replies with a transfer_response (<xref target="transfer_response"/>). This response MUST include an updated certificate which MUST have the same INRs as the certificate it replaces, minus the INRs specified in the TAO.</t>
<t>The parent determines if it (the parent) is the swing point. See <xref target="sec_swing_pt"/> for this procedure. If it is not the swing point, the parent repeats this process from step 1, acting as the child. If the parent is not the swing point but is a self-signed CA, an error code 1401 MUST be returned.</t>
</list></t>
</section>

<section title="INR Recipient Path">
<t>A recipient will have multiple parents within the RPKI if it has received INR allocations from multiple sources. In such cases, the recipient MUST select the parent via which the resources will be received. The means by which a recipient makes this decision are outside the scope of this protocol. (INR transfers require OOB coordination among the affected organizations. This coordination is expected to provide the recipient with a basis for selecting a parent for the transfer.)</t>
<t>Along the path from the transfer recipient to the swing point, with the INR recipient as the initial "child", the following messages MUST be transmitted in the order specified below.
<list style="numbers">
<t>The child sends a transfer_request, <xref target="transfer_request"></xref>, to the parent.</t>
<t>The parent confirms the validity of the transfer_request, responding with an error code 1203 for invalid requests. A transfer_request is valid only if all of the following are true:
<list style="symbols">
<t>The attached TAO is valid. See <xref target="sec_tao_validate"/> for TAO validation steps.</t>
<t>The TAO in the request is identical to the TAO published in the source's publication point.</t>
<t>The transfer is allowed by the transfer policy of the CA</t>
</list></t>
<t>The parent determines if it (the parent) is the swing point. See <xref target="sec_swing_pt"/> for this procedure. </t>
<t>If it is not the swing point, the parent replies with a transfer_response containing an error code. If the parent is a self-signed CA and it is not the swing point, an error code 1401 MUST be returned. If the parent is not a self-signed CA, an error code 1104 response MUST be returned, indicating that the transfer is valid and being pursued asynchronously. The parent then repeats this process from step 1, acting as the child.</t> 
</list>
</t>
<t>If, after an excessive wait, a child does not receive a response from its parent, the child SHOULD return error 1402 indicating a timeout. This error declares cancellation of the transfer request by the child, and MUST be propagated up AND down the path by each parent. See the previous section for a discussion of what constitutes "excessive".</t>
<t>During live transfers, CAs in the recipient path have an additional responsibility after receiving an updated certificate. The overlapPeriod field of the TAO MUST be less than that number of seconds from the current time to the notAfter value of the TAO. If this test fails, this CA MUST forward an error code 1403 up and down the path, ending the transfer. This minimizes the likelihood that the source and recipient do not have an adequate overlap in ownership of the INRs in question during a live transfer.</t>
</section>
<section title="Swing Point" anchor="sec_swing_pt">
<t>A CA determines that it is the swing point by verifying that both the INR source and the INR recipient SKIs, as defined in the TAO, are below the CA in the hierarchy. Because this determination is performed for both paths, starting at the source and the recipient, this will uniquely determine the swing point. This document does not cover the case where the swing point is the source or the recipient. If the swing point is the recipient, the INRs are being relinquished and returned to that organization. If the swing point is the source, the INRs are being assigned. This procedure is already accommodated by use of the up/down protocol. Because the RPKI hierarchy is intended to have a unique root, there should always exist a swing point. </t>
<t>The swing point MUST behave as follows:
<list style="numbers">
<t>Confirm that it is the swing point.</t>
<t>Confirm the validity and uniqueness of the Subject Key Identifiers (SKI) of the CAs (source and recipient)in the TAO.</t>
<t>Confirm that it controls the INRs to be transferred.</t>
<t>Wait to receive both transfer_requests, one from the path to the source and one from the path to the recipient.</t>
<t>Create an updated certificate for the CA on the path from the swing point to the transfer recipient. Publish this certificate in the swing point's publication point and send the updated certificate to the child CA using a transfer_response message. This updated certificate MUST have the same INRs as the certificate it replaces, plus the INRs specified in the TAO. (The swing point MUST still control the INRs being transferred, but this is a side effect of its normal certificate issuance process.)</t>
</list>
</t>
<t>Should a swing point receive an error code 1403 message from the CA in the recipient path, the swing point must forward the error code to the CA on the source path, indicating a cancellation of the transfer. </t>
</section>

<section title="Transfer Authorization Object" anchor="TAO">
<t>The TAO is encapsulated in a CMS object as defined in <xref target="RFC6492"/> Section 3.1.</t>
<section title="TAO Type">
<t>TAO OID TBD</t>
</section>
<section title="TAO Validation" anchor="sec_tao_validate">

<t>The TAO must be validated by each participant in the process. The creator of the TAO MUST validate the TAO after creation. All CAs that receive a Transfer Request MUST perform the following actions:
<list style="numbers">
<t>Determine that the TAO is valid as defined by the steps in  <xref target="RFC6488"/> Section 3.</t>
<t>Verify that either the transferFromSKI or the transferToSKI (or both) correspond to CAs that are descendants of this CA
<list style="empty">
<t>Note: This requires that the transfer recipient hold some address space and thus hold a valid CA Certificate before this process is initiated. </t>
</list>
</t>
<t>Verify that the transferFromSKI and the transferToSKI SKIs are valid, corresponding to the SKI extension of a CA within the RPKI, and unique, such that only one CA has an SKI extension that matches each of these values. (This check SHOULD be performed using the RPKI data acquired by the participant in its role as a relying party <xref target="RFC6480"/>.)</t>
<t>The parent of the source checks that the source holds the INRs in question. Each CA above that checks that the INRs are held by the CA that made the request.</t>
</list>
</t>
</section>
</section>

<section title="ASN.1 Specification of the TAO">

<t>
<figure>
<artwork> TransferAuthorization ::= SEQUENCE {
   transferFromSKI OCTET STRING,
   transferToSKI OCTET STRING,
   ipAddrBlocks [0] IPAddrBlocks OPTIONAL,
   asIdentifiers [1] ASIdentifiers OPTIONAL,
   liveXfer BOOLEAN DEFAULT FALSE,
   overlapPeriod INTEGER OPTIONAL
}</artwork>
</figure>
Either ipAddrBlocks or asIdentifiers, or both, MUST be included.</t>
<section title="transferFromSKI">
<t>The transferFromSKI MUST be equal to the SKI of the CA that holds the resources.</t>
</section>
<section title="transferToSKI">
<t>The transferToSKI MUST be equal to the SKI in a valid CA within the RPKI.</t>
</section>
<section title="ipAddrBlocks">
<t>IPAddrBlocks is specified in <xref target="RFC3779"></xref> Section 2. If the ipAddrBlocks attribute is included, it MUST NOT be empty and it MUST NOT have any resources marked as inherit.  </t>
</section>
<section title="asIdentifiers">
<t>ASIdentifiers is specified in <xref target="RFC3779"></xref> Section 3. If the asIdentifiers attribute is included, it MUST NOT be empty and the inherit flag MUST NOT be TRUE.</t>
</section>
<section title="liveXfer">
<t>This flag is set TRUE only for a transfer of live resources.</t>
</section>
<section title="overlapPeriod">
<t>overlapPeriod is the minimum number of seconds which the source and recipient MUST both hold the INRs. This field MUST hold a non-zero number for live transfers. The value MUST be omitted for transfers of unused space. Thus this field is present only if liveXfer is TRUE.</t>
</section>
</section>

<section title="Common Message Format">
<t>This document defines version 2 of the Common Message Format for the up/down protocol. Version 1 is defined in <xref target="RFC6492"/>. The format in version 2 is identical to version 1, but with several added attributes, defined in <xref target="inr_transfer"/>, and one additional constraint defined in <xref target="ee_constraint"></xref>. The checks specified in <xref target="RFC6492"/> Section 3.2 still apply and MUST be applied.</t>
</section>
<section title="End Entity Certificate Constraint" anchor="ee_constraint">
<t>This section corresponds to Section 3.1.1.4 in <xref target="RFC6492"></xref>. The End Entity (EE) certificate that is required here MUST have its resources marked as inherit. This convention is imposed to ensure that this certificate remains valid during the life of the TAO before, during, and after the transfer takes place.</t>
</section>
<section title="INR Transfer" anchor="inr_transfer">
<section title="Transfer">
<t>This query is used for all requests and responses made during a transfer. This includes messages between the initial sender and its parent, the receiver and its parent, and between each intermediate CA and its parent.</t>

<section title="Request" anchor="transfer_request">
<t>The value of the message "type" element for this request is:
<list>
<t>type="transfer_request"</t>
</list>
</t>
<t>----------------------</t>
<figure>
<preamble>Payload:</preamble>
<artwork> <request
tao_url="url">
[tao]
</request>
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="tao_url:">
value is the pointer to the location where the INR source has published the TAO. </t>
<t hangText="[tao]">
value is the Base64 encoding of the DER-encoded TAO. After decoding, this object MUST be identical to the object published by the source in its publication point.</t>
</list>
</t>
</section>
<section title="Response" anchor="transfer_response">
<t>The value of the message "type" element for this response is:

<list style="empty">
<t>type="transfer_response"</t>
</list>
</t>

<t>--------------------</t>
<figure>
<preamble>
Payload:
</preamble>
<artwork>
<class
tao_url="url"
cert_url="url"
resource_set_as="as resource set"
resource_set_ipv4="ipv4 resource set"
resource_set_ipv6="ipv6 resource set"
resource_set_notafter="datetime"
suggested_sia_head="[directory uri]">
<certificate cert_url="url"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set" >
[certificate]
</certificate>
<issuer>[issuer's certificate]</issuer>
</class>
</artwork>
</figure>

<t>In the case where the transfer is for live resources, not all responses will contain a certificate. For the CAs in the path with the INR source, an updated certificate, with the transferred INR removed, will be available once the transfer is complete and the INR source is prepared to relinquish control of the INRs. In contrast, the CAs along the path to the transfer recipient each receive a new certificate after the swing point receives and approves the messages from both the source and the recipient.</t>

<t>tao_url is identical to the tao_url in the request. The definition of all other attributes can be found in <xref target="RFC6492"/> Section 3.3.2.</t>
</section>
</section>
<section title="Request-Not-Performed Response">
<t>This response is an extension of <xref target="RFC6492"/> Section 3.6. In addition to the error codes defined there, Error Code 1401 is used when a self-signed CA determines that it is not an ancestor of both the source and the recipient. This indicates a failure of the automated transfer and a manual transfer must take place.</t>
</section>
<section title="Timeout Response">
<t>This response is an extension of <xref target="RFC6492"/> Section 3.6. In addition to the error codes defined there, Error Code 1402 is used when a CA determines that it has waited an excessive duration for a response from its parent. This indicates a failure of the transfer.</t>
</section>
<section title="Overlap Failure Response">
<t>This response is an extension of <xref target="RFC6492"/> Section 3.6. In addition to the error codes defined there, Error Code 1403 is used when a CA in the recipient path determines that the overlapPeriod value is less than the number of seconds between the current time and the notAfter value in the TAO. This indicates a failure of the transfer.</t>
</section>
</section>
<section title="XML Schema">
<t>
The following is a RELAX NG compact form schema <xref target="ISO.19757-2.2003"/> describing version 2 of this protocol.

<list>
<t>Note: As discussed in <xref target="W3C.REC-xml-names-20091208"/>, "the namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence.  It is not a goal that it be directly usable for retrieval of a schema (if any exists)".</t>
</list>
<figure>
<artwork>
default namespace = "http://www.apnic.net/specs/rescerts/up-down/"

grammar {
   resource_set_as = xsd:string {  maxLength="512000"
                                   pattern="[\-,0-9]*" }
   resource_set_ip4 = xsd:string { maxLength="512000"
                                   pattern="[\-,/.0-9]*" }
   resource_set_ip6 = xsd:string { maxLength="512000"
                                   pattern="[\-,/:0-9a-fA-F]*" }


   class_name = xsd:token { minLength="1" maxLength="1024" }
   ski = xsd:token { minLength="27" maxLength="1024" }
   label = xsd:token { minLength="1" maxLength="1024" }
   cert_url = xsd:string { minLength="10" maxLength="4096" }
   base64_binary = xsd:base64Binary { minLength="4"
                                      maxLength="512000" }
   tao_url = xsd:string { minLength="10" maxLength="4096" }

   start = element message {
      attribute version { xsd:positiveInteger {
                                           maxInclusive="1" } },
      attribute sender { label },
      attribute recipient { label },
      payload
   }

   payload |= attribute type { "list" }, list_request
   payload |= attribute type { "list_response"}, list_response
   payload |= attribute type { "issue" }, issue_request
   payload |= attribute type { "issue_response"}, issue_response
   payload |= attribute type { "revoke" }, revoke_request
   payload |= attribute type { "revoke_response"}, revoke_response
   payload |= attribute type { "error_response"}, error_response
   payload |= attribute type { "transfer_response"}, 
                                transfer_response

   list_request = empty
   list_response = class*

   class = element class {
     attribute class_name { class_name },
     attribute cert_url { cert_url },
     attribute resource_set_as { resource_set_as },
     attribute resource_set_ipv4 { resource_set_ip4 },
     attribute resource_set_ipv6 { resource_set_ip6 },
     attribute resource_set_notafter { xsd:dateTime },
     attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
                                           pattern="rsync://.+"} }?,
     element certificate {
       attribute cert_url { cert_url },
       attribute req_resource_set_as { resource_set_as }?,
       attribute req_resource_set_ipv4 { resource_set_ip4 }?,
       attribute req_resource_set_ipv6 { resource_set_ip6 }?,
       base64_binary
     }*,
     element issuer { base64_binary }
   }

   issue_request = element request {
     attribute class_name { class_name },
     attribute req_resource_set_as { resource_set_as }?,
     attribute req_resource_set_ipv4 { resource_set_ip4 }?,
     attribute req_resource_set_ipv6 { resource_set_ip6 }?,
     base64_binary
   }
   issue_response = class

   revoke_request = revocation
   revoke_response = revocation

   revocation = element key {
      attribute class_name { class_name },
      attribute ski { ski }
   }

   error_response =
     element status { xsd:positiveInteger { maxInclusive="9999" } },
     element description { attribute xml:lang { xsd:language },
                               xsd:string { maxLength="1024" } }*
   }

   transfer_request = element request {
     attribute tao_url { tao_url },
     element tao { base64_binary }
   }
   
   transfer_response = element response {
      attribute tao_url { tao_url }, 
      attribute cert_url { cert_url },
      attribute resource_set_as { resource_set_as },
      attribute resource_set_ipv4 { resource_set_ip4 },
      attribute resource_set_ipv6 { resource_set_ip6 },
      attribute resource_set_notafter { xsd:dateTime },
      attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
                                            pattern="rsync://.+"} }?,
      element certificate {
         attribute cert_url { cert_url },
         attribute req_resource_set_as { resource_set_as }?,
         attribute req_resource_set_ipv4 { resource_set_ip4 }?,
         attribute req_resource_set_ipv6 { resource_set_ip6 }?,
         base64_binary
      }*,
      element issuer { base64_binary }
   }</artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations">
<t>The checks described at each stage are designed to ensure that these four security goals are met:
<list style="symbols">
<t>the TAO was generated by the indicated INR source, that source holds the INRs being transferred, and the TAO has not been modified by another party</t>
<t>the transfer recipient is the intended recipient of the resources as per the INR source</t>
<t>each CA that processes a transfer request either holds the resources being transferred, or it is on the path between the swing point and the transfer recipient</t>
<t>each CA along the path approved the transfer (or has rejected it)</t>
</list>
</t>

<t>Up/down protocol messages contain a time-based anti-reply feature, so replays of these signed messages can be detected. If a request message is redirected, a CA receiving it will detect and reject this because the request will not be from one of its children. A redirected response message also will be detected because the response will not be from the child's immediate parent. Because all messages (both requests and responses) are contained within a CMS object, the sender of a message is validated through signature verification.</t>

<t>For live transfers, the source initiates the relinquishment of the INRs that were transferred. If they fail to initiate the relinquishment in a timely manner, the recipient may choose to contact any or all of the source's ancestors (up to the swing point) to pursue a forced relinquishment of resources. Any legal or contractual processes used are outside the scope of this document.</t>
</section>
<section title="IANA Considerations">
<t>An OID is requested for the TAO object defined above.</t>
</section>
<section title="Acknowledgements">
<t>The author would like to acknowledge the valued contribution of Steve Kent for providing a top level description of the TAO protocol, David Mandelberg for his contributions to the security of the protocol, and the authors of the rpki-updown protocol (<xref target="RFC6492"/>) Geoff Huston, Robert Loomans, Byron Ellacott, and Rob Austein.</t>
</section>
</middle>

<back>

<references title="Normative References">
&rfc6492;
&rfc2119;
&rfc3779;
&rfc6481;
&rfc6488;
</references>
<references title="Informative References">
&xml;
&rfc6480;
<reference anchor="ISO.19757-2.2003">
<front>
<title>Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG</title>
<author><organization>International Organization for Standardization</organization></author>
<date month="December" year="2003"/></front>
<seriesInfo name="ISO" value="International Standard 19757-2"/></reference>
</references>
</back>
</rfc>