idnits 2.17.1 draft-huston-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 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 635. 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 129: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 130: '... crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,...' RFC 2119 keyword, line 139: '... syntax version number. It MUST be 3,...' RFC 2119 keyword, line 144: '...stAlgorithms set MUST include only SHA...' RFC 2119 keyword, line 145: '... is 2.16.840.1.101.3.4.2.1. [RFC4055] It MUST NOT contain any other...' (27 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 (April 22, 2008) is 5849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 268 -- Looks like a reference, but probably isn't: '1' on line 255 == Missing Reference: 'TBS' is mentioned on line 401, but not defined == Missing Reference: 'None' is mentioned on line 522, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-09 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) Summary: 5 errors (**), 0 flaws (~~), 4 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 T. Manderson 4 Intended status: Informational G. Michaelson 5 Expires: October 24, 2008 APNIC 6 April 22, 2008 8 A Profile for Bogon Origin Attestations (BOAs) 9 draft-huston-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 October 24, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines a standard profile for Bogon Origin 43 Attestations (BOAs). A BOA is a digitally signed object that 44 provides a means of verifying that an IP address block holder has not 45 authorized any Autonomous System (AS) to originate routes that are 46 equivalent to any of the addresses listed in the BOA, and also 47 provides a means of verifying that BGP speaker is not using an AS as 48 a BGP speaker without appropriate authority to use that AS. The 49 proposed application of BOAs is intended to fit within the 50 requirements for adding security measures to inter-domain routing, 51 including the ability to support incremental and piecemeal deployment 52 of such measures, and does not require any changes to the 53 specification of BGP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Basic Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 4 60 2.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 4 62 2.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 4 63 2.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 6 64 2.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.1.6. signerInfo . . . . . . . . . . . . . . . . . . . . . . 6 66 3. BOA Validation . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4. BOA Use Practices . . . . . . . . . . . . . . . . . . . . . . 11 68 5. BOA Interpretation . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . . . 15 76 1. Introduction 78 This document defines an application of the Resource Public Key 79 Infrastructure (RPKI) to validate the attestations of Internet 80 Registries that certain addresses are currently neither allocated nor 81 assigned to any party, and any appearance of such addresses or ASes 82 in a routing advertisement in the Border Gateway Protocol (BGP) 83 [RFC4271] should be considered an invalid use of such addresses or 84 ASes. 86 The RPKI is based on Resource Certificates. Resource Certificates 87 are X.509 certificates that conform to the PKIX profile [RFC3280], 88 and to the extensions for IP addresses and AS identifiers [RFC3779]. 89 A Resource Certificate describes an action by an Issuer that binds a 90 list of IP address blocks and Autonomous System (AS) numbers to the 91 Subject of a certificate, identified by the unique association of the 92 Subject's private key with the public key contained in the Resource 93 Certificate. The PKI is structured such that each current Resource 94 Certificate matches a current resource allocation or assignment. 95 This is described in [ID.ietf-sidr-arch]. 97 BOAs can be regarded as a logical opposite of a Route Origin 98 Authorization (ROA) [ID.ietf-sidr-roa-format], and allows a resource 99 holder to explicitly list those IP addresses and ASes that are 100 denoted by the holder as not validly appearing in any routing 101 advertisement, and to make this attestation in a manner that a 102 relying party can validate under the framework of the RPKI. 104 A BOA is a digitally signed object that makes use of Cryptographic 105 Message Syntax (CMS) [RFC3852] as a standard encapsulation format. 106 CMS was chosen to take advantage of existing open source software 107 available for processing messages in this format. 109 2. Basic Format 111 Using CMS syntax, a BOA is a type of signed-data object. The general 112 format of a CMS object is: 114 ContentInfo ::= SEQUENCE { 115 contentType ContentType, 116 content [0] EXPLICIT ANY DEFINED BY contentType } 118 ContentType ::= OBJECT IDENTIFIER 120 2.1. Signed-Data Content Type 122 According to the CMS specification, The signed-data content type 123 shall have ASN.1 type SignedData: 125 SignedData ::= SEQUENCE { 126 version CMSVersion, 127 digestAlgorithms DigestAlgorithmIdentifiers, 128 encapContentInfo EncapsulatedContentInfo, 129 certificates [0] IMPLICIT CertificateSet OPTIONAL, 130 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 131 signerInfos SignerInfos } 133 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 135 SignerInfos ::= SET OF SignerInfo 137 2.1.1. version 139 The version is the syntax version number. It MUST be 3, 140 corresponding to the signerInfo structure having version number 3. 142 2.1.2. digestAlgorithms 144 The digestAlgorithms set MUST include only SHA-256, the OID for which 145 is 2.16.840.1.101.3.4.2.1. [RFC4055] It MUST NOT contain any other 146 algorithms. 148 2.1.3. encapContentInfo 150 encapContentInfo is the signed content, consisting of a content type 151 identifier and the content itself. 153 EncapsulatedContentInfo ::= SEQUENCE { 154 eContentType ContentType, 155 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 157 ContentType ::= OBJECT IDENTIFIER 159 2.1.3.1. eContentType 161 The ContentType for a BOA is defined as id-ct-rpkiBOA, and has the 162 numerical value of 1.2.840.113549.1.9.16.1.[TBS]. [This value has to 163 be assigned via an OID registration.] 164 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 165 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 167 id-ct OBJECT INDENTIFIER ::= { id-smime 1 } 169 id-ct-rpkiBOA OBJECT IDENTIFIER ::= { id-ct [TBS] } 171 2.1.3.2. eContent 173 The content of a BOA identifies a list of one or more ASes and a list 174 of one or more IP address prefixes that are asserted to be "bogons" 175 and, accordingly, BOAs are intended to act as a constraint on the 176 routing system to signal that no route object that that relates to 177 these ASes or IP addresses should be interpreted as representing a 178 valid routing attestation. A BOA is formally defined as: 180 id-ct-rpkiBOA ::= { 181 version [0] INTEGER DEFAULT 0, 182 asIDs SEQUENCE OF asIdsOrRange, 183 ipAddrBlocks SEQUENCE OF BOAIPAddressFamily } 185 ASIdOrRange ::= CHOICE { 186 id ASId, 187 range ASRange } 189 ASRange ::= SEQUENCE { 190 min ASId, 191 max ASId } 193 ASId ::= INTEGER 195 BOAIPAddressFamily ::= SEQUENCE { 196 addressFamily OCTET STRING (SIZE (2..3)), 197 addresses SEQUENCE OF IPAddress } 199 IPAddress ::= BIT STRING 201 2.1.3.2.1. version 203 The version number of the BogonOriginAttestation MUST be 0. 205 2.1.3.2.2. asIDs 207 The asIDs field contains the AS numbers that are to be regarded as 208 Bogon ASes. The set of AS numbers may be explicitly listed, or 209 specified as a continuous range of values. (See [RFC3779] for more 210 details.) 212 2.1.3.2.3. BOAIPAddressFamily 214 The BOAIPAddressFamily field encodes the set of IP address prefixes 215 that are to be regarded as Bogon IP addresses that are to be 216 constrained from appearing in any routing advertisement. The 217 intended semantics is that any route object that has the same address 218 prefix as that listed as a Bogon IP address, or is a more specific 219 prefix of a Bogon IP address can be regarded as a Bogon route object. 221 Note that the syntax here is more restrictive than that used in the 222 IP Address Delegation extension defined in RFC 3779. That extension 223 can represent arbitrary address ranges, whereas BOAs contain only 224 prefixes. 226 Within the BOAIPAddressFamily structure, addressFamily contains the 227 Address Family Identifier (AFI) of an IP address family. This 228 specification only supports IPv4 and IPv6. Therefore, addressFamily 229 MUST be either 0001 or 0002. The addresses field represents prefixes 230 as a sequence of type IPAddress. (See [RFC3779] for more details.) 232 2.1.4. certificates 234 The certificates field MAY be included. If so, it MUST contain only 235 the end entity (EE) certificate needed to validate this BOA. In the 236 use context of BOAs being made available to relying parties via 237 publication in a repository system, there is no a priori requirement 238 to include the EE certificate in the BOA. 240 2.1.5. crls 242 The crls field MUST be omitted. 244 2.1.6. signerInfo 246 SignerInfo is defined under CMS as: 248 SignerInfo ::= SEQUENCE { 249 version CMSVersion, 250 sid SignerIdentifier, 251 digestAlgorithm DigestAlgorithmIdentifier, 252 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 253 signatureAlgorithm SignatureAlgorithmIdentifier, 254 signature SignatureValue, 255 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 257 2.1.6.1. version 259 The version number MUST be 3, corresponding with the choice of 260 SubjectKeyIdentifier for the sid. 262 2.1.6.2. sid 264 The sid is defined as: 266 SignerIdentifier ::= CHOICE { 267 issuerAndSerialNumber IssuerAndSerialNumber, 268 subjectKeyIdentifier [0] SubjectKeyIdentifier } 270 For a BOA, the sid MUST be a SubjectKeyIdentifier. 272 2.1.6.3. digestAlgorithm 274 The digestAlgorithm MUST be SHA-256, the OID for which is 275 2.16.840.1.101.3.4.2.1. [RFC4055] 277 2.1.6.4. signedAttrs 279 Signed Attributes are defined as: 281 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 283 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 284 Attribute ::= SEQUENCE { 285 attrType OBJECT IDENTIFIER, 286 attrValues SET OF AttributeValue } 287 AttributeValue ::= ANY 289 The signer MUST digitally sign a collection of attributes along with 290 the content payload. Each attribute in the collection MUST be DER- 291 encoded. The syntax for attributes is defined in [X.501], and the 292 X.500 Directory provides a rich attribute syntax. A very simple 293 subset of this syntax is used extensively in [RFC3852], where 294 ATTRIBUTE.Type and ATTRIBUTE.id are the only parts of the ATTRIBUTE 295 class that are employed. 297 Each of the attributes used with this CMS profile has a single 298 attribute value. Even though the syntax is defined as a SET OF 299 AttributeValue, there MUST be exactly one instance of AttributeValue 300 present. 302 The SignedAttributes syntax within signerInfo is defined as a SET OF 303 Attribute. The SignedAttributes MUST include only one instance of 304 any particular attribute. 306 The signer MUST include the content-type and message-digest 307 attributes. The signer MAY also include the signing-time signed 308 attribute, the binary-signing-time signed attribute, or both signed 309 attributes. Other signed attributes that are deemed appropriate MAY 310 also be included. The intent is to allow additional signed 311 attributes to be included if a future need is identified. This does 312 not cause an interoperability concern because unrecognized signed 313 attributes are ignored at verification. 315 2.1.6.4.1. Content-Type Attribute 317 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 318 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 320 ContentType ::= OBJECT IDENTIFIER 322 A content-type attribute is required to contain the same object 323 identifier as the content type contained in the 324 EncapsulatedContentInfo. The signer MUST include a content-type 325 attribute containing the appropriate content type. Section 11.1 of 326 the CMS Specification [RFC3852] defines the content-type attribute. 328 2.1.6.4.2. Message-Digest Attribute 330 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 331 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 332 MessageDigest ::= OCTET STRING 334 The signer MUST include a message-digest attribute, having as its 335 value the output of a one-way hash function computed on the content 336 that is being signed. Section 11.2 of the CMS Specification 337 [RFC3852] defines the message-digest attribute. 339 2.1.6.4.3. Signing-Time Attribute 341 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 342 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 343 SigningTime ::= Time 344 Time ::= CHOICE { 345 utcTime UTCTime, 346 generalizedTime GeneralizedTime } 348 The signing-time attribute MAY be present in a BOA. 350 The signing-time attribute specifies the time, based on the local 351 system clock, at which the digital signature was applied to the 352 content. If both signing-time and binary-signing-time are present, 353 the time that is represented in both attributes MUST represent the 354 same time value. Section 11.3 of the CMS Specification [RFC3852] 355 defines the content-type attribute. 357 2.1.6.4.4. Binary-Signing-Time Attribute 359 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 360 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 361 smime(16) aa(2) 46 } 363 BinarySigningTime ::= BinaryTime 365 BinaryTime ::= INTEGER (0..MAX) 367 The signer MAY include a binary-signing-time attribute, specifying 368 the time at which the digital signature was applied to the content. 369 If both signing-time and binary-signing-time are present, the time 370 that is represented in both attributes MUST represent the same time 371 value. The binary-signing-time attribute is defined in [RFC4049]. 373 2.1.6.5. signatureAlgorithm 375 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 376 is 1.2.840.113549.1.1.1. 378 2.1.6.6. signature 380 The signature value is defined as: 382 SignatureValue ::= OCTET STRING 384 The signature characteristics are defined by the digest and signature 385 algorithms. 387 2.1.6.7. unsignedAttrs 389 unsignedAttrs MUST be omitted. 391 3. BOA Validation 393 Before a relying party can use a BOA as a constrictor of a routing 394 announcement, the relying party must use the RPKI to validate the 395 BOA. To do this the relying party performs the following steps: 397 1. Verify that the BOA syntax complies with this specification. In 398 particular, verify the following: 400 A. The eContentType of the CMS object is id-ct-rpkiBOA (OID 401 1.2.840.113549.1.9.16.1.[TBS]) 403 B. The version of the SignedData object is 3. 405 C. The digestAlgorithm in the SignedData object is SHA-256 (OID 406 2.16.840.1.101.3.4.2.1). 408 D. The crls field in the SignedData object is omitted. 410 E. The version of the BOA is 0. 412 F. The addressFamily in the BOAIPAddressFamily is either IPv4 or 413 IPv6 (0001 and 0002, respectively). 415 G. The version of the SignerInfo is 3. 417 H. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 418 2.16.840.1.101.3.4.2.1). 420 I. The signatureAlgorithm in the SignerInfo object is RSA (OID 421 1.2.840.113549.1.1.1). 423 J. The signedAttrs field in the SignerInfo object is included. 425 K. The unsignedAttrs field in the SignerInfo object is omitted. 427 2. Obtain an EE certificate that has a Subject Key Identifier (SKI) 428 that matches the sid field of the SignerInfo object. This 429 certificate may be obtained from the certificates field of the 430 SignedData object (if present), the RPKI repository system, or a 431 local cache. 433 3. Use the public key in the EE certificate to verify the signature 434 on the BOA. 436 4. Verify that the EE certificate has an IP Address Delegation 437 extension [RFC3779] and that the IP address prefix(es) in that 438 extension exactly matches the IP address prefix(es) in the BOA, 439 and the AS numbers in that extension exactly match the AS numbers 440 in the BOA. 442 5. Verify that the EE certificate is a valid end-entity certificate 443 in the resource PKI by constructing a valid certificate path to a 444 trust anchor. (See [ID.ietf-sidr-res-certs] for more details.) 446 Note that requiring an exact match between the IP address prefixes 447 and ASes in a BOA and the IP address prefixes and ASes in the 448 corresponding EE certificate does not place any limitations on BOA 449 use. Since each EE certificate in the RPKI architecture is used to 450 verify only a single BOA, it is natural to have the IP address 451 prefixes in the certificate match those in the corresponding BOA. 453 4. BOA Use Practices 455 BOAs are intended to allow relying parties a means of validating 456 whether route origination information as described in a route 457 advertisement refers to an IP address or AS number that has not been 458 validly allocated for use in the routing system. 460 Any party with a validly assigned Internet resource set and a CA 461 certificate that described this delegation can publish a BOA, 462 independently of the actions of the actions of the party that 463 assigned the resource set. BOAs are not hierarchically related. 465 An Internet Registry SHOULD maintain a single BOA in relation to each 466 parent registry that has assigned resources to this registry. 468 An Internet Registry SHOULD maintain a regular issuance cycle for 469 BOAs. 471 For registries that operate on a day-to-day basis in terms of 472 resource transactions, it is suggested that a local BOA management 473 practice would be that a new BOA should be issued on a regular 24 474 hour basis. The corresponding EE certificate should have a validity 475 period of no more than 72 hours from the time of issuance. Each time 476 a new EE certificate for a BOA is issued the previous BOA's EE 477 certificate should be revoked and the previous BOA removed from the 478 publication repository. 480 Parties that operate a local cache of RPKI objects should ensure that 481 they refresh BOA objects at intervals 24 hours to ensure that they 482 have the current BOA in the local cache. 484 5. BOA Interpretation 486 A BOA can be used to check a route object to determine if the 487 origination information in the route object refers to invalid IP 488 addresses or an invalid AS number. 490 If a route object has an AS origination that refers to an AS number 491 that is included in a valid BOA then the route object can be regarded 492 as a Bogon object, and local policies that apply to Bogon ASes can be 493 applied to the object. This holds whether or not the address prefix 494 of the route object is described by a valid ROA or not. 496 If a route object has an address prefix that is equal to, or is a 497 more specific prefix of an IP address that is included in a valid BOA 498 then the route object can be regarded as a Bogon object, and local 499 policies that apply to Bogon ASes can be applied to the object, 500 unless the address prefix and AS origination of the route object is 501 also described by a valid ROA, in which case the BOA is to be 502 disregarded. 504 6. Security Considerations 506 The purpose of a BOA is to convey an attestation by an address holder 507 that there is no authority for the generation of a route object that 508 refers to specified addresses or origination from specified ASes. 509 The integrity of a BOA must be established in order to validate the 510 authority of the Bogon Attestation. The BOA makes use of the CMS 511 signed message format for integrity, and thus inherits the security 512 considerations associated with that data structure. The right of the 513 BOA signer to authorize the attestation of specified IP addresses and 514 ASes as Bogons is established through use of the address space and AS 515 number PKI described in [ID.ietf-sidr-arch]. Specifically, a relying 516 party must verify the signature on the BOA using an X.509 certificate 517 issued under this PKI, and check that the prefix(es) in the BOA match 518 those in the address space extension in the certificate. 520 7. IANA Considerations 522 [None] 524 8. Acknowledgments 526 The authors are indebted to the authors of Route Origin Authorization 527 (ROA) [ID.ietf-sidr-roa-format], M. Lepinski, S. Kent and D. Kong, as 528 much of the text used to define a BOA has been borrowed from the ROA 529 format specification, and Russ Housley for clarification on the CMS 530 profile. 532 9. Normative References 534 [ID.ietf-sidr-arch] 535 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 536 to Support Secure Internet Routing", draft-ietf-sidr-arch 537 (work in progress), November 2007. 539 [ID.ietf-sidr-res-certs] 540 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 541 X.509 PKIX Resource Certificates", Work in progress: 542 Internet Drafts draft-ietf-sidr-res-certs-09.txt, 543 November 2007. 545 [ID.ietf-sidr-roa-format] 546 Lepinski, M., Kent, S., and D. Kong, "An Infrastructure to 547 Support Secure Internet Routing", 548 draft-ietf-sidr-roa-format (work in progress), July 2007. 550 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 551 X.509 Public Key Infrastructure Certificate and 552 Certificate Revocation List (CRL) Profile", RFC 3280, 553 April 2002. 555 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 556 Addresses and AS Identifiers", RFC 3779, June 2004. 558 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 559 RFC 3852, July 2004. 561 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 562 Representing Date and Time in ASN.1", RFC 4049, 563 April 2005. 565 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 566 Algorithms and Identifiers for RSA Cryptography for use in 567 the Internet X.509 Public Key Infrastructure Certificate 568 and Certificate Revocation List (CRL) Profile", RFC 4055, 569 June 2005. 571 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 572 Protocol 4 (BGP-4)", RFC 4271, January 2006. 574 [X.501] ITU-T, "ITU-T Recommendation X.501: Information Technology 575 - Open Systems interconnection - The Director Models", 576 1993. 578 Authors' Addresses 580 Geoff Huston 581 Asia Pacific Network Information Centre 583 Email: gih@apnic.net 584 URI: http://www.apnic.net 585 Terry Manderson 586 Asia Pacific Network Information Centre 588 Email: terry@apnic.net 589 URI: http://www.apnic.net 591 George Michaelson 592 Asia Pacific Network Information Centre 594 Email: ggm@apnic.net 595 URI: http://www.apnic.net 597 Full Copyright Statement 599 Copyright (C) The IETF Trust (2008). 601 This document is subject to the rights, licenses and restrictions 602 contained in BCP 78, and except as set forth therein, the authors 603 retain all their rights. 605 This document and the information contained herein are provided on an 606 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 607 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 608 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 609 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 610 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 611 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 613 Intellectual Property 615 The IETF takes no position regarding the validity or scope of any 616 Intellectual Property Rights or other rights that might be claimed to 617 pertain to the implementation or use of the technology described in 618 this document or the extent to which any license under such rights 619 might or might not be available; nor does it represent that it has 620 made any independent effort to identify any such rights. Information 621 on the procedures with respect to rights in RFC documents can be 622 found in BCP 78 and BCP 79. 624 Copies of IPR disclosures made to the IETF Secretariat and any 625 assurances of licenses to be made available, or the result of an 626 attempt made to obtain a general license or permission for the use of 627 such proprietary rights by implementers or users of this 628 specification can be obtained from the IETF on-line IPR repository at 629 http://www.ietf.org/ipr. 631 The IETF invites any interested party to bring to its attention any 632 copyrights, patents or patent applications, or other proprietary 633 rights that may cover technology that may be required to implement 634 this standard. Please address the information to the IETF at 635 ietf-ipr@ietf.org. 637 Acknowledgment 639 Funding for the RFC Editor function is provided by the IETF 640 Administrative Support Activity (IASA).