idnits 2.17.1 draft-ietf-sidr-publication-10.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 487 has weird spacing: '...element erro...' == Line 488 has weird spacing: '...element fail...' -- The document date (January 10, 2017) is 2662 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' == Outdated reference: A later version (-08) exists of draft-ietf-sidr-delta-protocol-04 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-rpki-oob-setup-05 Summary: 0 errors (**), 0 flaws (~~), 5 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 W3C / MIT 4 Intended status: Standards Track A. Sonalker 5 Expires: July 14, 2017 TowerSec 6 R. Austein 7 Dragon Research Labs 8 January 10, 2017 10 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) 11 draft-ietf-sidr-publication-10 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 Even in cases where a certificate issuer runs their own publication 20 repository, it can be useful to run the certificate engine itself on 21 a different machine from the publication repository. This document 22 defines a protocol which addresses these needs. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 14, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 5 62 2.1. Common XML Message Format . . . . . . . . . . . . . . . . 5 63 2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 6 64 2.3. Listing the repository . . . . . . . . . . . . . . . . . 7 65 2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 8 66 2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 9 68 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.1. Query, No Existing Object . . . . . . . . . . 11 70 3.2. Query, Overwriting Existing Object . . . . . . 11 71 3.3. Query . . . . . . . . . . . . . . . . . . . . 12 72 3.4. Reply . . . . . . . . . . . . . . . . . . . . 12 73 3.5. With Optional Elements . . . . . . . . . 12 74 3.6. Without Optional Elements . . . . . . . . 13 75 3.7. Error Handling With Multi-Element Queries . . . . . . . . 13 76 3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 13 77 3.7.2. Successful Multi-Element Response . . . . . . . . . . 14 78 3.7.3. Failure Multi-Element Response, First Error Only . . 14 79 3.7.4. Failure Multi-Element Response, All Errors . . . . . 15 80 3.8. Query . . . . . . . . . . . . . . . . . . . . . . 16 81 3.9. Reply . . . . . . . . . . . . . . . . . . . . . . 16 82 4. Operational Considerations . . . . . . . . . . . . . . . . . 16 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 88 8.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 This document assumes a working knowledge of the Resource Public Key 94 Infrastructure (RPKI), which is intended to support improved routing 95 security on the Internet. See [RFC6480] for an overview of the RPKI. 97 In order to make participation in the RPKI easier, it is helpful to 98 have a few consolidated repositories for RPKI objects, thus saving 99 every participant from the cost of maintaining a new service. 100 Similarly, relying parties using the RPKI objects will find it faster 101 and more reliable to retrieve the necessary set from a smaller number 102 of repositories. 104 These consolidated RPKI object repositories will in many cases be 105 outside the administrative scope of the organization issuing a given 106 RPKI object. In some cases, outsourcing operation of the repository 107 will be an explicit goal: some resource holders who strongly wish to 108 control their own RPKI private keys may lack the resources to operate 109 a 24x7 repository, or may simply not wish to do so. 111 The operator of an RPKI publication repository may well be an 112 Internet registry which issues certificates to its customers, but it 113 need not be; conceptually, operation of a an RPKI publication 114 repository is separate from operation of RPKI CA. 116 Even in cases where a resource holder operates both a certificate 117 engine and a publication repository, it can be useful to separate the 118 two functions, as they have somewhat different operational and 119 security requirements. 121 This document defines an RPKI publication protocol which allows 122 publication either within or across organizational boundaries, and 123 which makes fairly minimal demands on either the CA engine or the 124 publication service. 126 The authentication and message integrity architecture of the 127 publication protocol is essentially identical to the architecture 128 used in [RFC6492], because the participants in this protocol are the 129 same CA engines as in RFC 6492; this allows reuse of the same 130 "Business PKI" ("BPKI", see Section 1.2) infrastructure used to 131 support RFC 6492. As in RCC 6492, authorization is a matter of 132 external configuration: we assume that any given publication 133 repository has some kind of policy controlling which certificate 134 engines are allowed to publish, modify, or withdraw particular RPKI 135 objects, most likely following the recommendation in [RFC6480] 136 Section 4.4, the details of this policy are a private matter between 137 the operator of a certificate engine and the operator of the chosen 138 publication repository. 140 The following diagram attempts to convey where this publication 141 protocol fits into the overall data flow between the certificate 142 issuers and relying parties: 144 +------+ +------+ +------+ 145 | CA | | CA | | CA | 146 +------+ +------+ +------+ 147 | | | Publication Protocol 148 | | | Business relationship 149 +-------+ | +--------+ perhaps set up by 150 | | | draft-ietf-sidr-rpki-oob-setup 151 +----v---v--v-----+ 152 | | 153 | Publication | 154 | Repository | 155 | | 156 +-----------------+ Distribution protocols 157 | rsync or RRDP 158 +--------------+----------------+ 159 | | | 160 +-------v-----+ +------v------+ +------v------+ 161 | Relying | | Relying | | Relying | 162 | Party | | Party | | Party | 163 +-------------+ +-------------+ +-------------+ 165 The publication protocol itself is not visible to relying parties: a 166 relying party sees the public interface of the publication server, 167 which is an rsync or RRDP ([I-D.ietf-sidr-delta-protocol]) server. 169 Operators of certificate engines and publication repositories may 170 find [I-D.ietf-sidr-rpki-oob-setup] a useful tool in setting up the 171 pairwise relationships between these servers, but are not required to 172 use it. 174 1.1. Historical Note 176 This protocol started out as an informal collaboration between 177 several of the early RPKI implementers, and while it was always the 178 designers' intention that the resulting protocol end up on the IETF 179 standards track, it took a few years to get there, because 180 standardization of other pieces of the overall RPKI protocol space 181 was more urgent. The standards track version of this publication 182 protocol preserves the original XML namespace and protocol version 183 scheme in order to maintain backwards compatibility with running code 184 implemented against older versions of the specification. 186 1.2. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 "Publication engine" and "publication server" are used 193 interchangeably to refer to the server providing the service 194 described in this document. 196 "Business Public Key Infrastructure" ("Business PKI" or "BPKI") 197 refers to a PKI, separate from the RPKI, used to authenticate clients 198 to the publication engine. We use the term "Business PKI" here 199 because an Internet registry might already have a PKI for 200 authenticating its clients and might wish to reuse that PKI for this 201 protocol. There is, however, no requirement to reuse such a PKI. 203 2. Protocol Specification 205 The publication protocol uses XML ([XML]) messages wrapped in signed 206 CMS messages, carried over HTTP transport. 208 The publication protocol uses a simple request/response interaction. 209 The client passes a request to the server, and the server generates a 210 corresponding response. 212 A message exchange commences with the client initiating an HTTP POST 213 with content type of "application/rpki-publication", with the message 214 object as the body. The server's response will similarly be the body 215 of the response with a content type of "application/rpki- 216 publication". 218 The content of the POST and the server's response will be a well- 219 formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = 220 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. 222 The CMS signatures are used to protect the integrity of the protocol 223 messages and to authenticate the client and server to each other. 224 Authorization to perform particular operations is a local matter, 225 perhaps determined by contractual agreements between the operators of 226 any particular client-server pair, but in any case is beyond the 227 scope of this specification. 229 2.1. Common XML Message Format 231 The XML schema for this protocol is below in Section 2.6. The basic 232 XML message format looks like this: 234 238 239 240 244 245 247 Common attributes: 249 version: The value of this attribute is the version of this 250 protocol. This document describes version 4. 252 type: The possible values of this attribute are "reply" and "query". 254 A query PDU may be one of three types: , , or 255 . 257 A reply PDU may be one of three types: , , or 258 . 260 The and PDUs include a "tag" attribute to 261 facilitate bulk operation. When performing bulk operations, a CA 262 engine will probably find it useful to specify a distinct tag value 263 for each or PDU, to simplify matching an error 264 with the PDU which triggered it. The tag attribute is mandatory, to 265 simplify parsing, but a CA engine which has no particular use for 266 tagging MAY use any syntactically legal value, including simply using 267 the empty string for all tag fields. 269 2.2. Publication and Withdrawal 271 The publication protocol uses a common message format to request 272 publication of any RPKI object. This format was chosen specifically 273 to allow this protocol to accommodate new types of RPKI objects 274 without needing changes to this protocol. 276 Both the and PDUs have a payload of a tag and 277 a URI. The query also contains the DER object to be 278 published, encoded in Base64. 280 Both the and PDUs also have a "hash" 281 attribute, which carries a hash of an existing object at the 282 specified repository URI, encoded as a hexadecimal string. For 283 PDUs, the hash MUST be present, as this operation makes 284 no sense if there is no existing object to withdraw. For 285 PDUs, the hash is MUST be present if the publication operation is 286 overwriting an existing object, and MUST NOT be present if this 287 publication operation is writing to a new URI where no prior object 288 exists. Presence of an object when no "hash" attribute has been 289 specified is an error, as is absence of an object or an incorrect 290 hash value when a "hash" attribute has been specified. Any such 291 errors MUST be reported using the PDU. 293 The hash algorithm is SHA-256 [SHS], to simplify comparison of 294 publication protocol hashes with RPKI manifest hashes. 296 The intent behind the "hash" attribute is to allow the client and 297 server to detect any disagreements about the effect that a 298 or PDU will have on the repository. 300 Note that every publish and withdraw action requires a new manifest, 301 thus every publish or withdraw action will involve at least two 302 objects. 304 Processing of a query message is handled atomically: either the 305 entire query succeeds or none of it does. When a query message 306 contains multiple PDUs, failure of any PDU may require the server to 307 roll back actions triggered by earlier PDUs. 309 When a query messages containing or PDUs 310 succeeds, the server returns a single reply. 312 When a query fails, the server returns one or more 313 reply PDUs. Typically, a server will only generate one 314 corresponding to the first query PDU that failed, but 315 servers MAY return multiple PDUs at the implementor's 316 discretion. 318 2.3. Listing the repository 320 The operation allows the client to ask the server for a 321 complete listing of objects which the server believes the client has 322 published. This is intended primarily to allow the client to recover 323 upon detecting (probably via use of the "hash" attribute, see 324 Section 2.2) that they have somehow lost synchronization. 326 The query consists of a single PDU. A query MUST be 327 the only PDU in a query - it may not be combined with any 328 or queries. 330 The reply consists of zero or more PDUs, one per object 331 published in this repository by this client, each PDU conveying the 332 URI and hash of one published object. 334 2.4. Error handling 336 Errors are handled at two levels. 338 Errors that make it impossible to decode a query or encode a response 339 are handled at the HTTP layer. 4xx and 5xx HTTP response codes 340 indicate that something bad happened. 342 In all other cases, errors result in an XML PDU. 343 Like the rest of this protocol, PDUs are CMS-signed 344 XML messages and thus can be archived to provide an audit trail. 346 PDUs only appear in replies, never in queries. 348 The "tag" attribute of the PDU associated with a 349 or PDU MUST be set to the same value as the 350 "tag" attribute in the PDU which generated the error. A client can 351 use the "tag" attribute to determine which PDU caused processing of 352 an update to fail. 354 The error itself is conveyed in the "error_code" attribute. The 355 value of this attribute is a token indicating the specific error that 356 occurred. 358 The body of the element contains two sub-elements: 360 1. An optional text element , which if present, 361 contains a text string with debugging information intended for 362 human consumption. 364 2. An optional element , which, if present, contains a 365 verbatim copy of the query PDU whose failure triggered the 366 PDU. The quoted element must be syntactically 367 valid. 369 See Section 3.7 for examples of a multi-element query and responses. 371 2.5. Error Codes 373 These are the defined error codes as well as some discussion of each. 374 Text similar to these descriptions may be sent in an 375 element to help explain the error encountered. 377 xml_error: Encountered an XML problem. Note that some XML errors 378 may be severe enough to require error reporting at the HTTP layer, 379 instead. Implementations MAY choose to report any or all XML 380 errors at the HTTP layer. 382 permission_failure: Client does not have permission to update this 383 URI. 385 bad_cms_signature: Bad CMS signature. 387 object_already_present: An object is already present at this URI, 388 yet a "hash" attribute was not specified. A "hash" attribute must 389 be specified when overwriting or deleting an object. Perhaps 390 client and server are out of sync? 392 no_object_present: There is no object present at this URI, yet a 393 "hash" attribute was specified. Perhaps client and server are out 394 of sync? 396 no_object_matching_hash The "hash" attribute supplied does not match 397 the "hash" attribute of the object at this URI. Perhaps client 398 and server are out of sync? 400 consistency_problem: Server detected an update that looks like it 401 will cause a consistency problem (e.g. an object was deleted, but 402 the manifest was not updated). Note that a server is not required 403 to make such checks. Indeed, it may be unwise for a server to do 404 so. This error code just provides a way for the server to explain 405 its (in-)action. 407 other_error: A meteor fell on the server. 409 2.6. XML Schema 411 The following is a [RelaxNG] compact form schema describing the 412 Publication Protocol. 414 This schema is normative: in the event of a disagreement between this 415 schema and the document text above, this schema is authoritative. 417 # RelaxNG schema for RPKI publication protocol. 419 default namespace = 420 "http://www.hactrn.net/uris/rpki/publication-spec/" 422 # This is version 4 of the protocol. 424 version = "4" 426 # Top level PDU is either a query or a reply. 428 start |= element msg { 429 attribute version { version }, 430 attribute type { "query" }, 431 query_elt 432 } 434 start |= element msg { 435 attribute version { version }, 436 attribute type { "reply" }, 437 reply_elt 438 } 440 # Tag attributes for bulk operations. 442 tag = attribute tag { xsd:token { maxLength="1024" } } 444 # Base64 encoded DER stuff. 446 base64 = xsd:base64Binary 448 # Publication URIs. 450 uri = attribute uri { xsd:anyURI { maxLength="4096" } } 452 # Digest of an existing object (hexadecimal). 454 hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } } 456 # Error codes. 458 error |= "xml_error" 459 error |= "permission_failure" 460 error |= "bad_cms_signature" 461 error |= "object_already_present" 462 error |= "no_object_present" 463 error |= "no_object_matching_hash" 464 error |= "consistency_problem" 465 error |= "other_error" 467 # and query elements 469 query_elt |= ( 470 element publish { tag, uri, hash?, base64 } | 471 element withdraw { tag, uri, hash } 472 )* 474 # reply 476 reply_elt |= element success { empty } 477 # query and reply 479 query_elt |= element list { empty } 480 reply_elt |= element list { uri, hash }* 482 # reply 484 reply_elt |= element report_error { 485 tag?, 486 attribute error_code { error }, 487 element error_text { xsd:string { maxLength="512000" }}?, 488 element failed_pdu { query_elt }? 489 }* 491 3. Examples 493 Following are examples of various queries and the corresponding 494 replies for the RPKI publication protocol. 496 Note the authors have taken liberties with the Base64, hash, and URI 497 text in these examples in the interest of making the examples fit 498 nicely into RFC text format. 500 3.1. Query, No Existing Object 502 506 507 510 SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= 511 512 514 3.2. Query, Overwriting Existing Object 515 519 520 521 525 SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= 526 527 529 3.3. Query 531 535 536 540 542 3.4. Reply 544 548 549 551 3.5. With Optional Elements 552 556 559 560 Can't delete an object I don't have 561 562 563 567 SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= 568 569 570 571 573 3.6. Without Optional Elements 575 579 582 584 3.7. Error Handling With Multi-Element Queries 586 3.7.1. Multi-Element Query 587 591 594 SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= 595 596 600 603 SGVsbG8sIG15IG5hbWUgaXMgQ2Fyb2w= 604 605 609 612 SGVsbG8sIG15IG5hbWUgaXMgRXZl 613 614 616 3.7.2. Successful Multi-Element Response 618 622 623 625 3.7.3. Failure Multi-Element Response, First Error Only 626 630 633 634 638 639 640 642 3.7.4. Failure Multi-Element Response, All Errors 644 648 651 652 656 657 658 661 662 665 SGVsbG8sIG15IG5hbWUgaXMgRXZl 666 667 668 669 671 3.8. Query 673 677 678 680 3.9. Reply 682 686 689 692 695 698 700 4. Operational Considerations 702 There are two basic options open to the repository operator as to how 703 the publication tree is laid out. The first option is simple: each 704 publication client is given its own directory one level below the top 705 of the rsync module, and there is no overlap between the publication 706 spaces used by different clients. For example: 708 rsync://example.org/rpki/Alice/ 709 rsync://example.org/rpki/Bob/ 710 rsync://example.org/rpki/Carol/ 712 This has the advantage of being very easy for the publication 713 operator to manage, but has the drawback of making it difficult for 714 relying parties to fetch published objects efficiently, particularly 715 for relying party implementations which follow the safety rule of 716 never retrieving anything from a URI which didn't come directly from 717 either a signed object or a trust anchor locator. 719 Given that the mandatory-to-implement retrieval protocol for relying 720 parties is rsync, a more efficient repository structure would be one 721 which minimized the number of rsync fetches required. One such 722 structure would be one in which the publication directories for 723 subjects were placed underneath the publication directories of their 724 issuers: since the normal synchronization tree walk is top-down, this 725 can significantly reduce the total number of rsync connections 726 required to synchronize. For example: 728 rsync://example.org/rpki/Alice/ 729 rsync://example.org/rpki/Alice/Bob/ 730 rsync://example.org/rpki/Alice/Bob/Carol/ 732 Preliminary measurement suggests that, in the case of large numbers 733 of small publication directories, the time needed to set up and tear 734 down individual rsync connections becomes significant, and that a 735 properly optimized tree structure can reduce synchronization time by 736 an order of magnitude. 738 The more complex tree structure does require careful attention when 739 setting up clients. In the example above, assuming that Alice issues 740 to Bob who in turn issues to Carol, Alice has ceded control of a 741 portion of her publication space to Bob, who has in turn ceded a 742 portion of that to Carol. 744 The details of how the repository operator determines that Alice has 745 given Bob permission to nest Bob's publication directory under 746 Alice's is outside the scope of this protocol. 748 5. IANA Considerations 750 IANA is asked to register the application/rpki-publication MIME media 751 type as follows: 753 MIME media type name: application 754 MIME subtype name: rpki-publication 755 Required parameters: None 756 Optional parameters: None 757 Encoding considerations: binary 758 Security considerations: Carries an RPKI Publication Protocol 759 Message, as defined in this document. 760 Interoperability considerations: None 761 Published specification: This document 762 Applications which use this media type: HTTP 763 Additional information: 764 Magic number(s): None 765 File extension(s): 766 Macintosh File Type Code(s): 767 Person & email address to contact for further information: 768 Rob Austein 769 Intended usage: COMMON 770 Author/Change controller: IETF 772 6. Security Considerations 774 The RPKI publication protocol and the data it publishes use entirely 775 separate PKIs for authentication. The published data is 776 authenticated within the RPKI, and this protocol has nothing to do 777 with that authentication, nor does it require that the published 778 objects be valid in the RPKI. The publication protocol uses a 779 separate Business PKI (BPKI) to authenticate its messages. 781 Each RPKI publication protocol message is CMS-signed. Because of 782 that protection at the application layer, this protocol does not 783 require the use of HTTPS or other transport security mechanisms. 785 Although the hashes used in the and PDUs are 786 cryptographically strong, the digest algorithm was selected for 787 convenience in comparing these hashes with the hashes that appear in 788 RPKI manifests. The hashes used in the and 789 PDUs are not particularly security-sensitive, because these PDUs are 790 protected by the CMS signatures. 792 Compromise of a publication server, perhaps through mismanagement of 793 BPKI private keys, could lead to a denial-of-service attack on the 794 RPKI. An attacker gaining access to BPKI private keys could use this 795 protocol to delete (withdraw) RPKI objects, leading to routing 796 changes or failures. Accordingly, as in most PKIs, good key 797 management practices are important. 799 7. Acknowledgements 801 The authors would like to thank: Geoff Huston, George Michaelson, 802 Oleg Muravskiy, Paul Wouters, Randy Bush, Rob Loomans, Robert 803 Kisteleki, Tim Bruijnzeels, Tom Petch, and anybody else who helped 804 along the way but whose name(s) the authors have temporarily 805 forgotten. 807 8. References 809 8.1. Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", RFC 2119, BCP 14, March 1997. 814 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 815 RFC 5652, STD 70, September 2009. 817 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 818 Protocol for Provisioning Resource Certificates", 819 RFC 6492, February 2012. 821 [SHS] National Institute of Standards and Technology, "Secure 822 Hash Standard", FIPS PUB 180-4, March 2012, 823 . 826 8.2. Informative References 828 [I-D.ietf-sidr-delta-protocol] 829 Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 830 "RPKI Repository Delta Protocol", draft-ietf-sidr-delta- 831 protocol-04 (work in progress), September 2016. 833 [I-D.ietf-sidr-rpki-oob-setup] 834 Austein, R., "An Out-Of-Band Setup Protocol For RPKI 835 Production Services", draft-ietf-sidr-rpki-oob-setup-05 836 (work in progress), December 2016. 838 [RelaxNG] Clark, J., "RELAX NG Compact Syntax", OASIS , November 839 2002, . 842 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 843 Secure Internet Routing", RFC 6480, February 2012. 845 [XML] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C CR 846 CR-xml11-20021015, October 2002. 848 Authors' Addresses 850 Samuel Weiler 851 W3C / MIT 853 Email: weiler@csail.mit.edu 855 Anuja Sonalker 856 TowerSec Automotive Cyber Security 858 Email: asonalker@tower-sec.com 860 Rob Austein 861 Dragon Research Labs 863 Email: sra@hactrn.net