draft-ietf-sidr-publication-00.txt | draft-ietf-sidr-publication-01.txt | |||
---|---|---|---|---|
Network Working Group S. Weiler | Network Working Group S. Weiler | |||
Internet-Draft A. Sonalker | Internet-Draft A. Sonalker | |||
Intended status: Standards Track SPARTA, Inc. | Intended status: Standards Track SPARTA, Inc. | |||
Expires: April 21, 2011 October 18, 2010 | Expires: January 12, 2012 R. Austein | |||
ISC | ||||
July 11, 2011 | ||||
A Publication Protocol for the Resource Public Key Infrastructure (RPKI) | A Publication Protocol for the Resource Public Key Infrastructure (RPKI) | |||
draft-ietf-sidr-publication-00 | draft-ietf-sidr-publication-01 | |||
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 that. | This document provides the protocol for doing so. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 April 21, 2011. | This Internet-Draft will expire on January 12, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 | 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Common Details . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Common Details . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1.1. Common XML Message Format . . . . . . . . . . . . . . 4 | 3.1.1. Common XML Message Format . . . . . . . . . . . . . . 4 | |||
3.2. Control Protocol . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Control Sub-Protocol . . . . . . . . . . . . . . . . . . . 5 | |||
3.2.1. Config Object . . . . . . . . . . . . . . . . . . . . 5 | 3.2.1. Config Object . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2.2. Client Object . . . . . . . . . . . . . . . . . . . . 5 | 3.2.2. Client Object . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Publication Protocol . . . . . . . . . . . . . . . . . . . 6 | 3.3. Publication Sub-Protocol . . . . . . . . . . . . . . . . . 6 | |||
3.4. Error handling . . . . . . . . . . . . . . . . . . . . . . 6 | 3.4. Error handling . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4. Operational Considerations . . . . . . . . . . . . . . . . . . 10 | 4. Operational Considerations . . . . . . . . . . . . . . . . . . 9 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
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. [I-D.ietf-sidr-arch] | security on the Internet. [I-D.ietf-sidr-arch] | |||
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, clients using the RPKI objects will find it faster and | Similarly, relying parties using the RPKI objects will find it faster | |||
more reliable to retrieve the necessary set from a smaller number of | and more reliable to retrieve the necessary set from a smaller number | |||
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. Hence the need for a protocol to publish RPKI objects. | RPKI object. Hence the need for a protocol to publish RPKI objects. | |||
This document defines the RPKI publication protocol, including a sub- | This document defines the RPKI publication protocol, including a sub- | |||
protocol for configuring the publication engine. | protocol for configuring the publication engine. | |||
1.1. Terminology | 1.1. Terminology | |||
skipping to change at page 3, line 45 | skipping to change at page 3, line 45 | |||
"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. | to the publication engine. | |||
2. Context | 2. Context | |||
This protocol was designed specifically for the case where an | This protocol was designed specifically for the case where an | |||
internet registry, already issuing RPKI certificates to its children, | internet registry, already issuing RPKI certificates to its children, | |||
also wishes to run a publication service for its children. | also wishes to run a publication service for its children. | |||
We use the term "Business PKI" here to suggest that an internet | We use the term "Business PKI" here because an internet registry | |||
registry might already have a PKI, separate from the RPKI, for | might already have a PKI, separate from the RPKI, for authenticating | |||
authenticating its clients and might wish to reuse that PKI for this | its clients and might wish to reuse that PKI for this protocol. Such | |||
protocol. Such reuse is not a requirement. | reuse is not a requirement. | |||
3. Protocol Specification | 3. Protocol Specification | |||
In summary, the publication protocol uses XML messages wrapped in | In summary, the publication protocol uses XML messages wrapped in | |||
CMS, carried over HTTP transport. | CMS, carried over HTTP transport. | |||
The publication procotol consists of two separate subprotocols. The | The publication procotol consists of two separate subprotocols. The | |||
first is a control protocol used to configure a publication engine. | first is a control protocol used to configure a publication engine. | |||
The second subprotocol, which we refer to by the overloaded term | The second subprotocol, which we refer to by the overloaded term | |||
"publication protocol", is used to request publication of specific | "publication protocol", is used to request publication of specific | |||
objects. The publication engine operates a single HTTP server on a | objects. The publication engine operates a single HTTP server on a | |||
single port. It distinguishes between the two protocols by using | single port. It distinguishes between the two protocols by using | |||
different URLs for them. | different URLs for them. | |||
3.1. Common Details | 3.1. Common Details | |||
This section discusses details that the two subprotocols have in | This section discusses details that the two subprotocols have in | |||
common, including the transport and CMS wrappers. This portion of | common, including the transport and CMS wrappers. | |||
the protocol is largely inherited from the provisioning protocol | ||||
([I-D.ietf-sidr-rescerts-provisioning]). | ||||
Both protocols use a simple request/response interaction. The client | Both protocols use a simple request/response interaction. The client | |||
passes a request to the server, and the server generates a | passes a request to the server, and the server generates a | |||
corresponding response. A message exchange commences with the client | corresponding response. | |||
initiating an HTTP POST with content type of "application/x-rpki", | ||||
with the message object as the body. The server's response will | ||||
similarly be the body of the response with a content type of | ||||
"application/x-rpki". | ||||
The content of the POST, and the server's response, will be a well- | A message exchange commences with the client initiating an HTTP POST | |||
with content type of "application/rpki-publication", with the message | ||||
object as the body. The server's response will similarly be the body | ||||
of the response with a content type of "application/ | ||||
rpki-publication". | ||||
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 | 1.2.840.113549.1.7.2 as described in Section 3.1 of | |||
[I-D.ietf-sidr-rescerts-provisioning]. | [I-D.ietf-sidr-rescerts-provisioning]. | |||
3.1.1. Common XML Message Format | 3.1.1. Common XML Message Format | |||
The publication protocol uses the same message passing design as the | The XML schema for this protocol (including both subprotocols) is | |||
provisioning protocol. The XML schema for this protocol (including | below in Section 3.5. Both subprotocols use the same basic XML | |||
both subprotocols) is below in Section 3.5. Both subprotocols use | message format, which looks like: | |||
the same basic XML message format, which looks like: | ||||
<?xml version='1.0' encoding='us-ascii'?> | <?xml version='1.0' encoding='us-ascii'?> | |||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | <msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | |||
version="1" | version="2" | |||
type="message type"> | type="message type"> | |||
[one or more PDUs] | [one or more PDUs] | |||
</msg> | </msg> | |||
version: | ||||
The value of this attribute is the version of this protocol. | ||||
This document describes version 1. | ||||
type: | version: | |||
The possible values of this attribute are "reply" and "query". | The value of this attribute is the version of this protocol. | |||
This document describes version 2. | ||||
3.2. Control Protocol | type: | |||
The possible values of this attribute are "reply" and "query". | ||||
The control protocol is used to configure a publication server. It | A query PDU may be one of four types: config_query, client_query, | |||
can set global variables (at the moment, limited to a BPKI CRL) and | publish_query, or withdraw_query. The first two are used by the | |||
manage clients who are allowed to publish data on the server. | control sub-protocol, the latter two by the publication sub-protocol. | |||
The control protocol has two objects: the <config/> object, and the | A reply PDU may be one of five types: config_reply, client_reply, | |||
<client/> object. | publish_reply, withdraw_reply, or report_error_reply. | |||
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) MUST have the tag attribute set to the same value. | ||||
3.2. Control Sub-Protocol | ||||
The control sub-protocol is used to configure a publication server. | ||||
It can set global variables (at the moment, limited to a BPKI CRL) | ||||
and manage clients who are allowed to publish data on the server. | ||||
3.2.1. Config Object | 3.2.1. Config Object | |||
The <config/> object allows configuration of data that apply to the | The <config/> object allows configuration of data that apply to the | |||
entire publication server rather than a particular client. There is | entire publication server rather than a particular client. There is | |||
exactly one <config/> object in the publication server, and it only | exactly one <config/> object in the publication server, and it only | |||
supports the "set" and "get" actions -- it cannot be created or | supports the "set" and "get" actions -- it cannot be created or | |||
destroyed. | destroyed. Its use is typically restricted to the repository | |||
operator. | ||||
The <config/> object only has one data element that can be set: the | The <config/> object only has one data element that can be set: the | |||
bpki_crl. This is used by the publication server when authenticating | bpki_crl. This is used by the publication server when authenticating | |||
clients. | clients. | |||
3.2.2. Client Object | 3.2.2. Client Object | |||
Unlike the <config/> object the <client/> object represents one | Unlike the <config/> object, the <client/> object represents one | |||
client authorized to use the publication server. | client authorized to use the publication server. There may well be | |||
more than one <client/> object on each publication server. Again, | ||||
its use is typically restricted to the respository operator. | ||||
The <client/> object supports five actions: "create", "set", "get", | The <client/> object supports five actions: "create", "set", "get", | |||
"list", and "destroy". Each client has a "client_handle" attribute, | "list", and "destroy". Each client has a "client_handle" attribute, | |||
which is used in responses and must be specified in "create", "set", | which is used in responses and must be specified in "create", "set", | |||
"get", or "destroy" actions. | "get", or "destroy" actions. | |||
Payload data which can be configured in a <client/> object include: | Payload data which can be configured in a <client/> object include: | |||
o base_uri (attribute): This attribute represents the base URI below | o base_uri (attribute): This attribute represents the base URI below | |||
which the client will be allowed to publish data. Additional | which the client will be allowed to publish data. Additional | |||
constraints may be imposed by the Publication Server in certain | constraints may be imposed by the publication server in certain | |||
cases, for e.g., a child publishing directly under its parent. | cases, for e.g., a child publishing directly under its parent. | |||
o bpki_cert (element): This represents the X509 BPKI CA certificate | ||||
o bpki_cert (element): This represents the X.509 BPKI CA certificate | ||||
for this client. This should be used as part of the certificate | for this client. This should be used as part of the certificate | |||
chain when validating incoming TLS and CMS messages. Two valid | chain when validating incoming CMS messages. Two valid approaches | |||
approaches exist. If the optional bpki_glue certificate is being | exist. If the optional bpki_glue certificate is being used, then | |||
used, then the bpki_cert certificate should be issued by the | the bpki_cert certificate should be issued by the bpki_glue | |||
bpki_glue certificate; otherwise, the bpki_cert certificate should | certificate; otherwise, the bpki_cert certificate should be issued | |||
be issued by the publication engine's bpki_ta certificate. | by the publication engine's bpki_ta certificate. | |||
o bpki_glue (element): This is an additional (optional) type of X509 | ||||
certificate for this client. It may be used in certain | o bpki_glue (element): This is an additional (optional) type of | |||
X.509 certificate for this client. It may be used in certain | ||||
pathological cross-certification cases which require a two- | pathological cross-certification cases which require a two- | |||
certificate chain due to issuer name conflicts. When being used, | certificate chain due to issuer name conflicts. When being used, | |||
issuing order is that the bpki_glue certificate should be the | issuing order is that the bpki_glue certificate should be the | |||
issuer of the bpki_cert certificate. Otherwise, it should be | issuer of the bpki_cert certificate. Otherwise, it should be | |||
issued by the publication engine's bpki_ta certificate. Since | issued by the publication engine's bpki_ta certificate. Since | |||
this is an optional use certificate, it may be left unset if not | this is an optional use certificate, it may be left unset if not | |||
needed. | needed. | |||
3.3. Publication Protocol | 3.3. Publication Sub-Protocol | |||
The publication protocol is structured differently from the control | The sub-publication protocol requests publication or withdrawal from | |||
protocol in that objects in the publication protocol represent | publication of RPKI objects. | |||
objects to be published or objects to be withdrawn from publication. | ||||
Each kind of object supports two actions: "publish" and "withdraw". | The publication protocol uses a common message format to request | |||
In each case the XML element representing the object to be published | publication of any RPKI object. This format was chosen specifically | |||
or withdrawn has a "uri" attribute which contains the publication | to allow this protocol to accommodate new types of RPKI objects | |||
URI. For "publish" actions, the XML element body contains the DER | without needing changes to this protocol. | |||
object to be published, encoded in Base64; for "withdraw" actions, | ||||
the XML element body is empty. | ||||
The publication protocol uses four types of objects: | Both the <publish/> and <withdraw/> objects have a payload of an | |||
o Certificate Object: The <certificate/> object represents an RPKI | optional tag and a URI. The <publish/> query also contains the DER | |||
certificate to be published or withdrawn. | object to be published, encoded in Base64. | |||
o CRL Object: The <crl/> object represents an RPKI CRL to be | ||||
published or withdrawn. | ||||
o Manifest Object: The <manifest/> object represents an RPKI | ||||
publication manifest to be published or withdrawn. See | ||||
[I-D.ietf-sidr-rpki-manifests] for more information on manifests. | ||||
o ROA Object: The <roa/> object represents a ROA to be published or | ||||
withdrawn. See [I-D.ietf-sidr-roa-format] for more information on | ||||
ROAs. | ||||
Note that every publication or withdrawal action requires a new | Note that every publish and withdraw action requires a new manifest, | |||
manifest, thus every publication or withdrawal action will involve at | thus every publish or withdraw action will involve at least two | |||
least two objects. | objects. | |||
3.4. Error handling | 3.4. Error handling | |||
Errors are handled similarly in both subprotocols, and they're | Errors are handled similarly in both subprotocols, and they're | |||
handled at two levels. | handled at two levels. | |||
Since all messages in this protocol are conveyed over HTTP | Since all messages in this protocol are conveyed over HTTP | |||
connections, basic errors are indicated via the HTTP response code. | connections, basic errors are indicated via the HTTP response code. | |||
4xx and 5xx responses indicate that something bad happened. Errors | 4xx and 5xx responses indicate that something bad happened. Errors | |||
that make it impossible to decode a query or encode a response are | that make it impossible to decode a query or encode a response are | |||
handled in this way. | handled in this way. | |||
Where possible, errors will result in an XML <report_error/> message | Where possible, errors will result in an XML <report_error/> message | |||
which takes the place of the expected protocol response message. | which takes the place of the expected protocol response message. | |||
<report_error/> messages are CMS-signed XML messages like the rest of | <report_error/> messages are CMS-signed XML messages like the rest of | |||
this protocol, and thus can be archived to provide an audit trail. | this protocol, and thus can be archived to provide an audit trail. | |||
<report_error/> messages only appear in replies, never in queries. | <report_error/> messages only appear in replies, never in queries. | |||
skipping to change at page 7, line 18 | skipping to change at page 7, line 27 | |||
Where possible, errors will result in an XML <report_error/> message | Where possible, errors will result in an XML <report_error/> message | |||
which takes the place of the expected protocol response message. | which takes the place of the expected protocol response message. | |||
<report_error/> messages are CMS-signed XML messages like the rest of | <report_error/> messages are CMS-signed XML messages like the rest of | |||
this protocol, and thus can be archived to provide an audit trail. | this protocol, and thus can be archived to provide an audit trail. | |||
<report_error/> messages only appear in replies, never in queries. | <report_error/> messages only appear in replies, never in queries. | |||
The <report_error/> message can appear in both the control and | The <report_error/> message can appear in both the control and | |||
publication subprotocols. | publication subprotocols. | |||
The <report_error/> message includes an optional "tag" attribute to | Like all other messages in this protocol, the <report_error/> message | |||
assist in matching the error with a particular query when using | includes a "tag" attribute to assist in matching the error with a | |||
batching. | particular query when using batching. It is optional to set the tag | |||
on queries but, if set on the query, it MUST be set on the reply or | ||||
error. | ||||
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. [TODO: define these tokens] | occurred. | |||
The body of the <report_error/> element itself is an optional text | The body of the <report_error/> element itself is an optional text | |||
string; if present, this is debugging information. At present this | string; if present, this is debugging information. | |||
capabilty is not used, debugging information goes to syslog. | ||||
3.5. XML Schema | 3.5. 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. | |||
default namespace = "http://www.hactrn.net/uris/rpki/publication-spec/" | default namespace = "http://www.hactrn.net/uris/rpki/publication-spec/" | |||
# Top level PDU | # Top level PDU | |||
start = element msg { | ||||
start = element msg { attribute version { xsd:positiveInteger { | attribute version { "2" } , | |||
maxInclusive="1" } }, ((attribute type { "query" }, query_elt*) | | ( ( attribute type { "query" }, query_elt*) | | |||
(attribute type { "reply" }, reply_elt*)) } | (attribute type { "reply" }, reply_elt*)) | |||
} | ||||
# PDUs allowed in a query | # PDUs allowed in a query | |||
query_elt = ( config_query | client_query | certificate_query | | query_elt = ( config_query | client_query | publish_query | | |||
crl_query | manifest_query | roa_query ) | withdraw_query ) | |||
# PDUs allowed in a reply | # PDUs allowed in a reply | |||
reply_elt = ( config_reply | client_reply | certificate_reply | | reply_elt = ( config_reply | client_reply | publish_reply | | |||
crl_reply | manifest_reply | roa_reply | report_error_reply ) | withdraw_reply | report_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 { maxLength="512000" } | base64 = xsd:base64Binary | |||
# Publication URLs | # Publication URLs | |||
uri_t = xsd:anyURI { maxLength="4096" } | uri_t = xsd:anyURI { maxLength="4096" } | |||
uri = attribute uri { uri_t } | uri = attribute uri { uri_t } | |||
# Handles on remote objects (replaces passing raw SQL IDs). NB: | # Handles on remote objects (replaces passing raw SQL IDs). NB: | |||
# Unlike the up-down protocol, handles in this protocol allow "/" as a | # Unlike the up-down protocol, handles in this protocol allow | |||
# hierarchy delimiter. | # "/" as a hierarchy delimiter. | |||
object_handle = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" } | object_handle = xsd:string { | |||
maxLength="255" pattern="[\-_A-Za-z0-9/]*" } | ||||
# <config/> element (use restricted to repository operator) | # <config/> element (use restricted to repository operator) | |||
# config_handle attribute, create, list, and destroy commands omitted | # config_handle attribute: create, list, and destroy commands | |||
# deliberately, see code for details | # omitted deliberately. | |||
config_payload = (element bpki_crl { base64 }?) | config_payload = (element bpki_crl { base64 }?) | |||
config_query |= element config { attribute action { "set" }, tag?, | config_query |= element config { attribute action { "set" }, tag?, | |||
config_payload } | config_payload } | |||
config_reply |= element config { attribute action { "set" }, tag? } | config_reply |= element config { attribute action { "set" }, tag? } | |||
config_query |= element config { attribute action { "get" }, tag? } | config_query |= element config { attribute action { "get" }, tag? } | |||
config_reply |= element config { attribute action { "get" }, tag?, | config_reply |= element config { attribute action { "get" }, tag?, | |||
config_payload } | config_payload } | |||
# <client/> element (use restricted to repository operator) | # <client/> element (use restricted to repository operator) | |||
client_handle = attribute client_handle { object_handle } | client_handle = attribute client_handle { object_handle } | |||
client_payload = (attribute base_uri { uri_t }?, element bpki_cert { | client_payload = (attribute base_uri { uri_t }?, element bpki_cert { | |||
base64 }?, element bpki_glue { base64 }?) | base64 }?, element bpki_glue { base64 }?) | |||
client_query |= element client { attribute action { "create" }, | ||||
client_query |= element client { attribute action { "create" }, tag?, | tag?, client_handle, client_payload } | |||
client_handle, client_payload } | client_reply |= element client { attribute action { "create" }, | |||
client_reply |= element client { attribute action { "create" }, tag?, | tag?, client_handle } | |||
client_handle } | ||||
client_query |= element client { attribute action { "set" }, tag?, | client_query |= element client { attribute action { "set" }, tag?, | |||
client_handle, client_payload } | client_handle, client_payload } | |||
client_reply |= element client { attribute action { "set" }, tag?, | client_reply |= element client { attribute action { "set" }, tag?, | |||
client_handle } | client_handle } | |||
client_query |= element client { attribute action { "get" }, tag?, | client_query |= element client { attribute action { "get" }, tag?, | |||
client_handle } | client_handle } | |||
client_reply |= element client { attribute action { "get" }, tag?, | client_reply |= element client { attribute action { "get" }, tag?, | |||
client_handle, client_payload } | client_handle, client_payload } | |||
client_query |= element client { attribute action { "list" }, tag? } | client_query |= element client { attribute action { "list" }, tag? } | |||
client_reply |= element client { attribute action { "list" }, tag?, | client_reply |= element client { attribute action { "list" }, tag?, | |||
client_handle, client_payload } | client_handle, client_payload } | |||
client_query |= element client { attribute action { "destroy" }, tag?, | client_query |= element client { attribute action { "destroy" }, | |||
client_handle } | tag?, client_handle } | |||
client_reply |= element client { attribute action { "destroy" }, tag?, | client_reply |= element client { attribute action { "destroy" }, | |||
client_handle } | tag?, client_handle } | |||
# <certificate/> element | ||||
certificate_query |= element certificate { attribute action { | ||||
"publish" }, tag?, uri, base64 } | ||||
certificate_reply |= element certificate { attribute action { | ||||
"publish" }, tag?, uri } | ||||
certificate_query |= element certificate { attribute action { | ||||
"withdraw" }, tag?, uri } | ||||
certificate_reply |= element certificate { attribute action { | ||||
"withdraw" }, tag?, uri } | ||||
# <crl/> element | ||||
crl_query |= element crl { attribute action { "publish" }, tag?, uri, | ||||
base64 } | ||||
crl_reply |= element crl { attribute action { "publish" }, tag?, uri } | ||||
crl_query |= element crl { attribute action { "withdraw" }, tag?, uri } | ||||
crl_reply |= element crl { attribute action { "withdraw" }, tag?, uri } | ||||
# <manifest/> element | ||||
manifest_query |= element manifest { attribute action { "publish" }, | ||||
tag?, uri, base64 } | ||||
manifest_reply |= element manifest { attribute action { "publish" }, | ||||
tag?, uri } | ||||
manifest_query |= element manifest { attribute action { "withdraw" }, | ||||
tag?, uri } | ||||
manifest_reply |= element manifest { attribute action { "withdraw" }, | ||||
tag?, uri } | ||||
# <roa/> element | # <publish/> element | |||
publish_query |= element publish { tag?, uri, base64 } | ||||
publish_reply |= element publish { tag?, uri } | ||||
roa_query |= element roa { attribute action { "publish" }, tag?, uri, | # <withdraw/> element | |||
base64 } | withdraw_query |= element withdraw { tag?, uri } | |||
roa_reply |= element roa { attribute action { "publish" }, tag?, uri } | withdraw_reply |= element withdraw { tag?, uri } | |||
roa_query |= element roa { attribute action { "withdraw" }, tag?, uri } | ||||
roa_reply |= element roa { attribute action { "withdraw" }, tag?, uri } | ||||
# <report_error/> element | # <report_error/> element | |||
error = xsd:token { maxLength="1024" } | error = xsd:token { maxLength="1024" } | |||
report_error_reply = element report_error { | report_error_reply = element report_error { | |||
tag?, | tag?, | |||
attribute error_code { error }, | attribute error_code { error }, | |||
xsd:string { maxLength="512000" }? | xsd:string { maxLength="512000" }? | |||
} | } | |||
4. Operational Considerations | 4. Operational Considerations | |||
Placeholder section to talk about nesting children under parents in | Placeholder section to talk about nesting children under parents in | |||
the sameso repository, to allow for a single rsync to fetch both | the same repository, to allow for a single rsync to fetch both | |||
(observing that the rsync setup times tends to dominate over the sync | (observing that the rsync setup times tends to dominate over the sync | |||
time). And, more distressingly, talk about the access control | time). And, more distressingly, talk about the access control | |||
impacts of that nesting. | impacts of that nesting. | |||
5. IANA Considerations | 5. IANA Considerations | |||
This document specifies no IANA Actions. | IANA is asked to register the application/rpki-publication MIME media | |||
type as follows: | ||||
MIME media type name: application | ||||
MIME subtype name: rpki-publication | ||||
Required parameters: None | ||||
Optional parameters: None | ||||
Encoding considerations: binary | ||||
Security considerations: Carries an RPKI Publication Protocol | ||||
Message, as defined in this document. | ||||
Interoperability considerations: None | ||||
Published specification: This document | ||||
Applications which use this media type: HTTP | ||||
Additional information: | ||||
Magic number(s): None | ||||
File extension(s): | ||||
Macintosh File Type Code(s): | ||||
Person & email address to contact for further information: | ||||
Rob Austein <sra@isc.org> | ||||
Intended usage: COMMON | ||||
Author/Change controller: Rob Austein <sra@isc.org> | ||||
6. Security Considerations | 6. Security Considerations | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[I-D.ietf-sidr-res-certs] | ||||
Huston, G., Michaelson, G., and R. Loomans, "A Profile for | ||||
X.509 PKIX Resource Certificates", | ||||
draft-ietf-sidr-res-certs-19 (work in progress), | ||||
October 2010. | ||||
[I-D.ietf-sidr-rescerts-provisioning] | [I-D.ietf-sidr-rescerts-provisioning] | |||
Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A | Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A | |||
Protocol for Provisioning Resource Certificates", | Protocol for Provisioning Resource Certificates", | |||
draft-ietf-sidr-rescerts-provisioning-07 (work in | draft-ietf-sidr-rescerts-provisioning-10 (work in | |||
progress), October 2010. | progress), June 2011. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | ||||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | ||||
(TLS) Protocol Version 1.2", RFC 5246, August 2008. | ||||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | ||||
Housley, R., and W. Polk, "Internet X.509 Public Key | ||||
Infrastructure Certificate and Certificate Revocation List | ||||
(CRL) Profile", RFC 5280, May 2008. | ||||
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, | [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, | |||
RFC 5652, September 2009. | RFC 5652, September 2009. | |||
[X.690] Postel, J., "ITU-T Recommendation X.690: ISO/IEC 8825- | ||||
1:2002, Information technology - ASN.1 encoding rules: | ||||
Specification of Basic Encoding Rules (BER), Canonical | ||||
Encoding Rules (CER) and Distinguished Encoding Rules | ||||
(DER)", 2002. | ||||
7.2. Informative References | 7.2. Informative References | |||
[I-D.ietf-sidr-arch] | [I-D.ietf-sidr-arch] | |||
Lepinski, M. and S. Kent, "An Infrastructure to Support | Lepinski, M. and S. Kent, "An Infrastructure to Support | |||
Secure Internet Routing", draft-ietf-sidr-arch-11 (work in | Secure Internet Routing", draft-ietf-sidr-arch-13 (work in | |||
progress), September 2010. | progress), May 2011. | |||
[I-D.ietf-sidr-roa-format] | ||||
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route | ||||
Origin Authorizations (ROAs)", | ||||
draft-ietf-sidr-roa-format-07 (work in progress), | ||||
July 2010. | ||||
[I-D.ietf-sidr-rpki-manifests] | ||||
Austein, R., Huston, G., Kent, S., and M. Lepinski, | ||||
"Manifests for the Resource Public Key Infrastructure", | ||||
draft-ietf-sidr-rpki-manifests-08 (work in progress), | ||||
October 2010. | ||||
Appendix A. Acknowledgments | ||||
We acknowledge the editors of [I-D.ietf-sidr-rescerts-provisioning] | ||||
(Geoff Huston, Robert Loomans, Byron Ellacott, and Rob Austein), from | ||||
whom we took some of the text for this document. | ||||
We especially thank Rob Austein, who implemented the publication | ||||
protocol and helped us to understand it. | ||||
Authors' Addresses | Authors' Addresses | |||
Samuel Weiler | Samuel Weiler | |||
SPARTA, Inc. | SPARTA, Inc. | |||
7110 Samuel Morse Drive | 7110 Samuel Morse Drive | |||
Columbia, Maryland 21046 | Columbia, Maryland 21046 | |||
US | US | |||
Email: weiler@sparta.com | Email: weiler@tislabs.com | |||
Anuja Sonalker | Anuja Sonalker | |||
SPARTA, Inc. | SPARTA, Inc. | |||
7110 Samuel Morse Drive | 7110 Samuel Morse Drive | |||
Columbia, Maryland 21046 | Columbia, Maryland 21046 | |||
US | US | |||
Email: Anuja.Sonalker@sparta.com | Email: Anuja.Sonalker@sparta.com | |||
Rob Austein | ||||
ISC | ||||
950 Charter Street | ||||
Redwood City, CA 94063 | ||||
USA | ||||
Email: sra@isc.org | ||||
End of changes. 60 change blocks. | ||||
211 lines changed or deleted | 156 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |