idnits 2.17.1 draft-austein-sidr-rpki-oob-setup-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 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '...f the key exchange MUST be ensured via...' RFC 2119 keyword, line 747: '... these exchanges MUST be ensured via e...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2013) is 3942 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: 'RFC5652' is defined on line 770, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Austein 3 Internet-Draft Dragon Research Labs 4 Intended status: Standards Track July 12, 2013 5 Expires: January 13, 2014 7 An Out-Of-Band Setup Protocol For RPKI Production Services 8 draft-austein-sidr-rpki-oob-setup-00 10 Abstract 12 This note describes a simple out-of-band protocol to ease setup of 13 the RPKI provisioning and publication protocols between two parties. 14 The protocol is encoded in a small number of XML messages, which can 15 be passed back and forth by any mutually agreeable secure means. 17 This setup protocol is not part of the provisioning or publication 18 protocol, rather, it is intended to simplify configuration of these 19 protocols by setting up relationships and exchanging BPKI keying 20 material. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 13, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Overview of the BPKI . . . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Common Protocol Elements . . . . . . . . . . . . . . . . 5 61 3.3. Protocol Messages . . . . . . . . . . . . . . . . . . . . 5 62 3.3.1. . . . . . . . . . . . . . . . . . . 6 63 3.3.2. . . . . . . . . . . . . . . . . . 6 64 3.3.3. . . . . . . . . . . . . . . . . 8 65 3.3.4. . . . . . . . . . . . . . . . 9 66 3.4. . . . . . . . . . . . . . . . . . . . . 10 67 3.5. . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 12 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 17 73 Appendix A. RelaxNG Schema . . . . . . . . . . . . . . . . . . . 17 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 This note describes a small XML-based out-of-band protocol used to 79 set up relationships between parents and children in the RPKI 80 provisioning protocol ([RFC6492]) and between publishers and 81 repositories in the RPKI publication protocol 82 ([I-D.ietf-sidr-publication]). 84 The basic function of this protocol is public key exchange, in the 85 form of self-signed BPKI X.509 certificates, but workshop experience 86 has demonstrated that it's simpler for the user if we also bundle the 87 other configuration information needed to bring up a new player into 88 the messages used in the key exchange. 90 The underlying transport for this protocol is deliberately 91 unspecified. It might be a USB stick, a web interface secured with 92 conventional HTTPS, PGP-signed email, a T-shirt printed with a QR 93 code, or a carrier pigeon. 95 Since much of the purpose of this protocol is key exchange, 96 authentication and integrity of the key exchange MUST be ensured via 97 external means. Typically such means will tie directly to a new or 98 existing business relationship 100 2. Overview of the BPKI 102 Several protocols related to RPKI provisioning use signed CMS 103 messages to authenticate the underlying XML-based protocols. 104 Verification of these CMS messages requires X.509 certificates. The 105 PKI that holds these certificates is distinct from the RPKI, and 106 contains no RFC 3779 resources. We refer to this as the "Business 107 PKI" (BPKI), to distinguish it from the RPKI. The "B" is a hint that 108 the certificate relationships in the BPKI are likely to follow and 109 become part of existing contractual relationships between the issuers 110 and subjects of this PKI. 112 The RPKI provisioning protocol does not dictate a particular 113 structure for the BPKI, beyond the basic requirement that it be 114 possible for one party to sign and the other party to verify the CMS 115 messages. This allows a certain amount of flexibility to allow an 116 Internet registry to reuse an existing PKI as the BPKI if that makes 117 sense in their context. 119 In order to keep this protocol simple, we adopt a somewhat 120 constrained model of the BPKI. The first two operations in this 121 protocol are an exchange of public keys between child and parent for 122 use in the provisioning protocol, the latter two operations in this 123 protocol are an exchange of public keys between publisher and 124 repository for use in the publication protocol. In each of these 125 operations, the sending party includes its public key, in the form of 126 a self-signed X.509 CA certificate. The private keys corresponding 127 to the exchanged certificates are not used to sign CMS messages 128 directly; instead, the exchanged CA certificates are the issuers of 129 the BPKI end-entity (EE) certificates which will be included in the 130 CMS messages and can be used, along with the exchanged certificates, 131 to verify the CMS messages. 133 Details of how to tie the exchanged certificates into an 134 implementation's local BPKI are left to the implementation, but the 135 recommended approach is to cross-certify the received public key and 136 subject name under one's own BPKI, using a Basic Constraints 137 extension with cA = TRUE, pathLenConstraint = 0, indicating that the 138 cross-certified certificate is a CA certificate which is allowed to 139 issue EE certificates but is not allowed to issue CA certificates. 140 See section 4.2.1.9 of [RFC5280] for more information about the Basic 141 Constraints extension. 143 For example, suppose that Alice and Bob each have their own self- 144 signed BPKI certificates: 146 Issuer: CN = Alice CA 147 Subject: CN = Alice CA 148 Public Key: [Alice CA Public Key] 149 BasicConstraints: cA = TRUE 151 Issuer: CN = Bob CA 152 Subject: CN = Bob CA 153 Public Key: [Bob CA Public Key] 154 BasicConstraints: cA = TRUE 156 Alice sends Bob her self-signed BPKI certificate, and Bob cross- 157 certifies its public key and subject name under Bob's own self-signed 158 BPKI certificate: 160 Issuer: CN = Bob CA 161 Subject: CN = Alice CA 162 Public Key: [Alice CA Public Key] 163 BasicConstraints: cA = TRUE, pathLenConstraint = 0 165 Later, when Bob receives a CMS message from Alice, Bob can verify 166 this message via a trust chain back to Bob's own trust anchor: 168 Issuer: CN = Alice CA 169 Subject: CN = Alice EE 170 Public Key: [Alice EE Public Key] 172 [[Need some text detailing required and allowed values in the 173 certificates: 2048-bit RSA, what extensions, .... But once we go 174 there we also have to provide a path for algorithm agility.]] 176 3. Protocol Elements 178 Each message in the protocol is a distinct XML element in the "http:/ 179 /www.hactrn.net/uris/rpki/rpki-setup/" XML namespace. 181 3.1. Nomenclature 183 All of the protocols configured by this setup protocol have their own 184 terminology for their actors, but in the context of this protocol 185 that terminology becomes somewhat confusing. All of the players in 186 this setup protocol issue certificates, are the subjects of other 187 certificates, operate servers, and, in most cases, act as clients for 188 one protocol or another. Therefore, this note uses its own terms for 189 the actors in this protocol. 191 Child: An entity acting in the client ("subject") role of the 192 provisioning protocol defined in [RFC6492]. 194 Parent: An entity acting in the server ("issuer") role of the 195 provisioning protocol defined in [RFC6492]. 197 Publisher: An entity acting in the client role of the publication 198 protocol defined in [I-D.ietf-sidr-publication]. 200 Repository: An entity acting in the server role of the publication 201 protocol defined in [I-D.ietf-sidr-publication]. 203 Note that a given entity might act in more than one of these roles; 204 for example, in one of the simplest cases, the child is the same 205 entity as the publisher, while the parent is the same entity as the 206 repository. 208 3.2. Common Protocol Elements 210 The first XML attribute in each message is a version field. This 211 document describes version 1 of the protocol. 213 Most messages contain, among other things, a self-signed BPKI X.509 214 certificate. These certificates are represented as XML elements 215 whose text value is the Base64 text encoding the DER representation 216 of the X.509 certificate. 218 A number of attributes contain "handles". A handle in this protocol 219 is a text string in the US-ASCII character set consisting of letters, 220 digits, and the special characters "/", "-", and "_". This protocol 221 places no special semantics on the structure of these handles, 222 although implementations might. Handles are protocol elements, not 223 necessarily meaningful to humans, thus the simplicity of a restricted 224 character set makes more sense than the complex rules which would be 225 needed for internationalized text. 227 3.3. Protocol Messages 229 The core of this protocol consists of four message types, 230 representing the basic request and response semantics needed to 231 configure a RPKI engine to talk to its parent and its repository via 232 the provisioning and publication protocols, respectively. 234 3.3.1. 236 The message is an initial setup request from a 237 provisioning protocol child to its provisioning protocol parent. 239 Fields in the message: 241 version: The version attribute specifies the protocol version. This 242 note describes protocol version 1. 244 child_handle: The child_handle attribute is what the child calls 245 itself. This is just a hint from the child to the parent, the 246 parent need not honor it. 248 child_bpki_ta: The element is the child's BPKI 249 identity, a self-signed X.509 BPKI certificate, encoded in Base64. 251 This CA certificate will be the issuer of the BPKI EE certificates 252 corresponding to private keys that the child will use when sending 253 provisioning protocol messages to the parent. 255 --------------------------------------------------------------------- 256 260 261 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 262 263 264 --------------------------------------------------------------------- 266 3.3.2. 268 The message is a response from a provisioning 269 protocol parent to a provisioning protocol child that had previously 270 sent a message. 272 Fields in the message: 274 version: The version attribute specifies the protocol version. This 275 note describes protocol version 1. 277 service_uri: The service_uri attribute contains an HTTP URL that the 278 child should contact for up-down ([RFC6492]) service. 280 child_handle: The child_handle attribute is the parent's name for 281 the child. This might or might not match the child_handle from 282 the message. If they do not match, the parent 283 wins, because the parent gets to dictate the names in the 284 provisioning protocol. This value is the sender field in 285 provisioning protocol request messages and the recipient field in 286 provisioning protocol response messages. 288 parent_handle: The parent_handle attribute is the parent's name for 289 itself. This value is the recipient field in provisioning 290 protocol request messages and the sender field in provisioning 291 protocol response messages. 293 parent_bpki_ta: The element is the parent's BPKI 294 identity, a self-signed X.509 BPKI certificate. 296 This certificate is the issuer of the BPKI EE certificates 297 corresponding to private keys that the parent will use to sign 298 provisioning protocol messages to the child. 300 offer: If an element is present, the parent is offering 301 publication service to the child. The element, if 302 present, is empty. 304 referral: If a element is present, it suggests a third- 305 party publication services that the child might use, and contains: 307 referrer: A referrer attribute, containing the handle by which 308 the publication repository knows the parent, 310 contact_uri: An optional contact_uri attribute that the child may 311 be able to follow for more information, and 313 Authorization token: The text of the element is the 314 Base64 encoding of a signed authorization token granting the 315 child the right to use a portion of the parent's namespace 316 at the publication repository in question. See Section 3.4 317 for details on the authorization token. 319 --------------------------------------------------------------------- 320 326 327 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 329 330 331 332 --------------------------------------------------------------------- 334 --------------------------------------------------------------------- 335 341 342 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 343 344 346 R28sIGxlbW1pbmdzLCBnbyE= 347 348 349 --------------------------------------------------------------------- 351 3.3.3. 353 The message is a setup request from a publisher 354 to a repository. 356 Fields in the message: 358 version: The version attribute specifies the protocol version. This 359 note describes protocol version 1. 361 publisher_handle: The publisher_handle attribute is the publisher's 362 name for itself. This is just a hint, the repository need not 363 honor it. 365 publisher_bpki_ta: The element is the 366 publisher's BPKI identity, a self-signed X.509 BPKI certificate. 367 This certificate is the issuer of the BPKI EE certificates 368 corresponding to private keys that the publisher will use to sign 369 publication protocol messages to the repository. 371 referral: If a element is present, it contains: 373 referrer: A referrer attribute containing the publication handle 374 of the referring parent, and 376 Authorization token: The text of the element is the 377 Base64 encoding of a signed authorization token granting the 378 publisher the right to use a portion of its parent's 379 namespace at this repository. See Section 3.4 for details 380 on the authorization token. 382 These fields are copies of values that a parent provided to the 383 child in the message (see Section 3.3.2). The 384 referrer attribute is present to aid lookup of the corresponding 385 certificate by the repository. Note that the repository operator 386 makes the final decision on whether to grant publication service 387 to the prospective publisher. The element just 388 conveys a parent's grant of permission to use a portion of that 389 parent's namespace. 391 --------------------------------------------------------------------- 392 396 397 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 398 399 400 --------------------------------------------------------------------- 402 3.3.4. 404 The message is a repository's response to a 405 publisher which has previously sent a message. 407 Fields in the message: 409 version: The version attribute specifies the protocol version. This 410 note describes protocol version 1. 412 service_uri: The service_uri attribute contains an HTTP URL that the 413 publisher should contact for publication service 414 ([I-D.ietf-sidr-publication]). 416 publisher_handle: The publisher_handle attribute is the repository's 417 name for the publisher. This may or may not match the 418 publisher_handle attribute in the publisher's 419 message. 421 sia_base: The sia_base attribute is the rsync:// URI for the base of 422 the publication space allocated to the publisher. 424 repository_bpki_ta: The element is the 425 repository's BPKI identity, a self-signed X.509 BPKI certificate. 427 --------------------------------------------------------------------- 428 434 435 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 436 437 438 --------------------------------------------------------------------- 440 3.4. 442 The element is a separate message which is signed 443 with CMS, then included as the Base64 content of elements 444 in other messages. 446 The eContentType for the signed CMS message is id-ct-xml. 448 Fields in the element: 450 version: The version attribute specifies the protocol version. This 451 note describes protocol version 1. 453 authorized_sia_base: The value of the authorized_sia_base attribute 454 is the rsync:// URI of the base of the namespace which the 455 referrer is delegating. 457 bpki_ta: The element is the identity of the entity to 458 whom the referrer is delegating the portion of the namespace named 459 in the authorized_sia_base attribute. The identity is represented 460 as a self-signed X.509 BPKI certificate. 462 --------------------------------------------------------------------- 463 467 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 468 469 --------------------------------------------------------------------- 471 3.5. 473 The element is an optional message which can be used in 474 response to any of the core protocol messages described in 475 Section 3.3. 477 Whether an element is an appropriate way to signal errors 478 back to the sender of a protocol message depends on details of the 479 implementation which are outside this specification. For example, if 480 this protocol is embedded in a web portal interface which is designed 481 to let a human being upload and download these messages via upload 482 and download forms, a human-readable error message may be more 483 appropriate. On the other hand, a portal intended to be driven by a 484 robotic client might well want to use an message to signal 485 errors. Similar arguments apply to non-web encapsulations (email, 486 USB stick, ...); the primary factor is likely to be whether the 487 implementation expects the error to be handled by a human being or by 488 a program. 490 Fields in the message: 492 version: The version attribute specifies the protocol version. This 493 note describes protocol version 1. 495 reason: The reason attribute contains a code indicating what was 496 wrong with the message. This version of the protocol defines the 497 following codes: 499 syntax-error: Receiver could not parse the offending message. 501 authentication-failure: Receiver could not authenticate the 502 offending message. 504 refused: Receiver refused to perform the requested action. 506 Offending message: The element contains a verbatim copy of 507 the message to which this error applies. 509 --------------------------------------------------------------------- 510 514 516 517 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 518 520 521 522 --------------------------------------------------------------------- 524 4. Protocol Walk-Through 526 This section walks through a few simple examples of the protocol in 527 use, and stars our old friends, Alice, Bob, and Carol. In this 528 example, Alice is the root of a RPKI tree, Bob wants to get address 529 and ASN resources from Alice, and Carol wants to get some of those 530 resources in turn from Bob. Alice offers publication service, which 531 is used by all three. 533 Alice, Bob, and Carol each generates his or her own self-signed BPKI 534 certificate. 536 Bob constructs a message and sends it to Alice: 538 --------------------------------------------------------------------- 539 543 544 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 545 546 547 --------------------------------------------------------------------- 549 o Bob's preferred handle is "Bob", so Bob uses that when setting 550 child_handle. 552 o is Bob's self-signed BPKI certificate. 554 Alice replies with a message, but Alice already 555 has 41 other children named Bob, so she calls this one "Bob-42". 556 Alice's provisioning protocol server happens to use a RESTful URL 557 scheme so that it can find the expected validation context for the 558 provisioning protocol CMS message just by looking at the URL, so the 559 service URL she provides to Bob includes both her name and Bob's. 560 Alice offers publication service, so she offers to let Bob use it; 561 Alice doesn't have to do this, she could just omit this and leave Bob 562 to find publication service on his own, but Alice is trying to be 563 helpful to her customer Bob. Bob doesn't have to accept Alice's 564 offer, but may choose to do so. 566 --------------------------------------------------------------------- 567 573 574 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 575 576 577 578 --------------------------------------------------------------------- 580 o is Alice's own self-signed BPKI certificate. 582 Bob receives Alice's and extracts the fields Bob's 583 RPKI engine will need to know about (child_handle, parent_handle, 584 service_uri, and ). Bob also sees the repository 585 offer, decides to take Alice up on this offer, and constructs a 586 message accordingly: 588 --------------------------------------------------------------------- 589 593 594 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 595 596 597 --------------------------------------------------------------------- 599 Alice receives Bob's request to use Alice's publication service, 600 decides to honor the offer she made, and sends back a 601 message in response. Alice recognizes Bob as 602 one of her own children, because she's already seen Bob's self-signed 603 BPKI certificate, so she allocates publication space to Bob under her 604 own publication space, so that relying parties who rsync her products 605 will pick up Bob's products automatically without needing an 606 additional fetch operation. 608 --------------------------------------------------------------------- 609 615 616 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 617 618 619 --------------------------------------------------------------------- 621 Bob should now have everything he needs to talk to Alice both for 622 provisioning and for publication. 624 A more interesting case is Bob's child, Carol. Carol wants to get 625 her resources from Bob, and, like Bob, does not particularly want to 626 operate a publication service. Bob doesn't have a publication 627 service of his own to offer, but he can refer Carol to Alice, along 628 with his permission for Carol to use a portion of the namespace that 629 Alice gave him. 631 Carol's to Bob looks very similar to Bob's earlier 632 request to Alice: 634 --------------------------------------------------------------------- 635 639 640 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 641 642 643 --------------------------------------------------------------------- 645 Bob's to Carol also looks a lot like Alice's 646 response to Bob, except that Bob includes a element 647 instead of an element. Carol is an only child, so Bob 648 leaves her name alone: 650 --------------------------------------------------------------------- 651 657 658 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 659 660 662 R28sIGxlbW1pbmdzLCBnbyE= 663 664 665 --------------------------------------------------------------------- 667 Bob's response includes a element with a referrer 668 attribute of "Alice/Bob-42", since that's Bob's name to Alice's 669 repository. The Base64-encoded authorization token is an 670 element in a CMS message that can be verified 671 against Bob's self-signed BPKI certificate, using a BPKI EE 672 certificate included in the CMS wrapper. The text 673 is Carol's self-signed BPKI certificate; Bob's signature over this 674 element indicates Bob's permission for Carol to use the indicated 675 portion of Bob's publication space. 677 --------------------------------------------------------------------- 678 682 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 683 684 --------------------------------------------------------------------- 686 Carol, not wanting to have to run a publication service, presents 687 Bob's referral to Alice in the hope that Alice will let Carol use 688 Alice's publication service. So Carol constructs a 689 message including the referral information 690 received from Bob, and sends it all to Alice: 692 --------------------------------------------------------------------- 693 697 698 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 699 700 702 R28sIGxlbW1pbmdzLCBnbyE= 703 705 706 --------------------------------------------------------------------- 708 Alice sees the signed authorization token Bob gave to Carol, checks 709 its signature, and unpacks it. When the signature proves valid and 710 the contained BPKI TA matches Carol's, Alice knows that Bob is 711 willing to let Carol use a portion of Bob's namespace. Given this, 712 Alice is willing to provide publication service to Carol in the 713 subtree allocated by Bob for this purpose, so Alice sends back a 714 : 716 --------------------------------------------------------------------- 717 723 724 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 725 726 727 --------------------------------------------------------------------- 729 Once Carol receives this response, Carol should be good to go. 731 In theory the publication referral mechanism can extend indefinitely 732 (for example, Carol can refer her child Dave to Alice for publication 733 service and it should all work). In practice, this has not yet been 734 implemented, much less tested. In order to keep the protocol 735 relatively simple, we've deliberately ignored perverse cases such as 736 Bob being willing to refer Carol to Alice but not wanting Carol to be 737 allowed to refer Dave to Alice. 739 5. IANA Considerations 741 Blah. 743 6. Security Considerations 745 As stated in Section 1, the basic function of this protocol is an 746 exchange of public keys to be used as BPKI trust anchors. Integrity 747 and authentication of these exchanges MUST be ensured via external 748 mechanisms deliberately left unspecified in this protocol. 750 7. Acknowledgements 752 The author would like to thank: Byron Ellacott, George Michaelson, 753 Leif Johansson, Matsuzaki Yoshinobu, Michael Elkins, Randy Bush, 754 Seiichi Kawamura, Tim Bruijnzeels, and anybody else who helped along 755 the way whose name the author has temporarily forgotten. 757 8. Normative References 759 [I-D.ietf-sidr-publication] 760 Weiler, S., Sonalker, A., and R. Austein, "A Publication 761 Protocol for the Resource Public Key Infrastructure 762 (RPKI)", draft-ietf-sidr-publication-03 (work in 763 progress), July 2012. 765 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 766 Housley, R., and W. Polk, "Internet X.509 Public Key 767 Infrastructure Certificate and Certificate Revocation List 768 (CRL) Profile", RFC 5280, May 2008. 770 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 771 5652, STD 70, September 2009. 773 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 774 Protocol for Provisioning Resource Certificates", RFC 775 6492, February 2012. 777 Appendix A. RelaxNG Schema 779 Here is a RelaxNG schema describing the protocol elements. 781 # $Id: rpki-setup.rnc 2408 2013-05-24 13:16:55Z sra $ 783 default namespace = "http://www.hactrn.net/uris/rpki/rpki-setup/" 785 version = "1" 787 base64 = xsd:base64Binary { maxLength="512000" } 788 handle = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" } 789 uri = xsd:anyURI { maxLength="4096" } 790 any = element * { attribute * { text }*, ( any | text )* } 792 authorization_token = base64 793 bpki_ta = base64 795 start |= child_request 796 start |= parent_response 797 start |= publisher_request 798 start |= repository_response 799 start |= authorization 800 start |= error 802 child_request = 803 element child_request { 804 attribute version { version }, 805 attribute child_handle { handle }, 806 element child_bpki_ta { bpki_ta } 807 } 809 parent_response = 810 element parent_response { 811 attribute version { version }, 812 attribute service_uri { uri }, 813 attribute child_handle { handle }, 814 attribute parent_handle { handle }, 815 element parent_bpki_ta { bpki_ta }, 816 element offer { empty }?, 817 element referral { 818 attribute referrer { handle }, 819 attribute contact_uri { uri }?, 820 authorization_token 821 }* 822 } 824 publisher_request = 825 element publisher_request { 826 attribute version { version }, 827 attribute publisher_handle { handle }, 828 element publisher_bpki_ta { bpki_ta }, 829 element referral { 830 attribute referrer { handle }, 831 authorization_token 832 }* 833 } 835 repository_response = 836 element repository_response { 837 attribute version { version }, 838 attribute service_uri { uri }, 839 attribute publisher_handle { handle }, 840 attribute sia_base { uri }, 841 element repository_bpki_ta { bpki_ta } 842 } 844 authorization = 845 element authorization { 846 attribute version { version }, 847 attribute authorized_sia_base { uri }, 848 bpki_ta 849 } 851 error = 852 element error { 853 attribute version { version }, 854 attribute reason { 855 "syntax-error" | 856 "authentication-failure" | 857 "refused" 858 }, 859 any? 860 } 862 Author's Address 864 Rob Austein 865 Dragon Research Labs 867 Email: sra@hactrn.net