idnits 2.17.1 draft-ietf-sidr-rpsl-sig-12.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2622, updated by this document, for RFC5378 checks: 1998-11-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2016) is 2893 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '6' on line 501 ** Downref: Normative reference to an Informational RFC: RFC 5781 ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR R. Kisteleki 3 Internet-Draft RIPE NCC 4 Updates: 2622, 4012 (if approved) B. Haberman 5 Intended status: Standards Track JHU APL 6 Expires: November 20, 2016 May 19, 2016 8 Securing RPSL Objects with RPKI Signatures 9 draft-ietf-sidr-rpsl-sig-12.txt 11 Abstract 13 This document describes a method to allow parties to electronically 14 sign Routing Policy Specification Language objects and validate such 15 electronic signatures. This allows relying parties to detect 16 accidental or malicious modifications on such objects. It also 17 allows parties who run Internet Routing Registries or similar 18 databases, but do not yet have Routing Policy System Security-based 19 authentication of the maintainers of certain objects, to verify that 20 the additions or modifications of such database objects are done by 21 the legitimate holder(s) of the Internet resources mentioned in those 22 objects. This document updates RFC 2622 and RFC 4012 to add the 23 signature attribute to supported RPSL objects. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 20, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3 61 2.1. General Attributes, Meta Information . . . . . . . . . . 3 62 2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5 63 2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5 64 2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 6 65 2.5. Validity Time of the Signature . . . . . . . . . . . . . 6 66 3. Signature Creation and Validation Steps . . . . . . . . . . . 6 67 3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8 69 3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9 70 4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10 71 5. Keys and Certificates used for Signature and Verification . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 9.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Objects stored in resource databases, like the RIPE DB, are generally 83 protected by an authentication mechanism: anyone creating or 84 modifying an object in the database has to have proper authorization 85 to do so, and therefore has to go through an authentication procedure 86 (provide a password, certificate, e-mail signature, etc.) However, 87 for objects transferred between resource databases, the 88 authentication is not guaranteed. This means that when a Routing 89 Policy Specification Language (RPSL) object is downloaded from a 90 database, the consumer can reasonably claim that the object is 91 authentic if it was locally created, but cannot make the same claim 92 for an object imported from a different database. Also, once such an 93 object is downloaded from the database, it becomes a simple (but 94 still structured) text file with no integrity protection. More 95 importantly, the authentication and integrity guarantees associated 96 with these objects do not always ensure that the entity that 97 generated them is authorized to make the assertions implied by the 98 data contained in the objects. 100 A potential use for resource certificates [RFC6487] is to use them to 101 secure such (both imported and downloaded) database objects, by 102 applying a digital signature over the object contents in lieu of 103 methods such as Routing Policy System Security [RFC2725]. The signer 104 of such signed database objects MUST possess a relevant resource 105 certificate, which shows him/her as the legitimate holder of an 106 Internet number resource. This mechanism allows the users of such 107 database objects to verify that the contents are in fact produced by 108 the legitimate holder(s) of the Internet resources mentioned in those 109 objects. It also allows the signatures to cover whole RPSL objects, 110 or just selected attributes of them. In other words, a digital 111 signature created using the private key associated with a resource 112 certificate can offer object security in addition to the channel 113 security already present in most of such databases. Object security 114 in turn allows such objects to be hosted in different databases and 115 still be independently verifiable. 117 While the approach outlined in this document mandates the use of the 118 RPKI for certificate distribution, it is not dependent upon the RPKI 119 for correct functionality. Equivalent functionality can be achieved 120 with a more traditional certificate authority, RFC 3779 [RFC3779] 121 extensions within the certificates, and the appropriate trust anchor 122 material to verify the digital signature. 124 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 125 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 [RFC2119]. 129 2. Signature Syntax and Semantics 131 When signing an RPSL object [RFC2622][RFC4012], the input for the 132 signature process is transformed into a sequence of strings of 133 (ASCII) data. The approach is similar to the one used in DKIM 134 (Domain Key Identified Mail) [RFC6376]. In the case of RPSL, the 135 object-to-be-signed closely resembles an SMTP header, so it seems 136 reasonable to adapt DKIM's relevant features. 138 2.1. General Attributes, Meta Information 140 The digital signature associated with an RPSL object is itself a new 141 attribute named "signature". It consists of mandatory and optional 142 fields. These fields are structured in a sequence of name and value 143 pairs, separated by a semicolon ";" and a white space. Collectively 144 these fields make up the value for the new "signature" attribute. 146 The "name" part of such a component is always a single ASCII 147 character that serves as an identifier; the value is an ASCII string 148 the contents of which depend on the field type. Mandatory fields 149 MUST appear exactly once, whereas optional fields MUST appear at most 150 once. 152 Mandatory fields of the "signature" attribute: 154 o Version of the signature (field "v"). This field MUST be set to 155 "rpkiv1" and MAY be the first field of the signature attribute to 156 simplify the parsing of the attributes' fields. The signature 157 format described in this document applies when the version field 158 is set to "rpkiv1". All the rest of the signature attributes are 159 defined by the value of version field. 161 o Reference to the certificate corresponding to the private key used 162 to sign this object (field "c"). The value of this field MUST be 163 a URL of type "rsync" [RFC5781] or "http(s)" [RFC7230] that points 164 to a specific resource certificate in an RPKI repository 165 [RFC6481]. Any non URL-safe characters (including semicolon ";" 166 and plus "+") must be URL encoded [RFC3986]. 168 o Signature method (field "m"): what hash and signature algorithms 169 were used to create the signature. This specification follows th 170 algorithms defined in RFC 6485 [RFC6485]. The algorithms are 171 referenced witin the signature attribute by the ASCII names of the 172 algorithms. 174 o Time of signing (field "t"). The format of the value of this 175 field MUST be in the Internet Date/Time ABNF format [RFC3339]. 176 All times MUST be converted to Universal Coordinated Time (UTC), 177 i.e., the ABNF time-offset is always "Z". 179 o The signed attributes (field "a"). This is a list of attribute 180 names, separated by an ASCII "+" character (if more than one 181 attribute is enumerated). The list must include any attribute at 182 most once. 184 o The signature itself (field "b"). This MUST be the last field in 185 the list. The signature is the output of the signature algorithm 186 using the appropriate private key and the calculated hash value of 187 the object as inputs. The value of this field is the digital 188 signature in base64 encoding (Section 4 of [RFC4648]). 190 Optional fields of the "signature" attribute: 192 o Signature expiration time (field "x"). The format of the value of 193 this field MUST be in the Internet Date/Time format [RFC3339]. 194 All times MUST be represented in UTC. 196 2.2. Signed Attributes 198 One can look at an RPSL object as an (ordered) set of attributes, 199 each having a "key: value" syntax. Understanding this structure can 200 help in developing more flexible methods for applying digital 201 signatures. 203 Some of these attributes are automatically added by the database, 204 some are database-dependent, yet others do not carry operationally 205 important information. This specification allows the maintainer of 206 such an object to decide which attributes are important (signed) and 207 which are not (not signed), from among all the attributes of the 208 object; in other words, we define a way of including important 209 attributes while excluding irrelevant ones. Allowing the maintainer 210 of an object to select the attributes that are covered by the digital 211 signature achieves the goals established in Section 1. 213 The type of the object determines the minimum set of attributes that 214 MUST be signed. The signer MAY choose to sign additional attributes, 215 in order to provide integrity protection for those attributes too. 217 When verifying the signature of an object, the verifier has to check 218 whether the signature itself is valid, and whether all the specified 219 attributes are referenced in the signature. If not, the verifier 220 MUST reject the signature and treat the object as a regular, non- 221 signed RPSL object. 223 2.3. Storage of the Signature Data 225 The result of applying the signature mechanism once is exactly one 226 new attribute for the object. As an illustration, the structure of a 227 signed RPSL object is as follows: 229 attribute1: value1 230 attribute2: value2 231 attribute3: value3 232 ... 233 signature: v=rpkiv1; c=rsync://.....; m=sha256WithRSAEncryption; 234 t=2014-12-31T23:59:60Z; 235 a=attribute1+attribute2+attribute3+...; 236 b= 238 2.4. Number Resource Coverage 240 Even if the signature over the object is valid according to the 241 signature validation rules, they may not be relevant to the object; 242 they also need to cover the relevant Internet number resources 243 mentioned in the object. 245 Therefore the Internet number resources present in [RFC3779] 246 extensions of the certificate referred to in the "c" field of the 247 signature MUST cover the resources in the primary key of the object 248 (e.g., value of the "aut-num:" attribute of an aut-num object, value 249 of the "inetnum:" attribute of an inetnum object, values of "route:" 250 and "origin:" attributes of a route object, etc.). 252 2.5. Validity Time of the Signature 254 The validity time interval of a signature is the intersection of the 255 validity time of the certificate used to verify the signature, the 256 "not before" time specified by the "t" field of the signature, and 257 the optional "not after" time specified by the "x" field of the 258 signature. 260 When checking multiple signatures, these checks are applied to each 261 signature, individually. 263 3. Signature Creation and Validation Steps 265 3.1. Canonicalization 267 The notion of canonicalization is essential to digital signature 268 generation and validation whenever data representations may change 269 between a signer and one or more signature verifiers. 270 Canonicalization defines how one transforms a representation of data 271 into a series of bits for signature generation and verification. The 272 task of canonicalization is to make irrelevant differences in 273 representations of the same object, which would otherwise cause 274 signature verification to fail. Examples of this could be: 276 o data transformations applied by the databases that host these 277 objects (such as notational changes for IPv4/IPv6 prefixes, 278 automatic addition/modification of "changed" attributes, etc.) 280 o the difference of line terminators across different systems. 282 This means that the destination database might change parts of the 283 submitted data after it was signed, which would cause signature 284 verification to fail. This document specifies strict 285 canonicalization rules to overcome this problem. 287 The following steps MUST be applied in order to achieve canonicalized 288 representation of an object, before the actual signature 289 (verification) process can begin: 291 1. Comments (anything beginning with a "#") MUST be omitted. 293 2. Any trailing white space MUST be omitted. 295 3. A multi-line attribute MUST be converted into its single-line 296 equivalent. This is accomplished by: 298 * Converting all line endings to a single blank space (ASCII 299 code 32). 301 * Concatenating all lines into a single line. 303 * Replacing the trailing blank space with a single new line 304 ("\n", ASCII code 10). 306 4. Numerical fields MUST be converted to canonical representations. 307 These include: 309 * Date and time fields MUST be converted to UTC and MUST be 310 represented in the Internet Date/Time format [RFC3339]. 312 * AS numbers MUST be converted to ASPLAIN syntax [RFC5396]. 314 * IPv6 addresses MUST be canonicalized as defined in [RFC5952]. 316 * IPv4 addresses MUST be represented as the ipv4-address type 317 defined by RPSL [RFC2622] 319 * All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR 320 notation [RFC4632]. 322 5. All ranges, lists, or sets of numerical fields are represented 323 using the appropriate RPSL attribute and each numerical element 324 contained within those attributes MUST conform to the 325 canonicalization rules in this document. The ordering of values 326 within such fields MUST be maintained during database transfers. 328 6. The name of each attribute MUST be converted into lower case, and 329 MUST be kept as part of the attribute line. 331 7. Tab characters ("\t", ASCII code 09) MUST be converted to spaces. 333 8. Multiple whitespaces MUST be collapsed into a single space (" ", 334 ASCII code 32) character. 336 9. All line endings MUST be converted to a singe new line ("\n", 337 ASCII code 10) character (thus avoiding CR vs. CRLF differences). 339 3.2. Signature Creation 341 Given an RPSL object and corresponding certificate, in order to 342 create the digital signature, the following steps MUST be performed: 344 1. Create a list of attribute names referring to the attributes that 345 will be signed (contents of the "a" field). The minimum set of 346 these attributes is determined by the object type; the signer MAY 347 select additional attributes. 349 2. Arrange the selected attributes according to the selection 350 sequence specified in the "a" field as above, omitting all 351 attributes that will not be signed. 353 3. Construct the new "signature" attribute, with all its fields, 354 leaving the value of the "b" field empty. 356 4. Apply canonicalization rules to the result (including the 357 "signature" attribute). 359 5. Create the signature over the results of the canonicalization 360 process (according to the signature and hash algorithms specified 361 in the "m" field of the signature attribute). 363 6. Insert the base64 encoded value of the signature as the value of 364 the "b" field. 366 7. Append the resulting "signature" attribute to the original 367 object. 369 3.3. Signature Validation 371 In order to validate a signature over such an object, the following 372 steps MUST be performed: 374 1. Verify the syntax of the "signature" attribute (i.e., whether it 375 contains the mandatory and optional components and the syntax of 376 these fields matches the specification as described in section 377 2.1.) 379 2. Fetch the certificate referred to in the "c" field of the 380 "signature" attribute, and check its validity using the steps 381 described in [RFC6487]. 383 3. Extract the list of attributes that were signed using the signer 384 from the "a" field of the "signature" attribute. 386 4. Verify that the list of signed attributes includes the minimum 387 set of attributes for that object type. 389 5. Arrange the selected attributes according to the selection 390 sequence provided in the value of the "a" field, omitting all 391 non-signed attributes. 393 6. Replace the value of the signature field "b" of the "signature" 394 attribute with an empty string. 396 7. Apply the canonicalization procedure to the selected attributes 397 (including the "signature" attribute). 399 8. Check the validity of the signature using the signature algorithm 400 specified in the "m" field of the signature attribute, the public 401 key contained in the certificate mentioned in the "c" field of 402 the signature, the signature value specified in the "b" field of 403 the signature attribute, and the output of the canonicalization 404 process. 406 4. Signed Object Types, Set of Signed Attributes 408 This section describes a list of object types that MAY signed using 409 this approach. For each object type, the set of attributes that MUST 410 be signed for these object types (the minimum set noted in 411 Section Section 3.3 is enumerated. 413 This list generally excludes attributes that are used to maintain 414 referential integrity in the databases that carry these objects, 415 since these usually make sense only within the context of such a 416 database, whereas the scope of the signatures is only one specific 417 object. Since the attributes in the referred object (such as mnt-by, 418 admin-c, tech-c, ...) can change without any modifications to the 419 signed object, signing such attributes could lead to false sense of 420 security in terms of the contents of the signed data; therefore 421 including such attributes should only be done in order to provide 422 full integrity protection of the object itself. 424 The newly constructed "signature" attribute is always included in the 425 list. The signature under construction MUST NOT include signature 426 attributes that are already present in the object. 428 as-block: 430 * as-block 432 * signature 434 aut-num: 436 * aut-num 438 * as-name 440 * member-of 442 * import 444 * mp-import 446 * export 447 * mp-export 449 * default 451 * mp-default 453 * signature 455 inet[6]num: 457 * inet[6]num 459 * netname 461 * country 463 * status 465 * signature 467 route[6]: 469 * route[6] 471 * origin 473 * holes 475 * member-of 477 * signature 479 It should be noted that the approach defined in this document has a 480 limitation in signing route[6] objects. This document only supports 481 a single signature per object. This means that it is not possible to 482 properly sign route[6] objects where one resource holder possesses 483 the ASN and another resource holder possesses the referenced prefix. 484 A future version of this specification may rsolve this limitation. 486 For each signature, the RFC3779 extension appearing in the 487 certificate used to verify the signature MUST include a resource 488 entry that is equivalent to, or covers ("less specific" than) the 489 following resources mentioned in the object the signature is attached 490 to: 492 o For the as-block object type: the resource in the "as-block" 493 attribute. 495 o For the aut-num object type: the resource in the "aut-num" 496 attribute. 498 o For the inet[6]num object type: the resource in the "inet[6]num" 499 attribute. 501 o For the route[6] object type: the resource in the "route[6]" or 502 "origin" (or both) attributes. 504 5. Keys and Certificates used for Signature and Verification 506 The certificate that is referred to in the signature (in the "c" 507 field): 509 o MUST be an end-entity (ie. non-CA) certificate 511 o MUST conform to the X.509 PKIX Resource Certificate profile 512 [RFC6487] 514 o MUST have an RFC 3779 extension that covers the Internet number 515 resource included in a signed attribute [RFC3779] 517 The certificate generated will omit the Subject Information Access 518 (SIA) extension mandated by RFC 6487 as that extension requires an 519 rsync URI for the accessLocation form and RPSL currently does not 520 support database access via rsync. 522 6. Security Considerations 524 RPSL objects stored in the IRR databases are public, and as such 525 there is no need for confidentiality. Each signed RPSL object can 526 have its integrity and authenticity verified using the supplied 527 digital signature and the referenced certificate. 529 Since the RPSL signature approach leverages X.509 extensions, the 530 security considerations in [RFC3779] apply here as well. 531 Additionally, implementers MUST follow the certificate validation 532 steps described in RFC 6487. 534 The maintainer of an object has the ability to include attributes in 535 the signature that are not included in the resource certificate used 536 to create the signature. Potentially, a maintainer may include 537 attributes that reference resources the maintainer is not authorized 538 to use. 540 It should be noted that this digital signature does not preclude 541 monkey-in-the-middle attacks where the adversary either intercepts 542 RPSL object transfers, deletes the signature attribute, and modifies 543 the contents or intercepts the transfer and drops the objects 544 destined for the requester. 546 7. IANA Considerations 548 [Note to IANA, to be removed prior to publication: there are no IANA 549 considerations stated in this version of the document.] 551 8. Acknowledgements 553 The authors would like to acknowledge the valued contributions from 554 Jos Boumans, Tom Harrison, Steve Kent, Sandra Murphy, Magnus Nystrom, 555 Alvaro Retana, Sean Turner, Geoff Huston, and Stephen Farrell in 556 preparation of this document. 558 9. References 560 9.1. Normative References 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, 564 DOI 10.17487/RFC2119, March 1997, 565 . 567 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 568 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 569 "Routing Policy Specification Language (RPSL)", RFC 2622, 570 DOI 10.17487/RFC2622, June 1999, 571 . 573 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 574 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 575 . 577 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 578 Addresses and AS Identifiers", RFC 3779, 579 DOI 10.17487/RFC3779, June 2004, 580 . 582 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 583 Resource Identifier (URI): Generic Syntax", STD 66, 584 RFC 3986, DOI 10.17487/RFC3986, January 2005, 585 . 587 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 588 "Routing Policy Specification Language next generation 589 (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005, 590 . 592 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 593 (CIDR): The Internet Address Assignment and Aggregation 594 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 595 2006, . 597 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 598 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 599 . 601 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 602 Autonomous System (AS) Numbers", RFC 5396, 603 DOI 10.17487/RFC5396, December 2008, 604 . 606 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 607 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 608 . 610 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 611 Address Text Representation", RFC 5952, 612 DOI 10.17487/RFC5952, August 2010, 613 . 615 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 616 Resource Certificate Repository Structure", RFC 6481, 617 DOI 10.17487/RFC6481, February 2012, 618 . 620 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 621 Use in the Resource Public Key Infrastructure (RPKI)", 622 RFC 6485, DOI 10.17487/RFC6485, February 2012, 623 . 625 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 626 X.509 PKIX Resource Certificates", RFC 6487, 627 DOI 10.17487/RFC6487, February 2012, 628 . 630 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 631 Protocol (HTTP/1.1): Message Syntax and Routing", 632 RFC 7230, DOI 10.17487/RFC7230, June 2014, 633 . 635 9.2. Informative References 637 [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. 638 Murphy, "Routing Policy System Security", RFC 2725, 639 DOI 10.17487/RFC2725, December 1999, 640 . 642 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 643 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 644 RFC 6376, DOI 10.17487/RFC6376, September 2011, 645 . 647 Authors' Addresses 649 Robert Kisteleki 651 Email: robert@ripe.net 652 URI: http://www.ripe.net 654 Brian Haberman 655 Johns Hopkins University Applied Physics Lab 657 Email: brian@innovationslab.net