idnits 2.17.1 draft-ietf-sidr-publication-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4666 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-sidr-rescerts-provisioning-10 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Weiler 3 Internet-Draft A. Sonalker 4 Intended status: Standards Track SPARTA, Inc. 5 Expires: January 12, 2012 R. Austein 6 ISC 7 July 11, 2011 9 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) 10 draft-ietf-sidr-publication-01 12 Abstract 14 This document defines a protocol for publishing Resource Public Key 15 Infrastructure (RPKI) objects. Even though the RPKI will have many 16 participants issuing certificates and creating other objects, it is 17 operationally useful to consolidate the publication of those objects. 18 This document provides the protocol for doing so. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 12, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Common Details . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1.1. Common XML Message Format . . . . . . . . . . . . . . 4 60 3.2. Control Sub-Protocol . . . . . . . . . . . . . . . . . . . 5 61 3.2.1. Config Object . . . . . . . . . . . . . . . . . . . . 5 62 3.2.2. Client Object . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Publication Sub-Protocol . . . . . . . . . . . . . . . . . 6 64 3.4. Error handling . . . . . . . . . . . . . . . . . . . . . . 7 65 3.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Operational Considerations . . . . . . . . . . . . . . . . . . 9 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 This document assumes a working knowledge of the Resource Public Key 77 Infrastructure (RPKI), which is intended to support improved routing 78 security on the Internet. [I-D.ietf-sidr-arch] 80 In order to make participation in the RPKI easier, it is helpful to 81 have a few consolidated repositories for RPKI objects, thus saving 82 every participant from the cost of maintaining a new service. 83 Similarly, relying parties using the RPKI objects will find it faster 84 and more reliable to retrieve the necessary set from a smaller number 85 of repositories. 87 These consolidated RPKI object repositories will in many cases be 88 outside the administrative scope of the organization issuing a given 89 RPKI object. Hence the need for a protocol to publish RPKI objects. 91 This document defines the RPKI publication protocol, including a sub- 92 protocol for configuring the publication engine. 94 1.1. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 "Publication engine" and "publication server" are used 101 interchangeably to refer to the server providing the service 102 described in this document. 104 "Business Public Key Infrastructure" ("Business PKI" or "BPKI") 105 refers to a PKI, separate from the RPKI, used to authenticate clients 106 to the publication engine. 108 2. Context 110 This protocol was designed specifically for the case where an 111 internet registry, already issuing RPKI certificates to its children, 112 also wishes to run a publication service for its children. 114 We use the term "Business PKI" here because an internet registry 115 might already have a PKI, separate from the RPKI, for authenticating 116 its clients and might wish to reuse that PKI for this protocol. Such 117 reuse is not a requirement. 119 3. Protocol Specification 121 In summary, the publication protocol uses XML messages wrapped in 122 CMS, carried over HTTP transport. 124 The publication procotol consists of two separate subprotocols. The 125 first is a control protocol used to configure a publication engine. 126 The second subprotocol, which we refer to by the overloaded term 127 "publication protocol", is used to request publication of specific 128 objects. The publication engine operates a single HTTP server on a 129 single port. It distinguishes between the two protocols by using 130 different URLs for them. 132 3.1. Common Details 134 This section discusses details that the two subprotocols have in 135 common, including the transport and CMS wrappers. 137 Both protocols use a simple request/response interaction. The client 138 passes a request to the server, and the server generates a 139 corresponding response. 141 A message exchange commences with the client initiating an HTTP POST 142 with content type of "application/rpki-publication", with the message 143 object as the body. The server's response will similarly be the body 144 of the response with a content type of "application/ 145 rpki-publication". 147 The content of the POST and the server's response will be a well- 148 formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = 149 1.2.840.113549.1.7.2 as described in Section 3.1 of 150 [I-D.ietf-sidr-rescerts-provisioning]. 152 3.1.1. Common XML Message Format 154 The XML schema for this protocol (including both subprotocols) is 155 below in Section 3.5. Both subprotocols use the same basic XML 156 message format, which looks like: 158 159 162 [one or more PDUs] 163 165 version: 166 The value of this attribute is the version of this protocol. 167 This document describes version 2. 169 type: 170 The possible values of this attribute are "reply" and "query". 172 A query PDU may be one of four types: config_query, client_query, 173 publish_query, or withdraw_query. The first two are used by the 174 control sub-protocol, the latter two by the publication sub-protocol. 176 A reply PDU may be one of five types: config_reply, client_reply, 177 publish_reply, withdraw_reply, or report_error_reply. 179 Each of these PDUs may include an optional tag to facilitate bulk 180 operation. If a tag is set in a query PDU, the corresponding 181 reply(s) MUST have the tag attribute set to the same value. 183 3.2. Control Sub-Protocol 185 The control sub-protocol is used to configure a publication server. 186 It can set global variables (at the moment, limited to a BPKI CRL) 187 and manage clients who are allowed to publish data on the server. 189 3.2.1. Config Object 191 The object allows configuration of data that apply to the 192 entire publication server rather than a particular client. There is 193 exactly one object in the publication server, and it only 194 supports the "set" and "get" actions -- it cannot be created or 195 destroyed. Its use is typically restricted to the repository 196 operator. 198 The object only has one data element that can be set: the 199 bpki_crl. This is used by the publication server when authenticating 200 clients. 202 3.2.2. Client Object 204 Unlike the object, the object represents one 205 client authorized to use the publication server. There may well be 206 more than one object on each publication server. Again, 207 its use is typically restricted to the respository operator. 209 The object supports five actions: "create", "set", "get", 210 "list", and "destroy". Each client has a "client_handle" attribute, 211 which is used in responses and must be specified in "create", "set", 212 "get", or "destroy" actions. 214 Payload data which can be configured in a object include: 216 o base_uri (attribute): This attribute represents the base URI below 217 which the client will be allowed to publish data. Additional 218 constraints may be imposed by the publication server in certain 219 cases, for e.g., a child publishing directly under its parent. 221 o bpki_cert (element): This represents the X.509 BPKI CA certificate 222 for this client. This should be used as part of the certificate 223 chain when validating incoming CMS messages. Two valid approaches 224 exist. If the optional bpki_glue certificate is being used, then 225 the bpki_cert certificate should be issued by the bpki_glue 226 certificate; otherwise, the bpki_cert certificate should be issued 227 by the publication engine's bpki_ta certificate. 229 o bpki_glue (element): This is an additional (optional) type of 230 X.509 certificate for this client. It may be used in certain 231 pathological cross-certification cases which require a two- 232 certificate chain due to issuer name conflicts. When being used, 233 issuing order is that the bpki_glue certificate should be the 234 issuer of the bpki_cert certificate. Otherwise, it should be 235 issued by the publication engine's bpki_ta certificate. Since 236 this is an optional use certificate, it may be left unset if not 237 needed. 239 3.3. Publication Sub-Protocol 241 The sub-publication protocol requests publication or withdrawal from 242 publication of RPKI objects. 244 The publication protocol uses a common message format to request 245 publication of any RPKI object. This format was chosen specifically 246 to allow this protocol to accommodate new types of RPKI objects 247 without needing changes to this protocol. 249 Both the and objects have a payload of an 250 optional tag and a URI. The query also contains the DER 251 object to be published, encoded in Base64. 253 Note that every publish and withdraw action requires a new manifest, 254 thus every publish or withdraw action will involve at least two 255 objects. 257 3.4. Error handling 259 Errors are handled similarly in both subprotocols, and they're 260 handled at two levels. 262 Since all messages in this protocol are conveyed over HTTP 263 connections, basic errors are indicated via the HTTP response code. 264 4xx and 5xx responses indicate that something bad happened. Errors 265 that make it impossible to decode a query or encode a response are 266 handled in this way. 268 Where possible, errors will result in an XML message 269 which takes the place of the expected protocol response message. 270 messages are CMS-signed XML messages like the rest of 271 this protocol, and thus can be archived to provide an audit trail. 273 messages only appear in replies, never in queries. 274 The message can appear in both the control and 275 publication subprotocols. 277 Like all other messages in this protocol, the message 278 includes a "tag" attribute to assist in matching the error with a 279 particular query when using batching. It is optional to set the tag 280 on queries but, if set on the query, it MUST be set on the reply or 281 error. 283 The error itself is conveyed in the error_code (attribute). The 284 value of this attribute is a token indicating the specific error that 285 occurred. 287 The body of the element itself is an optional text 288 string; if present, this is debugging information. 290 3.5. XML Schema 292 The following is a RelaxNG compact form schema describing the 293 Publication Protocol. 295 default namespace = "http://www.hactrn.net/uris/rpki/publication-spec/" 297 # Top level PDU 298 start = element msg { 299 attribute version { "2" } , 300 ( ( attribute type { "query" }, query_elt*) | 301 (attribute type { "reply" }, reply_elt*)) 302 } 304 # PDUs allowed in a query 305 query_elt = ( config_query | client_query | publish_query | 306 withdraw_query ) 308 # PDUs allowed in a reply 309 reply_elt = ( config_reply | client_reply | publish_reply | 310 withdraw_reply | report_error_reply ) 312 # Tag attributes for bulk operations 313 tag = attribute tag { xsd:token {maxLength="1024" } } 315 # Base64 encoded DER stuff 316 base64 = xsd:base64Binary 318 # Publication URLs 319 uri_t = xsd:anyURI { maxLength="4096" } 320 uri = attribute uri { uri_t } 322 # Handles on remote objects (replaces passing raw SQL IDs). NB: 323 # Unlike the up-down protocol, handles in this protocol allow 324 # "/" as a hierarchy delimiter. 325 object_handle = xsd:string { 326 maxLength="255" pattern="[\-_A-Za-z0-9/]*" } 328 # element (use restricted to repository operator) 329 # config_handle attribute: create, list, and destroy commands 330 # omitted deliberately. 331 config_payload = (element bpki_crl { base64 }?) 332 config_query |= element config { attribute action { "set" }, tag?, 333 config_payload } 334 config_reply |= element config { attribute action { "set" }, tag? } 335 config_query |= element config { attribute action { "get" }, tag? } 336 config_reply |= element config { attribute action { "get" }, tag?, 337 config_payload } 339 # element (use restricted to repository operator) 340 client_handle = attribute client_handle { object_handle } 341 client_payload = (attribute base_uri { uri_t }?, element bpki_cert { 342 base64 }?, element bpki_glue { base64 }?) 343 client_query |= element client { attribute action { "create" }, 344 tag?, client_handle, client_payload } 345 client_reply |= element client { attribute action { "create" }, 346 tag?, client_handle } 347 client_query |= element client { attribute action { "set" }, tag?, 348 client_handle, client_payload } 350 client_reply |= element client { attribute action { "set" }, tag?, 351 client_handle } 352 client_query |= element client { attribute action { "get" }, tag?, 353 client_handle } 354 client_reply |= element client { attribute action { "get" }, tag?, 355 client_handle, client_payload } 356 client_query |= element client { attribute action { "list" }, tag? } 357 client_reply |= element client { attribute action { "list" }, tag?, 358 client_handle, client_payload } 359 client_query |= element client { attribute action { "destroy" }, 360 tag?, client_handle } 361 client_reply |= element client { attribute action { "destroy" }, 362 tag?, client_handle } 364 # element 365 publish_query |= element publish { tag?, uri, base64 } 366 publish_reply |= element publish { tag?, uri } 368 # element 369 withdraw_query |= element withdraw { tag?, uri } 370 withdraw_reply |= element withdraw { tag?, uri } 372 # element 373 error = xsd:token { maxLength="1024" } 374 report_error_reply = element report_error { 375 tag?, 376 attribute error_code { error }, 377 xsd:string { maxLength="512000" }? 378 } 380 4. Operational Considerations 382 Placeholder section to talk about nesting children under parents in 383 the same repository, to allow for a single rsync to fetch both 384 (observing that the rsync setup times tends to dominate over the sync 385 time). And, more distressingly, talk about the access control 386 impacts of that nesting. 388 5. IANA Considerations 390 IANA is asked to register the application/rpki-publication MIME media 391 type as follows: 393 MIME media type name: application 394 MIME subtype name: rpki-publication 395 Required parameters: None 396 Optional parameters: None 397 Encoding considerations: binary 398 Security considerations: Carries an RPKI Publication Protocol 399 Message, as defined in this document. 400 Interoperability considerations: None 401 Published specification: This document 402 Applications which use this media type: HTTP 403 Additional information: 404 Magic number(s): None 405 File extension(s): 406 Macintosh File Type Code(s): 407 Person & email address to contact for further information: 408 Rob Austein 409 Intended usage: COMMON 410 Author/Change controller: Rob Austein 412 6. Security Considerations 414 7. References 416 7.1. Normative References 418 [I-D.ietf-sidr-rescerts-provisioning] 419 Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 420 Protocol for Provisioning Resource Certificates", 421 draft-ietf-sidr-rescerts-provisioning-10 (work in 422 progress), June 2011. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 428 RFC 5652, September 2009. 430 7.2. Informative References 432 [I-D.ietf-sidr-arch] 433 Lepinski, M. and S. Kent, "An Infrastructure to Support 434 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 435 progress), May 2011. 437 Authors' Addresses 439 Samuel Weiler 440 SPARTA, Inc. 441 7110 Samuel Morse Drive 442 Columbia, Maryland 21046 443 US 445 Email: weiler@tislabs.com 447 Anuja Sonalker 448 SPARTA, Inc. 449 7110 Samuel Morse Drive 450 Columbia, Maryland 21046 451 US 453 Email: Anuja.Sonalker@sparta.com 455 Rob Austein 456 ISC 457 950 Charter Street 458 Redwood City, CA 94063 459 USA 461 Email: sra@isc.org