idnits 2.17.1 draft-ietf-sidr-bogons-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 132: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 133: '... crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,...' RFC 2119 keyword, line 142: '... syntax version number. It MUST be 3,...' RFC 2119 keyword, line 147: '...stAlgorithms set MUST include only SHA...' RFC 2119 keyword, line 148: '... is 2.16.840.1.101.3.4.2.1. [RFC4055]. It MUST NOT contain any other...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (May 25, 2009) is 5450 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 270 -- Looks like a reference, but probably isn't: '1' on line 257 == Missing Reference: 'TBD' is mentioned on line 411, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-06 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-16 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-04 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-roa-validation-01 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-roa-validation (ref. 'I-D.ietf-sidr-roa-validation') ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing (SIDR) T. Manderson 3 Internet-Draft May 25, 2009 4 Intended status: Standards Track 5 Expires: November 26, 2009 7 A Profile for Bogon Origin Attestations (BOAs) 8 draft-ietf-sidr-bogons-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 26, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document defines a standard profile for Bogon Origin 47 Attestations (BOAs). A BOA is a digitally signed object that 48 provides a means of verifying that an IP address block holder has not 49 authorised any Autonomous System (AS) to originate routes that are 50 equivalent to any of the addresses listed in the BOA. A BOA also 51 provides a means of verifying that a BGP speaker is not using an AS 52 without appropriate authority. The proposed application of BOAs is 53 intended to fit within the requirements for adding security measures 54 to inter-domain routing, including the ability to support incremental 55 and piecemeal deployment of such measures, and does not require any 56 changes to the specification of the Border Gateway Protocol. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Basic Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 4 63 2.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 4 65 2.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 4 66 2.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 6 67 2.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1.6. signerInfo . . . . . . . . . . . . . . . . . . . . . . 6 69 3. BOA Validation . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. BOA Use Practices . . . . . . . . . . . . . . . . . . . . . . 11 71 5. BOA Interpretation . . . . . . . . . . . . . . . . . . . . . . 11 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 75 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 This document defines an application of the Resource Public Key 81 Infrastructure (RPKI) to validate the attestations of resource 82 holders and Internet Registries that certain addresses are currently 83 neither allocated to any party, nor in use by any party, and any 84 appearance of such addresses or AS's in a routing advertisement in 85 the Border Gateway Protocol (BGP) [RFC4271] should be considered an 86 invalid use of such addresses or Autonomous System Numbers. 88 The RPKI is based on Resource Certificates. Resource Certificates 89 are X.509 certificates that conform to the PKIX profile [RFC5280], 90 and to the extensions for IP addresses and AS identifiers [RFC3779]. 91 A Resource Certificate describes an action by an Issuer that binds a 92 list of IP address blocks and Autonomous System (AS) numbers to the 93 Subject of a certificate, identified by the unique association of the 94 Subject's private key with the public key contained in the Resource 95 Certificate. The RPKI is structured such that each current Resource 96 Certificate matches a current resource allocation or assignment. 97 This is described in [I-D.ietf-sidr-arch]. 99 BOAs can be regarded as a logical opposite of a Route Origin 100 Authorization (ROA) [I-D.ietf-sidr-roa-format], however are not 101 contradictory to a ROA and allows a resource holder to explicitly 102 list those IP addresses and AS's that are denoted by the holder as 103 not validly appearing in any routing advertisement, and to make this 104 attestation in a manner that a relying party can unambiguously 105 validate under the framework of the RPKI. 107 A BOA is a digitally signed object that makes use of Cryptographic 108 Message Syntax (CMS) [RFC3852] as a standard encapsulation format. 109 CMS was chosen to take advantage of existing open source software 110 available for processing messages in this format. 112 2. Basic Format 114 Using CMS syntax, a BOA is a type of signed-data object. The general 115 format of a CMS object is: 117 ContentInfo ::= SEQUENCE { 118 contentType ContentType, 119 content [0] EXPLICIT ANY DEFINED BY contentType } 121 ContentType ::= OBJECT IDENTIFIER 123 2.1. Signed-Data Content Type 125 According to the CMS specification, The signed-data content type 126 shall have ASN.1 type SignedData: 128 SignedData ::= SEQUENCE { 129 version CMSVersion, 130 digestAlgorithms DigestAlgorithmIdentifiers, 131 encapContentInfo EncapsulatedContentInfo, 132 certificates [0] IMPLICIT CertificateSet OPTIONAL, 133 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 134 signerInfos SignerInfos } 136 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 138 SignerInfos ::= SET OF SignerInfo 140 2.1.1. version 142 The version is the syntax version number. It MUST be 3, 143 corresponding to the signerInfo structure having version number 3. 145 2.1.2. digestAlgorithms 147 The digestAlgorithms set MUST include only SHA-256, the OID for which 148 is 2.16.840.1.101.3.4.2.1. [RFC4055]. It MUST NOT contain any other 149 algorithms. 151 2.1.3. encapContentInfo 153 encapContentInfo is the signed content, consisting of a content type 154 identifier and the content itself. 156 EncapsulatedContentInfo ::= SEQUENCE { 157 eContentType ContentType, 158 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 160 ContentType ::= OBJECT IDENTIFIER 162 2.1.3.1. eContentType 164 The ContentType for a BOA is defined as id-ct-rpkiBOA, and has the 165 numerical value of 1.2.840.113549.1.9.16.1.[TBD]. [This value needs 166 to be assigned via an OID registration.] 167 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 168 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 170 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 172 id-ct-rpkiBOA OBJECT IDENTIFIER ::= { id-ct [TBD] } 174 2.1.3.2. eContent 176 The content of a BOA identifies a list of one or more AS's and one or 177 more IP address prefixes that are asserted to be "bogons" and, 178 accordingly, BOAs are intended to act as a constraint on the routing 179 system to signal that no route object that that relates to these AS's 180 or IP addresses should be interpreted as representing a valid routing 181 attestation. A BOA is formally defined as: 183 id-ct-rpkiBOA ::= { 184 version [0] INTEGER DEFAULT 0, 185 asIDs SEQUENCE OF asIdsOrRange, 186 ipAddrBlocks SEQUENCE OF BOAIPAddressFamily } 188 ASIdOrRange ::= CHOICE { 189 id ASId, 190 range ASRange } 192 ASRange ::= SEQUENCE { 193 min ASId, 194 max ASId } 196 ASId ::= INTEGER 198 BOAIPAddressFamily ::= SEQUENCE { 199 addressFamily OCTET STRING (SIZE (2..3)), 200 addresses SEQUENCE OF IPAddress } 202 IPAddress ::= BIT STRING 204 2.1.3.2.1. version 206 The version number of the BogonOriginAttestation MUST be 0. 208 2.1.3.2.2. asIDs 210 The asIDs field contains the AS numbers that are to be regarded as 211 Bogon AS's. The set of AS numbers may be explicitly listed, or 212 specified as a continuous range of values. The field is to be 213 formatted as per the canonical format specified in [RFC3779]. 215 2.1.3.2.3. BOAIPAddressFamily 217 The BOAIPAddressFamily field encodes the set of IP address prefixes 218 that are to be regarded as Bogon IP addresses that are to be 219 constrained from appearing in any routing advertisement. The 220 intended semantics of an address prefix in a BOA is that any route 221 object that has the same address prefix as that listed as a Bogon IP 222 address, or is a more specific prefix of a Bogon IP address can be 223 regarded as a Bogon route object. 225 The syntax of the address prefixes listed in a BOA uses a subset of 226 the IP Address Delegation extension defined in [RFC3779]. The 227 BOAIPAddressFamily cannot contain arbitrary address ranges, but in 228 all other respects uses the same canonical format as the IP Address 229 Delegation Extension. 231 Within the BOAIPAddressFamily structure, addressFamily contains the 232 Address Family Identifier (AFI) of an IP address family. This 233 specification only supports IPv4 and IPv6. Therefore, addressFamily 234 MUST be either 0001 or 0002. The addresses field represents prefixes 235 as a sequence of type IPAddress, as defined in[RFC3779]. 237 2.1.4. certificates 239 The certificates field MUST be included, and MUST contain only the 240 end entity (EE) certificate needed to validate this BOA. 242 2.1.5. crls 244 The crls field MUST be omitted. 246 2.1.6. signerInfo 248 SignerInfo is defined under CMS as: 250 SignerInfo ::= SEQUENCE { 251 version CMSVersion, 252 sid SignerIdentifier, 253 digestAlgorithm DigestAlgorithmIdentifier, 254 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 255 signatureAlgorithm SignatureAlgorithmIdentifier, 256 signature SignatureValue, 257 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 259 2.1.6.1. version 261 The version number MUST be 3, corresponding with the choice of 262 SubjectKeyIdentifier for the sid. 264 2.1.6.2. sid 266 The sid is defined as: 268 SignerIdentifier ::= CHOICE { 269 issuerAndSerialNumber IssuerAndSerialNumber, 270 subjectKeyIdentifier [0] SubjectKeyIdentifier } 272 For a BOA, the sid MUST be a SubjectKeyIdentifier. 274 2.1.6.3. digestAlgorithm 276 The digestAlgorithm MUST be SHA-256, the OID for which is 277 2.16.840.1.101.3.4.2.1. [RFC4055] 279 2.1.6.4. signedAttrs 281 Signed Attributes are defined as: 283 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 285 Attribute ::= SEQUENCE { 286 attrType OBJECT IDENTIFIER, 287 attrValues SET OF AttributeValue } 289 AttributeValue ::= ANY 291 The signedAttr element MUST be present and MUST include the content- 292 type and message-digest attributes. The signer MAY also include the 293 signing-time signed attribute, the binary-signing-time signed 294 attribute, or both signed attributes. Other signed attributes that 295 are deemed appropriate MAY also be included. The intent is to allow 296 additional signed attributes to be included if a future need is 297 identified. This does not cause an interoperability concern because 298 unrecognized signed attributes are ignored by the relying party. 300 The signedAttr MUST include only a single instance of any particular 301 attribute. Additionally, even though the syntax allows for a SET OF 302 AttributeValue, in a BOA the attrValues must consist of only a single 303 AttributeValue. 305 2.1.6.4.1. Content-Type Attribute 307 The ContentType attribute MUST be present. The attrType OID for the 308 ContentType attribute is 1.2.840.113549.1.9.3. 310 The attrValues for the ContentType attribute in a ROA MUST be 311 1.2.840.113549.1.9.16.1.[TBD] (matching the eContentType in the 312 EncapsulatedContentInfo). 314 2.1.6.4.2. Message-Digest Attribute 316 The MessageDigest Attribute MUST be present. The attrType OID for 317 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 319 The attrValues for the MessageDigest attribute contains the output of 320 the digest algorithm applied to the content being signed, as 321 specified in Section 11.1 of[RFC3852]. 323 2.1.6.4.3. Signing-Time Attribute 325 The SigningTime Attribute MAY be present in a BOA. If it is present 326 it MUST be ignored by the relying party. The presence of absence of 327 the SigningTime attribute in no way affects the validation of the BOA 328 (as specified in Section 3). The attrType OID for the SigningTime 329 attribute is 1.2.840.113549.1.9.5. 331 The SigningTime attribute is defined as: 333 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 334 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 336 SigningTime ::= Time 338 Time ::= CHOICE { 339 utcTime UTCTime, 340 generalizedTime GeneralizedTime } 342 The Time element specifies the time, based on the local system clock, 343 at which the digital signature was applied to the content. 345 2.1.6.4.4. BinarySigningTime Attribute 347 The BinarySigningTime Attribute MAY be present. If it is present it 348 MUST be ignored by the relying party. The presence of absence of the 349 BinarySigningTime attribute in no way affects the validation of the 350 ROA (as specified in Section 3). The attrType OID for the 351 BinarySigningTime attribute is 1.2.840.113549.1.9.16.2.46. 353 The BinarySigningTime attribute is defined as: 355 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 356 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 357 smime(16) aa(2) 46 } 359 BinarySigningTime ::= BinaryTime 361 BinaryTime ::= INTEGER (0..MAX) 363 The BinaryTime element specifies the time, based on the local system 364 clock, at which the digital signature was applied to the content. 366 2.1.6.5. signatureAlgorithm 368 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 369 is 1.2.840.113549.1.1.1. 371 2.1.6.6. signature 373 The signature value is defined as: 375 SignatureValue ::= OCTET STRING 377 The signature characteristics are defined by the digest and signature 378 algorithms. 380 2.1.6.7. unsignedAttrs 382 unsignedAttrs MUST be omitted. 384 3. BOA Validation 386 Before a relying party can use a BOA as a constrictor of a routing 387 announcement, the relying party must use the RPKI to validate the 388 BOA. To do this the relying party performs the following steps: 390 1. Verify that the BOA syntax complies with this specification. In 391 particular, verify the following: 393 a. The contentType of the CMS object is SignedData (OID 394 1.2.840.113549.1.7.2) 396 b. The eContentType of the CMS object is id-ct-rpkiBOA (OID 397 1.2.840.113549.1.9.16.1.[TBD]) 399 c. The version of the SignedData object is 3. 401 d. The digestAlgorithm in the SignedData object is SHA-256 (OID 402 2.16.840.1.101.3.4.2.1). 404 e. The certificates field in the SignedData object is present 405 and contains an EE certificate whose Subject Key Identifier 406 (SKI) matches the sid field of the SignerInfo object. 408 f. The crls field in the SignedData object is omitted. 410 g. The eContentType in the EncapsulatedContentInfo is rid-ct- 411 rpkiBOA (OID 1.2.840.113549.1.9.16.1.[TBD]) 413 h. The version of the BOA is 0. 415 i. The addressFamily in the BOAIPAddressFamily is either IPv4 or 416 IPv6 (0001 and 0002, respectively). 418 j. The version of the SignerInfo is 3. 420 k. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 421 2.16.840.1.101.3.4.2.1). 423 l. The signatureAlgorithm in the SignerInfo object is RSA (OID 424 1.2.840.113549.1.1.1). 426 m. The signedAttrs field in the SignerInfo object is present and 427 contains both the ContentType attribute (OID 428 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 429 1.2.840.113549.1.9.4). . 431 n. The unsignedAttrs field in the SignerInfo object is omitted. 433 2. Use the public key in the EE certificate to verify the signature 434 on the BOA. 436 3. Verify that the EE certificate has an IP Address Delegation 437 extension [RFC3779] and that the IP address prefixes in that 438 extension cover the IP address prefixes in the BOA, and the AS 439 numbers in that extension cover the AS numbers in the BOA. 441 4. Verify that no valid ROA exists which also covers any more or 442 less specific prefixes, or any AS numbers. In the case that a 443 ROA does exist which overlaps the BOA in any way, the BOA MUST be 444 considered invalid. 445 5. Verify that the EE certificate is a valid end-entity certificate 446 in the resource PKI by constructing a valid certificate path to a 447 trust anchor. (See [I-D.ietf-sidr-res-certs] for more details.) 449 4. BOA Use Practices 451 BOAs are intended to allow relying parties a means of validating 452 whether route origination information as described in a route 453 advertisement refers to an IP address or AS number that has not been 454 validly allocated for use in the routing system. 456 Any party with a validly assigned Internet resource set and a CA 457 certificate that describes this allocation can publish a BOA, 458 independently of the actions of the actions of the party that 459 assigned the resource set. 461 An Internet Registry SHOULD maintain a single BOA in relation to each 462 parent registry that has assigned resources to this registry. 464 BOAs are not hierarchically related however they are subordinate to 465 the CA certificate that describes the immediate allocations assigned. 467 An Internet Registry SHOULD maintain a regular issuance cycle for 468 BOAs. 470 For registries that operate on a day-to-day basis in terms of 471 resource transactions, it is suggested that a local BOA management 472 practice would be that a new BOA should be issued on a regular 24 473 hour basis. The corresponding EE certificate should have a validity 474 period of no more than 72 hours from the time of issuance. Each time 475 a new EE certificate for a BOA is issued the previous BOA's EE 476 certificate should be revoked and the previous BOA removed from the 477 publication repository. 479 Parties that operate a local cache of RPKI objects should ensure that 480 they refresh BOA objects at intervals 24 hours to ensure that they 481 have the current BOA in the local cache. 483 5. BOA Interpretation 485 A BOA can be used to check an inter-domain routing advertisement 486 ("route") to determine if the origination information in the route 487 object refers to invalid IP addresses or an invalid AS number. 489 If a route has an AS origination that refers to an AS number that is 490 listed in a valid BOA, then the route can be regarded as a Bogon, and 491 local policies that apply to Bogon AS's can be applied to the route. 492 However if the AS number of this route is described in a valid ROA 493 whose EE certificate lists the AS number, the BOA MUST be considered 494 invalid 496 If a route has an address prefix that is equal to, or is a more 497 specific prefix of an IP address that is included in a valid BOA then 498 the route can be regarded as a Bogon, and local policies that apply 499 to Bogon prefixes can be applied to the route. However if the 500 address prefix of the route is described (either more or less 501 specific) by a valid ROA, the BOA MUST be considered invalid. 503 BOA interpretation in the context of validation of origination of 504 route objects is described in [I-D.ietf-sidr-roa-validation]. 506 6. Security Considerations 508 There is no assumption of confidentiality for the data in a BOA; it 509 is anticipated that BOAs will be stored in repositories that are 510 accessible to all ISPs, and perhaps to all Internet users. There is 511 no explicit authentication associated with a BOA, since the RPKI used 512 for BOA validation provides authorization but not authentication. 513 Although the BOA is a signed, application layer object, there is no 514 intent to convey non-repudiation via a BOA. 516 The purpose of a BOA is to convey an attestation by an address holder 517 that there is no authority for the generation of a route that refers 518 to specified addresses or origination from specified AS's. The 519 integrity of a BOA must be established in order to validate the 520 authority of the Bogon Attestation. The BOA makes use of the CMS 521 signed message format for integrity, and thus inherits the security 522 considerations associated with that data structure. The right of the 523 BOA signer to authorize the attestation of specified IP addresses and 524 AS's as Bogons is established through use of the address space and AS 525 number PKI described in [I-D.ietf-sidr-arch]. Specifically, a 526 relying party must verify the signature on the BOA using an X.509 527 certificate issued under this PKI, and check that the prefix(es) in 528 the BOA match, or are covered by those in the address space extension 529 in the certificate. 531 7. IANA Considerations 533 It would be anticipated that the IANA maintain a BOA for all 534 unallocated space or reserved space (IPv4, IPv6 and ASNs) not 535 intended for public use. 537 8. Acknowledgments 539 The authors are indebted to the authors of Route Origin Authorization 540 (ROA) [I-D.ietf-sidr-roa-format], M. Lepinski, S. Kent and D. Kong, 541 as much of the text used to define a BOA has been borrowed from the 542 ROA format specification, and Russ Housley for clarification on the 543 CMS profile. 545 Further the authors wish to thank many security people, too many to 546 name, for clarifying that negative attestations are a valid and 547 useful security construct. 549 Lastly, without the orginal thoughts and words from George Michaelson 550 and Geoff Huston this document would not exist. Their hands helped 551 form the concepts of why we need BOAs in the RPKI and historically 552 were two of the original three authors of this document. 554 9. Normative References 556 [I-D.ietf-sidr-arch] 557 Lepinski, M. and S. Kent, "An Infrastructure to Support 558 Secure Internet Routing", draft-ietf-sidr-arch-06 (work in 559 progress), March 2009. 561 [I-D.ietf-sidr-res-certs] 562 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 563 X.509 PKIX Resource Certificates", 564 draft-ietf-sidr-res-certs-16 (work in progress), 565 February 2009. 567 [I-D.ietf-sidr-roa-format] 568 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 569 Origin Authorizations (ROAs)", 570 draft-ietf-sidr-roa-format-04 (work in progress), 571 November 2008. 573 [I-D.ietf-sidr-roa-validation] 574 Huston, G. and G. Michaelson, "Validation of Route 575 Origination in BGP using the Resource Certificate PKI", 576 draft-ietf-sidr-roa-validation-01 (work in progress), 577 October 2008. 579 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 580 Addresses and AS Identifiers", RFC 3779, June 2004. 582 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 583 RFC 3852, July 2004. 585 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 586 Algorithms and Identifiers for RSA Cryptography for use in 587 the Internet X.509 Public Key Infrastructure Certificate 588 and Certificate Revocation List (CRL) Profile", RFC 4055, 589 June 2005. 591 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 592 Protocol 4 (BGP-4)", RFC 4271, January 2006. 594 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 595 Housley, R., and W. Polk, "Internet X.509 Public Key 596 Infrastructure Certificate and Certificate Revocation List 597 (CRL) Profile", RFC 5280, May 2008. 599 Author's Address 601 Terry Manderson 603 Email: terry@terrym.net