idnits 2.17.1 draft-ietf-sidr-delta-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2957 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: 'RFC7232' is defined on line 771, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AD-NUMBERS' ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bruijnzeels 3 Internet-Draft O. Muravskiy 4 Intended status: Standards Track RIPE NCC 5 Expires: September 22, 2016 B. Weber 6 Cobenian 7 R. Austein 8 Dragon Research Labs 9 D. Mandelberg 10 BBN Technologies 11 March 21, 2016 13 RPKI Repository Delta Protocol 14 draft-ietf-sidr-delta-protocol-02 16 Abstract 18 In the Resource Public Key Infrastructure (RPKI), certificate 19 authorities publish certificates, including end entity certificates, 20 Certificate Revocation Lists (CRL), and RPKI signed objects to 21 repositories. Relying Parties (RP) retrieve the published 22 information from those repositories. This document specifies a delta 23 protocol which provides relying parties with a mechanism to query a 24 repository for incremental updates, thus enabling the RP to keep its 25 state in sync with the repository. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 22, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. RPKI Repository Delta Protocol Implementation . . . . . . . . 3 64 3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Certificate Authority Use . . . . . . . . . . . . . . . . 4 66 3.3. Repository Server Use . . . . . . . . . . . . . . . . . . 5 67 3.3.1. Initialisation . . . . . . . . . . . . . . . . . . . 5 68 3.3.2. Publishing Updates . . . . . . . . . . . . . . . . . 5 69 3.4. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7 70 3.4.1. Processing the Update Notification File . . . . . . . 7 71 3.4.2. Processing a Snapshot File . . . . . . . . . . . . . 8 72 3.4.3. Processing Delta Files . . . . . . . . . . . . . . . 8 73 3.4.4. Polling the Update Notification File . . . . . . . . 9 74 3.5. File Definitions . . . . . . . . . . . . . . . . . . . . 9 75 3.5.1. Update Notification File . . . . . . . . . . . . . . 9 76 3.5.2. Snapshot File . . . . . . . . . . . . . . . . . . . . 11 77 3.5.3. Delta File . . . . . . . . . . . . . . . . . . . . . 12 78 3.5.4. XML Schema . . . . . . . . . . . . . . . . . . . . . 14 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 7. Normative References . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Introduction 93 In the Resource Public Key Infrastructure (RPKI), Certificate 94 Authorities (CAs) publish certificates [RFC6487], RPKI signed objects 95 [RFC6488], manifests [RFC6486], and CRLs to repositories. CAs may 96 have an embedded mechanism to publish to these repositories, or they 97 may use a separate repository server and publication protocol. RPKI 98 repositories are currently accessible using the rsync protocol, 99 allowing Relying Parties (RPs) to synchronise a local copy of the 100 RPKI repository used for validation with the remote repositories 101 [RFC6481]. 103 This document specifies an alternative repository access protocol 104 based on notification, snapshot and delta files that a RP can 105 retrieve over the HTTPS protocol. This allows RPs to perform either 106 a full (re-)synchronisation of their local copy of the repository 107 using snapshot files, or use delta files to keep their local 108 repository updated after initial synchronisation. 110 This protocol is designed to be consistent (in terms of data 111 structures) with the publication protocol [I-D.ietf-sidr-publication] 112 and treats publication events of one or more repository objects as 113 discrete events that can be communicated to relying parties. This 114 approach helps to minimize the amount of data that traverses the 115 network and thus helps minimize the amount of time until repository 116 convergence occurs. This protocol also provides a standards based 117 way to obtain consistent, point in time views of a single repository, 118 eliminating a number of consistency related issues. Finally, this 119 approach allows these discrete events to be communicated as immutable 120 files, so that caching infrastructure can be used to reduce the load 121 on a repository server when a large number of relying parties are 122 querying it. 124 3. RPKI Repository Delta Protocol Implementation 126 3.1. Informal Overview 128 Certification Authorities (CA) in the RPKI use a repository server to 129 publish their RPKI products, such as manifests, CRLs, signed 130 certificates and RPKI signed objects. This repository server may be 131 remote, or embedded in the CA engine itself. Certificates in the 132 RPKI that use a repository server that supports this delta protocol 133 include a special Subject Information Access (SIA) pointer referring 134 to a notification file. 136 The notification file includes a globally unique session_id in the 137 form of a version 4 UUID, and serial number that can be used by the 138 Relying Party (RP) to determine if it and the repository are 139 synchronised. Furthermore it includes a link to the most recent 140 complete snapshot of current objects that are published by the 141 repository server, and a list of links to delta files, for each 142 revision starting at a point determined by the repository server, up 143 to the current revision of the repository. 145 A RP that learns about a notification file location for the first 146 time can download it, and then proceed to download the latest 147 snapshot file, and thus create a local copy of the repository that is 148 in sync with the repository server. The RP should remember the 149 location of this notification file, the session_id and current serial 150 number. 152 RPs are encouraged to re-fetch this notification file at regular 153 intervals, but not more often than once per minute. After re- 154 fetching the notification file, the RP may find that there are one or 155 more delta files available that allow it to synchronise its local 156 repository with the current state of the repository server. If no 157 contiguous chain of deltas from RP's serial to the latest repository 158 serial is available, or if the session_id has changed, the RP should 159 perform a full resynchronisation instead. 161 As soon as the RP fetches new content in this way it should start a 162 validation process. An example of a reason why a RP may not do this 163 immediately is because it has learned of more than one notification 164 location and it prefers to complete all its updates before 165 validating. 167 The repository server may use caching infrastructure to reduce its 168 load. It should be noted that snapshots and deltas for any given 169 session_id and serial number contain an immutable record of the state 170 of the repository server at a certain point in time. For this reason 171 these files can be cached indefinitely. Notification files are 172 polled by RPs to discover if updates exist, and for this reason 173 notification files may not be cached for longer than one minute. 175 3.2. Certificate Authority Use 177 Certificate Authorities that use this delta protocol MUST include an 178 instance of an SIA AccessDescription extension in resource 179 certificates they produce, in addition to the ones defined in 180 [RFC6487], 182 AccessDescription ::= SEQUENCE { 183 accessMethod OBJECT IDENTIFIER, 184 accessLocation GeneralName } 186 This extension MUST use an accessMethod of id-ad-rpkiNotify, see: 187 [IANA-AD-NUMBERS], 189 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 190 id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 } 192 The accessLocation MUST be a URI [RFC3986], using the 'https' scheme, 193 that will point to the update notification file for the repository 194 server that publishes the products of this CA certificate. 196 Relying Parties that do not support this delta protocol MUST NOT 197 reject a CA certificate merely because it has an SIA extension 198 containing this new kind of AccessDescription. 200 3.3. Repository Server Use 202 3.3.1. Initialisation 204 When the repository server initialises it must perform the following 205 actions: 207 The server MUST generate a new random version 4 UUID to be used as 208 the session_id 210 The server MUST then generate a snapshot file for serial number 211 ONE for this new session that includes all currently known 212 published objects that the repository server is responsible for. 213 Note that this snapshot file MAY contain zero publish elements at 214 this point if no objects have been submitted for publication yet. 216 This snapshot file MUST be made available at a URL that is unique 217 to this session_id and serial number, so that it can be cached 218 indefinitely. 220 The format and caching concerns for snapshot files are explained 221 in more detail in Section 3.5.2. 223 After the snapshot file has been published the repository server 224 MUST publish a new notification file that contains the new 225 session_id, has serial number ONE, has one reference to the 226 snapshot file that was just published, and that contains no delta 227 references. 229 The format and caching concerns for update notification files are 230 explained in more detail in Section 3.5.1. 232 3.3.2. Publishing Updates 234 Whenever the repository server receives updates from a CA it SHOULD 235 generate new snapshot and delta files. However, if a publication 236 server services a large number of CAs it MAY choose to combine 237 updates from multiple CAs. If a publication server combines updates 238 in this way, it MUST NOT postpone publishing for longer than one 239 minute. 241 Updates must be processed as follows: 243 o The new repository serial number MUST be one greater than the 244 current repository serial number. 246 o A new delta file MUST be generated for this new serial. This 247 delta file MUST include all new, replaced and withdrawn objects 248 for multiple CAs if applicable, as a single change set. 250 o This delta file MUST be made available at a URL that is unique to 251 the current session_id and serial number, so that it can be cached 252 indefinitely. 254 o The format and caching concerns for delta files are explained in 255 more detail in Section 3.5.3. 257 o The repository server MUST also generate a new snapshot file for 258 this new serial. This file MUST contain all "publish" elements 259 for all current objects. 261 o The snapshot file MUST be made available at a URL that is unique 262 to this session and new serial, so that it can be cached 263 indefinitely. 265 o The format and caching concerns for snapshot files are explained 266 in more detail in Section 3.5.2. 268 o The update notification file SHOULD be kept small, and in order to 269 do so the repository server needs to make a decision about which 270 delta files to support. Any older delta files that, when combined 271 with all more recent delta files, will result in total size of 272 deltas exceeding the size of the snapshot, MUST be excluded. 274 o The server MAY also exclude more recent delta files if it finds 275 that their usage by a small number of RPs that would be forced to 276 perform a full synchronisation is outweighed by the performance 277 penalty for all RPs in having a large update notification file. 278 However the repository server SHOULD include all deltas for the 279 last two hours. 281 o A new notification file MUST now be created by the repository 282 server. This new notification file MUST include a reference to 283 the new snapshot file, and all delta files selected in the 284 previous steps. 286 o The format and caching concerns for update notification files are 287 explained in more detail in Section 3.5.1. 289 If the repository server is not capable of performing the above for 290 some reason, then it MUST perform a full re-initialisation, as 291 explained above in Section 3.3.1. 293 3.4. Relying Party Use 295 3.4.1. Processing the Update Notification File 297 When a Relying Party (RP) performs RPKI validation and learns about a 298 valid certificate with an SIA entry for the RRDP protocol, it SHOULD 299 prefer to use this protocol as follows. 301 The RP SHOULD download the update notification file, unless an update 302 notification file was already downloaded and processed from the same 303 location in this validation run. 305 The RP MAY use a "User-Agent" header explained in section 5.5.3. of 306 [RFC7231] to identify the name and version of the RP software used. 307 This is not required, but would be useful to help track capabilities 308 of Relying Parties in the event of changes to the RPKI standards. 310 When the RP downloads an update notification file it MUST verify the 311 file format and validation steps described in section 312 Section 3.5.1.3. If this verification fails, the file MUST be 313 rejected. 315 The RP MUST verify whether the session_id in this update notification 316 file matches the last known session_id for this update notification 317 file location. If the session_id matches the last known session_id, 318 then an RP MAY download and process missing delta files as described 319 in section Section 3.4.3, provided that all delta files for serial 320 numbers between the last processed serial number and the current 321 serial number in the notification file can be processed this way. 323 If the session_id was not previously known, or if delta files could 324 not be used, then the RP MUST update its last known session_id to 325 this session_id and download and process snapshot file on the update 326 notification file as described in section Section 3.4.2. 328 If neither update notification file and one snapshot file or delta 329 files could be processed this way, the RP MUST issue an operator 330 error, and SHOULD use an alternate repository retrieval mechanism if 331 it is available. 333 3.4.2. Processing a Snapshot File 335 When the RP downloads a snapshot file it MUST verify the file format 336 and validation steps described in Section 3.5.2.3. If this 337 verification fails, the file MUST be rejected. 339 Furthermore the RP MUST verify that the hash of the contents of this 340 file matches the hash on the update notification file that referenced 341 it. In case of a mismatch of this hash, the file MUST be rejected. 343 If an RP retrieved a snapshot file that is valid according to the 344 above criteria, it should perform the following actions: 346 The RP MUST verify that the session_id matches the session_id of 347 the notification file. If the session_id values do not match the 348 file MUST be rejected. 350 The RP MUST verify that the serial number of this snapshot file is 351 greater than the last processed serial number for this session_id. 352 If this fails the file MUST be rejected. 354 The RP SHOULD then add all publish elements to a local storage and 355 update its last processed serial number to the serial number of 356 this snapshot file. 358 3.4.3. Processing Delta Files 360 If an update notification file contains a contiguous chain of links 361 to delta files from the last processed serial number to the current 362 serial number, then RPs MUST attempt to download and process all 363 delta files in order of serial number as follows. 365 When the RP downloads a delta file it MUST verify the file format and 366 perform validation steps described in Section 3.5.3.3. If this 367 verification fails, the file MUST be rejected. 369 Furthermore the RP MUST verify that the hash of the contents of this 370 file matches the hash on the update notification file that referenced 371 it. In case of a mismatch of this hash, the file MUST be rejected. 373 If an RP retrieved a delta file that is valid according to the above 374 criteria, it should perform the following actions: 376 The RP MUST verify that the session_id matches the session_id of 377 the notification file. If the session_id values do not match the 378 file MUST be rejected. 380 The RP MUST verify that the serial number of this delta file is 381 exactly one greater than the last processed serial number for this 382 session_id, and if not this file MUST be rejected. 384 The RP SHOULD add all publish elements to a local storage and 385 update its last processed serial number to the serial number of 386 this snapshot file. 388 The RP SHOULD NOT remove objects from its local storage solely 389 because it encounters a "withdraw" element, because this would 390 enable a publication server to withdraw any object without the 391 signing Certificate Authority consent. Instead it is RECOMMENDED 392 that a RP uses additional strategies to determine if an object is 393 still relevant for validation before removing it from its local 394 storage. 396 3.4.4. Polling the Update Notification File 398 Once a Relying Party has learned about the location, session_id and 399 last processed serial number of repository that uses the RRDP 400 protocol, the RP MAY start polling the repository server for updates. 401 However the RP MUST NOT poll for updates more often than once every 1 402 minute, and in order to reduce data usage RPs MUST use the "If- 403 Modified-Since" header explained in section 3.3 of [RFC7232]in 404 requests. 406 If an RP finds that updates are available it SHOULD download and 407 process the file as described in Section 3.4.1, and initiate a new 408 validation process. A detailed description of the validation process 409 itself is out of scope of this document. 411 3.5. File Definitions 413 3.5.1. Update Notification File 415 3.5.1.1. Purpose 417 The update notification file is used by RPs to discover whether any 418 changes exist between the state of the repository and the RP's cache. 419 It describes the location of the files containing the snapshot and 420 incremental deltas which can be used by the RP to synchronise with 421 the repository. 423 3.5.1.2. Cache Concerns 425 A repository server MAY use caching infrastructure to cache the 426 notification file and reduce the load of HTTPS requests. However, 427 since this file is used by RPs to determine whether any updates are 428 available the repository server MUST ensure that this file is not 429 cached for longer than 1 minute. An exception to this rule is that 430 it is better to serve a stale notification file, then no notification 431 file. 433 How this is achieved exactly depends on the caching infrastructure 434 used. In general a repository server may find certain HTTP headers 435 to be useful, such as: Cache-Control: max-age=60. Another approach 436 can be to have the repository server push out new versions of the 437 notification file to the caching infrastructure when appropriate. 439 Relying Parties SHOULD NOT cache the notification file for longer 440 than 1 minute, regardless of the headers set by the repository server 441 or CDN. 443 3.5.1.3. File Format and Validation 445 Example notification file: 447 451 452 453 454 456 Note: URIs and hash values in this example are shortened because of 457 formatting. 459 The following validation rules must be observed when creating or 460 parsing notification files: 462 o A RP MUST reject any update notification file that is not well- 463 formed, or which does not conform to the RELAX NG schema outlined 464 in Section 3.5.4 of this document. 466 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp 468 o The encoding MUST be US-ASCII 470 o The version attribute in the notification root element MUST be 1 472 o The session_id attribute MUST be a random version 4 UUID unique to 473 this session 475 o The serial attribute must be an unbounded, unsigned positive 476 integer in decimal format indicating the current version of the 477 repository. 479 o The notification file MUST contain exactly one 'snapshot' element 480 for the current repository version. 482 o If delta elements are included they MUST form a contiguous 483 sequence of serial numbers starting at a revision determined by 484 the repository server, up to the serial number mentioned in the 485 notification element. 487 o The hash attribute in snapshot and delta elements must be the 488 hexadecimal encoding of the SHA-256 hash of the referenced file. 489 The RP MUST verify this hash when the file is retrieved and reject 490 the file if the hash does not match. 492 3.5.2. Snapshot File 494 3.5.2.1. Purpose 496 A snapshot is intended to reflect the complete and current contents 497 of the repository for a specific session and version. Therefore it 498 MUST contain all objects from the repository current as of the time 499 of the publication. 501 3.5.2.2. Cache Concerns 503 A snapshot reflects the content of the repository at a specific point 504 in time, and for that reason can be considered immutable data. 505 Snapshot files MUST be published at a URL that is unique to the 506 specific session and serial. 508 Because these files never change, they MAY be cached indefinitely. 509 However, in order to prevent that these files use a lot of space in 510 caching infrastructure it is RECOMMENDED that a limited interval is 511 used in the order of hours or days. 513 To avoid race conditions where an RP downloads a notification file 514 moments before it's updated, Repository Servers SHOULD retain old 515 snapshot files for at least 5 minutes after a new notification file 516 is published. 518 3.5.2.3. File Format and Validation 520 Example snapshot file: 522 526 527 ZXhhbXBsZTE= 528 529 530 ZXhhbXBsZTI= 531 532 533 ZXhhbXBsZTM= 534 535 537 The following rules must be observed when creating or parsing 538 snapshot files: 540 o A RP MUST reject any snapshot file that is not well-formed, or 541 which does not conform to the RELAX NG schema outlined in 542 Section 3.5.4 of this document. 544 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 546 o The encoding MUST be US-ASCII. 548 o The version attribute in the notification root element MUST be 1 550 o The session_id attribute MUST match the expected session_id in the 551 reference in the notification file. 553 o The serial attribute MUST match the expected serial in the 554 reference in the notification file. 556 o Note that the publish element is defined in the publication 557 protocol [I-D.ietf-sidr-publication] 559 3.5.3. Delta File 561 3.5.3.1. Purpose 563 An incremental delta file contains all changes for exactly one serial 564 increment of the repository server. In other words a single delta 565 will typically include all the new objects, updated objects and 566 withdrawn objects that a Certification Authority sent to the 567 repository server. In its simplest form the update could concern 568 only a single object, but it is recommended that CAs send all changes 569 for one of their key pairs: i.e. updated objects as well as a new 570 manifest and CRL as one atomic update message. 572 3.5.3.2. Cache Concerns 574 Deltas reflect the difference between two consecutive versions of a 575 repository for a given session. For that reason deltas can be 576 considered immutable data. Delta files MUST be published at a URL 577 that is unique to the specific session and serial. 579 Because these files never change, they MAY be cached indefinitely. 580 However, in order to prevent these files from using a lot of space in 581 caching infrastructure it is RECOMMENDED that a limited interval is 582 used in the order of hours or days. 584 To avoid race conditions where an RP downloads a notification file 585 moments before it's updated, Repository Servers SHOULD retain old 586 delta files for at least 5 minutes after they are no no longer 587 included in the latest notification file. 589 3.5.3.3. File Format and Validation 591 Example delta file: 593 597 599 ZXhhbXBsZTQ= 600 601 603 ZXhhbXBsZTU= 604 605 607 609 Note that a formal RELAX NG specification of this file format is 610 included later in this document. A RP MUST NOT process any delta 611 file that is incomplete or not well-formed. 613 The following validation rules must be observed when creating or 614 parsing delta files: 616 o A RP MUST reject any delta file that is not well-formed, or which 617 does not conform to the RELAX NG schema outlined in Section 3.5.4 618 of this document. 620 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 622 o The encoding MUST be US-ASCII. 624 o The version attribute in the delta root element MUST be 1 626 o The session_id attribute MUST be a random version 4 UUID unique to 627 this session 629 o The session_id attribute MUST match the expected session_id in the 630 reference in the notification file. 632 o The serial attribute MUST match the expected serial in the 633 reference in the notification file. 635 o Note that the publish and withdraw elements are defined in the 636 publication protocol [I-D.ietf-sidr-publication] 638 3.5.4. XML Schema 640 The following is a RELAX NG compact form schema describing version 1 641 of this protocol. 643 # 644 # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). 645 # 647 default namespace = "http://www.ripe.net/rpki/rrdp" 649 version = xsd:positiveInteger { maxInclusive="1" } 650 serial = xsd:nonNegativeInteger 651 uri = xsd:anyURI 652 uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } 653 hash = xsd:string { pattern = "[0-9a-fA-F]+" } 654 base64 = xsd:base64Binary 656 # Notification file: lists current snapshots and deltas 658 start |= element notification { 659 attribute version { version }, 660 attribute session_id { uuid }, 661 attribute serial { serial }, 662 element snapshot { 663 attribute uri { uri }, 664 attribute hash { hash } 665 }, 666 element delta { 667 attribute serial { serial }, 668 attribute uri { uri }, 669 attribute hash { hash } 670 }* 671 } 673 # Snapshot segment: think DNS AXFR. 675 start |= element snapshot { 676 attribute version { version }, 677 attribute session_id { uuid }, 678 attribute serial { serial }, 679 element publish { 680 attribute uri { uri }, 681 base64 682 }* 683 } 685 # Delta segment: think DNS IXFR. 687 start |= element delta { 688 attribute version { version }, 689 attribute session_id { uuid }, 690 attribute serial { serial }, 691 delta_element+ 692 } 694 delta_element |= element publish { 695 attribute uri { uri }, 696 attribute hash { hash }?, 697 base64 698 } 700 delta_element |= element withdraw { 701 attribute uri { uri }, 702 attribute hash { hash } 703 } 705 # Local Variables: 706 # indent-tabs-mode: nil 707 # comment-start: "# " 708 # comment-start-skip: "#[ \t]*" 709 # End: 711 4. Security Considerations 713 TBD 715 5. IANA Considerations 717 This document has no actions for IANA. 719 6. Acknowledgements 721 TBD 723 7. Normative References 725 [I-D.ietf-sidr-publication] 726 Weiler, S., Sonalker, A., and R. Austein, "A Publication 727 Protocol for the Resource Public Key Infrastructure 728 (RPKI)", draft-ietf-sidr-publication-07 (work in 729 progress), September 2015. 731 [IANA-AD-NUMBERS] 732 "SMI Security for PKIX Access Descriptor", 733 . 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, 738 DOI 10.17487/RFC2119, March 1997, 739 . 741 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 742 Resource Identifier (URI): Generic Syntax", STD 66, 743 RFC 3986, DOI 10.17487/RFC3986, January 2005, 744 . 746 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 747 Resource Certificate Repository Structure", RFC 6481, 748 DOI 10.17487/RFC6481, February 2012, 749 . 751 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 752 "Manifests for the Resource Public Key Infrastructure 753 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 754 . 756 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 757 X.509 PKIX Resource Certificates", RFC 6487, 758 DOI 10.17487/RFC6487, February 2012, 759 . 761 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 762 Template for the Resource Public Key Infrastructure 763 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 764 . 766 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 767 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 768 DOI 10.17487/RFC7231, June 2014, 769 . 771 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 772 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 773 DOI 10.17487/RFC7232, June 2014, 774 . 776 Authors' Addresses 778 Tim Bruijnzeels 779 RIPE NCC 781 Email: tim@ripe.net 783 Oleg Muravskiy 784 RIPE NCC 786 Email: oleg@ripe.net 788 Bryan Weber 789 Cobenian 791 Email: bryan@cobenian.com 793 Rob Austein 794 Dragon Research Labs 796 Email: sra@hactrn.net 797 David Mandelberg 798 BBN Technologies 800 Email: david@mandelberg.org