idnits 2.17.1 draft-ietf-sidr-publication-06.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 == Line 287 has weird spacing: '...owed in queri...' -- The document date (February 25, 2015) is 3346 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: August 29, 2015 Battelle Memorial Institute 6 R. Austein 7 Dragon Research Labs 8 February 25, 2015 10 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) 11 draft-ietf-sidr-publication-06 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 August 29, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 58 2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4 59 2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 4 60 2.3. Listing the repository . . . . . . . . . . . . . . . . . 5 61 2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 5 62 2.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.1. Query, No Existing Object . . . . . . . . . . 8 65 3.2. Query, Overwriting Existing Object . . . . . . 9 66 3.3. Reply . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Query . . . . . . . . . . . . . . . . . . . . 10 68 3.5. Reply . . . . . . . . . . . . . . . . . . . . 10 69 3.6. With Text . . . . . . . . . . . . . . . . 10 70 3.7. Without Text . . . . . . . . . . . . . . 10 71 4. Operational Considerations . . . . . . . . . . . . . . . . . 11 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 7.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 This document assumes a working knowledge of the Resource Public Key 82 Infrastructure (RPKI), which is intended to support improved routing 83 security on the Internet. [RFC6480] 85 In order to make participation in the RPKI easier, it is helpful to 86 have a few consolidated repositories for RPKI objects, thus saving 87 every participant from the cost of maintaining a new service. 88 Similarly, relying parties using the RPKI objects will find it faster 89 and more reliable to retrieve the necessary set from a smaller number 90 of repositories. 92 These consolidated RPKI object repositories will in many cases be 93 outside the administrative scope of the organization issuing a given 94 RPKI object. In some cases, outsourcing operation of the repository 95 will be an explicit goal: some resource holders who strongly wish to 96 control their own RPKI private keys may lack the resources to operate 97 a 24x7 repository, or may simply not wish to do so. 99 The operator of an RPKI publication repository may well be an 100 Internet registry which issues certificates to its customers, but it 101 need not be; conceptually, operation of a an RPKI publication 102 repository is separate from operation of RPKI CA. 104 This document defines an RPKI publication protocol which allows 105 publication either within or across organizational boundaries, and 106 which makes fairly minimal demands on either the CA engine or the 107 publication service. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 "Publication engine" and "publication server" are used 116 interchangeably to refer to the server providing the service 117 described in this document. 119 "Business Public Key Infrastructure" ("Business PKI" or "BPKI") 120 refers to a PKI, separate from the RPKI, used to authenticate clients 121 to the publication engine. We use the term "Business PKI" here 122 because an internet registry might already have a PKI for 123 authenticating its clients and might wish to reuse that PKI for this 124 protocol. There is, however, no requirement to reuse such a PKI. 126 2. Protocol Specification 128 The publication protocol uses XML messages wrapped in signed CMS 129 messages, carried over HTTP transport. 131 The publication protocol uses a simple request/response interaction. 132 The client passes a request to the server, and the server generates a 133 corresponding response. 135 A message exchange commences with the client initiating an HTTP POST 136 with content type of "application/rpki-publication", with the message 137 object as the body. The server's response will similarly be the body 138 of the response with a content type of "application/rpki- 139 publication". 141 The content of the POST and the server's response will be a well- 142 formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = 143 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. 145 2.1. Common XML Message Format 147 The XML schema for this protocol is below in Section 2.5. The basic 148 XML message format looks like this: 150 154 155 157 161 162 164 Common attributes: 166 version: The value of this attribute is the version of this 167 protocol. This document describes version 3. 169 type: The possible values of this attribute are "reply" and "query". 171 A query PDU may be one of three types: , , or 172 . 174 A reply PDU may be one of four types: , , , or . 177 Each of these PDUs may include an optional tag to facilitate bulk 178 operation. If a tag is set in a query PDU, the corresponding 179 reply(s) MUST have the tag attribute set to the same value. 181 2.2. Publication and Withdrawal 183 The publication protocol uses a common message format to request 184 publication of any RPKI object. This format was chosen specifically 185 to allow this protocol to accommodate new types of RPKI objects 186 without needing changes to this protocol. 188 Both the and PDUs have a payload of an 189 optional tag and a URI. The query also contains the DER 190 object to be published, encoded in Base64. 192 Both the and PDUs also have a "hash" 193 attribute, which carries a hash of an existing object at the 194 specified repository URI. For PDUs, the hash is 195 mandatory, as this operation makes no sense if there is no existing 196 object to withdraw. For PDUs, the hash MUST be present if 197 the publication operation is overwriting an existing object, and MUST 198 be omitted if this publication operation is writing to a new URI 199 where no prior object exists. Presence of an object when no hash 200 attribute is specified is an error, as is absence of the hash 201 attribute or an incorrect hash value when an object is present. Any 202 such errors MUST be reported using the PDU. 204 The current hash algorithm is SHA-256 [SHS], to simplify comparison 205 of publication protocol hashes with RPKI manifest hashes. 207 The intent behind the hash attribute is to allow the client and 208 server to detect any disagreements about the effect that a 209 or PDU will have on the repository. 211 Note that every publish and withdraw action requires a new manifest, 212 thus every publish or withdraw action will involve at least two 213 objects. 215 2.3. Listing the repository 217 The operation allows the client to ask the server for a 218 complete listing of objects which the server believes the client has 219 published. This is intended primarily to allow the client to recover 220 upon detecting (probably via use of the "hash" attribute, see 221 Section 2.2) that they have somehow lost synchronization. 223 The query consists of a single PDU. 225 The reply consists of zero or more PDUs, one per object 226 published in this repository by this client, each PDU conveying the 227 URI and hash of one published object. 229 2.4. Error handling 231 Errors are handled at two levels. 233 Since all messages in this protocol are conveyed over HTTP 234 connections, basic errors are indicated via the HTTP response code. 235 4xx and 5xx responses indicate that something bad happened. Errors 236 that make it impossible to decode a query or encode a response are 237 handled in this way. 239 Where possible, errors result in an XML PDU which 240 takes the place of the expected protocol response PDU. Like the rest 241 of this protocol, PDUs are CMS-signed XML messages 242 and thus can be archived to provide an audit trail. 244 PDUs only appear in replies, never in queries. 246 Like all other PDUs in this protocol, the PDU 247 includes a "tag" attribute to assist in matching the error with a 248 particular query when using batching. It is optional to set the tag 249 on queries but, if set on the query, it MUST be set on the reply or 250 error. 252 The error itself is conveyed in the error_code attribute. The value 253 of this attribute is a token indicating the specific error that 254 occurred. 256 The body of the element itself is an optional text 257 string; if present, this is debugging information. 259 2.5. XML Schema 261 The following is a RelaxNG compact form schema describing the 262 Publication Protocol. 264 # $Id: rpki-publication.rnc 3171 2015-02-26 00:09:05Z sra $ 265 # RelaxNG schema for RPKI publication protocol. 267 default namespace = 268 "http://www.hactrn.net/uris/rpki/publication-spec/" 270 # This is version 3 of the protocol. 272 version = "3" 274 # Top level PDU is either a query or a reply. 276 start |= element msg { 277 attribute version { version }, 278 attribute type { "query" }, 279 query_elt* 280 } 282 start |= element msg { 283 attribute version { version }, 284 attribute type { "reply" }, 285 reply_elt* 286 } 287 # PDUs allowed in queries and replies. 289 query_elt = publish_query | withdraw_query | list_query 290 reply_elt = publish_reply | withdraw_reply | list_reply | error_reply 292 # Tag attributes for bulk operations. 294 tag = attribute tag { xsd:token { maxLength="1024" } } 296 # Base64 encoded DER stuff. 298 base64 = xsd:base64Binary 300 # Publication URIs. 302 uri = attribute uri { xsd:anyURI { maxLength="4096" } } 304 # Digest of an existing object (hexadecimal). 306 hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } } 308 # Error codes. 310 error = xsd:token { maxLength="1024" } 312 # element 314 publish_query = element publish { tag?, uri, hash?, base64 } 315 publish_reply = element publish { tag?, uri } 317 # element 319 withdraw_query = element withdraw { tag?, uri, hash } 320 withdraw_reply = element withdraw { tag?, uri } 322 # element 324 list_query = element list { tag? } 325 list_reply = element list { tag?, uri, hash } 327 # element 329 error_reply = element report_error { 330 tag?, 331 attribute error_code { error }, 332 xsd:string { maxLength="512000" }? 333 } 335 3. Examples 337 Following are examples of various queries and the corresponding 338 replies for the RPKI publication protocol 340 3.1. Query, No Existing Object 342 346 348 MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhE 349 RjRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XDTA4 350 MDUyMjE4MDUxMloXDTA4MDUyNDE3NTQ1M1owMzExMC8GA1UEAxMoOEZCODIx 351 OEYwNkU1MEFCNzAyQTdEOTZEQzhGMENEQ0Q4MjhGN0YxNzCCASIwDQYJKoZI 352 hvcNAQEBBQADggEPADCCAQoCggEBAMeziKp0k5nP7v6SZoNsXIMQYRgNtC6F 353 r/9Xm/1yQHomiPqHUk47rHhGojYiK5AhkrwoYhkH4UjJl2iwklDYczXuaBU3 354 F5qrKlZ4aZnjIxdlP7+hktVpeApL6yuJTUAYeC3UIxnLDVdD6phydZ/FOQlu 355 ffiNDjzteCCvoyOUatqt8WB+oND6LToHp028g1YUYLHG6mur0dPdcHOVXLSm 356 UDuZ1HDz1nDuYvIVKjB/MpH9aW9XeaQ6ZFIlZVPwuuvI2brR+ThH7Gv27GL/ 357 o8qFdC300VQfoTZ+rKPGDE8K1cI906BL4kiwx9z0oiDcE96QCz+B0vsjc9mG 358 aA1jgAxlXWsCAwEAAaOCAhcwggITMB0GA1UdDgQWBBSPuCGPBuUKtwKn2W3I 359 8M3Ngo9/FzAfBgNVHSMEGDAWgBTfSoAX5mqekXLkYS2M9Mg/I43iozBVBgNV 360 HR8ETjBMMEqgSKBGhkRyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQv 361 UklSLzEvMzBxQUYtWnFucEZ5NUdFdGpQVElQeU9ONHFNLmNybDBFBggrBgEF 362 BQcBAQQ5MDcwNQYIKwYBBQUHMAKGKXJzeW5jOi8vbG9jYWxob3N0OjQ0MDAv 363 dGVzdGJlZC9XT01CQVQuY2VyMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIw 364 DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZsGCCsGAQUFBwEL 365 BIGOMIGLMDQGCCsGAQUFBzAFhihyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rl 366 c3RiZWQvUklSL1IwLzEvMFMGCCsGAQUFBzAKhkdyc3luYzovL2xvY2FsaG9z 367 dDo0NDAwL3Rlc3RiZWQvUklSL1IwLzEvajdnaGp3YmxDcmNDcDlsdHlQRE56 368 WUtQZnhjLm1uZjAaBggrBgEFBQcBCAEB/wQLMAmgBzAFAgMA/BUwPgYIKwYB 369 BQUHAQcBAf8ELzAtMCsEAgABMCUDAwAKAzAOAwUAwAACAQMFAcAAAiAwDgMF 370 AsAAAiwDBQDAAAJkMA0GCSqGSIb3DQEBCwUAA4IBAQCEhuH7jtI2PJY6+zwv 371 306vmCuXhtu9Lr2mmRw2ZErB8EMcb5xypMrNqMoKeu14K2x4a4RPJkK4yATh 372 M81FPNRsU5mM0acIRnAPtxjHvPME7PHN2w2nGLASRsZmaa+b8A7SSOxVcFUR 373 azENztppsolHeTpm0cpLItK7mNpudUg1JGuFo94VLf1MnE2EqARG1vTsNhel 374 /SM/UvOArCCOBvf0Gz7kSuupDSZ7qx+LiDmtEsLdbGNQBiYPbLrDk41PHrxd 375 x28qIj7ejZkRzNFw/3pi8/XK281h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx 376 0iwPYdLiDbdWFbtTdPcXBauY 377 378 380 3.2. Query, Overwriting Existing Object 382 386 389 MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhE 390 RjRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XDTA4 391 MDUyMjE4MDUxMloXDTA4MDUyNDE3NTQ1M1owMzExMC8GA1UEAxMoOEZCODIx 392 OEYwNkU1MEFCNzAyQTdEOTZEQzhGMENEQ0Q4MjhGN0YxNzCCASIwDQYJKoZI 393 hvcNAQEBBQADggEPADCCAQoCggEBAMeziKp0k5nP7v6SZoNsXIMQYRgNtC6F 394 r/9Xm/1yQHomiPqHUk47rHhGojYiK5AhkrwoYhkH4UjJl2iwklDYczXuaBU3 395 F5qrKlZ4aZnjIxdlP7+hktVpeApL6yuJTUAYeC3UIxnLDVdD6phydZ/FOQlu 396 ffiNDjzteCCvoyOUatqt8WB+oND6LToHp028g1YUYLHG6mur0dPdcHOVXLSm 397 UDuZ1HDz1nDuYvIVKjB/MpH9aW9XeaQ6ZFIlZVPwuuvI2brR+ThH7Gv27GL/ 398 o8qFdC300VQfoTZ+rKPGDE8K1cI906BL4kiwx9z0oiDcE96QCz+B0vsjc9mG 399 aA1jgAxlXWsCAwEAAaOCAhcwggITMB0GA1UdDgQWBBSPuCGPBuUKtwKn2W3I 400 8M3Ngo9/FzAfBgNVHSMEGDAWgBTfSoAX5mqekXLkYS2M9Mg/I43iozBVBgNV 401 HR8ETjBMMEqgSKBGhkRyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQv 402 UklSLzEvMzBxQUYtWnFucEZ5NUdFdGpQVElQeU9ONHFNLmNybDBFBggrBgEF 403 BQcBAQQ5MDcwNQYIKwYBBQUHMAKGKXJzeW5jOi8vbG9jYWxob3N0OjQ0MDAv 404 dGVzdGJlZC9XT01CQVQuY2VyMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIw 405 DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZsGCCsGAQUFBwEL 406 BIGOMIGLMDQGCCsGAQUFBzAFhihyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rl 407 c3RiZWQvUklSL1IwLzEvMFMGCCsGAQUFBzAKhkdyc3luYzovL2xvY2FsaG9z 408 dDo0NDAwL3Rlc3RiZWQvUklSL1IwLzEvajdnaGp3YmxDcmNDcDlsdHlQRE56 409 WUtQZnhjLm1uZjAaBggrBgEFBQcBCAEB/wQLMAmgBzAFAgMA/BUwPgYIKwYB 410 BQUHAQcBAf8ELzAtMCsEAgABMCUDAwAKAzAOAwUAwAACAQMFAcAAAiAwDgMF 411 AsAAAiwDBQDAAAJkMA0GCSqGSIb3DQEBCwUAA4IBAQCEhuH7jtI2PJY6+zwv 412 306vmCuXhtu9Lr2mmRw2ZErB8EMcb5xypMrNqMoKeu14K2x4a4RPJkK4yATh 413 M81FPNRsU5mM0acIRnAPtxjHvPME7PHN2w2nGLASRsZmaa+b8A7SSOxVcFUR 414 azENztppsolHeTpm0cpLItK7mNpudUg1JGuFo94VLf1MnE2EqARG1vTsNhel 415 /SM/UvOArCCOBvf0Gz7kSuupDSZ7qx+LiDmtEsLdbGNQBiYPbLrDk41PHrxd 416 x28qIj7ejZkRzNFw/3pi8/XK281h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx 417 0iwPYdLiDbdWFbtTdPcXBauY 418 419 421 3.3. Reply 422 426 428 430 3.4. Query 432 436 439 441 3.5. Reply 443 447 449 451 3.6. With Text 453 457 459 Shampooing with sterno again, are we? 460 461 463 3.7. Without Text 464 468 470 472 4. Operational Considerations 474 There are two basic options open to the repository operator as to how 475 the publication tree is laid out. The first option is simple: each 476 publication client is given its own directory one level below the top 477 of the rsync module, and there is no overlap between the publication 478 spaces used by different clients. For example: 480 rsync://example.org/rpki/Alice/ 481 rsync://example.org/rpki/Bob/ 482 rsync://example.org/rpki/Carol/ 484 This has the advantage of being very easy for the publication 485 operator to manage, but has the drawback of making it difficult for 486 relying parties to fetch published objects both safely and as 487 efficiently as possible. 489 Given that the mandatory-to-implement retrieval protocol for relying 490 parties is rsync, a more efficient repository structure would be one 491 which minimized the number of rsync fetches required. One such 492 structure would be one in which the publication directories for 493 subjects were placed underneath the publication directories of their 494 issuers: since the normal synchronization tree walk is top-down, this 495 can significantly reduce the total number of rsync connections 496 required to synchronize. For example: 498 rsync://example.org/rpki/Alice/ 499 rsync://example.org/rpki/Alice/Bob/ 500 rsync://example.org/rpki/Alice/Bob/Carol/ 502 Preliminary measurement suggests that, in the case of large numbers 503 of small publication directories, the time needed to set up and tear 504 down individual rsync connections becomes significant, and that a 505 properly optimized tree structure can reduce synchronization time by 506 an order of magnitude. 508 The more complex tree structure does require careful attention to the 509 base_uri attribute values when setting up clients. In the example 510 above, assuming that Alice issues to Bob who in turn issues to Carol, 511 Alice has ceded control of a portion of her publication space to Bob, 512 who has in turn ceded a portion of that to Carol, and the base_uri 513 attributes in the setup messages should reflect this. 515 The details of how the repository operator determines that Alice has 516 given Bob permission to nest Bob's publication directory under 517 Alice's is outside the scope of this protocol. 519 5. IANA Considerations 521 IANA is asked to register the application/rpki-publication MIME media 522 type as follows: 524 MIME media type name: application 525 MIME subtype name: rpki-publication 526 Required parameters: None 527 Optional parameters: None 528 Encoding considerations: binary 529 Security considerations: Carries an RPKI Publication Protocol 530 Message, as defined in this document. 531 Interoperability considerations: None 532 Published specification: This document 533 Applications which use this media type: HTTP 534 Additional information: 535 Magic number(s): None 536 File extension(s): 537 Macintosh File Type Code(s): 538 Person & email address to contact for further information: 539 Rob Austein 540 Intended usage: COMMON 541 Author/Change controller: Rob Austein 543 6. Security Considerations 545 The RPKI publication protocol and the data it publishes use entirely 546 separate PKIs for authentication. The published data is 547 authenticated within the RPKI, and this protocol has nothing to do 548 with that authentication, nor does it require that the published 549 objects be valid in the RPKI. The publication protocol uses a 550 separate Business PKI (BPKI) to authenticate its messages. 552 Each RPKI publication protocol message is CMS-signed. Because of 553 that protection at the application layer, this protocol does not 554 require the use of HTTPS or other transport security mechanisms. 556 Although the hashes used in the and PDUs are 557 cryptographic strength, the digest algorithm was selected for 558 convenience in comparing these hashes with the hashes that appear in 559 RPKI manifests. The hashes used in the and 560 PDUs are not particularly security-sensitive, because these PDUs are 561 protected by the CMS signatures. 563 Compromise of a publication server, perhaps through mismanagement of 564 BPKI keys, could lead to a denial-of-service attack on the RPKI. An 565 attacker gaining access to BPKI keys could use this protocol delete 566 (withdraw) RPKI objects, leading to routing changes or failures. 567 Accordingly, as in most PKIs, good key management practices are 568 important. 570 7. References 572 7.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", RFC 2119, BCP 14, March 1997. 577 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 578 5652, STD 70, September 2009. 580 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 581 Protocol for Provisioning Resource Certificates", RFC 582 6492, February 2012. 584 [SHS] National Institute of Standards and Technology, "Secure 585 Hash Standard", FIPS PUB 180-4, March 2012, 586 . 589 7.2. Informative References 591 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 592 Secure Internet Routing", RFC 6480, February 2012. 594 Authors' Addresses 596 Samuel Weiler 597 SPARTA, Inc. 598 7110 Samuel Morse Drive 599 Columbia, Maryland 21046 600 US 602 Email: weiler@tislabs.com 603 Anuja Sonalker 604 Battelle Memorial Institute 606 Email: sonalkera@battelle.org 608 Rob Austein 609 Dragon Research Labs 611 Email: sra@hactrn.net