idnits 2.17.1 draft-ietf-sidr-publication-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2013) is 3831 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 SPARTA, Inc. 4 Intended status: Standards Track A. Sonalker 5 Expires: April 23, 2014 Battelle Memorial Institute 6 R. Austein 7 Dragon Research Labs 8 October 20, 2013 10 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) 11 draft-ietf-sidr-publication-04 13 Abstract 15 This document defines a protocol for publishing Resource Public Key 16 Infrastructure (RPKI) objects. Even though the RPKI will have many 17 participants issuing certificates and creating other objects, it is 18 operationally useful to consolidate the publication of those objects. 19 This document provides the protocol for doing so. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 23, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 59 3.1. Common Details . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.1. Common XML Message Format . . . . . . . . . . . . . . 4 61 3.2. Control Sub-Protocol . . . . . . . . . . . . . . . . . . 5 62 3.2.1. Config Object . . . . . . . . . . . . . . . . . . . . 5 63 3.2.2. Client Object . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Publication Sub-Protocol . . . . . . . . . . . . . . . . 6 65 3.4. Error handling . . . . . . . . . . . . . . . . . . . . . 7 66 3.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.1. Set Query . . . . . . . . . . . . . . . . . . . 11 69 4.2. Set Reply . . . . . . . . . . . . . . . . . . . 12 70 4.3. Get Query . . . . . . . . . . . . . . . . . . . 12 71 4.4. Get Reply . . . . . . . . . . . . . . . . . . . 13 72 4.5. Create Query . . . . . . . . . . . . . . . . . 13 73 4.6. Create Reply . . . . . . . . . . . . . . . . . 14 74 4.7. Set Query . . . . . . . . . . . . . . . . . . . 14 75 4.8. Set Reply . . . . . . . . . . . . . . . . . . . 15 76 4.9. Get Query . . . . . . . . . . . . . . . . . . . 15 77 4.10. Get Reply . . . . . . . . . . . . . . . . . . . 15 78 4.11. List Query . . . . . . . . . . . . . . . . . . 16 79 4.12. List Reply . . . . . . . . . . . . . . . . . . 16 80 4.13. Destroy Query . . . . . . . . . . . . . . . . . 17 81 4.14. Destroy Reply . . . . . . . . . . . . . . . . . 17 82 4.15. Query . . . . . . . . . . . . . . . . . . . . 17 83 4.16. Reply . . . . . . . . . . . . . . . . . . . . 18 84 4.17. Query . . . . . . . . . . . . . . . . . . . . 18 85 4.18. Reply . . . . . . . . . . . . . . . . . . . . 19 86 4.19. With Text . . . . . . . . . . . . . . . . 19 87 4.20. Without Text . . . . . . . . . . . . . . 19 88 5. Operational Considerations . . . . . . . . . . . . . . . . . 19 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 93 8.2. Informative References . . . . . . . . . . . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 This document assumes a working knowledge of the Resource Public Key 99 Infrastructure (RPKI), which is intended to support improved routing 100 security on the Internet. [RFC6480] 102 In order to make participation in the RPKI easier, it is helpful to 103 have a few consolidated repositories for RPKI objects, thus saving 104 every participant from the cost of maintaining a new service. 105 Similarly, relying parties using the RPKI objects will find it faster 106 and more reliable to retrieve the necessary set from a smaller number 107 of repositories. 109 These consolidated RPKI object repositories will in many cases be 110 outside the administrative scope of the organization issuing a given 111 RPKI object. Hence the need for a protocol to publish RPKI objects. 113 This document defines the RPKI publication protocol, including a sub- 114 protocol for configuring the publication engine. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 "Publication engine" and "publication server" are used 123 interchangeably to refer to the server providing the service 124 described in this document. 126 "Business Public Key Infrastructure" ("Business PKI" or "BPKI") 127 refers to a PKI, separate from the RPKI, used to authenticate clients 128 to the publication engine. 130 2. Context 132 This protocol was designed specifically for the case where an 133 internet registry, already issuing RPKI certificates to its children, 134 also wishes to run a publication service for its children. 136 We use the term "Business PKI" here because an internet registry 137 might already have a PKI, separate from the RPKI, for authenticating 138 its clients and might wish to reuse that PKI for this protocol. Such 139 reuse is not a requirement. 141 3. Protocol Specification 142 In summary, the publication protocol uses XML messages wrapped in 143 CMS, carried over HTTP transport. 145 The publication procotol consists of two separate subprotocols. The 146 first is a control protocol used to configure a publication engine. 147 The second subprotocol, which we refer to by the overloaded term 148 "publication protocol", is used to request publication of specific 149 objects. The publication engine operates a single HTTP server on a 150 single port. It distinguishes between the two protocols by using 151 different URLs for them. 153 3.1. Common Details 155 This section discusses details that the two subprotocols have in 156 common, including the transport and CMS wrappers. 158 Both protocols use a simple request/response interaction. The client 159 passes a request to the server, and the server generates a 160 corresponding response. 162 A message exchange commences with the client initiating an HTTP POST 163 with content type of "application/rpki-publication", with the message 164 object as the body. The server's response will similarly be the body 165 of the response with a content type of "application/rpki- 166 publication". 168 The content of the POST and the server's response will be a well- 169 formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = 170 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. 172 3.1.1. Common XML Message Format 174 The XML schema for this protocol (including both subprotocols) is 175 below in Section 3.5. Both subprotocols use the same basic XML 176 message format, which looks like: 178 179 182 [one or more PDUs] 183 185 version: The value of this attribute is the version of this 186 protocol. This document describes version 2. 188 type: The possible values of this attribute are "reply" and "query". 190 A query PDU may be one of four types: config_query, client_query, 191 publish_query, or withdraw_query. The first two are used by the 192 control sub-protocol, the latter two by the publication sub-protocol. 194 A reply PDU may be one of five types: config_reply, client_reply, 195 publish_reply, withdraw_reply, or report_error_reply. 197 Each of these PDUs may include an optional tag to facilitate bulk 198 operation. If a tag is set in a query PDU, the corresponding 199 reply(s) MUST have the tag attribute set to the same value. 201 3.2. Control Sub-Protocol 203 The control sub-protocol is used to configure a publication server. 204 It can set global variables (at the moment, limited to a BPKI CRL) 205 and manage clients who are allowed to publish data on the server. 207 3.2.1. Config Object 209 The object allows configuration of data that apply to the 210 entire publication server rather than a particular client. There is 211 exactly one object in the publication server, and it only 212 supports the "set" and "get" actions -- it cannot be created or 213 destroyed. Its use is typically restricted to the repository 214 operator. 216 The object only has one data element that can be set: the 217 bpki_crl. This is used by the publication server when authenticating 218 clients. 220 3.2.2. Client Object 222 Unlike the object, the object represents one 223 client authorized to use the publication server. There may be more 224 than one object on each publication server. Again, its use 225 is typically restricted to the respository operator. 227 The object supports five actions: "create", "set", "get", 228 "list", and "destroy". Each client has a "client_handle" attribute, 229 which is used in responses and must be specified in "create", "set", 230 "get", or "destroy" actions. The "create" and "set" actions have an 231 optional flag to clear CMS-timestamp-based replay protection, to 232 allow recovery from misconfigured clocks. 234 Payload data which can be configured in a object include: 236 o base_uri (attribute): This attribute represents the base URI below 237 which the client will be allowed to publish data. Additional 238 constraints may be imposed by the publication server in certain 239 cases, for e.g., a child publishing directly under its parent. 241 o bpki_cert (element): This represents the X.509 BPKI CA certificate 242 for this client. This should be used as part of the certificate 243 chain when validating incoming CMS messages. Two valid approaches 244 exist. If the optional bpki_glue certificate is being used, then 245 the bpki_cert certificate should be issued by the bpki_glue 246 certificate; otherwise, the bpki_cert certificate should be issued 247 by the publication engine's bpki_ta certificate. 249 o bpki_glue (element): This is an additional (optional) type of 250 X.509 certificate for this client. It may be used in certain 251 pathological cross-certification cases which require a two- 252 certificate chain due to issuer name conflicts. When being used, 253 issuing order is that the bpki_glue certificate should be the 254 issuer of the bpki_cert certificate. Otherwise, it should be 255 issued by the publication engine's bpki_ta certificate. Since 256 this is an optional use certificate, it may be left unset if not 257 needed. 259 3.3. Publication Sub-Protocol 261 The publication sub-protocol requests publication or withdrawal from 262 publication of RPKI objects. 264 The publication protocol uses a common message format to request 265 publication of any RPKI object. This format was chosen specifically 266 to allow this protocol to accommodate new types of RPKI objects 267 without needing changes to this protocol. 269 Both the and objects have a payload of an 270 optional tag and a URI. The query also contains the DER 271 object to be published, encoded in Base64. 273 Note that every publish and withdraw action requires a new manifest, 274 thus every publish or withdraw action will involve at least two 275 objects. 277 3.4. Error handling 279 Errors are handled similarly in both subprotocols, and they're 280 handled at two levels. 282 Since all messages in this protocol are conveyed over HTTP 283 connections, basic errors are indicated via the HTTP response code. 284 4xx and 5xx responses indicate that something bad happened. Errors 285 that make it impossible to decode a query or encode a response are 286 handled in this way. 288 Where possible, errors will result in an XML message 289 which takes the place of the expected protocol response message. 290 messages are CMS-signed XML messages like the rest of 291 this protocol, and thus can be archived to provide an audit trail. 293 messages only appear in replies, never in queries. 294 The message can appear in both the control and 295 publication subprotocols. 297 Like all other messages in this protocol, the message 298 includes a "tag" attribute to assist in matching the error with a 299 particular query when using batching. It is optional to set the tag 300 on queries but, if set on the query, it MUST be set on the reply or 301 error. 303 The error itself is conveyed in the error_code (attribute). The 304 value of this attribute is a token indicating the specific error that 305 occurred. 307 The body of the element itself is an optional text 308 string; if present, this is debugging information. 310 3.5. XML Schema 312 The following is a RelaxNG compact form schema describing the 313 Publication Protocol. 315 # $Id: rpki-publication.rnc 2601 2013-10-18 19:21:28Z sra $ 316 # RelaxNG schema for RPKI publication protocol. 318 default namespace = 319 "http://www.hactrn.net/uris/rpki/publication-spec/" 321 # This is version 2 of the protocol. 323 version = "2" 324 # Top level PDU is either a query or a reply. 326 start = element msg { 327 attribute version { version } , 328 ( ( attribute type { "query" }, query_elt* ) | 329 ( attribute type { "reply" }, reply_elt* ) ) 330 } 332 # PDUs allowed in a query. 334 query_elt |= config_query 335 query_elt |= client_query 336 query_elt |= publish_query 337 query_elt |= withdraw_query 339 # PDUs allowed in a reply. 341 reply_elt |= config_reply 342 reply_elt |= client_reply 343 reply_elt |= publish_reply 344 reply_elt |= withdraw_reply 345 reply_elt |= report_error_reply 347 # Tag attributes for bulk operations. 349 tag = attribute tag { xsd:token { maxLength="1024" } } 351 # Base64 encoded DER stuff. 353 base64 = xsd:base64Binary 355 # Publication URLs. 357 uri_t = xsd:anyURI { maxLength="4096" } 358 uri = attribute uri { uri_t } 360 # Handles on remote objects (replaces passing raw SQL IDs). 362 object_handle = xsd:string { 363 maxLength = "255" 364 pattern="[\-_A-Za-z0-9/]*" 365 } 367 # Error codes. 369 error = xsd:token { maxLength="1024" } 371 # element (use restricted to repository operator) 372 config_payload = (element bpki_crl { base64 }?) 374 config_query |= element config { 375 attribute action { "set" }, 376 tag?, 377 config_payload 378 } 380 config_reply |= element config { 381 attribute action { "set" }, 382 tag? 383 } 385 config_query |= element config { 386 attribute action { "get" }, 387 tag? 388 } 390 config_reply |= element config { 391 attribute action { "get" }, 392 tag?, 393 config_payload 394 } 396 # element (use restricted to repository operator) 398 client_handle = attribute client_handle { object_handle } 400 client_payload = ( 401 attribute base_uri { uri_t }?, 402 element bpki_cert { base64 }?, 403 element bpki_glue { base64 }? 404 ) 406 client_clear_replay = ( 407 attribute clear_replay_protection { "yes" }? 408 ) 410 client_query |= element client { 411 attribute action { "create" }, 412 tag?, 413 client_handle, 414 client_clear_replay, 415 client_payload 416 } 418 client_reply |= element client { 419 attribute action { "create" }, 420 tag?, 421 client_handle 422 } 424 client_query |= element client { 425 attribute action { "set" }, 426 tag?, 427 client_handle, 428 client_clear_replay, 429 client_payload 430 } 432 client_reply |= element client { 433 attribute action { "set" }, 434 tag?, 435 client_handle 436 } 438 client_query |= element client { 439 attribute action { "get" }, 440 tag?, 441 client_handle 442 } 444 client_reply |= element client { 445 attribute action { "get" }, 446 tag?, 447 client_handle, 448 client_payload 449 } 451 client_query |= element client { 452 attribute action { "list" }, 453 tag? 454 } 456 client_reply |= element client { 457 attribute action { "list" }, 458 tag?, 459 client_handle, 460 client_payload 461 } 463 client_query |= element client { 464 attribute action { "destroy" }, 465 tag?, 466 client_handle 467 } 468 client_reply |= element client { 469 attribute action { "destroy" }, 470 tag?, 471 client_handle 472 } 474 # element 476 publish_query |= element publish { 477 tag?, 478 uri, 479 base64 480 } 482 publish_reply |= element publish { 483 tag?, 484 uri 485 } 487 # element 489 withdraw_query |= element withdraw { 490 tag?, 491 uri 492 } 494 withdraw_reply |= element withdraw { 495 tag?, 496 uri 497 } 499 # element 501 report_error_reply = element report_error { 502 tag?, 503 attribute error_code { error }, 504 xsd:string { maxLength="512000" }? 505 } 507 4. Examples 509 Following are examples of various queries and the corresponding 510 replies for the RPKI publication protocol 512 4.1. Set Query 513 517 519 520 MIIBezBlAgEBMA0GCSqGSIb3DQEBCwUAMCMxITAfBgNVBAMTGFRlc3QgQ2Vy 521 dGlmaWNhdGUgcHViZCBUQRcNMDgwNjAyMjE0OTQ1WhcNMDgwNzAyMjE0OTQ1 522 WqAOMAwwCgYDVR0UBAMCAQEwDQYJKoZIhvcNAQELBQADggEBAFWCWgBl4ljV 523 qX/CHo+RpqYtvmKMnjPVflMXUB7i28RGP4DAq4l7deDU7Q82xEJyE4TXMWDW 524 AV6UG6uUGum0VHWOcj9ohqyiZUGfOsKg2hbwkETm8sAENOsi1yNdyKGk6jZ1 525 6aF5fubxQqZa1pdGCSac1/ZYC5sLLhEz3kmz+B9z9mXFVc5TgAh4dN3Gy5ft 526 F8zZAFpDGnS4biCnRVqhGv6R0Lh/5xmii+ZU6kNDhbeMsjJg+ZOmtN+wMeHS 527 Ibjiy0WuuaZ3k2xSh0C94anrHBZAvvCRhbazjR0Ef5OMZ5lcllw3uO8IHuoi 528 sHKkehy4Y0GySdj98fV+OuiRTH9vt/M= 529 530 531 533 4.2. Set Reply 535 539 541 543 4.3. Get Query 545 549 551 553 4.4. Get Reply 555 559 561 562 MIIBezBlAgEBMA0GCSqGSIb3DQEBCwUAMCMxITAfBgNVBAMTGFRlc3QgQ2Vy 563 dGlmaWNhdGUgcHViZCBUQRcNMDgwNjAyMjE0OTQ1WhcNMDgwNzAyMjE0OTQ1 564 WqAOMAwwCgYDVR0UBAMCAQEwDQYJKoZIhvcNAQELBQADggEBAFWCWgBl4ljV 565 qX/CHo+RpqYtvmKMnjPVflMXUB7i28RGP4DAq4l7deDU7Q82xEJyE4TXMWDW 566 AV6UG6uUGum0VHWOcj9ohqyiZUGfOsKg2hbwkETm8sAENOsi1yNdyKGk6jZ1 567 6aF5fubxQqZa1pdGCSac1/ZYC5sLLhEz3kmz+B9z9mXFVc5TgAh4dN3Gy5ft 568 F8zZAFpDGnS4biCnRVqhGv6R0Lh/5xmii+ZU6kNDhbeMsjJg+ZOmtN+wMeHS 569 Ibjiy0WuuaZ3k2xSh0C94anrHBZAvvCRhbazjR0Ef5OMZ5lcllw3uO8IHuoi 570 sHKkehy4Y0GySdj98fV+OuiRTH9vt/M= 571 572 573 575 4.5. Create Query 577 581 585 586 MIIDGzCCAgOgAwIBAgIJAKi+/+wUhQlxMA0GCSqGSIb3DQEBBQUAMCQxIjAg 587 BgNVBAMTGVRlc3QgQ2VydGlmaWNhdGUgQm9iIFJvb3QwHhcNMDcwODAxMTk1 588 MzEwWhcNMDcwODMxMTk1MzEwWjAkMSIwIAYDVQQDExlUZXN0IENlcnRpZmlj 589 YXRlIEJvYiBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 590 rKYUtJaM5PH5917SG2ACc7iBYdQO2HYyu8Gb6i9Q2Gxc3cWEX7RTBvgOL79p 591 Wf3GIdnoupzMnoZVtY3GUx2G/0WkmLui2TCeDhcfXdQ4rcp8J3V/6ESj+yuE 592 PPOG8UN17mUKKgujrch6ZvgCDO9AyOK/uXu+ABQXTPsn2pVe2EVh3V004ShL 593 i8GKgVdqb/rW/6GTg0Xb/zLT6WWMuT++6sXTlztJdQYkRamJvKfQDU1naC8m 594 AkGf79Tba0xyBGAUII0GfREY6t4/+NAP2Yyb3xNlBqcJoTov0JfNKHZcCZeP 595 r79j7LK/hkZxxip+Na9xDpE+oQRV+DRukCRJdiqg+wIDAQABo1AwTjAMBgNV 596 HRMEBTADAQH/MB0GA1UdDgQWBBTDEsXJe6pjAQD4ULlB7+GMDBlimTAfBgNV 597 HSMEGDAWgBTDEsXJe6pjAQD4ULlB7+GMDBlimTANBgkqhkiG9w0BAQUFAAOC 598 AQEAWWkNcW6S1tKKqtzJsdfhjJiAAPQmOXJskv0ta/8f6Acgcum1YieNdtT0 599 n96P7CUHOWP8QBb91JzeewR7b6WJLwb1Offs3wNq3kk75pJe89r4XY39EZHh 600 MW+Dv0PhIKu2CgD4LeyH1FVTQkF/QObGEmkn+s+HTsuzd1l2VLwcP1Smsqep 601 6LAlFj62qqaIJzNeQ9NVkBqtkygnYlBOkaBTHfQTux3jYNpEo8JJB5e/WFdH 602 YyMNrG2xMOtIC7T4+IOHgT8PgrNhaeDg9ctewj0X8Qi9nI9nXeinicLX8vj6 603 hdEq3ORv7RZMJNYqv1HQ3wUE2B7fCPFv7EUwzaCds1kgRQ== 604 605 606 608 4.6. Create Reply 610 614 617 619 4.7. Set Query 621 625 628 629 MIIDGzCCAgOgAwIBAgIJAKi+/+wUhQlxMA0GCSqGSIb3DQEBBQUAMCQxIjAg 630 BgNVBAMTGVRlc3QgQ2VydGlmaWNhdGUgQm9iIFJvb3QwHhcNMDcwODAxMTk1 631 MzEwWhcNMDcwODMxMTk1MzEwWjAkMSIwIAYDVQQDExlUZXN0IENlcnRpZmlj 632 YXRlIEJvYiBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 633 rKYUtJaM5PH5917SG2ACc7iBYdQO2HYyu8Gb6i9Q2Gxc3cWEX7RTBvgOL79p 634 Wf3GIdnoupzMnoZVtY3GUx2G/0WkmLui2TCeDhcfXdQ4rcp8J3V/6ESj+yuE 635 PPOG8UN17mUKKgujrch6ZvgCDO9AyOK/uXu+ABQXTPsn2pVe2EVh3V004ShL 636 i8GKgVdqb/rW/6GTg0Xb/zLT6WWMuT++6sXTlztJdQYkRamJvKfQDU1naC8m 637 AkGf79Tba0xyBGAUII0GfREY6t4/+NAP2Yyb3xNlBqcJoTov0JfNKHZcCZeP 638 r79j7LK/hkZxxip+Na9xDpE+oQRV+DRukCRJdiqg+wIDAQABo1AwTjAMBgNV 639 HRMEBTADAQH/MB0GA1UdDgQWBBTDEsXJe6pjAQD4ULlB7+GMDBlimTAfBgNV 640 HSMEGDAWgBTDEsXJe6pjAQD4ULlB7+GMDBlimTANBgkqhkiG9w0BAQUFAAOC 641 AQEAWWkNcW6S1tKKqtzJsdfhjJiAAPQmOXJskv0ta/8f6Acgcum1YieNdtT0 642 n96P7CUHOWP8QBb91JzeewR7b6WJLwb1Offs3wNq3kk75pJe89r4XY39EZHh 643 MW+Dv0PhIKu2CgD4LeyH1FVTQkF/QObGEmkn+s+HTsuzd1l2VLwcP1Smsqep 644 6LAlFj62qqaIJzNeQ9NVkBqtkygnYlBOkaBTHfQTux3jYNpEo8JJB5e/WFdH 645 YyMNrG2xMOtIC7T4+IOHgT8PgrNhaeDg9ctewj0X8Qi9nI9nXeinicLX8vj6 646 hdEq3ORv7RZMJNYqv1HQ3wUE2B7fCPFv7EUwzaCds1kgRQ== 647 648 649 651 4.8. Set Reply 653 657 660 662 4.9. Get Query 664 668 671 673 4.10. Get Reply 675 679 683 684 MIIDGzCCAgOgAwIBAgIJAKi+/+wUhQlxMA0GCSqGSIb3DQEBBQUAMCQxIjAg 685 BgNVBAMTGVRlc3QgQ2VydGlmaWNhdGUgQm9iIFJvb3QwHhcNMDcwODAxMTk1 686 MzEwWhcNMDcwODMxMTk1MzEwWjAkMSIwIAYDVQQDExlUZXN0IENlcnRpZmlj 687 YXRlIEJvYiBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 688 rKYUtJaM5PH5917SG2ACc7iBYdQO2HYyu8Gb6i9Q2Gxc3cWEX7RTBvgOL79p 689 Wf3GIdnoupzMnoZVtY3GUx2G/0WkmLui2TCeDhcfXdQ4rcp8J3V/6ESj+yuE 690 PPOG8UN17mUKKgujrch6ZvgCDO9AyOK/uXu+ABQXTPsn2pVe2EVh3V004ShL 691 i8GKgVdqb/rW/6GTg0Xb/zLT6WWMuT++6sXTlztJdQYkRamJvKfQDU1naC8m 692 AkGf79Tba0xyBGAUII0GfREY6t4/+NAP2Yyb3xNlBqcJoTov0JfNKHZcCZeP 693 r79j7LK/hkZxxip+Na9xDpE+oQRV+DRukCRJdiqg+wIDAQABo1AwTjAMBgNV 694 HRMEBTADAQH/MB0GA1UdDgQWBBTDEsXJe6pjAQD4ULlB7+GMDBlimTAfBgNV 695 HSMEGDAWgBTDEsXJe6pjAQD4ULlB7+GMDBlimTANBgkqhkiG9w0BAQUFAAOC 696 AQEAWWkNcW6S1tKKqtzJsdfhjJiAAPQmOXJskv0ta/8f6Acgcum1YieNdtT0 697 n96P7CUHOWP8QBb91JzeewR7b6WJLwb1Offs3wNq3kk75pJe89r4XY39EZHh 698 MW+Dv0PhIKu2CgD4LeyH1FVTQkF/QObGEmkn+s+HTsuzd1l2VLwcP1Smsqep 699 6LAlFj62qqaIJzNeQ9NVkBqtkygnYlBOkaBTHfQTux3jYNpEo8JJB5e/WFdH 700 YyMNrG2xMOtIC7T4+IOHgT8PgrNhaeDg9ctewj0X8Qi9nI9nXeinicLX8vj6 701 hdEq3ORv7RZMJNYqv1HQ3wUE2B7fCPFv7EUwzaCds1kgRQ== 702 703 704 706 4.11. List Query 708 712 714 716 4.12. List Reply 718 722 725 726 MIIDGzCCAgOgAwIBAgIJAKi+/+wUhQlxMA0GCSqGSIb3DQEBBQUAMCQxIjAg 727 BgNVBAMTGVRlc3QgQ2VydGlmaWNhdGUgQm9iIFJvb3QwHhcNMDcwODAxMTk1 728 MzEwWhcNMDcwODMxMTk1MzEwWjAkMSIwIAYDVQQDExlUZXN0IENlcnRpZmlj 729 YXRlIEJvYiBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 730 rKYUtJaM5PH5917SG2ACc7iBYdQO2HYyu8Gb6i9Q2Gxc3cWEX7RTBvgOL79p 731 Wf3GIdnoupzMnoZVtY3GUx2G/0WkmLui2TCeDhcfXdQ4rcp8J3V/6ESj+yuE 732 PPOG8UN17mUKKgujrch6ZvgCDO9AyOK/uXu+ABQXTPsn2pVe2EVh3V004ShL 733 i8GKgVdqb/rW/6GTg0Xb/zLT6WWMuT++6sXTlztJdQYkRamJvKfQDU1naC8m 734 AkGf79Tba0xyBGAUII0GfREY6t4/+NAP2Yyb3xNlBqcJoTov0JfNKHZcCZeP 735 r79j7LK/hkZxxip+Na9xDpE+oQRV+DRukCRJdiqg+wIDAQABo1AwTjAMBgNV 736 HRMEBTADAQH/MB0GA1UdDgQWBBTDEsXJe6pjAQD4ULlB7+GMDBlimTAfBgNV 737 HSMEGDAWgBTDEsXJe6pjAQD4ULlB7+GMDBlimTANBgkqhkiG9w0BAQUFAAOC 738 AQEAWWkNcW6S1tKKqtzJsdfhjJiAAPQmOXJskv0ta/8f6Acgcum1YieNdtT0 739 n96P7CUHOWP8QBb91JzeewR7b6WJLwb1Offs3wNq3kk75pJe89r4XY39EZHh 740 MW+Dv0PhIKu2CgD4LeyH1FVTQkF/QObGEmkn+s+HTsuzd1l2VLwcP1Smsqep 741 6LAlFj62qqaIJzNeQ9NVkBqtkygnYlBOkaBTHfQTux3jYNpEo8JJB5e/WFdH 742 YyMNrG2xMOtIC7T4+IOHgT8PgrNhaeDg9ctewj0X8Qi9nI9nXeinicLX8vj6 743 hdEq3ORv7RZMJNYqv1HQ3wUE2B7fCPFv7EUwzaCds1kgRQ== 744 745 746 748 4.13. Destroy Query 750 754 757 759 4.14. Destroy Reply 761 765 768 770 4.15. Query 772 776 778 MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhE 779 RjRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XDTA4 780 MDUyMjE4MDUxMloXDTA4MDUyNDE3NTQ1M1owMzExMC8GA1UEAxMoOEZCODIx 781 OEYwNkU1MEFCNzAyQTdEOTZEQzhGMENEQ0Q4MjhGN0YxNzCCASIwDQYJKoZI 782 hvcNAQEBBQADggEPADCCAQoCggEBAMeziKp0k5nP7v6SZoNsXIMQYRgNtC6F 783 r/9Xm/1yQHomiPqHUk47rHhGojYiK5AhkrwoYhkH4UjJl2iwklDYczXuaBU3 784 F5qrKlZ4aZnjIxdlP7+hktVpeApL6yuJTUAYeC3UIxnLDVdD6phydZ/FOQlu 785 ffiNDjzteCCvoyOUatqt8WB+oND6LToHp028g1YUYLHG6mur0dPdcHOVXLSm 786 UDuZ1HDz1nDuYvIVKjB/MpH9aW9XeaQ6ZFIlZVPwuuvI2brR+ThH7Gv27GL/ 787 o8qFdC300VQfoTZ+rKPGDE8K1cI906BL4kiwx9z0oiDcE96QCz+B0vsjc9mG 788 aA1jgAxlXWsCAwEAAaOCAhcwggITMB0GA1UdDgQWBBSPuCGPBuUKtwKn2W3I 789 8M3Ngo9/FzAfBgNVHSMEGDAWgBTfSoAX5mqekXLkYS2M9Mg/I43iozBVBgNV 790 HR8ETjBMMEqgSKBGhkRyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQv 791 UklSLzEvMzBxQUYtWnFucEZ5NUdFdGpQVElQeU9ONHFNLmNybDBFBggrBgEF 792 BQcBAQQ5MDcwNQYIKwYBBQUHMAKGKXJzeW5jOi8vbG9jYWxob3N0OjQ0MDAv 793 dGVzdGJlZC9XT01CQVQuY2VyMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIw 794 DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZsGCCsGAQUFBwEL 795 BIGOMIGLMDQGCCsGAQUFBzAFhihyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rl 796 c3RiZWQvUklSL1IwLzEvMFMGCCsGAQUFBzAKhkdyc3luYzovL2xvY2FsaG9z 797 dDo0NDAwL3Rlc3RiZWQvUklSL1IwLzEvajdnaGp3YmxDcmNDcDlsdHlQRE56 798 WUtQZnhjLm1uZjAaBggrBgEFBQcBCAEB/wQLMAmgBzAFAgMA/BUwPgYIKwYB 799 BQUHAQcBAf8ELzAtMCsEAgABMCUDAwAKAzAOAwUAwAACAQMFAcAAAiAwDgMF 800 AsAAAiwDBQDAAAJkMA0GCSqGSIb3DQEBCwUAA4IBAQCEhuH7jtI2PJY6+zwv 801 306vmCuXhtu9Lr2mmRw2ZErB8EMcb5xypMrNqMoKeu14K2x4a4RPJkK4yATh 802 M81FPNRsU5mM0acIRnAPtxjHvPME7PHN2w2nGLASRsZmaa+b8A7SSOxVcFUR 803 azENztppsolHeTpm0cpLItK7mNpudUg1JGuFo94VLf1MnE2EqARG1vTsNhel 804 /SM/UvOArCCOBvf0Gz7kSuupDSZ7qx+LiDmtEsLdbGNQBiYPbLrDk41PHrxd 805 x28qIj7ejZkRzNFw/3pi8/XK281h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx 806 0iwPYdLiDbdWFbtTdPcXBauY 807 808 810 4.16. Reply 812 816 818 820 4.17. Query 822 826 829 831 4.18. Reply 833 837 839 841 4.19. With Text 843 847 849 Shampooing with sterno again, are we? 850 851 853 4.20. Without Text 855 859 861 863 5. Operational Considerations 865 There are two basic options open to the repository operator as to how 866 the publication tree is laid out. The first option is simple: each 867 publication client is given its own directory one level below the top 868 of the rcynic module, and there is no overlap between the publication 869 spaces used by different clients. For example: 871 rsync://example.org/rpki/Alice/ 872 rsync://example.org/rpki/Bob/ 873 rsync://example.org/rpki/Carol/ 875 This has the advantage of being very easy for the publication 876 operator to manage, but has the drawback of making it difficult for 877 relying parties to fetch published objects both safely and as 878 efficiently as possible. 880 Given that the mandatory-to-implement retrieval protocol for relying 881 parties is rsync, a more efficient repository structure would be one 882 which minimized the number of rsync fetches required. One such 883 structure would be one in which the publication directories for 884 subjects were placed underneath the publication directories of their 885 issuers: since the normal synchronization tree walk is top-down, this 886 can significantly reduce the total number of rsync connections 887 required to synchronize. For example: 889 rsync://example.org/rpki/Alice/ 890 rsync://example.org/rpki/Alice/Bob/ 891 rsync://example.org/rpki/Alice/Bob/Carol/ 893 Preliminary measurement suggests that, in the case of large numbers 894 of small publication directories, the time needed to set up and tear 895 down individual rsync connections becomes significant, and that a 896 properly optimized tree structure can reduce synchronization time by 897 an order of magnitude. 899 The more complex tree structure does require careful attention to the 900 base_uri attribute values when setting up clients. In the example 901 above, assuming that Alice issues to Bob who in turn issues to Carol, 902 Alice has ceded control of a portion of her publication space to Bob, 903 who has in turn ceded a portion of that to Carol, and the base_uri 904 attributes in the setup messages should reflect this. 906 The details of how the repository operator determines that Alice has 907 given Bob permission to nest Bob's publication directory under 908 Alice's is outside the scope of this protocol. 910 6. IANA Considerations 912 IANA is asked to register the application/rpki-publication MIME media 913 type as follows: 915 MIME media type name: application 916 MIME subtype name: rpki-publication 917 Required parameters: None 918 Optional parameters: None 919 Encoding considerations: binary 920 Security considerations: Carries an RPKI Publication Protocol 921 Message, as defined in this document. 922 Interoperability considerations: None 923 Published specification: This document 924 Applications which use this media type: HTTP 925 Additional information: 926 Magic number(s): None 927 File extension(s): 928 Macintosh File Type Code(s): 929 Person & email address to contact for further information: 930 Rob Austein 931 Intended usage: COMMON 932 Author/Change controller: Rob Austein 934 7. Security Considerations 936 The RPKI publication protocol and the data it publishes use entirely 937 separate PKIs for authentication. The published data is 938 authenticated within the RPKI, and this protocol has nothing to do 939 with that authentication, nor does it require that the published 940 objects be valid in the RPKI. The publication protocol uses a 941 separate Business PKI (BPKI) to authenticate its messages. 943 Each of the RPKI publication protocol messages is CMS-signed. 944 Because of that protection at the application layer, this protocol 945 does not require the use of HTTPS or other transport security 946 mechanisms. 948 Compromise of a publication server, perhaps through mismanagement of 949 BPKI keys, could lead to a denial-of-service attack on the RPKI. An 950 attacker gaining access to BPKI keys could use this protocol delete 951 (withdraw) RPKI objects, leading to routing changes or failures. 952 Accordingly, as in most PKIs, good key management practices are 953 important. 955 8. References 957 8.1. Normative References 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", RFC 2119, BCP 14, March 1997. 962 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 963 5652, STD 70, September 2009. 965 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 966 Protocol for Provisioning Resource Certificates", RFC 967 6492, February 2012. 969 8.2. Informative References 971 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 972 Secure Internet Routing", RFC 6480, February 2012. 974 Authors' Addresses 976 Samuel Weiler 977 SPARTA, Inc. 978 7110 Samuel Morse Drive 979 Columbia, Maryland 21046 980 US 982 Email: weiler@tislabs.com 984 Anuja Sonalker 985 Battelle Memorial Institute 987 Email: sonalkera@battelle.org 989 Rob Austein 990 Dragon Research Labs 992 Email: sra@hactrn.net