idnits 2.17.1 draft-weiler-sidr-publication-00.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 are 20 instances of too long lines in the document, the longest one being 5 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 5, 2010) is 5036 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) == Unused Reference: 'I-D.ietf-sidr-res-certs' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 449, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 == Outdated reference: A later version (-11) exists of draft-ietf-sidr-rescerts-provisioning-06 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-09 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-06 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-07 Summary: 3 errors (**), 0 flaws (~~), 11 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 6, 2011 July 5, 2010 7 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) 8 draft-weiler-sidr-publication-00 10 Abstract 12 This document defines a protocol for publishing Resource Public Key 13 Infrastructure (RPKI) objects. Even though the RPKI will have many 14 participants issuing certificates and creating other objects, it is 15 operationally useful to consolidate the publication of those objects. 16 This document provides the protocol for that. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 6, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Common Details . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1.1. Common XML Message Format . . . . . . . . . . . . . . 4 58 3.2. Control Protocol . . . . . . . . . . . . . . . . . . . . . 5 59 3.2.1. Config Object . . . . . . . . . . . . . . . . . . . . 5 60 3.2.2. Client Object . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Publication Protocol . . . . . . . . . . . . . . . . . . . 6 62 3.4. Error handling . . . . . . . . . . . . . . . . . . . . . . 6 63 3.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Operational Considerations . . . . . . . . . . . . . . . . . . 10 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 This document assumes a working knowledge of the Resource Public Key 76 Infrastructure (RPKI), which is intended to support improved routing 77 security on the Internet. [I-D.ietf-sidr-arch] 79 In order to make participation in the RPKI easier, it is helpful to 80 have a few consolidated repositories for RPKI objects, thus saving 81 every participant from the cost of maintaining a new service. 82 Similarly, relying parties using the RPKI objects will find it faster 83 and more reliable to retrieve the necessary set from a smaller number 84 of repositories. 86 These consolidated RPKI object repositories will in many cases be 87 outside the administrative scope of the organization issuing a given 88 RPKI object. Hence the need for a protocol to publish RPKI objects. 90 This document defines the RPKI publication protocol, including a sub- 91 protocol for configuring the publication engine. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 "Publication engine" and "publication server" are used 100 interchangeably to refer to the server providing the service 101 described in this document. 103 "Business Public Key Infrastructure" ("Business PKI" or "BPKI") 104 refers to a PKI, separate from the RPKI, used to authenticate clients 105 to the publication engine. 107 2. Context 109 This protocol was designed specifically for the case where an 110 internet registry, already issuing RPKI certificates to its children, 111 also wishes to run a publication service for its children. 113 We use the term "Business PKI" here to suggest that an internet 114 registry might already have a PKI, separate from the RPKI, for 115 authenticating its clients and might wish to reuse that PKI for this 116 protocol. Such reuse is not a requirement. 118 3. Protocol Specification 120 In summary, the publication protocol uses XML messages wrapped in 121 CMS, carried over HTTP transport. 123 The publication procotol consists of two separate subprotocols. The 124 first is a control protocol used to configure a publication engine. 125 The second subprotocol, which we refer to by the overloaded term 126 "publication protocol", is used to request publication of specific 127 objects. The publication engine operates a single HTTP server on a 128 single port. It distinguishes between the two protocols by using 129 different URLs for them. 131 3.1. Common Details 133 This section discusses details that the two subprotocols have in 134 common, including the transport and CMS wrappers. This portion of 135 the protocol is largely inherited from the provisioning protocol 136 ([I-D.ietf-sidr-rescerts-provisioning]). 138 Both protocols use a simple request/response interaction. The client 139 passes a request to the server, and the server generates a 140 corresponding response. A message exchange commences with the client 141 initiating an HTTP POST with content type of "application/x-rpki", 142 with the message object as the body. The server's response will 143 similarly be the body of the response with a content type of 144 "application/x-rpki". 146 The content of the POST, and the server's response, will be a well- 147 formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = 148 1.2.840.113549.1.7.2 as described in Section 3.1 of 149 [I-D.ietf-sidr-rescerts-provisioning]. 151 3.1.1. Common XML Message Format 153 The publication protocol uses the same message passing design as the 154 provisioning protocol. The XML schema for this protocol (including 155 both subprotocols) is below in Section 3.5. Both subprotocols use 156 the same basic XML message format, which looks like: 158 159 162 [one or more PDUs] 163 164 version: 165 The value of this attribute is the version of this protocol. 166 This document describes version 1. 168 type: 169 The possible values of this attribute are "reply" and "query". 171 3.2. Control Protocol 173 The control protocol is used to configure a publication server. It 174 can set global variables (at the moment, limited to a BPKI CRL) and 175 manage clients who are allowed to publish data on the server. 177 The control protocol has two objects: the object, and the 178 object. 180 3.2.1. Config Object 182 The object allows configuration of data that apply to the 183 entire publication server rather than a particular client. There is 184 exactly one object in the publication server, and it only 185 supports the "set" and "get" actions -- it cannot be created or 186 destroyed. 188 The object only has one data element that can be set: the 189 bpki_crl. This is used by the publication server when authenticating 190 clients. 192 3.2.2. Client Object 194 Unlike the object the object represents one 195 client authorized to use the publication server. 197 The object supports five actions: "create", "set", "get", 198 "list", and "destroy". Each client has a "client_handle" attribute, 199 which is used in responses and must be specified in "create", "set", 200 "get", or "destroy" actions. 202 Payload data which can be configured in a object include: 203 o base_uri (attribute): This attribute represents the base URI below 204 which the client will be allowed to publish data. Additional 205 constraints may be imposed by the Publication Server in certain 206 cases, for e.g., a child publishing directly under its parent. 207 o bpki_cert (element): This represents the X509 BPKI CA certificate 208 for this client. This should be used as part of the certificate 209 chain when validating incoming TLS and CMS messages. Two valid 210 approaches exist. If the optional bpki_glue certificate is being 211 used, then the bpki_cert certificate should be issued by the 212 bpki_glue certificate; otherwise, the bpki_cert certificate should 213 be issued by the publication engine's bpki_ta certificate. 214 o bpki_glue (element): This is an additional (optional) type of X509 215 certificate for this client. It may be used in certain 216 pathological cross-certification cases which require a two- 217 certificate chain due to issuer name conflicts. When being used, 218 issuing order is that the bpki_glue certificate should be the 219 issuer of the bpki_cert certificate. Otherwise, it should be 220 issued by the publication engine's bpki_ta certificate. Since 221 this is an optional use certificate, it may be left unset if not 222 needed. 224 3.3. Publication Protocol 226 The publication protocol is structured differently from the control 227 protocol in that objects in the publication protocol represent 228 objects to be published or objects to be withdrawn from publication. 230 Each kind of object supports two actions: "publish" and "withdraw". 231 In each case the XML element representing the object to be published 232 or withdrawn has a "uri" attribute which contains the publication 233 URI. For "publish" actions, the XML element body contains the DER 234 object to be published, encoded in Base64; for "withdraw" actions, 235 the XML element body is empty. 237 The publication protocol uses four types of objects: 238 o Certificate Object: The object represents an RPKI 239 certificate to be published or withdrawn. 240 o CRL Object: The object represents an RPKI CRL to be 241 published or withdrawn. 242 o Manifest Object: The object represents an RPKI 243 publication manifest to be published or withdrawn. See 244 [I-D.ietf-sidr-rpki-manifests] for more information on manifests. 245 o ROA Object: The object represents a ROA to be published or 246 withdrawn. See [I-D.ietf-sidr-roa-format] for more information on 247 ROAs. 249 Note that every publication or withdrawal action requires a new 250 manifest, thus every publication or withdrawal action will involve at 251 least two objects. 253 3.4. Error handling 255 Errors are handled similarly in both subprotocols, and they're 256 handled at two levels. 258 Since all messages in this protocol are conveyed over HTTP 259 connections, basic errors are indicated via the HTTP response code. 261 4xx and 5xx responses indicate that something bad happened. Errors 262 that make it impossible to decode a query or encode a response are 263 handled in this way. 265 Where possible, errors will result in an XML message 266 which takes the place of the expected protocol response message. 267 messages are CMS-signed XML messages like the rest of 268 this protocol, and thus can be archived to provide an audit trail. 270 messages only appear in replies, never in queries. 271 The message can appear in both the control and 272 publication subprotocols. 274 The message includes an optional "tag" attribute to 275 assist in matching the error with a particular query when using 276 batching. 278 The error itself is conveyed in the error_code (attribute). The 279 value of this attribute is a token indicating the specific error that 280 occurred. [TODO: define these tokens] 282 The body of the element itself is an optional text 283 string; if present, this is debugging information. At present this 284 capabilty is not used, debugging information goes to syslog. 286 3.5. XML Schema 288 The following is a RelaxNG compact form schema describing the 289 Publication Protocol. 291 default namespace = "http://www.hactrn.net/uris/rpki/publication-spec/" 293 # Top level PDU 295 start = element msg { attribute version { xsd:positiveInteger { 296 maxInclusive="1" } }, ((attribute type { "query" }, query_elt*) | 297 (attribute type { "reply" }, reply_elt*)) } 299 # PDUs allowed in a query 300 query_elt = ( config_query | client_query | certificate_query | 301 crl_query | manifest_query | roa_query ) 303 # PDUs allowed in a reply 304 reply_elt = ( config_reply | client_reply | certificate_reply | 305 crl_reply | manifest_reply | roa_reply | report_error_reply ) 307 # Tag attributes for bulk operations 308 tag = attribute tag { xsd:token {maxLength="1024" } } 310 # Base64 encoded DER stuff 311 base64 = xsd:base64Binary { maxLength="512000" } 313 # Publication URLs 314 uri_t = xsd:anyURI { maxLength="4096" } 315 uri = attribute uri { uri_t } 317 # Handles on remote objects (replaces passing raw SQL IDs). NB: 318 # Unlike the up-down protocol, handles in this protocol allow "/" as a 319 # hierarchy delimiter. 320 object_handle = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" } 322 # element (use restricted to repository operator) 323 # config_handle attribute, create, list, and destroy commands omitted 324 # deliberately, see code for details 326 config_payload = (element bpki_crl { base64 }?) 328 config_query |= element config { attribute action { "set" }, tag?, 329 config_payload } 330 config_reply |= element config { attribute action { "set" }, tag? } 331 config_query |= element config { attribute action { "get" }, tag? } 332 config_reply |= element config { attribute action { "get" }, tag?, 333 config_payload } 335 # element (use restricted to repository operator) 337 client_handle = attribute client_handle { object_handle } 339 client_payload = (attribute base_uri { uri_t }?, element bpki_cert { 340 base64 }?, element bpki_glue { base64 }?) 342 client_query |= element client { attribute action { "create" }, tag?, 343 client_handle, client_payload } 344 client_reply |= element client { attribute action { "create" }, tag?, 345 client_handle } 346 client_query |= element client { attribute action { "set" }, tag?, 347 client_handle, client_payload } 348 client_reply |= element client { attribute action { "set" }, tag?, 349 client_handle } 350 client_query |= element client { attribute action { "get" }, tag?, 351 client_handle } 352 client_reply |= element client { attribute action { "get" }, tag?, 353 client_handle, client_payload } 354 client_query |= element client { attribute action { "list" }, tag? } 355 client_reply |= element client { attribute action { "list" }, tag?, 356 client_handle, client_payload } 357 client_query |= element client { attribute action { "destroy" }, tag?, 358 client_handle } 359 client_reply |= element client { attribute action { "destroy" }, tag?, 360 client_handle } 362 # element 364 certificate_query |= element certificate { attribute action { 365 "publish" }, tag?, uri, base64 } 367 certificate_reply |= element certificate { attribute action { 368 "publish" }, tag?, uri } 370 certificate_query |= element certificate { attribute action { 371 "withdraw" }, tag?, uri } 373 certificate_reply |= element certificate { attribute action { 374 "withdraw" }, tag?, uri } 376 # element 378 crl_query |= element crl { attribute action { "publish" }, tag?, uri, 379 base64 } 380 crl_reply |= element crl { attribute action { "publish" }, tag?, uri } 381 crl_query |= element crl { attribute action { "withdraw" }, tag?, uri } 382 crl_reply |= element crl { attribute action { "withdraw" }, tag?, uri } 384 # element 386 manifest_query |= element manifest { attribute action { "publish" }, 387 tag?, uri, base64 } 388 manifest_reply |= element manifest { attribute action { "publish" }, 389 tag?, uri } 390 manifest_query |= element manifest { attribute action { "withdraw" }, 391 tag?, uri } 392 manifest_reply |= element manifest { attribute action { "withdraw" }, 393 tag?, uri } 395 # element 397 roa_query |= element roa { attribute action { "publish" }, tag?, uri, 398 base64 } 399 roa_reply |= element roa { attribute action { "publish" }, tag?, uri } 400 roa_query |= element roa { attribute action { "withdraw" }, tag?, uri } 401 roa_reply |= element roa { attribute action { "withdraw" }, tag?, uri } 403 # element 404 error = xsd:token { maxLength="1024" } 406 report_error_reply = element report_error { 407 tag?, 408 attribute error_code { error }, 409 xsd:string { maxLength="512000" }? 410 } 412 4. Operational Considerations 414 Placeholder section to talk about nesting children under parents in 415 the sameso repository, to allow for a single rsync to fetch both 416 (observing that the rsync setup times tends to dominate over the sync 417 time). And, more distressingly, talk about the access control 418 impacts of that nesting. 420 5. IANA Considerations 422 This document specifies no IANA Actions. 424 6. Security Considerations 426 7. References 428 7.1. Normative References 430 [I-D.ietf-sidr-res-certs] 431 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 432 X.509 PKIX Resource Certificates", 433 draft-ietf-sidr-res-certs-18 (work in progress), May 2010. 435 [I-D.ietf-sidr-rescerts-provisioning] 436 Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 437 Protocol for Provisioning Resource Certificates", 438 draft-ietf-sidr-rescerts-provisioning-06 (work in 439 progress), May 2010. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 446 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 447 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 449 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 450 Housley, R., and W. Polk, "Internet X.509 Public Key 451 Infrastructure Certificate and Certificate Revocation List 452 (CRL) Profile", RFC 5280, May 2008. 454 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 455 RFC 5652, September 2009. 457 [X.690] Postel, J., "ITU-T Recommendation X.690: ISO/IEC 8825- 458 1:2002, Information technology - ASN.1 encoding rules: 459 Specification of Basic Encoding Rules (BER), Canonical 460 Encoding Rules (CER) and Distinguished Encoding Rules 461 (DER)", 2002. 463 7.2. Informative References 465 [I-D.ietf-sidr-arch] 466 Lepinski, M. and S. Kent, "An Infrastructure to Support 467 Secure Internet Routing", draft-ietf-sidr-arch-09 (work in 468 progress), October 2009. 470 [I-D.ietf-sidr-roa-format] 471 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 472 Origin Authorizations (ROAs)", 473 draft-ietf-sidr-roa-format-06 (work in progress), 474 October 2009. 476 [I-D.ietf-sidr-rpki-manifests] 477 Austein, R., Huston, G., Kent, S., and M. Lepinski, 478 "Manifests for the Resource Public Key Infrastructure", 479 draft-ietf-sidr-rpki-manifests-07 (work in progress), 480 May 2010. 482 Appendix A. Acknowledgments 484 We acknowledge the editors of [I-D.ietf-sidr-rescerts-provisioning] 485 (Geoff Huston, Robert Loomans, Byron Ellacott, and Rob Austein), from 486 whom we took some of the text for this document. 488 We especially thank Rob Austein, who implemented the publication 489 protocol and helped us to understand it. 491 Authors' Addresses 493 Samuel Weiler 494 SPARTA, Inc. 495 7110 Samuel Morse Drive 496 Columbia, Maryland 21046 497 US 499 Email: weiler@tislabs.com 501 Anuja Sonalker 502 SPARTA, Inc. 503 7110 Samuel Morse Drive 504 Columbia, Maryland 21046 505 US 507 Email: Anuja.Sonalker@sparta.com