draft-ietf-sidr-publication-07.txt   draft-ietf-sidr-publication-08.txt 
Network Working Group S. Weiler Network Working Group S. Weiler
Internet-Draft Parsons Internet-Draft Parsons
Intended status: Standards Track A. Sonalker Intended status: Standards Track A. Sonalker
Expires: March 28, 2016 Battelle Memorial Institute Expires: September 22, 2016 TowerSec
R. Austein R. Austein
Dragon Research Labs Dragon Research Labs
September 25, 2015 March 21, 2016
A Publication Protocol for the Resource Public Key Infrastructure (RPKI) A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-publication-07 draft-ietf-sidr-publication-08
Abstract Abstract
This document defines a protocol for publishing Resource Public Key This document defines a protocol for publishing Resource Public Key
Infrastructure (RPKI) objects. Even though the RPKI will have many Infrastructure (RPKI) objects. Even though the RPKI will have many
participants issuing certificates and creating other objects, it is participants issuing certificates and creating other objects, it is
operationally useful to consolidate the publication of those objects. operationally useful to consolidate the publication of those objects.
This document provides the protocol for doing so. This document provides the protocol for doing so.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4 2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4
2.2. General Operation . . . . . . . . . . . . . . . . . . . . 4 2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 4
2.3. Publication and Withdrawal . . . . . . . . . . . . . . . 5 2.3. Listing the repository . . . . . . . . . . . . . . . . . 5
2.4. Listing the repository . . . . . . . . . . . . . . . . . 5 2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 6
2.5. Error handling . . . . . . . . . . . . . . . . . . . . . 6 2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7
2.6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 7
2.7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 8
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. <publish/> Query, No Existing Object . . . . . . . . . . 10 3.1. <publish/> Query, No Existing Object . . . . . . . . . . 9
3.2. <publish/> Query, Overwriting Existing Object . . . . . . 10 3.2. <publish/> Query, Overwriting Existing Object . . . . . . 10
3.3. <publish/> Reply . . . . . . . . . . . . . . . . . . . . 10 3.3. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 10
3.4. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 10 3.4. <success/> Reply . . . . . . . . . . . . . . . . . . . . 10
3.5. <withdraw/> Reply . . . . . . . . . . . . . . . . . . . . 11 3.5. <report_error/> With Optional Elements . . . . . . . . . 10
3.6. <report_error/> With Optional Elements . . . . . . . . . 11 3.6. <report_error/> Without Optional Elements . . . . . . . . 11
3.7. <report_error/> Without Optional Elements . . . . . . . . 11 3.7. Error Handling With Multi-Element Queries . . . . . . . . 11
3.8. Error Handling With Multi-Element Queries . . . . . . . . 11 3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 11
3.8.1. Multi-Element Query . . . . . . . . . . . . . . . . . 11 3.7.2. Successful Multi-Element Response . . . . . . . . . . 12
3.8.2. Successful Multi-Element Response . . . . . . . . . . 12 3.7.3. Failure Multi-Element Response, First Error Only . . 12
3.8.3. Failure Multi-Element Response . . . . . . . . . . . 13 3.7.4. Failure Multi-Element Response, All Errors . . . . . 13
3.8. <list/> Query . . . . . . . . . . . . . . . . . . . . . . 14
3.9. <list/> Reply . . . . . . . . . . . . . . . . . . . . . . 14
4. Operational Considerations . . . . . . . . . . . . . . . . . 14 4. Operational Considerations . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
skipping to change at page 3, line 35 skipping to change at page 3, line 37
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
"Publication engine" and "publication server" are used "Publication engine" and "publication server" are used
interchangeably to refer to the server providing the service interchangeably to refer to the server providing the service
described in this document. described in this document.
"Business Public Key Infrastructure" ("Business PKI" or "BPKI") "Business Public Key Infrastructure" ("Business PKI" or "BPKI")
refers to a PKI, separate from the RPKI, used to authenticate clients refers to a PKI, separate from the RPKI, used to authenticate clients
to the publication engine. We use the term "Business PKI" here to the publication engine. We use the term "Business PKI" here
because an internet registry might already have a PKI for because an Internet registry might already have a PKI for
authenticating its clients and might wish to reuse that PKI for this authenticating its clients and might wish to reuse that PKI for this
protocol. There is, however, no requirement to reuse such a PKI. protocol. There is, however, no requirement to reuse such a PKI.
2. Protocol Specification 2. Protocol Specification
The publication protocol uses XML messages wrapped in signed CMS The publication protocol uses XML messages wrapped in signed CMS
messages, carried over HTTP transport. messages, carried over HTTP transport.
The publication protocol uses a simple request/response interaction. The publication protocol uses a simple request/response interaction.
The client passes a request to the server, and the server generates a The client passes a request to the server, and the server generates a
skipping to change at page 4, line 11 skipping to change at page 4, line 14
object as the body. The server's response will similarly be the body object as the body. The server's response will similarly be the body
of the response with a content type of "application/rpki- of the response with a content type of "application/rpki-
publication". publication".
The content of the POST and the server's response will be a well- The content of the POST and the server's response will be a well-
formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID =
1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492].
2.1. Common XML Message Format 2.1. Common XML Message Format
The XML schema for this protocol is below in Section 2.7. The basic The XML schema for this protocol is below in Section 2.6. The basic
XML message format looks like this: XML message format looks like this:
<msg <msg
type="query" type="query"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<!-- Zero or more PDUs --> <!-- Zero or more PDUs -->
</msg> </msg>
<msg <msg
type="reply" type="reply"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<!-- Zero or more PDUs --> <!-- Zero or more PDUs -->
</msg> </msg>
Common attributes: Common attributes:
version: The value of this attribute is the version of this version: The value of this attribute is the version of this
protocol. This document describes version 3. protocol. This document describes version 4.
type: The possible values of this attribute are "reply" and "query". type: The possible values of this attribute are "reply" and "query".
A query PDU may be one of three types: <publish/>, <withdraw/>, or A query PDU may be one of three types: <publish/>, <withdraw/>, or
<list/>. <list/>.
A reply PDU may be one of four types: <publish/>, <withdraw/>, A reply PDU may be one of three types: <success/>, <list/>, or
<list/>, or <report_error/>. <report_error/>.
Each of these PDUs may include an optional tag to facilitate bulk
operation. If a tag is set in a query PDU, the corresponding
reply(s) or error(s) MUST have the tag attribute set to the same
value.
2.2. General Operation
Processing of a query message is handled atomically: either the The <publish/> and <withdraw/> PDUs include a tag to facilitate bulk
entire query succeeds or none of it does. When a query message operation.
contains multiple PDUs, failure of any PDU may require the server to
roll back actions triggered by earlier PDUs.
2.3. Publication and Withdrawal 2.2. Publication and Withdrawal
The publication protocol uses a common message format to request The publication protocol uses a common message format to request
publication of any RPKI object. This format was chosen specifically publication of any RPKI object. This format was chosen specifically
to allow this protocol to accommodate new types of RPKI objects to allow this protocol to accommodate new types of RPKI objects
without needing changes to this protocol. without needing changes to this protocol.
Both the <publish/> and <withdraw/> PDUs have a payload of an Both the <publish/> and <withdraw/> PDUs have a payload of a tag and
optional tag and a URI. The <publish/> query also contains the DER a URI. The <publish/> query also contains the DER object to be
object to be published, encoded in Base64. published, encoded in Base64.
Both the <publish/> and <withdraw/> PDUs also have a "hash" Both the <publish/> and <withdraw/> PDUs also have a "hash"
attribute, which carries a hash of an existing object at the attribute, which carries a hash of an existing object at the
specified repository URI. For <withdraw/> PDUs, the hash is specified repository URI. For <withdraw/> PDUs, the hash is
mandatory, as this operation makes no sense if there is no existing mandatory, as this operation makes no sense if there is no existing
object to withdraw. For <publish/> PDUs, the hash MUST be present if object to withdraw. For <publish/> PDUs, the hash MUST be present if
the publication operation is overwriting an existing object, and MUST the publication operation is overwriting an existing object, and MUST
be omitted if this publication operation is writing to a new URI be omitted if this publication operation is writing to a new URI
where no prior object exists. Presence of an object when no hash where no prior object exists. Presence of an object when no "hash"
attribute is specified is an error, as is absence of the hash attribute is specified is an error, as is absence of the "hash"
attribute or an incorrect hash value when an object is present. Any attribute or an incorrect hash value when an object is present. Any
such errors MUST be reported using the <report_error/> PDU. such errors MUST be reported using the <report_error/> PDU.
The hash algorithm is SHA-256 [SHS], to simplify comparison of The hash algorithm is SHA-256 [SHS], to simplify comparison of
publication protocol hashes with RPKI manifest hashes. publication protocol hashes with RPKI manifest hashes.
The intent behind the hash attribute is to allow the client and The intent behind the "hash" attribute is to allow the client and
server to detect any disagreements about the effect that a <publish/> server to detect any disagreements about the effect that a <publish/>
or <withdraw/> PDU will have on the repository. or <withdraw/> PDU will have on the repository.
Note that every publish and withdraw action requires a new manifest, Note that every publish and withdraw action requires a new manifest,
thus every publish or withdraw action will involve at least two thus every publish or withdraw action will involve at least two
objects. objects.
2.4. Listing the repository Processing of a query message is handled atomically: either the
entire query succeeds or none of it does. When a query message
contains multiple PDUs, failure of any PDU may require the server to
roll back actions triggered by earlier PDUs.
When a query messages containing <publish/> and/or <withdraw/> PDUs
succeeds, a single <success/> reply is returned.
When a query fails, one or more <report_error/> reply PDUs are
generated. Typically, only one <report_error/> reply is generated,
corresponding to the first query PDU that failed. Servers are
permitted to return multiple <report_error/> PDUs.
2.3. Listing the repository
The <list/> operation allows the client to ask the server for a The <list/> operation allows the client to ask the server for a
complete listing of objects which the server believes the client has complete listing of objects which the server believes the client has
published. This is intended primarily to allow the client to recover published. This is intended primarily to allow the client to recover
upon detecting (probably via use of the "hash" attribute, see upon detecting (probably via use of the "hash" attribute, see
Section 2.3) that they have somehow lost synchronization. Section 2.2) that they have somehow lost synchronization.
The <list/> query consists of a single PDU. The <list/> query consists of a single PDU. A <list/> query must be
the only PDU in a query - it may not be combined with any <publish/>
or <withdraw/> queries.
The <list/> reply consists of zero or more PDUs, one per object The <list/> reply consists of zero or more PDUs, one per object
published in this repository by this client, each PDU conveying the published in this repository by this client, each PDU conveying the
URI and hash of one published object. URI and hash of one published object.
2.5. Error handling 2.4. Error handling
Errors are handled at two levels. Errors are handled at two levels.
Errors that make it impossible to decode a query or encode a response Errors that make it impossible to decode a query or encode a response
are handled at the HTTP layer. 4xx and 5xx HTTP response codes are handled at the HTTP layer. 4xx and 5xx HTTP response codes
indicate that something bad happened. indicate that something bad happened.
In all other cases, errors result in an XML <report_error/> PDU which In all other cases, errors result in an XML <report_error/> PDU.
takes the place of the expected protocol response PDU. Like the rest Like the rest of this protocol, <report_error/> PDUs are CMS-signed
of this protocol, <report_error/> PDUs are CMS-signed XML messages XML messages and thus can be archived to provide an audit trail.
and thus can be archived to provide an audit trail.
<report_error/> PDUs only appear in replies, never in queries. <report_error/> PDUs only appear in replies, never in queries.
Like all other reply PDUs, if a "tag" attribute was set on the query The "tag" attribute of the <report_error/> PDU associated with a
that generated the error, the <report_error/> PDU MUST have its tag <publish/> or <withdraw/> PDU MUST be set to the same value as the
attribute set to the same value. "tag" attribute in the PDU which generated the error. A client can
use the "tag" attribute to determine which PDU caused processing of
an update to fail.
The error itself is conveyed in the error_code attribute. The value The error itself is conveyed in the "error_code" attribute. The
of this attribute is a token indicating the specific error that value of this attribute is a token indicating the specific error that
occurred. occurred.
The body of the <report_error/> element contains two sub-elements: The body of the <report_error/> element contains two sub-elements:
1. An optional text element <error_text/>, which if present, 1. An optional text element <error_text/>, which if present,
contains a text string with debugging information intended for contains a text string with debugging information intended for
human consumption. human consumption.
2. An optional element <failed_pdu/>, which, if present, contains a 2. An optional element <failed_pdu/>, which, if present, contains a
verbatim copy of the query PDU whose failure triggered the verbatim copy of the query PDU whose failure triggered the
<report_error/> PDU. The quoted element must be syntactically <report_error/> PDU. The quoted element must be syntactically
valid. valid.
The position of a <report_error/> element in a reply corresponds to See Section 3.7 for examples of a multi-element query and responses.
the point in processing the query message where the error occurred.
In the simple case of a query message containing only a single
element, the <report_error/> element will be the only element in the
reply. If, however, the query message contains more than one
element, the <report_error/> element may be preceeded by normal
responses indicating operations that would have succeeded.
There are several ways that a client can match up elements in a
response message with the corresponding elements in the query
message:
o For a one-element query, this is trivial.
o For multi-element queries, the simplest way of matching resposes
uses the optional tag attribute. The protocol requires tags from
query elements to be copied into reply elements, so simply giving
each query element a unique tag will suffice.
o If for some reason the client implementation is not able or
willing to use unique tags within a multi-element query message,
the client can still match queries to responses by counting
elements in the reply message. This approach is not recommended.
See Section 3.8 for examples of a multi-element query and responses.
2.6. Error Codes 2.5. Error Codes
These are the defined error codes as well as some discussion of each. These are the defined error codes as well as some discussion of each.
Text similar to these descriptions may be sent in an <error_text/> Text similar to these descriptions may be sent in an <error_text/>
element to help explain the error encountered. element to help explain the error encountered.
xml_error: Encountered an XML problem. Note that some XML errors
may be severe enough to require error reporting at the HTTP layer,
instead. Implementations MAY choose to report any or all XML
errors at the HTTP layer.
permission_failure: Client does not have permission to update this permission_failure: Client does not have permission to update this
URI. URI.
bad_cms_signature: Bad CMS signature. bad_cms_signature: Bad CMS signature.
object_already_present: An object is already present at this URI, object_already_present: An object is already present at this URI,
yet a hash attribute was not specified. A hash attribute must be yet a "hash" attribute was not specified. A "hash" attribute must
specified when overwriting or deleting an object. Perhaps client be specified when overwriting or deleting an object. Perhaps
and server are out of sync? client and server are out of sync?
no_object_present: There is no object present at this URI, yet a no_object_present: There is no object present at this URI, yet a
hash attribute was specified. Perhaps client and server are out "hash" attribute was specified. Perhaps client and server are out
of sync? of sync?
no_object_matching_hash The hash attribute supplied does not match no_object_matching_hash The "hash" attribute supplied does not match
the hash attribute of the object at this URI. Perhaps client and the "hash" attribute of the object at this URI. Perhaps client
server are out of sync? and server are out of sync?
consistency_problem: Server detected an update that looks like it consistency_problem: Server detected an update that looks like it
will cause a consistency problem (e.g. an object was deleted, but will cause a consistency problem (e.g. an object was deleted, but
the manifest was not updated). Note that a server is not required the manifest was not updated). Note that a server is not required
to make such checks. Indeed, it may be unwise for a server to do to make such checks. Indeed, it may be unwise for a server to do
so. This error code just provides a way for the server to explain so. This error code just provides a way for the server to explain
its (in-)action. its (in-)action.
other_error: A meteor fell on the server. other_error: A meteor fell on the server.
2.7. XML Schema 2.6. XML Schema
The following is a RelaxNG compact form schema describing the The following is a RelaxNG compact form schema describing the
Publication Protocol. Publication Protocol.
# $Id: rpki-publication.rnc 3407 2015-09-25 21:05:28Z sra $ # $Id: rpki-publication.rnc 3595 2016-03-21 21:31:37Z sra $
# RelaxNG schema for RPKI publication protocol. # RelaxNG schema for RPKI publication protocol.
default namespace = default namespace =
"http://www.hactrn.net/uris/rpki/publication-spec/" "http://www.hactrn.net/uris/rpki/publication-spec/"
# This is version 3 of the protocol. # This is version 4 of the protocol.
version = "3" version = "4"
# Top level PDU is either a query or a reply. # Top level PDU is either a query or a reply.
start |= element msg { start |= element msg {
attribute version { version }, attribute version { version },
attribute type { "query" }, attribute type { "query" },
query_elt* query_elt*
} }
start |= element msg { start |= element msg {
attribute version { version }, attribute version { version },
attribute type { "reply" }, attribute type { "reply" },
reply_elt* reply_elt*
} }
# PDUs allowed in queries and replies.
query_elt = publish_query | withdraw_query | list_query
reply_elt = publish_reply | withdraw_reply | list_reply | error_reply
# Tag attributes for bulk operations. # Tag attributes for bulk operations.
tag = attribute tag { xsd:token { maxLength="1024" } } tag = attribute tag { xsd:token { maxLength="1024" } }
# Base64 encoded DER stuff. # Base64 encoded DER stuff.
base64 = xsd:base64Binary base64 = xsd:base64Binary
# Publication URIs. # Publication URIs.
uri = attribute uri { xsd:anyURI { maxLength="4096" } } uri = attribute uri { xsd:anyURI { maxLength="4096" } }
# Digest of an existing object (hexadecimal). # Digest of an existing object (hexadecimal).
hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } } hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } }
# Error codes. # Error codes.
error |= "xml_error"
error |= "permission_failure" error |= "permission_failure"
error |= "bad_cms_signature" error |= "bad_cms_signature"
error |= "object_already_present" error |= "object_already_present"
error |= "no_object_present" error |= "no_object_present"
error |= "no_object_matching_hash" error |= "no_object_matching_hash"
error |= "consistency_problem" error |= "consistency_problem"
error |= "other_error" error |= "other_error"
# <publish/> element # <publish/> query
publish_query = element publish { tag?, uri, hash?, base64 } query_elt |= element publish { tag, uri, hash?, base64 }
publish_reply = element publish { tag?, uri } # <withdraw/> query
# <withdraw/> element query_elt |= element withdraw { tag, uri, hash }
withdraw_query = element withdraw { tag?, uri, hash } # <success/> reply
withdraw_reply = element withdraw { tag?, uri }
# <list/> element reply_elt |= element success { empty }
list_query = element list { tag? } # <list/> query and reply
list_reply = element list { tag?, uri, hash }
# <report_error/> element query_elt |= element list { empty }
reply_elt |= element list { uri, hash }
error_reply = element report_error { # <report_error/> reply
reply_elt |= element report_error {
tag?, tag?,
attribute error_code { error }, attribute error_code { error },
element error_text { xsd:string { maxLength="512000" }}?, element error_text { xsd:string { maxLength="512000" }}?,
element failed_pdu { query_elt }? element failed_pdu { query_elt }?
} }
3. Examples 3. Examples
Following are examples of various queries and the corresponding Following are examples of various queries and the corresponding
replies for the RPKI publication protocol. replies for the RPKI publication protocol.
Note the authors have taken liberties with the Base64, hash, and URI Note the authors have taken liberties with the Base64, hash, and URI
text in these examples in the interest of making the examples fit text in these examples in the interest of making the examples fit
nicely into RFC text format. nicely into RFC text format.
3.1. <publish/> Query, No Existing Object 3.1. <publish/> Query, No Existing Object
<msg <msg
type="query" type="query"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<publish <publish
uri="rsync://wombat.example/Alice/60d730635fce156f.cer"> tag="foo"
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
</publish> </publish>
</msg> </msg>
3.2. <publish/> Query, Overwriting Existing Object 3.2. <publish/> Query, Overwriting Existing Object
<msg <msg
type="query" type="query"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<publish <publish
hash="60d730635fce156f" hash="01a97a70ac477f06"
uri="rsync://wombat.example/Alice/60d730635fce156f.cer"> tag="foo"
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
</publish> </publish>
</msg> </msg>
3.3. <publish/> Reply 3.3. <withdraw/> Query
<msg
type="reply"
version="3"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<publish
uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/>
</msg>
3.4. <withdraw/> Query
<msg <msg
type="query" type="query"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<withdraw <withdraw
hash="60d730635fce156f" hash="01a97a70ac477f06"
uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/> tag="foo"
uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"/>
</msg> </msg>
3.5. <withdraw/> Reply 3.4. <success/> Reply
<msg <msg
type="reply" type="reply"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<withdraw <success/>
uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/>
</msg> </msg>
3.6. <report_error/> With Optional Elements 3.5. <report_error/> With Optional Elements
<msg <msg
type="reply" type="reply"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<report_error <report_error
error_code="no_object_matching_hash"> error_code="no_object_matching_hash"
tag="foo">
<error_text> <error_text>
Can't delete an object I don't have Can't delete an object I don't have
</error_text> </error_text>
<failed_pdu> <failed_pdu>
<publish <publish
hash="60d730635fce156f" hash="01a97a70ac477f06"
uri="rsync://wombat.example/Alice/60d730635fce156f.cer"> tag="foo"
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
</publish> </publish>
</failed_pdu> </failed_pdu>
</report_error> </report_error>
</msg> </msg>
3.7. <report_error/> Without Optional Elements 3.6. <report_error/> Without Optional Elements
<msg <msg
type="reply" type="reply"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<report_error <report_error
error_code="object_already_present"/> error_code="object_already_present"
tag="foo"/>
</msg> </msg>
3.8. Error Handling With Multi-Element Queries 3.7. Error Handling With Multi-Element Queries
3.8.1. Multi-Element Query 3.7.1. Multi-Element Query
<msg <msg
type="query" type="query"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<publish <publish
tag="Alice" tag="Alice"
uri="rsync://wombat.example/Alice/3bc51062973c458d.cer"> uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
QWxpY2U= SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
</publish> </publish>
<withdraw <withdraw
hash="cd9fb1e148ccd844" hash="f46a4198efa3070e"
tag="Bob" tag="Bob"
uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/> uri="rsync://wombat.example/Bob/f46a4198efa3070e.cer"/>
<publish <publish
tag="Carol" tag="Carol"
uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer"> uri="rsync://wombat.example/Carol/32e0544eeb510ec0.cer">
Q2Fyb2w= SGVsbG8sIG15IG5hbWUgaXMgQ2Fyb2w=
</publish> </publish>
<list/>
<withdraw <withdraw
hash="809a721743350c0c" hash="421ee4ac65732d72"
tag="Dave" tag="Dave"
uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/> uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
<publish <publish
tag="Eve" tag="Eve"
uri="rsync://wombat.example/Eve/b9bae658d9657985.cer"> uri="rsync://wombat.example/Eve/9dd859b01e5c2ebd.cer">
RXZl SGVsbG8sIG15IG5hbWUgaXMgRXZl
</publish> </publish>
</msg> </msg>
3.8.2. Successful Multi-Element Response 3.7.2. Successful Multi-Element Response
<msg <msg
type="reply" type="reply"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<publish <success/>
tag="Alice"
uri="rsync://wombat.example/Alice/3bc51062973c458d.cer"/>
<withdraw
tag="Bob"
uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/>
<publish
tag="Carol"
uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer"/>
<list
hash="f842c3e1858df8c8"
uri="rsync://wombat.example/Fee/f842c3e1858df8c8.cer"/>
<list
hash="b139ca23414476bb"
uri="rsync://wombat.example/Fie/b139ca23414476bb.cer"/>
<list
hash="1995e9544ba80191"
uri="rsync://wombat.example/Foe/1995e9544ba80191.cer"/>
<list
hash="9c00b310c10a022c"
uri="rsync://wombat.example/Fum/9c00b310c10a022c.cer"/>
<withdraw
tag="Dave"
uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/>
<publish
tag="Eve"
uri="rsync://wombat.example/Eve/b9bae658d9657985.cer"/>
</msg> </msg>
3.8.3. Failure Multi-Element Response 3.7.3. Failure Multi-Element Response, First Error Only
<msg <msg
type="reply" type="reply"
version="3" version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<publish
tag="Alice"
uri="rsync://wombat.example/Alice/3bc51062973c458d.cer"/>
<withdraw
tag="Bob"
uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/>
<publish
tag="Carol"
uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer"/>
<list
hash="f842c3e1858df8c8"
uri="rsync://wombat.example/Fee/f842c3e1858df8c8.cer"/>
<list
hash="b139ca23414476bb"
uri="rsync://wombat.example/Fie/b139ca23414476bb.cer"/>
<list
hash="1995e9544ba80191"
uri="rsync://wombat.example/Foe/1995e9544ba80191.cer"/>
<list
hash="9c00b310c10a022c"
uri="rsync://wombat.example/Fum/9c00b310c10a022c.cer"/>
<report_error <report_error
error_code="no_object_matching_hash" error_code="no_object_matching_hash"
tag="Dave"> tag="Dave">
<failed_pdu> <failed_pdu>
<withdraw <withdraw
hash="809a721743350c0c" hash="421ee4ac65732d72"
tag="Dave" tag="Dave"
uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/> uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
</failed_pdu> </failed_pdu>
</report_error> </report_error>
</msg> </msg>
3.7.4. Failure Multi-Element Response, All Errors
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<report_error
error_code="no_object_matching_hash"
tag="Dave">
<failed_pdu>
<withdraw
hash="421ee4ac65732d72"
tag="Dave"
uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
</failed_pdu>
</report_error>
<report_error
error_code="object_already_present"
tag="Eve">
<failed_pdu>
<publish
tag="Eve"
uri="rsync://wombat.example/Eve/9dd859b01e5c2ebd.cer">
SGVsbG8sIG15IG5hbWUgaXMgRXZl
</publish>
</failed_pdu>
</report_error>
</msg>
3.8. <list/> Query
<msg
type="query"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<list/>
</msg>
3.9. <list/> Reply
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<list
hash="eb719b72f0648cf4"
uri="rsync://wombat.example/Fee/eb719b72f0648cf4.cer"/>
<list
hash="c7c50a68b7aa50bf"
uri="rsync://wombat.example/Fie/c7c50a68b7aa50bf.cer"/>
<list
hash="f222481ded47445d"
uri="rsync://wombat.example/Foe/f222481ded47445d.cer"/>
<list
hash="15b94e08713275bc"
uri="rsync://wombat.example/Fum/15b94e08713275bc.cer"/>
</msg>
4. Operational Considerations 4. Operational Considerations
There are two basic options open to the repository operator as to how There are two basic options open to the repository operator as to how
the publication tree is laid out. The first option is simple: each the publication tree is laid out. The first option is simple: each
publication client is given its own directory one level below the top publication client is given its own directory one level below the top
of the rsync module, and there is no overlap between the publication of the rsync module, and there is no overlap between the publication
spaces used by different clients. For example: spaces used by different clients. For example:
rsync://example.org/rpki/Alice/ rsync://example.org/rpki/Alice/
rsync://example.org/rpki/Bob/ rsync://example.org/rpki/Bob/
skipping to change at page 15, line 29 skipping to change at page 15, line 22
rsync://example.org/rpki/Alice/Bob/ rsync://example.org/rpki/Alice/Bob/
rsync://example.org/rpki/Alice/Bob/Carol/ rsync://example.org/rpki/Alice/Bob/Carol/
Preliminary measurement suggests that, in the case of large numbers Preliminary measurement suggests that, in the case of large numbers
of small publication directories, the time needed to set up and tear of small publication directories, the time needed to set up and tear
down individual rsync connections becomes significant, and that a down individual rsync connections becomes significant, and that a
properly optimized tree structure can reduce synchronization time by properly optimized tree structure can reduce synchronization time by
an order of magnitude. an order of magnitude.
The more complex tree structure does require careful attention to the The more complex tree structure does require careful attention to the
base_uri attribute values when setting up clients. In the example "base_uri" attribute values when setting up clients. In the example
above, assuming that Alice issues to Bob who in turn issues to Carol, above, assuming that Alice issues to Bob who in turn issues to Carol,
Alice has ceded control of a portion of her publication space to Bob, Alice has ceded control of a portion of her publication space to Bob,
who has in turn ceded a portion of that to Carol, and the base_uri who has in turn ceded a portion of that to Carol, and the "base_uri"
attributes in the <client/> setup messages should reflect this. attributes in the <client/> setup messages should reflect this.
The details of how the repository operator determines that Alice has The details of how the repository operator determines that Alice has
given Bob permission to nest Bob's publication directory under given Bob permission to nest Bob's publication directory under
Alice's is outside the scope of this protocol. Alice's is outside the scope of this protocol.
5. IANA Considerations 5. IANA Considerations
IANA is asked to register the application/rpki-publication MIME media IANA is asked to register the application/rpki-publication MIME media
type as follows: type as follows:
skipping to change at page 17, line 12 skipping to change at page 17, line 12
Accordingly, as in most PKIs, good key management practices are Accordingly, as in most PKIs, good key management practices are
important. important.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
5652, STD 70, September 2009. RFC 5652, STD 70, September 2009.
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
Protocol for Provisioning Resource Certificates", RFC Protocol for Provisioning Resource Certificates",
6492, February 2012. RFC 6492, February 2012.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-4, March 2012, Hash Standard", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
7.2. Informative References 7.2. Informative References
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
Authors' Addresses Authors' Addresses
Samuel Weiler Samuel Weiler
Parsons Parsons
Email: weiler@tislabs.com Email: weiler@tislabs.com
Anuja Sonalker Anuja Sonalker
Battelle Memorial Institute TowerSec Automotive Cyber Security
Email: sonalkera@battelle.org Email: asonalker@tower-sec.com
Rob Austein Rob Austein
Dragon Research Labs Dragon Research Labs
Email: sra@hactrn.net Email: sra@hactrn.net
 End of changes. 89 change blocks. 
223 lines changed or deleted 214 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/