draft-ietf-sidr-publication-12.txt | rfc8181.txt | |||
---|---|---|---|---|
Network Working Group S. Weiler | Internet Engineering Task Force (IETF) S. Weiler | |||
Internet-Draft W3C / MIT | Request for Comments: 8181 W3C / MIT | |||
Intended status: Standards Track A. Sonalker | Category: Standards Track A. Sonalker | |||
Expires: September 12, 2017 TowerSec | ISSN: 2070-1721 STEER Tech | |||
R. Austein | R. Austein | |||
Dragon Research Labs | Dragon Research Labs | |||
March 11, 2017 | July 2017 | |||
A Publication Protocol for the Resource Public Key Infrastructure (RPKI) | A Publication Protocol for the Resource Public Key Infrastructure (RPKI) | |||
draft-ietf-sidr-publication-12 | ||||
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. | |||
Even in cases where a certificate issuer runs their own publication | Even in cases where a certificate issuer runs its own publication | |||
repository, it can be useful to run the certificate engine itself on | repository, it can be useful to run the certificate engine itself on | |||
a different machine from the publication repository. This document | a different machine from the publication repository. This document | |||
defines a protocol which addresses these needs. | defines a protocol which addresses these needs. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on September 12, 2017. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc8181. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Protocol Specification . . . . . . . . . . . . . . . . . . . 5 | 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 5 | |||
2.1. Common XML Message Format . . . . . . . . . . . . . . . . 5 | 2.1. Common XML Message Format . . . . . . . . . . . . . . . . 6 | |||
2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 7 | 2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 7 | |||
2.3. Listing the repository . . . . . . . . . . . . . . . . . 8 | 2.3. Listing the Repository . . . . . . . . . . . . . . . . . 8 | |||
2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 8 | 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 9 | 2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 10 | 2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
3.1. <publish/> Query, No Existing Object . . . . . . . . . . 12 | 3.1. <publish/> Query, No Existing Object . . . . . . . . . . 12 | |||
3.2. <publish/> Query, Overwriting Existing Object . . . . . . 12 | 3.2. <publish/> Query, Overwriting Existing Object . . . . . . 12 | |||
3.3. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 12 | 3.3. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 13 | |||
3.4. <success/> Reply . . . . . . . . . . . . . . . . . . . . 12 | 3.4. <success/> Reply . . . . . . . . . . . . . . . . . . . . 13 | |||
3.5. <report_error/> With Optional Elements . . . . . . . . . 13 | 3.5. <report_error/> with Optional Elements . . . . . . . . . 13 | |||
3.6. <report_error/> Without Optional Elements . . . . . . . . 13 | 3.6. <report_error/> without Optional Elements . . . . . . . . 14 | |||
3.7. Error Handling With Multi-Element Queries . . . . . . . . 13 | 3.7. Error Handling with Multi-Element Queries . . . . . . . . 14 | |||
3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 13 | 3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 14 | |||
3.7.2. Successful Multi-Element Response . . . . . . . . . . 14 | 3.7.2. Successful Multi-Element Response . . . . . . . . . . 15 | |||
3.7.3. Failure Multi-Element Response, First Error Only . . 14 | 3.7.3. Failure Multi-Element Response, First Error Only . . 15 | |||
3.7.4. Failure Multi-Element Response, All Errors . . . . . 15 | 3.7.4. Failure Multi-Element Response, All Errors . . . . . 16 | |||
3.8. <list/> Query . . . . . . . . . . . . . . . . . . . . . . 16 | 3.8. <list/> Query . . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.9. <list/> Reply . . . . . . . . . . . . . . . . . . . . . . 16 | 3.9. <list/> Reply . . . . . . . . . . . . . . . . . . . . . . 17 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 19 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 18 | 6.2. Informative References . . . . . . . . . . . . . . . . . 20 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . 19 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
1. Introduction | 1. Introduction | |||
This document assumes a working knowledge of the Resource Public Key | This document assumes a working knowledge of the Resource Public Key | |||
Infrastructure (RPKI), which is intended to support improved routing | Infrastructure (RPKI), which is intended to support improved routing | |||
security on the Internet. See [RFC6480] for an overview of the RPKI. | security on the Internet. See [RFC6480] for an overview of the RPKI. | |||
In order to make participation in the RPKI easier, it is helpful to | In order to make participation in the RPKI easier, it is helpful to | |||
have a few consolidated repositories for RPKI objects, thus saving | have a few consolidated repositories for RPKI objects, thus saving | |||
every participant from the cost of maintaining a new service. | every participant from the cost of maintaining a new service. | |||
Similarly, relying parties using the RPKI objects will find it faster | Similarly, relying parties using the RPKI objects will find it faster | |||
and more reliable to retrieve the necessary set from a smaller number | and more reliable to retrieve the necessary set from a smaller number | |||
of repositories. | of repositories. | |||
These consolidated RPKI object repositories will in many cases be | These consolidated RPKI object repositories will in many cases be | |||
outside the administrative scope of the organization issuing a given | outside the administrative scope of the organization issuing a given | |||
RPKI object. In some cases, outsourcing operation of the repository | RPKI object. In some cases, outsourcing operation of the repository | |||
will be an explicit goal: some resource holders who strongly wish to | will be an explicit goal: some resource holders who strongly wish to | |||
control their own RPKI private keys may lack the resources to operate | control their own RPKI private keys may lack the resources to operate | |||
a 24x7 repository, or may simply not wish to do so. | a 24x7 repository or may simply not wish to do so. | |||
The operator of an RPKI publication repository may well be an | The operator of an RPKI publication repository may well be an | |||
Internet registry which issues certificates to its customers, but it | Internet registry which issues certificates to its customers, but it | |||
need not be; conceptually, operation of a an RPKI publication | need not be; conceptually, operation of an RPKI publication | |||
repository is separate from operation of RPKI CA. | repository is separate from operation of an RPKI Certification | |||
Authority (CA). | ||||
Even in cases where a resource holder operates both a certificate | Even in cases where a resource holder operates both a certificate | |||
engine and a publication repository, it can be useful to separate the | engine and a publication repository, it can be useful to separate the | |||
two functions, as they have somewhat different operational and | two functions, as they have somewhat different operational and | |||
security requirements. | security requirements. | |||
This document defines an RPKI publication protocol which allows | This document defines an RPKI publication protocol which allows | |||
publication either within or across organizational boundaries, and | publication either within or across organizational boundaries and | |||
which makes fairly minimal demands on either the CA engine or the | which makes fairly minimal demands on both the CA engine and the | |||
publication service. | publication service. | |||
The authentication and message integrity architecture of the | The authentication and message integrity architecture of the | |||
publication protocol is essentially identical to the architecture | publication protocol is essentially identical to the architecture | |||
used in [RFC6492], because the participants in this protocol are the | used in [RFC6492] because the participants in this protocol are the | |||
same CA engines as in RFC 6492; this allows reuse of the same | same CA engines as in RFC 6492; this allows reuse of the same | |||
"Business PKI" ("BPKI", see Section 1.2) infrastructure used to | "Business PKI" (BPKI) (see Section 1.2) infrastructure used to | |||
support RFC 6492. As in RFC 6492, authorization is a matter of | support RFC 6492. As in RFC 6492, authorization is a matter of | |||
external configuration: we assume that any given publication | external configuration: we assume that any given publication | |||
repository has some kind of policy controlling which certificate | repository has some kind of policy controlling which certificate | |||
engines are allowed to publish, modify, or withdraw particular RPKI | engines are allowed to publish, modify, or withdraw particular RPKI | |||
objects, most likely following the recommendation in [RFC6480] | objects, most likely following the recommendation in [RFC6480], | |||
Section 4.4, the details of this policy are a private matter between | Section 4.4; the details of this policy are a private matter between | |||
the operator of a certificate engine and the operator of the chosen | the operator of a certificate engine and the operator of the chosen | |||
publication repository. | publication repository. | |||
The following diagram attempts to convey where this publication | The following diagram attempts to convey where this publication | |||
protocol fits into the overall data flow between the certificate | protocol fits into the overall data flow between the certificate | |||
issuers and relying parties: | issuers and relying parties: | |||
+------+ +------+ +------+ | +------+ +------+ +------+ | |||
| CA | | CA | | CA | | | CA | | CA | | CA | | |||
+------+ +------+ +------+ | +------+ +------+ +------+ | |||
| | | Publication Protocol | | | | Publication protocol | |||
| | | Business relationship | | | | business relationship | |||
+-------+ | +--------+ perhaps set up by | +-------+ | +--------+ perhaps set up by | |||
| | | draft-ietf-sidr-rpki-oob-setup | | | | RFC 8183 | |||
+----v---v--v-----+ | +----v---v--v-----+ | |||
| | | | | | |||
| Publication | | | Publication | | |||
| Repository | | | Repository | | |||
| | | | | | |||
+-----------------+ Distribution protocols | +-----------------+ Distribution protocols | |||
| rsync or RRDP | | rsync or RRDP | |||
+--------------+----------------+ | +--------------+----------------+ | |||
| | | | | | | | |||
+-------v-----+ +------v------+ +------v------+ | +-------v-----+ +------v------+ +------v------+ | |||
| Relying | | Relying | | Relying | | | Relying | | Relying | | Relying | | |||
| Party | | Party | | Party | | | Party | | Party | | Party | | |||
+-------------+ +-------------+ +-------------+ | +-------------+ +-------------+ +-------------+ | |||
The publication protocol itself is not visible to relying parties: a | The publication protocol itself is not visible to relying parties: a | |||
relying party sees the public interface of the publication server, | relying party sees the public interface of the publication server, | |||
which is an rsync or RRDP ([I-D.ietf-sidr-delta-protocol]) server. | which is an rsync or RPKI Repository Delta Protocol (RRDP) [RFC8182] | |||
server. | ||||
Operators of certificate engines and publication repositories may | Operators of certificate engines and publication repositories may | |||
find [I-D.ietf-sidr-rpki-oob-setup] a useful tool in setting up the | find [RFC8183] a useful tool in setting up the pairwise relationships | |||
pairwise relationships between these servers, but are not required to | between these servers, but they are not required to use it. | |||
use it. | ||||
1.1. Historical Note | 1.1. Historical Note | |||
This protocol started out as an informal collaboration between | This protocol started out as an informal collaboration between | |||
several of the early RPKI implementers, and while it was always the | several of the early RPKI implementers, and while it was always the | |||
designers' intention that the resulting protocol end up on the IETF | designers' intention that the resulting protocol end up on the IETF | |||
standards track, it took a few years to get there, because | Standards Track, it took a few years to get there because | |||
standardization of other pieces of the overall RPKI protocol space | standardization of other pieces of the overall RPKI protocol space | |||
was more urgent. The standards track version of this publication | was more urgent. The Standards Track version of this publication | |||
protocol preserves the original XML namespace and protocol version | protocol preserves the original XML namespace and protocol version | |||
scheme in order to maintain backwards compatibility with running code | scheme in order to maintain backwards compatibility with running code | |||
implemented against older versions of the specification. | implemented against older versions of the specification. | |||
1.2. Terminology | 1.2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
document are to be interpreted as described in [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
"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 ([XML]) messages wrapped in signed | The publication protocol uses XML [XML] messages wrapped in signed | |||
CMS messages, carried over HTTP transport ([RFC7230]). The CMS | Cryptographic Message Syntax (CMS) messages, carried over HTTP | |||
encapsulation is identical to that used in [RFC6492], section 3.1 and | transport [RFC7230]. The CMS encapsulation is identical to that used | |||
subsections. | in Section 3.1 (and subsections) of RFC 6492 [RFC6492]. | |||
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 | |||
corresponding response. | corresponding response. | |||
A message exchange commences with the client initiating an HTTP POST | A message exchange commences with the client initiating an HTTP POST | |||
with content type of "application/rpki-publication", with the message | with a content type of "application/rpki-publication", with the | |||
object as the body. The server's response will similarly be the body | message object as the body. The server's response will similarly be | |||
of the response with a content type of "application/rpki- | the body of the response with a content type of "application/ | |||
publication". | rpki-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 CMS [RFC5652] object with OID = 1.2.840.113549.1.7.2 as | |||
1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. | described in Section 3.1 of [RFC6492]. | |||
The CMS signatures are used to protect the integrity of the protocol | The CMS signatures are used to protect the integrity of the protocol | |||
messages and to authenticate the client and server to each other. | messages and to authenticate the client and server to each other. | |||
Authorization to perform particular operations is a local matter, | Authorization to perform particular operations is a local matter, | |||
perhaps determined by contractual agreements between the operators of | perhaps determined by contractual agreements between the operators of | |||
any particular client-server pair, but in any case is beyond the | any particular client-server pair, but in any case is beyond the | |||
scope of this specification. | scope of this specification. | |||
2.1. Common XML Message Format | 2.1. Common XML Message Format | |||
skipping to change at page 6, line 19 ¶ | skipping to change at page 6, line 27 ¶ | |||
<!-- Zero or more PDUs --> | <!-- Zero or more PDUs --> | |||
</msg> | </msg> | |||
<msg | <msg | |||
type="reply" | type="reply" | |||
version="4" | 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> | |||
As noted above, the outermost XML element is encapsulated in in a | As noted above, the outermost XML element is encapsulated in a signed | |||
signed CMS message. Query messages are signed by the client, reply | CMS message. Query messages are signed by the client, and reply | |||
messages are signed by the server. | messages are signed by the server. | |||
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 4. | 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 | |||
skipping to change at page 6, line 48 ¶ | skipping to change at page 7, line 8 ¶ | |||
engine will probably find it useful to specify a distinct tag value | engine will probably find it useful to specify a distinct tag value | |||
for each <publish/> or <withdraw/> PDU, to simplify matching an error | for each <publish/> or <withdraw/> PDU, to simplify matching an error | |||
with the PDU which triggered it. The tag attribute is mandatory, to | with the PDU which triggered it. The tag attribute is mandatory, to | |||
simplify parsing, but a CA engine which has no particular use for | simplify parsing, but a CA engine which has no particular use for | |||
tagging MAY use any syntactically legal value, including simply using | tagging MAY use any syntactically legal value, including simply using | |||
the empty string for all tag fields. | the empty string for all tag fields. | |||
This document describes version 4 of this protocol. An | This document describes version 4 of this protocol. An | |||
implementation which understands only this version of the protocol | implementation which understands only this version of the protocol | |||
MUST reject messages with a different protocol version attribute, | MUST reject messages with a different protocol version attribute, | |||
signalling the error as described in Section 2.4. Since "4" is | signaling the error as described in Section 2.4. Since "4" is | |||
currently the only value allowed for the version attribute in the | currently the only value allowed for the version attribute in the | |||
schema (Section 2.6), an incorrect protocol version can be detected | schema (Section 2.6), an incorrect protocol version can be detected | |||
either by checking the version attribute directly or as a schema | either by checking the version attribute directly or as a schema | |||
validation error. Any future update to this protocol which is either | validation error. Any future update to this protocol which is either | |||
syntactically or semantically incompatible with the current version | syntactically or semantically incompatible with the current version | |||
will need to increment the protocol version number. | will need to increment the protocol version number. | |||
2.2. 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 a tag and | Both the <publish/> and <withdraw/> PDUs have a payload of a tag and | |||
an rsync URI ([RFC3986], [RFC5781]). The <publish/> query also | an rsync URI [RFC3986] [RFC5781]. The <publish/> query also contains | |||
contains the DER object to be published, encoded in Base64 ([RFC4648] | the DER object to be published, encoded in Base64 ([RFC4648], | |||
section 4, with line breaks within the Base64 text permitted but not | Section 4, with line breaks within the Base64 text permitted but not | |||
required). | required). | |||
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, encoded as a hexadecimal string. For | specified repository URI, encoded as a hexadecimal string. For | |||
<withdraw/> PDUs, the hash MUST be present, as this operation makes | <withdraw/> PDUs, the hash MUST be present, as this operation makes | |||
no sense if there is no existing object to withdraw. For <publish/> | no sense if there is no existing object to withdraw. For <publish/> | |||
PDUs, the hash MUST be present if the publication operation is | PDUs, the hash MUST be present if the publication operation is | |||
overwriting an existing object, and MUST NOT be present if this | overwriting an existing object, and it MUST NOT be present if this | |||
publication operation is writing to a new URI where no prior object | publication operation is writing to a new URI where no prior object | |||
exists. Presence of an object when no "hash" attribute has been | exists. Presence of an object when no "hash" attribute has been | |||
specified is an error, as is absence of an object or an incorrect | specified is an error, as is absence of an object or an incorrect | |||
hash value when a "hash" attribute has been specified. Any such | hash value when a "hash" attribute has been specified. Any such | |||
errors MUST be reported using the <report_error/> PDU. | 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 | |||
skipping to change at page 8, line 8 ¶ | skipping to change at page 8, line 16 ¶ | |||
entire query succeeds or none of it does. When a query message | entire query succeeds or none of it does. When a query message | |||
contains multiple PDUs, failure of any PDU may require the server to | contains multiple PDUs, failure of any PDU may require the server to | |||
roll back actions triggered by earlier PDUs. | roll back actions triggered by earlier PDUs. | |||
When a query message containing <publish/> or <withdraw/> PDUs | When a query message containing <publish/> or <withdraw/> PDUs | |||
succeeds, the server returns a single <success/> reply. | succeeds, the server returns a single <success/> reply. | |||
When a query fails, the server returns one or more <report_error/> | When a query fails, the server returns one or more <report_error/> | |||
reply PDUs. Typically, a server will only generate one | reply PDUs. Typically, a server will only generate one | |||
<report_error/> corresponding to the first query PDU that failed, but | <report_error/> corresponding to the first query PDU that failed, but | |||
servers MAY return multiple <report_error/> PDUs at the implementor's | servers MAY return multiple <report_error/> PDUs at the implementer's | |||
discretion. | discretion. | |||
2.3. Listing the repository | 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.2) that they have somehow lost synchronization. | Section 2.2) that they have somehow lost synchronization. | |||
The <list/> query consists of a single PDU. A <list/> query MUST be | 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/> | the only PDU in a query -- it may not be combined with any <publish/> | |||
or <withdraw/> queries. | 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.4. 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. | In all other cases, errors result in an XML <report_error/> PDU. | |||
Like the rest of this protocol, <report_error/> PDUs are CMS-signed | Like the rest of this protocol, <report_error/> PDUs are CMS-signed | |||
XML messages and thus can be archived to provide an audit trail. | XML messages and thus can be archived to provide an audit trail. | |||
skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 13 ¶ | |||
"tag" attribute in the PDU which generated the error. A client can | "tag" attribute in the PDU which generated the error. A client can | |||
use the "tag" attribute to determine which PDU caused processing of | use the "tag" attribute to determine which PDU caused processing of | |||
an update to fail. | an update to fail. | |||
The error itself is conveyed in the "error_code" attribute. The | The error itself is conveyed in the "error_code" attribute. The | |||
value 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. | |||
See Section 3.7 for examples of a multi-element query and responses. | See Section 3.7 for examples of a multi-element query and responses. | |||
skipping to change at page 9, line 41 ¶ | skipping to change at page 9, line 49 ¶ | |||
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 | yet a "hash" attribute was not specified. A "hash" attribute must | |||
be specified when overwriting or deleting an object. Perhaps | be specified when overwriting or deleting an object. Perhaps | |||
client 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 | |||
the "hash" attribute of the object at this URI. Perhaps client | match the "hash" attribute of the object at this URI. Perhaps | |||
and server are out of sync? | client 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.6. XML Schema | 2.6. XML Schema | |||
The following is a [RelaxNG] compact form schema describing the | The following is a [RELAX-NG] compact form schema describing the | |||
Publication Protocol. | publication protocol. | |||
This schema is normative: in the event of a disagreement between this | This schema is normative: in the event of a disagreement between this | |||
schema and the document text above, this schema is authoritative. | schema and the document text above, this schema is authoritative. | |||
# RelaxNG schema for RPKI publication protocol. | # RELAX NG 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 4 of the protocol. | # This is version 4 of the protocol. | |||
version = "4" | 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 | |||
} | } | |||
# 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. | |||
skipping to change at page 11, line 44 ¶ | skipping to change at page 12, line 10 ¶ | |||
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 that the authors have taken liberties with the Base64, hash, and | |||
text in these examples in the interest of making the examples fit | URI text in these examples in the interest of making the examples fit | |||
nicely into RFC text format. Similarly, these examples do not show | nicely into RFC text format. Similarly, these examples do not show | |||
the CMS signature wrapper around the XML, just the XML payload. | the CMS signature wrapper around the XML, just the XML payload. | |||
3.1. <publish/> Query, No Existing Object | 3.1. <publish/> Query, No Existing Object | |||
<msg | <msg | |||
type="query" | type="query" | |||
version="4" | version="4" | |||
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> | xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> | |||
<!-- body is base64(new-object) --> | <!-- body is base64(new-object) --> | |||
skipping to change at page 13, line 4 ¶ | skipping to change at page 13, line 19 ¶ | |||
version="4" | version="4" | |||
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> | xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> | |||
<!-- hash is hex(SHA-256(old-object)) --> | <!-- hash is hex(SHA-256(old-object)) --> | |||
<withdraw | <withdraw | |||
hash="01a97a70ac477f06" | hash="01a97a70ac477f06" | |||
tag="foo" | tag="foo" | |||
uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"/> | uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"/> | |||
</msg> | </msg> | |||
3.4. <success/> Reply | 3.4. <success/> Reply | |||
<msg | <msg | |||
type="reply" | type="reply" | |||
version="4" | version="4" | |||
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> | xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> | |||
<success/> | <success/> | |||
</msg> | </msg> | |||
3.5. <report_error/> With Optional Elements | 3.5. <report_error/> with Optional Elements | |||
<msg | <msg | |||
type="reply" | type="reply" | |||
version="4" | 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"> | tag="foo"> | |||
<error_text> | <error_text> | |||
Can't delete an object I don't have | Can't delete an object I don't have | |||
skipping to change at page 13, line 34 ¶ | skipping to change at page 14, line 5 ¶ | |||
<publish | <publish | |||
hash="01a97a70ac477f06" | hash="01a97a70ac477f06" | |||
tag="foo" | tag="foo" | |||
uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"> | uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"> | |||
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= | SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= | |||
</publish> | </publish> | |||
</failed_pdu> | </failed_pdu> | |||
</report_error> | </report_error> | |||
</msg> | </msg> | |||
3.6. <report_error/> Without Optional Elements | 3.6. <report_error/> without Optional Elements | |||
<msg | <msg | |||
type="reply" | type="reply" | |||
version="4" | 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"/> | tag="foo"/> | |||
</msg> | </msg> | |||
3.7. Error Handling With Multi-Element Queries | 3.7. Error Handling with Multi-Element Queries | |||
3.7.1. Multi-Element Query | 3.7.1. Multi-Element Query | |||
<msg | <msg | |||
type="query" | type="query" | |||
version="4" | 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/01a97a70ac477f06.cer"> | uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"> | |||
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= | SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= | |||
</publish> | </publish> | |||
<withdraw | <withdraw | |||
skipping to change at page 16, line 36 ¶ | skipping to change at page 17, line 27 ¶ | |||
<list | <list | |||
hash="f222481ded47445d" | hash="f222481ded47445d" | |||
uri="rsync://wombat.example/Foe/f222481ded47445d.cer"/> | uri="rsync://wombat.example/Foe/f222481ded47445d.cer"/> | |||
<list | <list | |||
hash="15b94e08713275bc" | hash="15b94e08713275bc" | |||
uri="rsync://wombat.example/Fum/15b94e08713275bc.cer"/> | uri="rsync://wombat.example/Fum/15b94e08713275bc.cer"/> | |||
</msg> | </msg> | |||
4. IANA Considerations | 4. IANA Considerations | |||
IANA is asked to register the application/rpki-publication MIME media | IANA has registered the "application/rpki-publication" media type as | |||
type as follows: | follows: | |||
MIME media type name: application | Type name: application | |||
MIME subtype name: rpki-publication | Subtype name: rpki-publication | |||
Required parameters: None | Required parameters: None | |||
Optional parameters: None | Optional parameters: None | |||
Encoding considerations: binary | Encoding considerations: binary | |||
Security considerations: Carries an RPKI Publication Protocol | Security considerations: Carries an RPKI publication protocol | |||
Message, as defined in this document. | message, as defined in RFC 8181. | |||
Interoperability considerations: None | Interoperability considerations: None | |||
Published specification: [[RFCxxxx]] | Published specification: RFC 8181 | |||
Applications which use this media type: HTTP | Applications which use this media type: HTTP | |||
Additional information: | Additional information: | |||
Magic number(s): None | Magic number(s): None | |||
File extension(s): | File extension(s): None | |||
Macintosh File Type Code(s): | Macintosh File Type Code(s): None | |||
Person & email address to contact for further information: | Person & email address to contact for further information: | |||
Rob Austein <sra@hactrn.net> | Rob Austein <sra@hactrn.net> | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Author/Change controller: IETF | Author/Change controller: IETF | |||
5. Security Considerations | 5. Security Considerations | |||
The RPKI publication protocol and the data it publishes use entirely | The RPKI publication protocol and the data it publishes use entirely | |||
separate PKIs for authentication. The published data is | separate PKIs for authentication. The published data is | |||
authenticated within the RPKI, and this protocol has nothing to do | authenticated within the RPKI, and this protocol has nothing to do | |||
with that authentication, nor does it require that the published | with that authentication, nor does it require that the published | |||
objects be valid in the RPKI. The publication protocol uses a | objects be valid in the RPKI. The publication protocol uses a | |||
separate Business PKI (BPKI) to authenticate its messages. | separate BPKI to authenticate its messages. | |||
Each RPKI publication protocol message is wrapped in a signed CMS | Each RPKI publication protocol message is wrapped in a signed CMS | |||
message, which provides message integrity protection and an auditable | message, which provides message integrity protection and an auditable | |||
form of message authentication. Because of these protections at the | form of message authentication. Because of these protections at the | |||
application layer, and because all the data being published are | application layer, and because all the data being published are | |||
intended to be public information in any case, this protocol does | intended to be public information in any case, this protocol does | |||
not, strictly speaking, require the use of HTTPS or other transport | not, strictly speaking, require the use of HTTPS or other transport | |||
security mechanisms. There may, however, be circumstances in which a | security mechanisms. There may, however, be circumstances in which a | |||
particular publication operator may prefer HTTPS over HTTP anyway, as | particular publication operator may prefer HTTPS over HTTP anyway, as | |||
a matter of (BPKI) CA policy. Use of HTTP versus HTTPS here is, | a matter of (BPKI) CA policy. Use of HTTP versus HTTPS here is, | |||
essentially, a private matter between the repository operator and its | essentially, a private matter between the repository operator and its | |||
clients. Note, however, that even if a client/server pair uses HTTPS | clients. Note, however, that even if a client/server pair uses HTTPS | |||
for this protocol, message authentication for this protocol is still | for this protocol, message authentication for this protocol is still | |||
based on the CMS signatures, not HTTPS. | based on the CMS signatures, not HTTPS. | |||
Although the hashes used in the <publish/> and <withdraw/> PDUs are | Although the hashes used in the <publish/> and <withdraw/> PDUs are | |||
cryptographically strong, the digest algorithm was selected for | cryptographically strong, the digest algorithm was selected for | |||
convenience in comparing these hashes with the hashes that appear in | convenience in comparing these hashes with the hashes that appear in | |||
RPKI manifests. The hashes used in the <publish/> and <withdraw/> | RPKI manifests. The hashes used in the <publish/> and <withdraw/> | |||
PDUs are not particularly security-sensitive, because these PDUs are | PDUs are not particularly security sensitive because these PDUs are | |||
protected by the CMS signatures. Because of this, the most likely | protected by the CMS signatures. Because of this, the most likely | |||
reason for a change to this digest algorithm would be to track a | reason for a change to this digest algorithm would be to track a | |||
corresponding change in the digest algorithm used in RPKI manifests. | corresponding change in the digest algorithm used in RPKI manifests. | |||
If and when such a change happens, it will require incrementing the | If and when such a change happens, it will require incrementing the | |||
version number of this publication protocol, but given that the most | version number of this publication protocol, but given that the most | |||
likely implementation of a publication server uses these hashes as | likely implementation of a publication server uses these hashes as | |||
lookup keys in a database, bumping the protocol version number would | lookup keys in a database, bumping the protocol version number would | |||
be a relatively minor portion of the effort of changing the | be a relatively minor portion of the effort of changing the | |||
algorithm. | algorithm. | |||
Compromise of a publication server, perhaps through mismanagement of | Compromise of a publication server, perhaps through mismanagement of | |||
BPKI private keys, could lead to a denial-of-service attack on the | BPKI private keys, could lead to a denial-of-service attack on the | |||
RPKI. An attacker gaining access to BPKI private keys could use this | RPKI. An attacker gaining access to BPKI private keys could use this | |||
protocol to delete (withdraw) RPKI objects, leading to routing | protocol to delete (withdraw) RPKI objects, leading to routing | |||
changes or failures. Accordingly, as in most PKIs, good key | changes or failures. Accordingly, as in most PKIs, good key | |||
management practices are important. | management practices are important. | |||
6. Acknowledgements | 6. References | |||
The authors would like to thank: Geoff Huston, George Michaelson, | ||||
Oleg Muravskiy, Paul Wouters, Randy Bush, Rob Loomans, Robert | ||||
Kisteleki, Tim Bruijnzeels, Tom Petch, and anybody else who helped | ||||
along the way but whose name(s) the authors have temporarily | ||||
forgotten. | ||||
7. References | ||||
7.1. Normative References | 6.1. Normative References | |||
[RelaxNG] Clark, J., "RELAX NG Compact Syntax", OASIS , November | [RELAX-NG] Clark, J., "RELAX NG Compact Syntax", OASIS Committee | |||
2002, <https://www.oasis-open.org/committees/relax-ng/ | Specification, November 2002, | |||
<https://www.oasis-open.org/committees/relax-ng/ | ||||
compact-20021121.html>. | compact-20021121.html>. | |||
[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", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", RFC 3986, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
STD 66, January 2005. | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
<http://www.rfc-editor.org/info/rfc3986>. | ||||
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | |||
Encodings", RFC 4648, October 2006. | Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | |||
<http://www.rfc-editor.org/info/rfc4648>. | ||||
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", | [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, | |||
RFC 5652, STD 70, September 2009. | RFC 5652, DOI 10.17487/RFC5652, September 2009, | |||
<http://www.rfc-editor.org/info/rfc5652>. | ||||
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI | [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI | |||
Scheme", RFC 5781, February 2010. | Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, | |||
<http://www.rfc-editor.org/info/rfc5781>. | ||||
[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", | Protocol for Provisioning Resource Certificates", | |||
RFC 6492, February 2012. | RFC 6492, DOI 10.17487/RFC6492, February 2012, | |||
<http://www.rfc-editor.org/info/rfc6492>. | ||||
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
2014. | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7230>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <http://www.rfc-editor.org/info/rfc8174>. | ||||
[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 (SHS)", FIPS PUB 180-4, | |||
<http://csrc.nist.gov/publications/fips/fips180-4/ | DOI 10.6028/NIST.FIPS.180-4, August 2015, | |||
fips-180-4.pdf>. | <http://nvlpubs.nist.gov/nistpubs/FIPS/ | |||
NIST.FIPS.180-4.pdf>. | ||||
[XML] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C CR | [XML] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C | |||
CR-xml11-20021015, October 2002. | Consortium Recommendation REC-xml11-20060816, October | |||
2002, <http://www.w3.org/TR/2002/CR-xml11-20021015>. | ||||
7.2. Informative References | 6.2. Informative References | |||
[I-D.ietf-sidr-delta-protocol] | [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support | |||
Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, | Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, | |||
"RPKI Repository Delta Protocol", draft-ietf-sidr-delta- | February 2012, <http://www.rfc-editor.org/info/rfc6480>. | |||
protocol-07 (work in progress), February 2017. | ||||
[I-D.ietf-sidr-rpki-oob-setup] | [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, | |||
Austein, R., "An Out-Of-Band Setup Protocol For RPKI | "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, | |||
Production Services", draft-ietf-sidr-rpki-oob-setup-09 | DOI 10.17487/RFC8182, July 2017, | |||
(work in progress), February 2017. | <http://www.rfc-editor.org/info/rfc8182>. | |||
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support | [RFC8183] Austein, R., "An Out-of-Band Setup Protocol for Resource | |||
Secure Internet Routing", RFC 6480, February 2012. | Public Key Infrastructure (RPKI) Production Services", | |||
RFC 8183, DOI 10.17487/RFC8183, July 2017, | ||||
<http://www.rfc-editor.org/info/rfc8183>. | ||||
Acknowledgements | ||||
The authors would like to thank: Geoff Huston, George Michaelson, | ||||
Oleg Muravskiy, Paul Wouters, Randy Bush, Rob Loomans, Robert | ||||
Kisteleki, Tim Bruijnzeels, Tom Petch, and anybody else who helped | ||||
along the way but whose name(s) the authors have temporarily | ||||
forgotten. | ||||
Authors' Addresses | Authors' Addresses | |||
Samuel Weiler | Samuel Weiler | |||
W3C / MIT | W3C / MIT | |||
Email: weiler@csail.mit.edu | Email: weiler@csail.mit.edu | |||
Anuja Sonalker | Anuja Sonalker | |||
TowerSec Automotive Cyber Security | STEER Tech | |||
Email: anuja@steer-tech.com | ||||
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. 78 change blocks. | ||||
152 lines changed or deleted | 169 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |