idnits 2.17.1 draft-ietf-sidr-bogons-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 630. 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 : ---------------------------------------------------------------------------- ** 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 125: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 126: '... crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,...' RFC 2119 keyword, line 135: '... syntax version number. It MUST be 3,...' RFC 2119 keyword, line 140: '...stAlgorithms set MUST include only SHA...' RFC 2119 keyword, line 141: '... is 2.16.840.1.101.3.4.2.1. [RFC4055]. It MUST NOT contain any other...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 5, 2008) is 5682 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: '0' on line 263 -- Looks like a reference, but probably isn't: '1' on line 250 == Missing Reference: 'TBD' is mentioned on line 404, but not defined == Missing Reference: 'None' is mentioned on line 527, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'ID.ietf-sidr-arch') ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Standards Track APNIC 5 Expires: April 8, 2009 T. Manderson 6 October 5, 2008 8 A Profile for Bogon Origin Attestations (BOAs) 9 draft-ietf-sidr-bogons-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 8, 2009. 36 Abstract 38 This document defines a standard profile for Bogon Origin 39 Attestations (BOAs). A BOA is a digitally signed object that 40 provides a means of verifying that an IP address block holder has not 41 authorized any Autonomous System (AS) to originate routes that are 42 equivalent to any of the addresses listed in the BOA. A BOA also 43 provides a means of verifying that BGP speaker is not using an AS 44 without appropriate authority to use that AS. The proposed 45 application of BOAs is intended to fit within the requirements for 46 adding security measures to inter-domain routing, including the 47 ability to support incremental and piecemeal deployment of such 48 measures, and does not require any changes to the specification of 49 the Border Gateway Protocol. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Basic Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 4 56 2.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 4 58 2.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 4 59 2.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 6 60 2.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1.6. signerInfo . . . . . . . . . . . . . . . . . . . . . . 6 62 3. BOA Validation . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4. BOA Use Practices . . . . . . . . . . . . . . . . . . . . . . 11 64 5. BOA Interpretation . . . . . . . . . . . . . . . . . . . . . . 12 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Introduction 74 This document defines an application of the Resource Public Key 75 Infrastructure (RPKI) to validate the attestations of Internet 76 Registries that certain addresses are currently neither allocated nor 77 assigned to any party, and any appearance of such addresses or AS's 78 in a routing advertisement in the Border Gateway Protocol (BGP) 79 [RFC4271] should be considered an invalid use of such addresses or 80 AS's. 82 The RPKI is based on Resource Certificates. Resource Certificates 83 are X.509 certificates that conform to the PKIX profile [RFC5280], 84 and to the extensions for IP addresses and AS identifiers [RFC3779]. 85 A Resource Certificate describes an action by an Issuer that binds a 86 list of IP address blocks and Autonomous System (AS) numbers to the 87 Subject of a certificate, identified by the unique association of the 88 Subject's private key with the public key contained in the Resource 89 Certificate. The RPKI is structured such that each current Resource 90 Certificate matches a current resource allocation or assignment. 91 This is described in [ID.ietf-sidr-arch]. 93 BOAs can be regarded as a logical opposite of a Route Origin 94 Authorization (ROA) [ID.ietf-sidr-roa-format], and allows a resource 95 holder to explicitly list those IP addresses and AS's that are 96 denoted by the holder as not validly appearing in any routing 97 advertisement, and to make this attestation in a manner that a 98 relying party can validate under the framework of the RPKI. 100 A BOA is a digitally signed object that makes use of Cryptographic 101 Message Syntax (CMS) [RFC3852] as a standard encapsulation format. 102 CMS was chosen to take advantage of existing open source software 103 available for processing messages in this format. 105 2. Basic Format 107 Using CMS syntax, a BOA is a type of signed-data object. The general 108 format of a CMS object is: 110 ContentInfo ::= SEQUENCE { 111 contentType ContentType, 112 content [0] EXPLICIT ANY DEFINED BY contentType } 114 ContentType ::= OBJECT IDENTIFIER 116 2.1. Signed-Data Content Type 118 According to the CMS specification, The signed-data content type 119 shall have ASN.1 type SignedData: 121 SignedData ::= SEQUENCE { 122 version CMSVersion, 123 digestAlgorithms DigestAlgorithmIdentifiers, 124 encapContentInfo EncapsulatedContentInfo, 125 certificates [0] IMPLICIT CertificateSet OPTIONAL, 126 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 127 signerInfos SignerInfos } 129 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 131 SignerInfos ::= SET OF SignerInfo 133 2.1.1. version 135 The version is the syntax version number. It MUST be 3, 136 corresponding to the signerInfo structure having version number 3. 138 2.1.2. digestAlgorithms 140 The digestAlgorithms set MUST include only SHA-256, the OID for which 141 is 2.16.840.1.101.3.4.2.1. [RFC4055]. It MUST NOT contain any other 142 algorithms. 144 2.1.3. encapContentInfo 146 encapContentInfo is the signed content, consisting of a content type 147 identifier and the content itself. 149 EncapsulatedContentInfo ::= SEQUENCE { 150 eContentType ContentType, 151 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 153 ContentType ::= OBJECT IDENTIFIER 155 2.1.3.1. eContentType 157 The ContentType for a BOA is defined as id-ct-rpkiBOA, and has the 158 numerical value of 1.2.840.113549.1.9.16.1.[TBD]. [This value needs 159 to be assigned via an OID registration.] 160 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 161 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 163 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 165 id-ct-rpkiBOA OBJECT IDENTIFIER ::= { id-ct [TBD] } 167 2.1.3.2. eContent 169 The content of a BOA identifies a list of one or more AS's and one or 170 more IP address prefixes that are asserted to be "bogons" and, 171 accordingly, BOAs are intended to act as a constraint on the routing 172 system to signal that no route object that that relates to these AS's 173 or IP addresses should be interpreted as representing a valid routing 174 attestation. A BOA is formally defined as: 176 id-ct-rpkiBOA ::= { 177 version [0] INTEGER DEFAULT 0, 178 asIDs SEQUENCE OF asIdsOrRange, 179 ipAddrBlocks SEQUENCE OF BOAIPAddressFamily } 181 ASIdOrRange ::= CHOICE { 182 id ASId, 183 range ASRange } 185 ASRange ::= SEQUENCE { 186 min ASId, 187 max ASId } 189 ASId ::= INTEGER 191 BOAIPAddressFamily ::= SEQUENCE { 192 addressFamily OCTET STRING (SIZE (2..3)), 193 addresses SEQUENCE OF IPAddress } 195 IPAddress ::= BIT STRING 197 2.1.3.2.1. version 199 The version number of the BogonOriginAttestation MUST be 0. 201 2.1.3.2.2. asIDs 203 The asIDs field contains the AS numbers that are to be regarded as 204 Bogon AS's. The set of AS numbers may be explicitly listed, or 205 specified as a continuous range of values. The field is to be 206 formatted as per the canonical format specified in [RFC3779]. 208 2.1.3.2.3. BOAIPAddressFamily 210 The BOAIPAddressFamily field encodes the set of IP address prefixes 211 that are to be regarded as Bogon IP addresses that are to be 212 constrained from appearing in any routing advertisement. The 213 intended semantics of an address prefix in a BOA is that any route 214 object that has the same address prefix as that listed as a Bogon IP 215 address, or is a more specific prefix of a Bogon IP address can be 216 regarded as a Bogon route object. 218 The syntax of the addres prefixes listed in a BOA uses a subset of 219 the IP Address Delegation extension defined in [RFC3779]. The 220 BOAIPAddressFamily cannot contain arbitrary address ranges, but in 221 all other respects uses the same canonical format as the IP Address 222 Delegation Extension. 224 Within the BOAIPAddressFamily structure, addressFamily contains the 225 Address Family Identifier (AFI) of an IP address family. This 226 specification only supports IPv4 and IPv6. Therefore, addressFamily 227 MUST be either 0001 or 0002. The addresses field represents prefixes 228 as a sequence of type IPAddress, as defined in[RFC3779]. 230 2.1.4. certificates 232 The certificates field MUST be included, and MUST contain only the 233 end entity (EE) certificate needed to validate this BOA. 235 2.1.5. crls 237 The crls field MUST be omitted. 239 2.1.6. signerInfo 241 SignerInfo is defined under CMS as: 243 SignerInfo ::= SEQUENCE { 244 version CMSVersion, 245 sid SignerIdentifier, 246 digestAlgorithm DigestAlgorithmIdentifier, 247 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 248 signatureAlgorithm SignatureAlgorithmIdentifier, 249 signature SignatureValue, 250 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 252 2.1.6.1. version 254 The version number MUST be 3, corresponding with the choice of 255 SubjectKeyIdentifier for the sid. 257 2.1.6.2. sid 259 The sid is defined as: 261 SignerIdentifier ::= CHOICE { 262 issuerAndSerialNumber IssuerAndSerialNumber, 263 subjectKeyIdentifier [0] SubjectKeyIdentifier } 265 For a BOA, the sid MUST be a SubjectKeyIdentifier. 267 2.1.6.3. digestAlgorithm 269 The digestAlgorithm MUST be SHA-256, the OID for which is 270 2.16.840.1.101.3.4.2.1. [RFC4055] 272 2.1.6.4. signedAttrs 274 Signed Attributes are defined as: 276 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 278 Attribute ::= SEQUENCE { 279 attrType OBJECT IDENTIFIER, 280 attrValues SET OF AttributeValue } 282 AttributeValue ::= ANY 284 The signedAttr element MUST be present and MUST include the content- 285 type and message-digest attributes. The signer MAY also include the 286 signing-time signed attribute, the binary-signing-time signed 287 attribute, or both signed attributes. Other signed attributes that 288 are deemed appropriate MAY also be included. The intent is to allow 289 additional signed attributes to be included if a future need is 290 identified. This does not cause an interoperability concern because 291 unrecognized signed attributes are ignored by the relying party. 293 The signedAttr MUST include only a single instance of any particular 294 attribute. Additionally, even though the syntax allows for a SET OF 295 AttributeValue, in a BOA the attrValues must consist of only a single 296 AttributeValue. 298 2.1.6.4.1. Content-Type Attribute 300 The ContentType attribute MUST be present. The attrType OID for the 301 ContentType attribute is 1.2.840.113549.1.9.3. 303 The attrValues for the ContentType attribute in a ROA MUST be 304 1.2.840.113549.1.9.16.1.[TBD] (matching the eContentType in the 305 EncapsulatedContentInfo). 307 2.1.6.4.2. Message-Digest Attribute 309 The MessageDigest Attribute MUST be present. The attrType OID for 310 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 312 The attrValues for the MessageDigest attribute contains the output of 313 the digest algorithm applied to the content being signed, as 314 specified in Section 11.1 of[RFC3852]. 316 2.1.6.4.3. Signing-Time Attribute 318 The SigningTime Attribute MAY be present in a BOA. If it is present 319 it MUST be ignored by the relying party. The presence of absence of 320 the SigningTime attribute in no way affects the validation of the BOA 321 (as specified in Section 3). The attrType OID for the SigningTime 322 attribute is 1.2.840.113549.1.9.5. 324 The SigningTime attribute is defined as: 326 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 327 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 329 SigningTime ::= Time 331 Time ::= CHOICE { 332 utcTime UTCTime, 333 generalizedTime GeneralizedTime } 335 The Time element specifies the time, based on the local system clock, 336 at which the digital signature was applied to the content. 338 2.1.6.4.4. BinarySigningTime Attribute 340 The BinarySigningTime Attribute MAY be present. If it is present it 341 MUST be ignored by the relying party. The presence of absence of the 342 BinarySigningTime attribute in no way affects the validation of the 343 ROA (as specified in Section 3). The attrType OID for the 344 BinarySigningTime attribute is 1.2.840.113549.1.9.16.2.46. 346 The BinarySigningTime attribute is defined as: 348 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 349 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 350 smime(16) aa(2) 46 } 352 BinarySigningTime ::= BinaryTime 354 BinaryTime ::= INTEGER (0..MAX) 356 The BinaryTime element specifies the time, based on the local system 357 clock, at which the digital signature was applied to the content. 359 2.1.6.5. signatureAlgorithm 361 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 362 is 1.2.840.113549.1.1.1. 364 2.1.6.6. signature 366 The signature value is defined as: 368 SignatureValue ::= OCTET STRING 370 The signature characteristics are defined by the digest and signature 371 algorithms. 373 2.1.6.7. unsignedAttrs 375 unsignedAttrs MUST be omitted. 377 3. BOA Validation 379 Before a relying party can use a BOA as a constrictor of a routing 380 announcement, the relying party must use the RPKI to validate the 381 BOA. To do this the relying party performs the following steps: 383 1. Verify that the BOA syntax complies with this specification. In 384 particular, verify the following: 386 a. The contentType of the CMS object is SignedData (OID 387 1.2.840.113549.1.7.2) 389 b. The eContentType of the CMS object is id-ct-rpkiBOA (OID 390 1.2.840.113549.1.9.16.1.[TBD]) 392 c. The version of the SignedData object is 3. 394 d. The digestAlgorithm in the SignedData object is SHA-256 (OID 395 2.16.840.1.101.3.4.2.1). 397 e. The certificates field in the SignedData object is present 398 and contains an EE certificate whose Subject Key Identifier 399 (SKI) matches the sid field of the SignerInfo object. 401 f. The crls field in the SignedData object is omitted. 403 g. The eContentType in the EncapsulatedContentInfo is rid-ct- 404 rpkiBOA (OID 1.2.840.113549.1.9.16.1.[TBD]) 406 h. The version of the BOA is 0. 408 i. The addressFamily in the BOAIPAddressFamily is either IPv4 or 409 IPv6 (0001 and 0002, respectively). 411 j. The version of the SignerInfo is 3. 413 k. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 414 2.16.840.1.101.3.4.2.1). 416 l. The signatureAlgorithm in the SignerInfo object is RSA (OID 417 1.2.840.113549.1.1.1). 419 m. The signedAttrs field in the SignerInfo object is present and 420 contains both the ContentType attribute (OID 421 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 422 1.2.840.113549.1.9.4). . 424 n. The unsignedAttrs field in the SignerInfo object is omitted. 426 2. Use the public key in the EE certificate to verify the signature 427 on the BOA. 429 3. Verify that the EE certificate has an IP Address Delegation 430 extension [RFC3779] and that the IP address prefixes in that 431 extension exactly match the IP address prefixes in the BOA, and 432 the AS numbers in that extension exactly match the AS numbers in 433 the BOA. 435 4. Verify that the EE certificate is a valid end-entity certificate 436 in the resource PKI by constructing a valid certificate path to a 437 trust anchor. (See [ID.ietf-sidr-res-certs] for more details.) 439 Note that requiring an exact match between the IP address prefixes 440 and AS's in a BOA and the IP address prefixes and AS's in the 441 corresponding EE certificate does not place any limitations on BOA 442 use. Since each EE certificate in the RPKI architecture is used to 443 verify only a single BOA, it is natural to have the IP address 444 prefixes in the certificate match those in the corresponding BOA. 446 4. BOA Use Practices 448 BOAs are intended to allow relying parties a means of validating 449 whether route origination information as described in a route 450 advertisement refers to an IP address or AS number that has not been 451 validly allocated for use in the routing system. 453 Any party with a validly assigned Internet resource set and a CA 454 certificate that describes this delegation can publish a BOA, 455 independently of the actions of the actions of the party that 456 assigned the resource set. 458 BOAs are not hierarchically related. 460 An Internet Registry SHOULD maintain a single BOA in relation to each 461 parent registry that has assigned resources to this registry. 463 An Internet Registry SHOULD maintain a regular issuance cycle for 464 BOAs. 466 For registries that operate on a day-to-day basis in terms of 467 resource transactions, it is suggested that a local BOA management 468 practice would be that a new BOA should be issued on a regular 24 469 hour basis. The corresponding EE certificate should have a validity 470 period of no more than 72 hours from the time of issuance. Each time 471 a new EE certificate for a BOA is issued the previous BOA's EE 472 certificate should be revoked and the previous BOA removed from the 473 publication repository. 475 Parties that operate a local cache of RPKI objects should ensure that 476 they refresh BOA objects at intervals 24 hours to ensure that they 477 have the current BOA in the local cache. 479 5. BOA Interpretation 481 A BOA can be used to check a route object to determine if the 482 origination information in the route object refers to invalid IP 483 addresses or an invalid AS number. 485 If a route object has an AS origination that refers to an AS number 486 that is included in a valid BOA then the route object can be regarded 487 as a Bogon object, and local policies that apply to Bogon AS's can be 488 applied to the object. This holds whether or not the address prefix 489 of the route object is described by a valid ROA or not. 491 If a route object has an address prefix that is equal to, or is a 492 more specific prefix of an IP address that is included in a valid BOA 493 then the route object can be regarded as a Bogon object, and local 494 policies that apply to Bogon AS's can be applied to the object, 495 unless the address prefix and AS origination of the route object is 496 also described by a valid ROA, in which case the BOA is to be 497 disregarded. In other words a valid ROA SHOULD infer a higher trust 498 preference than a ROA if a valid ROA and BOA exist for the same 499 address prefix and AS number. 501 6. Security Considerations 503 There is no assumption of confidentiality for the data in a BOA; it 504 is anticipated that BOAs will be stored in repositories that are 505 accessible to all ISPs, and perhaps to all Internet users. There is 506 no explicit authentication associated with a BOA, since the RPKI used 507 for BOA validation provides authorization but not authentication. 508 Although the BOA is a signed, application layer object, there is no 509 intent to convey non-repudiation via a BOA. 511 The purpose of a BOA is to convey an attestation by an address holder 512 that there is no authority for the generation of a route object that 513 refers to specified addresses or origination from specified AS's. 514 The integrity of a BOA must be established in order to validate the 515 authority of the Bogon Attestation. The BOA makes use of the CMS 516 signed message format for integrity, and thus inherits the security 517 considerations associated with that data structure. The right of the 518 BOA signer to authorize the attestation of specified IP addresses and 519 AS's as Bogons is established through use of the address space and AS 520 number PKI described in [ID.ietf-sidr-arch]. Specifically, a relying 521 party must verify the signature on the BOA using an X.509 certificate 522 issued under this PKI, and check that the prefix(es) in the BOA match 523 those in the address space extension in the certificate. 525 7. IANA Considerations 527 [None] 529 8. Acknowledgments 531 The authors are indebted to the authors of Route Origin Authorization 532 (ROA) [ID.ietf-sidr-roa-format], M. Lepinski, S. Kent and D. Kong, as 533 much of the text used to define a BOA has been borrowed from the ROA 534 format specification, and Russ Housley for clarification on the CMS 535 profile. 537 9. Normative References 539 [ID.ietf-sidr-arch] 540 Lepinski, M. and S. Kent, "An Infrastructure to Support 541 Secure Internet Routing", draft-ietf-sidr-arch (work in 542 progress), February 2008. 544 [ID.ietf-sidr-res-certs] 545 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 546 X.509 PKIX Resource Certificates", Internet 547 Draft draft-ietf-sidr-res-certs, August 2008. 549 [ID.ietf-sidr-roa-format] 550 Lepinski, M., Kent, S., and D. Kong, "An Infrastructure to 551 Support Secure Internet Routing", 552 draft-ietf-sidr-roa-format (work in progress), July 2008. 554 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 555 Addresses and AS Identifiers", RFC 3779, June 2004. 557 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 558 RFC 3852, July 2004. 560 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 561 Algorithms and Identifiers for RSA Cryptography for use in 562 the Internet X.509 Public Key Infrastructure Certificate 563 and Certificate Revocation List (CRL) Profile", RFC 4055, 564 June 2005. 566 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 567 Protocol 4 (BGP-4)", RFC 4271, January 2006. 569 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 570 Housley, R., and W. Polk, "Internet X.509 Public Key 571 Infrastructure Certificate and Certificate Revocation List 572 (CRL) Profile", RFC 5280, May 2008. 574 Authors' Addresses 576 Geoff Huston 577 Asia Pacific Network Information Centre 579 Email: gih@apnic.net 580 URI: http://www.apnic.net 582 George Michaelson 583 Asia Pacific Network Information Centre 585 Email: ggm@apnic.net 586 URI: http://www.apnic.net 588 Terry Manderson 590 Email: terry@terrym.net 592 Full Copyright Statement 594 Copyright (C) The IETF Trust (2008). 596 This document is subject to the rights, licenses and restrictions 597 contained in BCP 78, and except as set forth therein, the authors 598 retain all their rights. 600 This document and the information contained herein are provided on an 601 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 602 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 603 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 604 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 605 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 606 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 608 Intellectual Property 610 The IETF takes no position regarding the validity or scope of any 611 Intellectual Property Rights or other rights that might be claimed to 612 pertain to the implementation or use of the technology described in 613 this document or the extent to which any license under such rights 614 might or might not be available; nor does it represent that it has 615 made any independent effort to identify any such rights. Information 616 on the procedures with respect to rights in RFC documents can be 617 found in BCP 78 and BCP 79. 619 Copies of IPR disclosures made to the IETF Secretariat and any 620 assurances of licenses to be made available, or the result of an 621 attempt made to obtain a general license or permission for the use of 622 such proprietary rights by implementers or users of this 623 specification can be obtained from the IETF on-line IPR repository at 624 http://www.ietf.org/ipr. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights that may cover technology that may be required to implement 629 this standard. Please address the information to the IETF at 630 ietf-ipr@ietf.org.