idnits 2.17.1 draft-weis-sobgp-certificates-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BGP' is mentioned on line 91, but not defined == Missing Reference: 'RSA' is mentioned on line 226, but not defined == Missing Reference: 'RFC1421' is mentioned on line 1601, but not defined == Unused Reference: 'IAB-SC' is defined on line 1951, but no explicit reference was found in the text == Unused Reference: 'RFC3281' is defined on line 1956, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- No information found for draft-ng-sobgp-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SOBGP-BGP' -- Possible downref: Normative reference to a draft: ref. 'SOBGP-DEPLOY' == Outdated reference: A later version (-04) exists of draft-lonvick-sobgp-radius-03 -- Possible downref: Normative reference to a draft: ref. 'SOBGP-RADIUS' -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Brian Weis, Editor 3 INTERNET-DRAFT Cisco Systems 4 draft-weis-sobgp-certificates-01.txt 5 Expires: April, 2004 October, 2003 7 Secure Origin BGP (soBGP) Certificates 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working groups. 16 Note that other groups may also distribute working documents as 17 Internet Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes the format of digital certificates that are 33 used by the Secure Origin BGP (soBGP) extensions to BGP, as well as 34 acceptable use of those certificates. Included are certificates 35 providing authentication, authorization, and policy distribution. 37 Secure Origin BGP (soBGP) Certificates October, 2003 39 Table of Contents 41 1.0 Introduction......................................................3 42 1.1 Key Words.......................................................3 43 1.2 Terminology.....................................................3 44 2.0 Overview..........................................................4 45 2.1 Digital Signature Algorithms....................................5 46 3.0 Entity Certificate (Entitycert)...................................5 47 3.1 Format..........................................................6 48 3.2 Creation........................................................7 49 3.3 Distribution....................................................8 50 3.4 Validation......................................................8 51 3.5 Revocation and Expiration......................................10 52 4.0 Authorization Certificates (Authcert)............................10 53 4.1 Format.........................................................11 54 4.2 Creation.......................................................15 55 4.3 Distribution...................................................16 56 4.4 Validation.....................................................16 57 4.5 Revocation.....................................................17 58 5.0 Prefix Policy Certificates (PrefixPolicycert)....................17 59 5.1 Format.........................................................17 60 5.2 Creation.......................................................22 61 5.3 Distribution...................................................23 62 5.4 Validation.....................................................23 63 5.5 Revocation.....................................................23 64 6.0 AS Policy Certificates (ASPolicycert)............................24 65 6.1 Format.........................................................24 66 6.2 Creation.......................................................31 67 6.3 Distribution...................................................32 68 6.4 Validation.....................................................32 69 6.5 Revocation.....................................................32 70 7.0 Security Considerations..........................................33 71 7.1 Entitycerts....................................................33 72 7.2 Authcerts......................................................33 73 7.3 PrefixPolicycerts..............................................34 74 7.4 ASPolicycerts..................................................34 75 7.5 Entitycert Uniform Resource Locators...........................34 76 8.0 IANA Considerations..............................................34 77 8.1 Authorization Certificate......................................35 78 8.2 Prefix Policy Certificate......................................35 79 8.3 AS Policy Certificate..........................................36 80 9.0 Acknowledgments..................................................37 81 10.0 References......................................................37 82 10.1 Normative References..........................................37 83 10.2 Informative References........................................38 84 Editor's Address.....................................................38 85 Secure Origin BGP (soBGP) Certificates October, 2003 87 1.0 Introduction 89 There is a great deal of concern over the security of routing systems 90 within the Internet. This is particularly true in relation to the 91 Border Gateway Protocol [BGP], the protocol used to provide routing 92 information between Autonomous Systems (ASes). Source Origin BGP 93 (soBGP) provides a method that ASes can use to determine the 94 correctness of BGP messages received by their BGP routers. It also 95 provides a method for ASes to detect implausible routes reported in a 96 BGP Update AS_PATH, and acts as an aid in detecting misconfigured 97 routers advertising incorrect routes. 99 Source Origin BGP does not define changes to BGP Updates. Rather, it 100 provides authorization and path policy "out-of-band" from the BGP 101 Updates. An AS compares the information claimed in BGP Updates to the 102 soBGP policy, and makes judgments to the fitness of the claim. 104 Source Origin BGP distributes authorization and policy as digitally 105 signed objects, which can be distributed in many ways. To aid 106 interoperability, extensions have been defined in [SOBGP-BGP] that 107 support distribution of the digitally signed soBGP objects within BGP 108 itself.. 110 Source Origin BGP deployment models are discussed in [SOBGP-DEPLOY]. 112 Extensions to RADIUS to support soBGP are defined in [SOBGP-RADIUS]. 114 This document defines the format of the digitally signed objects used 115 by soBGP, as well as the operations to be performed on those objects. 117 1.1 Key Words 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 120 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 121 this document are to be interpreted as described in [RFC2119]. 123 1.2 Terminology 125 This document frequently uses the following terms: 127 AS Policy Certificate (ASPolicycert) 128 A digital certificate that asserts routing policy for an 129 Autonomous System. 131 Authorization Certificates (Authcerts) 132 A digital certificate that asserts that an Autonomous System is 133 authorized to advertise a particular prefix. 135 Entity 136 Participants within the routing system. These include Regional 137 Internet Registry (RIR) authorities, Local Internet Registry 138 (LIR) authorities, Internet Service Providers (ISPs), and other 139 Secure Origin BGP (soBGP) Certificates October, 2003 141 organizations participating in soBGP. An Entity must have an 142 Autonomous System (AS) number assigned to it as a unique 143 identity, even if it does not source routes within the routing 144 system. 146 Entity Certificate (Entitycert) 147 An X.509 certificate that asserts a mapping between an Autonomous 148 System identifier and a public key. 150 Prefix Policy Certificate (Prefixpolicycert) 151 A digital certificate mapping usage policy to one or more 152 prefixes. 154 Regional Internet Registry (RIR) 155 An entity recognized by IANA and tasked with managing IP address 156 space within a wide geographical area. RIRs allocate address 157 space to Local Internet Registries and other entities. 159 Local Internet Registry (LIR) 160 An entity that allocates address space to the users of the 161 network services that it provides. 163 2.0 Overview 165 Source Origin BGP refers to participants within the routing system 166 as entities. Each entity must have an Autonomous System (AS) 167 number, issued from an authorized entity (e.g., Regional Internet 168 Registry), to participate in soBGP. Entities may have one or more 169 roles within soBGP. They may act as a trusted signer, an authorizer 170 of address blocks, and/or as a route originator. 172 Source Origin BGP provides a method of verifying that an AS is 173 authorized to advertise certain prefixes. The authorization to 174 advertise prefixes or a given address space is validated through 175 Authorization Certificates (Authcerts). Authcerts are issued by 176 entities (e.g., ISP) that allocate prefixes. 178 An AS given an Authcert (e.g., ISP customer) may assign local policy 179 to be used with the prefixes listed in the Authcert using a Prefix 180 Policy Certificate (PrefixPolicycert). 182 Policies specific to an Autonomous System are provided through AS 183 Policy Certificates (ASPolicycerts). This policy enables another 184 entity to develop a database of plausible paths through the routing 185 system, and aids in detecting impossible and fraudulent paths. 187 Authcerts, PrefixPolicycerts, and ASPolicycerts are verified using 188 public keys embedded in Entity Certificates (Entitycerts). 189 Entitycerts are X.509 certificates as specified by [RFC3280]. 191 Figure 1 illustrates the relationship between soBGP certificates for 192 a single AS. AS 1 allocates a prefix to AS 2. AS 1 also issues an 193 Authcert to AS 2 proving that AS 2 may legitimately use that prefix. 194 In this example, AS 1 also acts as an Entitycert issuer for AS 2. AS 195 Secure Origin BGP (soBGP) Certificates October, 2003 197 2 then creates two policy certificates: one specifying particular 198 policy for the authorized prefix, and one specifying particular 199 policy for the AS. 201 +-----+------+ 202 | AS 1 | 203 +-------| Entitycert | 204 / +------------+ 205 / | 206 + | 207 | | 208 v v 209 +-------+--+ +-----+------+ +------------------+ 210 | AS 2 | | AS 2 | | AS 2 | 211 | Authcert | | Entitycert |-------> | PrefixPolicycert | 212 +----------+ +------------+ +------------------+ 213 | 214 | +------------------+ 215 | | AS 2 | 216 +---------> | ASPolicycert | 217 +------------------+ 219 Figure 1. Relationship between soBGP certificates 221 Each of the soBGP certificates is discussed in detail in subsequent 222 sections of this document. 224 2.1 Digital Signature Algorithms 226 The RSA Public Key Algorithm [RSA] is a widely deployed public key 227 algorithm commonly used for digital signatures. Compared to other 228 public key algorithms, signature verification is relatively quick. 229 This property is useful considering the large number of signature 230 verifications that will be done on soBGP certificates. The RSA 231 Algorithm is commonly supported in hardware, and is no longer 232 encumbered by intellectual property claims. 234 All soBGP implementations MUST support a digital signature of a SHA1 235 digest encrypted with the RSA algorithm. An implementation MAY 236 support other signature methods, but any AS using alternate signature 237 methods run the risk of their signatures not being universally 238 verifiable. 240 3.0 Entity Certificate (Entitycert) 242 Entitycerts provide authentication, providing a binding of an 243 identity (i.e., autonomous system number) to a public key. The 244 authenticity of the binding is verified with a digital signature, 245 where the public key of the certificate issuer has been previously 246 accepted by an receiver as valid. Issuer public keys can either be 247 Secure Origin BGP (soBGP) Certificates October, 2003 249 manually configured, or are verified through the use of another 250 issuer's trusted public key in a "web of trust" built by the 251 receiver. 253 Entitycerts are used to verify, through a trust model, the existence 254 of an entity within the routing system, and the value of that 255 entity's public key for use in the routing system. Each entity 256 within the routing system participating in soBGP MUST generate a 257 public/private key pair. The public key portion of this pair is then 258 signed, verifying that anyone using this public key is actually the 259 entity in question. This signature may be provided by various other 260 trusted parties within the routing system, including (but not 261 limited to): 263 - The authority that issued the autonomous system number. 265 - An external commercial authority that provides authentication 266 certificates for other commercial transactions. 268 - Any other trusted party within the domain of Internet routing, 269 such as a well known Service Provider. 271 - Self-signed if the entity is well known within the routing system. 273 A public key is used to verify the validity of other messages 274 transmitted by this entity within the routing system.The public key, 275 along with other verifying information, is formatted into an 276 Entitycert, as described in the next section. 278 3.1 Format 280 An Entitycert MUST be formatted as an X.509 authentication 281 certificate, as defined in [RFC3280]. The Entitycert MUST be 282 generated with a signature of type sha1withRSAEncryption [RFC3279]. 284 The primary identity in soBGP is the autonomous system number. 285 Because of this, each entity that issues Entitycerts MUST be 286 assigned an AS number, even if they do not originate routes into the 287 internetwork. In accordance with Section 4.2.1.7 of [RFC3280], 288 issuers MUST verify all parts of the subject alternative name, 289 including the AS number, before issuing the certificate. 291 An Entitycert MUST have a subjectAltname critical extension, which 292 MUST contain the AS number of the subject as an otherName choice. 293 The AS number is encoded with the OID defined in Section 3.2.1 of 294 [ADDR-EXT]. 296 An Entitycert MUST have an issuerAltname critical extension, which 297 MUST contain the AS number of the subject as an otherName choice. 298 The AS number is encoded with the OID defined in Section 3.2.1 of 299 [ADDR-EXT]. 301 Secure Origin BGP (soBGP) Certificates October, 2003 303 The X.509 Issuer and Subject distinguished names are not used by 304 soBGP. In accordance with Section 4.2.1.7 of [RFC3280], when 305 subjectAltName is required, the Subject field MAY be empty. 307 3.2 Creation 309 An Entitycert is usually created with the following steps: 311 - The entity requesting an Entitycert generates a signature key pair 312 - The entity forwards its identity (including its AS number) and the 313 public key to an Entitycert issuer using the certificate 314 registration mechanism supported by the issuer. 315 - The issuing autonomous system verifies that the identity of the 316 receiving autonomous system, generates an Entitycert including 317 that identity, and signs it with its own private key. 318 - The issuing autonomous system returns the Entitycert to the 319 receiving autonomous system. 321 3.2.1 Certificate Uniqueness 323 Digital certificates are created as uniquely named objects, which 324 allows them to be uniquely identified. For the purposes of soBGP, the 325 pair of CertificateSerialNumber and IssuerAltName values uniquely 326 identifies entity Certificates. Note that although RFC 3280 contains 327 an X.509v3 IssuerName, it is not used elsewhere within soBGP. 329 3.2.2 Certificate Encoding 331 Entitycerts distributed in [SOBGP-BGP] use their native DER [X.690] 332 form. If Entitycerts are manually distributed (e.g., through 333 electronic mail) they may need to be base64 encoded into ASCII as 334 described in Section 4.3 of [RFC1421]. 336 3.2.3 Multiplicity of Entitycerts 338 An autonomous system MAY enroll with more than one issuer, which 339 results in multiple Entitycerts. An AS holding certificates from 340 different well-known issuing entities within the routing system may 341 result in a greater number of other autonomous systems accepting 342 their public key. Or, it may simply result in other autonomous 343 systems accepting their public key faster, which increases BGP 344 convergence times. 346 If an entity detects that an autonomous system has valid Entitycerts 347 from different issuers, the entity SHOULD treat the various 348 Entitycerts as independent. Revocation from one issuer does not 349 necessarily imply that Entitycerts from other issuers are invalid. 350 An issuer may revoke a certificate for reasons other than private 351 key compromise or loss. 353 Secure Origin BGP (soBGP) Certificates October, 2003 355 However, even if an issuer states key compromise as the reason for 356 revocation, a receiving entity SHOULD treat this state as specific 357 to the issuer. Note that if the state of one issuer were instead 358 considered transitive, the erroneous revocation of a single issuer 359 would result in a denial of service attack on the victim autonomous 360 system. 362 In the face of inconsistent state from different issuers, a receiver 363 MAY choose to trust one issuer over another. For example, a receiver 364 may choose to prefer the result of an issuer they directly trust to 365 an issuer that was verified further away in the "web of trust". 367 3.3 Distribution 369 Entitycerts may be distributed using any number of methods, for 370 example: 372 - maintained in a directory maintained by the issuing autonomous 373 system, 374 - distributed via some out of band mechanism, and/or 375 - distributed within BGP using extensions defined in [SOBGP-BGP]. 377 To ensure interoperability, the receiving autonomous system SHOULD 378 distribute its Entitycert within BGP. 380 3.4 Validation 382 Any device receiving an Entitycert can verify it by validating the 383 signature on the certificate, along with the verifying information. 384 If a Certificate Revocation List (CRL) is available for that issuer, 385 it MUST be consulted to verify that this certificate has not been 386 revoked. Once validation is complete, the public key contained in 387 this certificate may be used to verify messages purportedly sent by 388 this entity. 390 3.4.1 Web of Trust 392 An soBGP entity uses the "web of trust" paradigm for purposes of 393 Entitycert validation, where the entity learns the validity of 394 public keys over time. An entity follows the following procedure for 395 validating Entitycerts in the web of trust. 397 - A small number of Entitycerts are manually configured and copied 398 to a device's local configuration. These are implicitly trusted as 399 being previously verified and authenticated. 400 - When the entity receives a new Entitycert, it checks to see if it 401 has the public key of the issuing autonomous system in its 402 configuration. If so, it attempts to validate the Entitycert, 403 using the previously known public key, and any revocation material 404 that is available from the issuer. 406 Secure Origin BGP (soBGP) Certificates October, 2003 408 - If the new Entitycert proves valid, it is added to the device's 409 local configuration and may be used to validate subsequently 410 received Entitycerts. 411 - If the new Entitycert cannot be validated because the issuer?s 412 public key is not yet available, local policy dictates as to 413 whether or not the certificate is held awaiting the issuer?s 414 certificate. 416 Figure 2 shows an example web of trust. In this example, Entitycerts 417 for AS 1 and AS 5 would be manually copied to the local 418 configuration on the box. Other Entitycerts would be validated using 419 the usual PKI path validation techniques. 421 +------------+ +------------+ 422 | AS 1 | | AS 5 | 423 | Entitycert | | Entitycert | 424 +-----+------+ +---+----+---+ 425 | / \ 426 | / \ 427 | + + 428 | | | 429 V V V 430 +------------+ +------------+ +------------+ 431 | AS 2 | | AS 6 | | AS 7 | 432 | Entitycert | | Entitycert | | Entitycert | 433 +---+----+---+ +------------+ +-----+------+ 434 / \ | 435 / \ V 436 + + +------------+ 437 | | | AS 8 | 438 V V | Entitycert | 439 +------------+ +------------+ +-----+------+ 440 | AS 3 | | AS 4 | | 441 | Entitycert | | Entitycert | V 442 +------------+ +------------+ +------------+ 443 | AS 9 | 444 | Entitycert | 445 +------------+ 447 Figure 2. Example Web of Trust 449 An autonomous system may define local policy to restrict the scope 450 of the web of trust. However it should be noted that any local 451 policy restricting the web of trust reduces the value of soBGP 452 authorization and path validation. 454 One type of local policy would be to accept only a certain "depth" 455 of Entitycert issuers. For example, consider if AS 6 in Figure 2 456 only accepted two levels of issuers. AS 6 would only trust ASes 457 1,2,5,6 and 7 to issue Entitycerts. It would never validate the 458 Entitycert from ASes 3, 4, 8, and 9. 460 Secure Origin BGP (soBGP) Certificates October, 2003 462 3.4.2 Self-signed Entitycerts 464 Entitycerts MAY be self-signed, but SHOULD only be accepted from 465 autonomous systems when an alternative method exists of validating 466 that the self-signed certificate is genuine. For example, 467 distribution out-of-band using a trusted delivery procedure would be 468 acceptable. 470 Typical users of a self-signed Entitycert would be: 472 - A commercial authority in the business of providing authentication 473 certificates for many types of commercial transactions 474 - An Entitycert issuer that is at the top of a hierarchy of issuers 475 - A well-known trusted party within the domain of Internet routing 477 3.5 Revocation and Expiration 479 Any entity issuing an Entitycert may have need to revoke it. The 480 entity MAY use any form for propagating that revocation list, but 481 SHOULD also send it as part of an AS Policy Certificate (distributed 482 using [SOBGP-BGP]). This allows autonomous systems that cannot route 483 to the issuing autonomous system to verify that the Entitycert has 484 not been revoked. 486 If an Entitycert is discarded due to revocation, the Authcert and 487 Policy databases should be examined. Any Authcerts and Policy 488 certificates that were validated using the discarded certificate 489 should be removed from the database. 491 X.509 certificates contain expiration dates. Any device validating 492 Entitycerts MUST have a time of day clock that is close to real time 493 in order to properly deal with expired certificates 495 If an Entitycert is discarded due to expiration, an Authcerts or 496 Policy certificates validated using the discarded certificate remain 497 valid if another valid Entitycert for the AS can be found containing 498 the same public key. 500 4.0 Authorization Certificates (Authcert) 502 Authcerts prove the right of an entity to advertise particular 503 address spaces. They are generated in a hierarchical manner 504 following the order of address space allocation (i.e., from RIR, to 505 LIR or ISP, to customer), and are distributed along with the address 506 space allocation. Receivers use the Authcert to validate 507 announcements received in BGP UPDATE messages. 509 The authorization certificate binds one or more prefix blocks to a 510 particular autonomous system. It is typically provided by an entity 511 issuing a prefix block to an autonomous system, and is digitally 512 signed by the issuing autonomous system. The Authcert can be thought 513 Secure Origin BGP (soBGP) Certificates October, 2003 515 of as an "Attribute Certificate" in the spirit of RFC 3281, although 516 it does not follow the syntax of that document. 518 The authenticity of Authcerts is verified with a digital signature 519 provided by the issuing autonomous system. Authcerts do not contain 520 public keys. Rather, they bind an address space to a particular 521 identity (i.e., autonomous system). 523 4.1 Format 525 The Authcert is defined as a header block followed by a set of 526 Type/Length/Value attributes, as identified in the following 527 sections. Each Authcert TLV includes a type, which is treated as a 528 16 bit (two octet) unsigned integer. The TLVs described must be 529 placed within the Authcert in type order; every Authcert should 530 begin with a TLV type 1 (Autonomous System and Options). All TLVs 531 are REQUIRED to be in an Authcert unless otherwise noted. 533 4.1.1 Authcert Header 535 0 1 2 3 536 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 537 +---------------+---------------+-------------------------------+ 538 | Cert. Marker | Type Id | Length | 539 +---------------+---------------+-------------------------------+ 540 | TLVs 541 +---------------- 543 o Certificate Marker: "162(0xa2), identifying this as an soBGP 544 certificate. 546 o Type ID: "1(0x01), identifying this as an Authcert. 548 o Length: Set to the length of the TLVs. 550 o TLVs: The Type/Length/Value attributes making up an Authcert. 552 4.1.2 The Authorizing AS 554 0 1 2 3 555 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 556 +-------------------------------+-------------------------------+ 557 | TLV Type | Length | 558 +-------------------------------+-------------------------------+ 559 | Autonomous System | 560 +---------------------------------------------------------------+ 562 o TLV type: 1 (0x0001) 564 o Length: Set to 4. 566 Secure Origin BGP (soBGP) Certificates October, 2003 568 o AS: (4 octets), the autonomous system authorizing other 569 entities to advertise prefixes within this block. AS numbers 570 containing only two octets should be placed in the least 571 significant octets of this four-octet field (the two rightmost 572 octets). 574 Each authorizing entity MUST have an autonomous system number, used 575 as a unique identifier, even though they may not advertise prefixes 576 into the routing system. 578 4.1.3 Authorized Originator 580 0 1 2 3 581 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 582 +-------------------------------+-------------------------------+ 583 | TLV Type | Length | 584 +-------------------------------+-------------------------------+ 585 | Autonomous System | 586 +---------------------------------------------------------------+ 588 o TLV type: 2 (0x0002) 590 o Length: Set to 4. 592 o AS: (4 octets), the autonomous system of an entity authorized 593 to advertise prefixes within this block. AS numbers containing 594 only two octets should be placed in the least significant 595 octets of this four-octet field (the two rightmost octets). 597 Multiple authorized originator TLVs may be included in the Authcert. 599 4.1.4 The Serial Number TLV 601 0 1 2 3 602 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 603 +-------------------------------+-------------------------------+ 604 | TLV Type | Length | 605 +-------------------------------+-------------------------------+ 606 | Serial Number | 607 +---------------------------------------------------------------+ 609 o TLV type: 3 (0x0003) 611 o Length: Set to 4. 613 o Serial Number: (4 octets), unsigned integer taken from a number 614 space maintained by the Authorizing AS indicating the serial 615 number of this Authorization certificate. The Authorizing AS 616 MUST manage the number space as a monotonically increasing 617 value so that a relative ordering of Authcerts is maintained. 619 Secure Origin BGP (soBGP) Certificates October, 2003 621 4.1.5 Authorizing AS Entitycert Uniform Resource Locator 623 0 1 2 3 624 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 625 +-------------------------------+-------------------------------+ 626 | TLV Type | Length | 627 +-------------------------------+-------------------------------+ 628 | URL | 629 +---------------- 631 o TLV type: 4 (0x0004) 633 o Length: Denotes the length of the URL in octets. 635 o URL: A uniform resource locator indicating a location where the 636 Authorizing AS?s Entitycert can be found. 638 An Authcert may omit this TLV. However, an implementation is 639 REQUIRED to correctly parse them if they are present. A receiving 640 device MAY choose to ignore the URL TLV. 642 4.1.6 Authorizing AS Validation List Uniform Resource Locator 644 0 1 2 3 645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 646 +-------------------------------+-------------------------------+ 647 | TLV Type | Length | 648 +-------------------------------+-------------------------------+ 649 | URL | 650 +---------------- 652 o TLV type: 5 (0x0005) 654 o Length: Denotes the length of the URL in octets. 656 o URL: A uniform resource locator indicating a location where the 657 Authorizing AS?s Validation List can be found. 659 An Authcert may omit this TLV. However, an implementation is 660 REQUIRED to correctly parse them if they are present. A receiving 661 device MAY choose to ignore the URL TLV. 663 4.1.7 The Address Prefix TLV 665 The address prefix TLV shall define blocks of address within which 666 the authorized AS' are allowed to advertise prefixes (or routes). 668 Secure Origin BGP (soBGP) Certificates October, 2003 670 0 1 2 3 671 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 672 +-------------------------------+-------------------------------+ 673 | TLV Type | Length | 674 +-------------------------------+---------------+---------------+ 675 | Address Family Identifier | RESERVED | Subsequent AFI| 676 +-------------------------------+---------------+---------------+ 677 | NLRI Data | 678 +---------------- 680 o TLV Type: 14 (0x000D) 682 o Length (2 octets), set to 4 + the length of the NLRI Data. 684 o Address Family Identifier: This field carries the identity of 685 the Network Layer protocol associated with the Network Address 686 that follows. Presently defined values for this field are 687 specified in RFC 1700 (see the Address Family Numbers section). 689 o RESERVED: Set to 0. 691 o Subsequent AFI: This field provides additional information 692 about the type of the Network Layer Reachability Information 693 carried in the attribute. 695 o NLRI Data: An address prefix as described in Section 4 of 696 [RFC2858]. 698 4.1.8 Signature 700 0 1 2 3 701 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 702 +-------------------------------+-------------------------------+ 703 | TLV Type | Length | 704 +-------------------------------+-------------------------------+ 705 | Signature Type | Number of Issuers | 706 +-------------------------------+-------------------------------+ 707 | Entity Certificate Issuer Autonomous System | 708 +-------------------------------+-------------------------------+ 709 | Entity Certificate Serial Number | 710 +-------------------------------+-------------------------------+ 711 | ... | 712 +---------------------------------------------------------------+ 713 | Signature | 714 +------------------ 716 o TLV type: 65535 (0xFFFF) 718 o Length: (2 octets), unsigned integer denoting the length of the 719 payload bytes which follow. 721 Secure Origin BGP (soBGP) Certificates October, 2003 723 o Signature Type: (2 octets), unsigned integer denoting the type 724 of signature (the algorithm used to build this signature). Each 725 possible signing algorithm is assigned an integer from this 726 field. Signature type 1 is defined as an RSA encryption of a 727 SHA1 digest. 729 o Number of Issuers (2 octets): The number of Entitycert 730 references included in the signature payload. If more than one 731 Entitycert reference follows, all Entitycerts MUST contain the 732 same public key for the same authorizing autonomous system. 734 o Entity Certificate Issuer Autonomous System: (4 octets), the 735 autonomous system of the entity that provided the Entitycert to 736 the Authorizing AS. AS numbers containing only two octets 737 should be placed in the least significant octets of this four- 738 octet field (the two rightmost octets). 740 o Entity Certificate Serial Number: (4 octets), the Entitycert 741 serial number containing the public key of the Authorizing AS. 743 o Signature: The signature itself. 745 The signature is calculated using the private key of the authorizing 746 entity across all the TLVs within the Authcert. The Signature TLV 747 MUST be appended as the last TLV in the Authcert after the signature 748 has been computed. 750 4.2 Creation 752 An Authcert is usually created by the authorizing autonomous system 753 with the following steps: 755 - Allocate a prefix block to the receiving autonomous system. 756 - Build an Authcert by adding TLVs containing its own AS number, the 757 receiving (authorized) AS number, the prefix block, a unique 758 sequence number, and any other information (e.g., URL pointing to 759 the Entitycert that signed this Authcert.). 760 - Sign the Authcert by hashing and encrypting the Authcert TLVs. 761 Place the signature (and other required) information in a 762 Signature TLV, and append it to the Authcert. 764 4.2.1 Certificate Uniqueness 766 Digital certificates are created as uniquely named objects, which 767 allows them to be uniquely identified. An Authcert is uniquely 768 identified by the pair of Authorized Originator and Serial Number 769 TLV values. 771 4.2.2 Certificate Encoding 772 Secure Origin BGP (soBGP) Certificates October, 2003 774 Authcerts distributed in [SOBGP-BGP] are distributed in TLV form. 775 However if they are manually distributed (e.g., through electronic 776 mail) they may need to be base64 encoded into ASCII as described in 777 Section 4.3 of [RFC1421]. 779 4.3 Distribution 781 Authcerts are distributed as part of a Prefix Policy Certificate, so 782 that an autonomous system can reliably match distribution policy to 783 the prefix block. 785 4.4 Validation 787 The Authcert is validated using the following steps. 789 - Identify the Entitycert that signed the Authcert. The correct 790 Entitycert is uniquely identified with the Entity Certificate 791 Issuer Autonomous System and Entity Certificate Serial Number 792 contained in the Signature TLV. The Entity Certificate Issuer 793 Autonomous System is compared with the AS number in the Entitycert 794 IssuerAltName field. The Entity Certificate Serial Number is 795 compared with the Entitycert CertificateSerialNumber. 796 - Obtain the Entitycert that signed the Authcert, and validate it. 797 The Entitycert may be in a local cache (already received via BGP 798 extensions), retrieved using the URL in the Authcert, or through 799 other means. If an entity does not have the validating public key 800 it MUST NOT assume the Authcert is valid. 801 - Verify that the autonomous system identifier in SubjectAltname 802 matches the Authorized Originator TLV value of the Authcert. 803 - If an Authorization Certificate Validity List is available, 804 validate that the issuer of the Entitycert has not invalidated the 805 Authcert. Validity lists may be distributed in the signers 806 ASPolicycert, or a pointer to the list may be distributed in the 807 Authcert in an Authorizing AS Validation List URL. If no 808 Authorization Certificate Validity List is available, an entity 809 MAY accept the certificate. However if a validation list is 810 received later, the entity MUST check the validity of all 811 certificates that had been previously accepted. 812 - Hash the Authcert TLVs. 813 - Extract the signature from the Authcert. 814 - Extract the public key from the Entitycert, and use it to decrypt 815 the signature. 816 - Accept the Authcert as valid if the computed hash matches the 817 decrypted hash. If the hashes do not match, the Authcert MUST be 818 discarded. 820 4.4.1 Self-generated Authcerts 822 Self-generated Authcerts are dangerous, because a responsible third 823 party does not assign the authorization. Trusting an autonomous 824 Secure Origin BGP (soBGP) Certificates October, 2003 826 system to declare its own address space nullifies most of the 827 protections outlined in this document. 829 However, the autonomous systems at the highest level of allocation 830 (e.g. Regional Internet Registries (RIRs) or Local Internet 831 Registries (LIRs)) may not be able to find a responsible third party 832 to sign their Authcerts. In this case, self-generated Authcerts may 833 be unavoidable. 835 Authcerts MAY be self-generated, but MUST only be accepted from 836 autonomous systems that have been explicitly authorized and locally 837 configured. For example, a device may be configured to accept 838 Authcerts for the RIR autonomous systems. 840 4.5 Revocation 842 An entity issuing an Authcert MUST keep an Authcert revocation list. 843 The entity MAY use any form for propagating that revocation list. 845 Because BGP routers do not necessarily have synchronized clocks, 846 Authcerts do not carry expiration times, and thus do not expire. 847 Revocation is only method of invalidating an Authcert. 849 Revocation information may be represented as a "validation list". A 850 validation list includes lists of both valid and invalid (i.e., 851 revoked) certificates. Any number not appearing in the list MUST be 852 considered invalid. Validation list may be more efficient than a 853 pure revocation list for Authcerts in the case where a large number 854 of serial numbers have been revoked by an issuer. 856 An autonomous system SHOULD include an Authcert validation list in 857 their AS Policy Certificate (distributed using [SOBGP-BGP]). This 858 allows autonomous systems that cannot route to the issuing 859 autonomous system to verify that the Entitycert has not been 860 revoked. 862 5.0 Prefix Policy Certificates (PrefixPolicycert) 864 The PrefixPolicycert carries policy information sourced from route 865 originators. It provides a specific set of policy regarding one or 866 more prefix blocks. The owner of the prefix block creates it. There 867 is only one valid PrefixPolicycert for each prefix block at any 868 given time. 870 PrefixPolicycerts are verified with a digital signature provided by 871 the autonomous system generating the policy. It does not contain a 872 public key. Rather, it binds a particular policy to a particular 873 identity (i.e., autonomous system). 875 5.1 Format 876 Secure Origin BGP (soBGP) Certificates October, 2003 878 This certificate is formatted as a series of TLVs. Each TLV will 879 include a type, which is treated as a 16 bit (two octet) unsigned 880 integer, a length, which is also two octets, and a variable length 881 data field. TLVs MUST be placed in the PrefixPolicycert in type 882 order. 884 5.1.1 PrefixPolicycert Header 886 0 1 2 3 887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 888 +---------------+---------------+-------------------------------+ 889 | Cert. Marker | Type Id | Length | 890 +---------------+---------------+-------------------------------+ 891 | TLVs 892 +---------------- 894 o Certificate Marker: "162(0xa2), identifying this as an soBGP 895 certificate. 897 o Type ID: "2(0x02), identifying this as an PrefixPolicycert. 899 o Length: Set to the length of the TLVs. 901 o TLVs: The Type/Length/Value attributes making up an 902 PrefixPolicycert. 904 5.1.2 The Originating Autonomous System 906 0 1 2 3 907 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 908 +-------------------------------+-------------------------------+ 909 | TLV Type | Length | 910 +-------------------------------+-------------------------------+ 911 | Originating Autonomous System | 912 +---------------------------------------------------------------+ 914 o TLV type: 1 (0x0001) 916 o Length: Set to 4. 918 o Originating Autonomous System: (4 octets), the autonomous 919 system which originated this certificate. AS numbers containing 920 only two octets should be placed in the least significant 921 octets of this four-octet field (the two rightmost octets). 923 5.1.3 The Serial Number 924 Secure Origin BGP (soBGP) Certificates October, 2003 926 0 1 2 3 927 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 928 +-------------------------------+-------------------------------+ 929 | TLV Type | Length | 930 +-------------------------------+-------------------------------+ 931 | Serial Number | 932 +---------------------------------------------------------------+ 934 o TLV type: 2 (0x0002) 936 o Length: Set to 4. 938 o Serial Number: (4 octets), A serial number which identifies 939 this PrefixPolicycert, taken from a 32 bit number space. 941 5.1.4 Authorizing AS Entitycert Uniform Resource Locator 943 0 1 2 3 944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 945 +-------------------------------+-------------------------------+ 946 | TLV Type | Length | 947 +-------------------------------+-------------------------------+ 948 | URL | 949 +---------------- 951 o TLV type: 3 (0x0003) 953 o Length: Denotes the length of the URL in octets. 955 o URL: A uniform resource locator indicating a location where the 956 Authorizing AS?s Entitycert can be found. 958 An PrefixPolicycert may omit this TLV. However, an implementation is 959 REQUIRED to correctly parse them if they are present. A receiving 960 device MAY choose to ignore the URL TLV. 962 5.1.5 Authcert 964 0 1 2 3 965 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 966 +-------------------------------+-------------------------------+ 967 | TLV Type | Length | 968 +-------------------------------+-------------------------------+ 969 | Authentication Certificate | 970 +---------------- 972 o TLV type: 4 (0x0004) 974 o Length: Set to the length of the Authentication Certificate. 976 o Authentication Certificate containing a prefix block for which 977 the PrefixPolicycert applies. 979 Secure Origin BGP (soBGP) Certificates October, 2003 981 One or more Authcert TLVs MUST be included in the PrefixPolicycert. 983 5.1.6 Policies 985 0 1 2 3 986 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 987 +-------------------------------+-------------------------------+ 988 | TLV Type | Length | 989 +-------------------------------+-------------------------------+ 990 | Options | SubTVs 991 +-------------------------------+-------------- 993 o TLV type: 5 (0x0005) 995 o Length: Set to the sum of the Options size (2) and the length 996 of the SubTVs. 998 o Options: (2 octets), a bit field describing various policies 999 which should be applied to the prefixes indicated. 1001 o SubTVs: (variable length), zero or more fields, the length of 1002 which is determined by the type, as described below. 1004 5.1.6.1 Option bits 1006 The options bit field describes policies that should be applied 1007 to the address prefix described in the TLV. These options are: 1009 o Bit 0: Path Check. If this bit is set, the receiver should not 1010 accept any prefix for which the path cannot be verified as 1011 described in the section Verifying the Path, below. 1013 o Bit 1: Second Hop Check. If this bit is set, the receiver 1014 should not accept any prefix for which the second entry in the 1015 AS PATH cannot be verified as described in the section 1016 Verifying the Second Hop, below. 1018 o Bits 2-15: Reserved for future use. 1020 5.1.6.2 SubTVs 1022 The Authcert Policy subTVs provide optional policy information for 1023 the block of addresses included in the Authcert indicated; each 1024 subTV is of a fixed length, as determined by its type. 1026 Secure Origin BGP (soBGP) Certificates October, 2003 1028 0 1 2 3 1029 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1030 +-------------------------------+------------------------------+ 1031 | TV Type | Data.... 1032 +-------------------------------+------------------------- 1034 o TV Type: (2 octets), An unsigned integer indicating the type of 1035 subTV 1037 Types defined within this specification are: 1039 - Type 1: Must Include AS, 4 octets of data, an AS which must be 1040 included in the AS path of any prefix falling within this block 1041 of addresses. 1043 - Type 2: OR Include AS, 4 octets of data, at least one of the 1044 included OR Include AS' must be included in the AS path of any 1045 prefix falling within this block of addresses. 1047 - Type 3: Maximum Prefix Length, 1 octet of data, the maximum 1048 length of any prefix allowed within this block of prefixes. 1050 5.1.7 Signature 1052 0 1 2 3 1053 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1054 +-------------------------------+-------------------------------+ 1055 | TLV Type | Length | 1056 +-------------------------------+-------------------------------+ 1057 | Signature Type | Number of Issuers | 1058 +-------------------------------+-------------------------------+ 1059 | Entity Certificate Issuer Autonomous System | 1060 +-------------------------------+-------------------------------+ 1061 | Entity Certificate Serial Number | 1062 +-------------------------------+-------------------------------+ 1063 | ... | 1064 +---------------------------------------------------------------+ 1065 | Signature | 1066 +------------------ 1068 o TLV type: 65535 (0xFFFF) 1070 o Length: (2 octets), unsigned integer denoting the length of the 1071 payload bytes which follow. 1073 o Signature Type: (2 octets), unsigned integer denoting the type 1074 of signature (the algorithm used to build this signature). Each 1075 possible signing algorithm is assigned an integer from this 1076 field. Signature type 1 is defined as an RSA encryption of a 1077 SHA1 digest. 1079 Secure Origin BGP (soBGP) Certificates October, 2003 1081 o Number of Issuers (2 octets): The number of Entitycert 1082 references included in the signature payload. If more than one 1083 Entitycert reference follows, all Entitycerts MUST contain the 1084 same public key for the same authorizing autonomous system. 1086 o Entity Certificate Issuer Autonomous System: (4 octets), the 1087 autonomous system of the entity that provided the Entitycert to 1088 the AS issuing the PrefixPolicycert. AS numbers containing only 1089 two octets should be placed in the least significant octets of 1090 this four-octet field (the two rightmost octets). 1092 o Entity Certificate Serial Number: (4 octets), the Entitycert 1093 serial number containing the public key of the AS issuing the 1094 PrefixPolicycert. 1096 o Signature: The signature itself. 1098 The signature is calculated using the private key of the authorizing 1099 entity across all the TLVs within the PrefixPolicycert. The 1100 Signature TLV MUST be appended as the last TLV in the 1101 PrefixPolicycert after the signature has been computed. 1103 5.2 Creation 1105 An PrefixPolicycert is created by an autonomous system for prefix 1106 blocks that it owns. An autonomous system creates it with the 1107 following steps: 1109 - Build an PrefixPolicycert by adding TLVs containing its own AS 1110 number, a unique sequence number, policy related to one or more 1111 prefix blocks, and the Authcert or Authcerts defining the prefix 1112 blocks to which this policy applies. 1113 - Sign the PrefixPolicycert by hashing and encrypting the 1114 PrefixPolicycert TLVs. Place the signature (and other required) 1115 information in a Signature TLV, and append it to the 1116 PrefixPolicycert. 1118 5.2.1 Certificate Uniqueness 1120 Digital certificates are created as uniquely named objects, which 1121 allows them to be uniquely identified. A PrefixPolicycert is 1122 uniquely identified by the pair of Authorized Originator and Serial 1123 Number TLV values. 1125 5.2.2 Certificate Encoding 1127 PrefixPolicycert distributed in [SOBGP-BGP] are distributed in TLV 1128 form. However if they are manually distributed (e.g., through 1129 electronic mail) they may need to be encoded into ASCII. 1130 PrefixPolicycert SHOULD be base64 encoded as described in Section 1131 4.3 of [RFC1421]. 1133 Secure Origin BGP (soBGP) Certificates October, 2003 1135 5.3 Distribution 1137 PrefixPolicycerts may be distributed using any number of methods, 1138 for example: 1140 - maintained in a directory maintained by the issuing autonomous 1141 system, 1142 - distributed via some out of band mechanism, or 1143 - distributed within BGP using extensions defined in [SOBGP-BGP]. 1145 To ensure interoperability, an autonomous system SHOULD distribute 1146 its PrefixPolicycerts within BGP. 1148 5.4 Validation 1150 The Authcert included in the Authcert TLV MUST be validated as 1151 correct before the Policy TLV can be accepted. Thus, the Authcert 1152 should be extracted from the PrefixPolicycert and validated before 1153 the PrefixPolicycert is validated. 1155 The PrefixPolicycert is validated using the following steps. 1157 - Identify the Entitycert that signed the PrefixPolicycert. The 1158 correct Entitycert is uniquely identified with the Entity 1159 Certificate Issuer Autonomous System and Entity Certificate Serial 1160 Number contained in the Signature TLV. The Entity Certificate 1161 Issuer Autonomous System is compared with the AS number in the 1162 Entitycert IssuerAltName field. The Entity Certificate Serial 1163 Number is compared with the Entitycert CertificateSerialNumber. 1164 - Obtain the Entitycert that signed the Authcert, and validate it. 1165 The Entitycert may be in a local cache (already received via BGP 1166 extensions), retrieved using the URL in the Authcert, or through 1167 other means. If an entity does not have the validating public key 1168 it MUST NOT assume the PrefixPolicycert is valid. 1169 - Verify that the autonomous system identifier in SubjectAltname 1170 matches the Authorized Originator TLV value of the 1171 PrefixPolicycert. 1172 - Hash the PrefixPolicycert TLVs. 1173 - Extract the signature from the PrefixPolicycert. 1174 - Extract the public key from the Entitycert, and use it to decrypt 1175 the signature. 1176 - Validate that the computed hash matches the decrypted hash. If the 1177 hashes do not match, the PrefixPolicycert MUST be discarded. 1179 Once a PrefixPolicycert has been validated, any PrefixPolicycert 1180 that matches the following criteria MUST be discarded: 1181 - has a lower serial number from the same originating AS, and 1182 - includes an Authcert with the same prefix block 1184 5.5 Revocation 1185 Secure Origin BGP (soBGP) Certificates October, 2003 1187 Any entity issuing an PrefixPolicycert MUST keep a revocation list. 1188 The entity MAY use any form for propagating that revocation list. 1190 Because BGP routers do not necessarily have synchronized clocks, 1191 PrefixPolicycert do not carry expiration times, and thus do not 1192 expire. Revocation is only method of invalidating an 1193 PrefixPolicycert. 1195 Revocation information may be represented as a "validation list". A 1196 validation list includes lists of both valid and invalid (i.e., 1197 revoked) certificates. Any number not appearing in the list MUST be 1198 considered invalid. Validation list may be more efficient than a 1199 pure revocation list for PrefixPolicycerts in the case where a large 1200 number of serial numbers have been revoked by an issuer. 1202 An autonomous system SHOULD include an PrefixPolicycert validation 1203 list in their AS Policy Certificate (distributed using [SOBGP-BGP]). 1204 This allows autonomous systems that cannot route to the issuing 1205 autonomous system to verify that the Entitycert has not been 1206 revoked. 1208 6.0 AS Policy Certificates (ASPolicycert) 1210 The ASPolicycert provides a specific set of policy relating to an 1211 autonomous system. An administrative entity within the autonomous 1212 system creates it. There is only one valid ASPolicycert for each 1213 autonomous system at any given time. 1215 ASPolicycerts are verified with a digital signature from the 1216 autonomous system generating the policy. It does not contain a 1217 public key. Rather, it binds a particular policy to a particular 1218 identity (i.e., autonomous system). 1220 6.1 Format 1222 This certificate is formatted as a series of TLVs. Each TLV will 1223 include a type, which is treated as a 16 bit (two octet) unsigned 1224 integer, a length, which is also two octets, and a variable length 1225 data field. TLVs MUST be placed in the ASPolicycert in type order. 1227 6.1.1 ASPolicycert Header 1229 0 1 2 3 1230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1231 +---------------+---------------+-------------------------------+ 1232 | Cert. Marker | Type Id | Length | 1233 +---------------+---------------+-------------------------------+ 1234 | TLVs 1235 +---------------- 1237 o Certificate Marker: "162(0xa2), identifying this as an soBGP 1238 certificate. 1240 Secure Origin BGP (soBGP) Certificates October, 2003 1242 o Type ID: "3(0x03), identifying this as an ASPolicycert. 1244 o Length: Set to the length of the TLVs. 1246 o TLVs: The Type/Length/Value attributes making up an 1247 ASPolicycert. 1249 6.1.2 The Originating Autonomous System 1251 0 1 2 3 1252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1253 +-------------------------------+-------------------------------+ 1254 | TLV Type | Length | 1255 +-------------------------------+-------------------------------+ 1256 | Originating Autonomous System | 1257 +---------------------------------------------------------------+ 1259 o TLV type: 1 (0x0001) 1261 o Length: Set to 4. 1263 o Originating Autonomous System: (4 octets), the autonomous 1264 system which originated this certificate. AS numbers containing 1265 only two octets should be placed in the least significant 1266 octets of this four-octet field (the two rightmost octets). 1268 6.1.3 The Serial Number 1270 0 1 2 3 1271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1272 +-------------------------------+-------------------------------+ 1273 | TLV Type | Length | 1274 +-------------------------------+-------------------------------+ 1275 | Serial Number | 1276 +---------------------------------------------------------------+ 1278 o TLV type: 2 (0x0002) 1280 o Length: Set to 4. 1282 o Serial Number: (4 octets), A serial number which identifies 1283 this ASPolicycert, taken from a 32 bit number space. 1285 6.1.4 Authorizing AS Entitycert Uniform Resource Locator 1286 Secure Origin BGP (soBGP) Certificates October, 2003 1288 0 1 2 3 1289 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1290 +-------------------------------+-------------------------------+ 1291 | TLV Type | Length | 1292 +-------------------------------+-------------------------------+ 1293 | URL | 1294 +---------------- 1296 o TLV type: 3 (0x0003) 1298 o Length: Denotes the length of the URL in octets. 1300 o URL: A uniform resource locator indicating a location where the 1301 Authorizing AS?s Entitycert can be found. 1303 An PrefixPolicycert may omit this TLV. However, an implementation is 1304 REQUIRED to correctly parse them if they are present. A receiving 1305 device MAY choose to ignore the URL TLV. 1307 6.1.5 Attached Transit Autonomous Systems 1309 0 1 2 3 1310 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1311 +-------------------------------+-------------------------------+ 1312 | TLV Type | Length | 1313 +-------------------------------+---------------+---------------+ 1314 | Address Family Identifier | RESERVED | Subsequent AFI | 1315 +-------------------------------+---------------+---------------+ 1316 | Autonomous Systems | 1317 +----------------- 1319 o TLV type: 4 (0x0004) 1321 o Length: Set to 4 + 4 octets for each autonomous system in the 1322 list. 1324 o Address Family Identifier: This field carries the identity a 1325 the Network Layer protocol. Presently defined values for this 1326 field are specified in RFC 1700 (see the Address Family Numbers 1327 section). 1329 o RESERVED: Set to 0. 1331 o Subsequent AFI: This field provides additional information 1332 about the type of the Network Layer protocol. 1334 o Autonomous Systems: List of autonomous systems which are 1335 connected to the originating autonomous system through some 1336 form of peering arrangement and which may transit traffic from 1337 the origin AS. Each AS number takes four octets. AS number 1338 values containing only two octets should be placed in the least 1339 Secure Origin BGP (soBGP) Certificates October, 2003 1341 significant octets of this four-octet field (the two rightmost 1342 octets). 1344 One or more Attached Transit AS TLVs may be included in the Policy 1345 Certificate. Each type 4 TLV indicates an AS which is connected to 1346 the AS which originates this ASPolicycert through a BGP peering 1347 relationship. 1349 6.1.6 Attached Non-transit Autonomous Systems 1351 0 1 2 3 1352 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1353 +-------------------------------+-------------------------------+ 1354 | TLV Type | Length | 1355 +-------------------------------+---------------+---------------+ 1356 | Address Family Identifier | RESERVED | Subsequent AFI| 1357 +-------------------------------+---------------+---------------+ 1358 | Autonomous Systems | 1359 +------------------ 1361 o TLV type: 5 (0x0005) 1363 o Length: Set to 4 + 4 octets for each autonomous system in the 1364 list. 1366 o Address Family Identifier: This field carries the identity a 1367 the Network Layer protocol. Presently defined values for this 1368 field are specified in RFC 1700 (see the Address Family Numbers 1369 section). 1371 o RESERVED: Set to 0. 1373 o Subsequent AFI: This field provides additional information 1374 about the type of the Network Layer protocol. 1376 o Autonomous Systems: List of autonomous systems which are 1377 connected to the originating autonomous system through some 1378 form of peering arrangement and which may not transit traffic 1379 from the origin AS. Each AS number takes four octets. AS number 1380 values containing only two octets should be placed in the least 1381 significant octets of this four-octet field (the two rightmost 1382 octets). 1384 One or more Attached Non-Transit AS TLVs may be included in the 1385 ASPolicycert. Each type 5 TLV indicates an AS which is connected to 1386 the AS which originates this ASPolicycert through a BGP peering 1387 relationship. 1389 6.1.7 Revoked Entity Certificate List 1390 Secure Origin BGP (soBGP) Certificates October, 2003 1392 0 1 2 3 1393 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1394 +-------------------------------+-------------------------------+ 1395 | TLV Type | Length | 1396 +-------------------------------+-------------------------------+ 1397 | Entity Certificate Revocation List 1398 +---------------- 1400 o TLV type: 6 (0x0006) 1402 o Length: (2 octets), length of TLV data (the list of revoked 1403 Entity Certificates) in octets 1405 o Entity Certificate Revocation List: A revocation list created 1406 by the autonomous system, which includes a list of revoked 1407 Entity Certificates issued by this autonomous system. The 1408 format of the revocation list MUST be as defined in [RFC3280]. 1410 A single Revoked Entity Certificate List TLV MAY be included in an 1411 ASPolicycert, or it may be omitted. 1413 When an Entity Certificate Revocation List is received, all 1414 currently held Entitycerts from this issuer MUST be checked against 1415 the validity list. Entitycerts found to be invalid MUST be deleted. 1417 6.1.8 Authorization Certificate Validity List 1419 0 1 2 3 1420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1421 +-------------------------------+-------------------------------+ 1422 | TLV Type | Length | 1423 +-------------------------------+-------------------------------+ 1424 | Validity Ranges 1425 +---------------- 1427 o TLV type: 7 (0x0007) 1429 o Length: (2 octets), length of TLV data (the list of revoked 1430 Authorization Certificates) in octets 1432 o Validity Ranges: A list of validity subTVs defining which 1433 serial numbers are valid and invalid. Validity ranges are 1434 interpreted in order until a match is found. For more 1435 information on validity lists, see Section 4.5. 1437 A single TLV of this type MAY be included in an ASPolicycert, or it 1438 may be omitted. 1440 When an Authorization Certificate Validity List is received, all 1441 currently held Authcerts from this issuer MUST be checked against 1442 the validity list. Authcerts found to be invalid MUST be deleted. 1444 Secure Origin BGP (soBGP) Certificates October, 2003 1446 6.1.8.1 Validity Ranges 1448 0 1 2 3 1449 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1450 +-------------------------------+-------------------------------+ 1451 | subTV Type | Size of Range | 1452 +-------------------------------+-------------------------------+ 1453 | Lowest Authorization Serial Number | 1454 +---------------------------------------------------------------+ 1456 o subTV type: (2 octets). 1458 SubTV type Value 1459 ---------- ----- 1460 VALID 0 1461 INVALID 1 1463 o Size of Range: (2 octets). Number of contiguous serial numbers 1464 defining a range. 1466 o Lowest Authorization Serial Number (4 octets). The lowest value 1467 in the range. 1469 6.1.9 Prefix Policy Certificate Validity List 1471 0 1 2 3 1472 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1473 +-------------------------------+-------------------------------+ 1474 | TLV Type | Length | 1475 +-------------------------------+-------------------------------+ 1476 | Validity Ranges 1477 +---------------- 1479 o TLV type: 8 (0x0008) 1481 o Length: (2 octets), length of TLV data (the list of revoked 1482 Authorization Certificates) in octets 1484 o Validity Ranges: A list of validity subTVs (as defined in the 1485 previous section) defining which PrefixPolicycert serial 1486 numbers are valid and invalid. Validity ranges are interpreted 1487 in order until a match is found.. For more information on 1488 validity lists, see Section 5.5. 1490 A single TLV of this type MAY be included in an ASPolicycert, or it 1491 may be omitted. 1493 When an Prefix Policy Validity List is received, all currently held 1494 PrefixPolicycerts from this issuer MUST be checked against the 1495 validity list. PrefixPolicycerts found to be invalid MUST be 1496 deleted. 1498 Secure Origin BGP (soBGP) Certificates October, 2003 1500 6.1.10 Most Recent AS Policy Certificate Uniform Resource Locator 1502 0 1 2 3 1503 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1504 +-------------------------------+-------------------------------+ 1505 | TLV Type | Length | 1506 +-------------------------------+-------------------------------+ 1507 | URL | 1508 +---------------- 1510 o TLV type: 9 (0x0009) 1512 o Length: Denotes the length of the URL in octets. 1514 o URL: A uniform resource locator indicating a location where the 1515 most recent AS Policy Certificate can be found. This is useful 1516 for a receiver to verify that they have the most recent AS 1517 Policy Certificate for an AS. 1519 An PrefixPolicycert may omit this TLV. However, an implementation is 1520 REQUIRED to correctly parse them if they are present. A receiving 1521 device MAY choose to ignore the URL TLV. 1523 6.1.11 Signature 1525 0 1 2 3 1526 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1527 +-------------------------------+-------------------------------+ 1528 | TLV Type | Length | 1529 +-------------------------------+-------------------------------+ 1530 | Signature Type | Number of Issuers | 1531 +-------------------------------+-------------------------------+ 1532 | Entity Certificate Issuer Autonomous System | 1533 +-------------------------------+-------------------------------+ 1534 | Entity Certificate Serial Number | 1535 +-------------------------------+-------------------------------+ 1536 | ... | 1537 +---------------------------------------------------------------+ 1538 | Signature | 1539 +------------------ 1541 o TLV type: 65535 (0xFFFF) 1543 o Length: (2 octets), unsigned integer denoting the length of the 1544 payload bytes which follow. 1546 o Signature Type: (2 octets), unsigned integer denoting the type 1547 of signature (the algorithm used to build this signature). Each 1548 possible signing algorithm is assigned an integer from this 1549 Secure Origin BGP (soBGP) Certificates October, 2003 1551 field. Signature type 1 is defined as an RSA encryption of a 1552 SHA1 digest. 1554 o Number of Issuers (2 octets): The number of Entitycert 1555 references included in the signature payload. If more than one 1556 Entitycert reference follows, all Entitycerts MUST contain the 1557 same public key for the same authorizing autonomous system. 1559 o Entity Certificate Issuer Autonomous System: (4 octets), the 1560 autonomous system of the entity that provided the Entitycert to 1561 the AS issuing the PrefixPolicycert. AS numbers containing only 1562 two octets should be placed in the least significant octets of 1563 this four-octet field (the two rightmost octets). 1565 o Entity Certificate Serial Number: (4 octets), the Entitycert 1566 serial number containing the public key of the AS issuing the 1567 PrefixPolicycert. 1569 o Signature: The signature itself. 1571 The signature is calculated using the private key of the authorizing 1572 entity across all the TLVs within the ASPolicycert. The Signature 1573 TLV MUST be appended as the last TLV in the ASPolicycert after the 1574 signature has been computed. 1576 6.2 Creation 1578 An ASPolicycert is created by an autonomous system in order to relay 1579 its own policy. An autonomous system creates it with the following 1580 steps: 1582 - Build an ASPolicycert by adding TLVs containing its own AS number, 1583 a unique sequence number, and policy related to the autonomous 1584 system. 1585 - Sign the ASPolicycert by hashing and encrypting the ASPolicycert 1586 TLVs. Place the signature (and other required) information in a 1587 Signature TLV, and append it to the ASPolicycert. 1589 6.2.1 Certificate Uniqueness 1591 Digital certificates are created as uniquely named objects, which 1592 allows them to be uniquely identified. An ASPolicycert is uniquely 1593 identified by the pair of Authorized Originator and Serial Number 1594 TLV values. 1596 6.2.2 Certificate Encoding 1598 ASPolicycert distributed in [SOBGP-BGP] are distributed in TLV form. 1599 However if they are manually distributed (e.g., through electronic 1600 mail) they may need to be encoded into ASCII. ASPolicycert SHOULD be 1601 base64 encoded following Section 4.3 of [RFC1421]. 1603 Secure Origin BGP (soBGP) Certificates October, 2003 1605 6.3 Distribution 1607 ASPolicycert may be distributed using any number of methods, for 1608 example: 1610 - maintained in a directory maintained by the issuing autonomous 1611 system, 1612 - distributed via some out of band mechanism, or 1613 - distributed within BGP using extensions defined in [SOBGP-BGP]. 1615 To ensure interoperability, an autonomous system SHOULD distribute 1616 its ASPolicycert within BGP. 1618 6.4 Validation 1620 The ASPolicycert is validated using the following steps. 1622 - Identify the Entitycert that signed the ASPolicycert. The correct 1623 Entitycert is uniquely identified with the Entity Certificate 1624 Issuer Autonomous System and Entity Certificate Serial Number 1625 contained in the Signature TLV. The Entity Certificate Issuer 1626 Autonomous System is compared with the AS number in the Entitycert 1627 IssuerAltName field. The Entity Certificate Serial Number is 1628 compared with the Entitycert CertificateSerialNumber. 1629 - Obtain the Entitycert that signed the ASPolicycert, and validate 1630 it. The Entitycert may be in a local cache (already received via 1631 BGP extensions), retrieved using the URL in the Authcert, or 1632 through other means. If an entity does not have the validating 1633 public key it MUST NOT assume the ASPolicycert is valid. 1634 - Verify that the autonomous system identifier in SubjectAltname 1635 matches the Authorized Originator TLV value of the ASPolicycert. 1636 - Hash the ASPolicycert TLVs. 1637 - Extract the signature from the ASPolicycert. 1638 - Extract the public key from the Entitycert, and use it to decrypt 1639 the signature. 1640 - Validate that the computed hash matches the decrypted hash. If the 1641 hashes do not match, the ASPolicycert MUST be discarded. 1643 Once an ASPolicycert has been validated, any ASPolicycert with a 1644 lower serial number from the same originating AS MUST be discarded. 1646 6.5 Revocation 1648 Each ASPolicycert issued by an autonomous system overrides any 1649 previously issued ASPolicycerts from this autonomous system. 1650 Therefore, revocation is not required. 1652 Secure Origin BGP (soBGP) Certificates October, 2003 1654 If present, a receiver has the opportunity of using the Most Recent 1655 AS Policy Certificate URL in the ASPolicycert to verify that they 1656 have the most recent policy certificate. 1658 7.0 Security Considerations 1660 This document describes the format of authentication, authorization, 1661 and policy certificates used to with [SOBGP-BGP]. Each certificate 1662 type is digitally signed, and therefore requires no external 1663 protection to ensure its integrity. There are no restrictions on how 1664 they may be distributed. Revocation schemes are defined for all 1665 certificate types. 1667 The following sections describe the security considerations of each 1668 of those objects. 1670 7.1 Entitycerts 1672 Entitycerts provide authentication, providing a binding of an 1673 identity (i.e., autonomous system number) to a public key. The 1674 authenticity of the binding is verified with a digital signature, 1675 where the public key of the certificate issuer has been previously 1676 accepted as valid. Issuer public keys can either be manually 1677 configured, or are verified through the use of another issuer's 1678 trusted public key in a "web of trust" built by the receiver. 1680 Certificate issuers MUST maintain certificate revocation lists 1681 (CRLs). Entities verifying Entitycerts SHOULD reference the 1682 certificate revocation lists whenever possible. (Mandating the 1683 consultation of a CRL as part of the verification process is not 1684 possible, because the CRL may not be available at the time 1685 verification is performed. For example, if the issuer maintains the 1686 CRL on a directory server to which routing is not yet setup.) 1687 Issuers SHOULD distribute their CRLs within their AS Policy 1688 Certificates to increase the likelihood of a receiver having the CRL 1689 available. 1691 Self-signed Entitycerts may be necessary in order to start a chain 1692 of trust. However self-signed Entitycerts MUST be manually validated 1693 as accurate before the enclosed public key is used, else the "web of 1694 trust" breaks down. 1696 7.2 Authcerts 1698 Authcerts provide authorization, where the issuer of a prefix block 1699 certifies that it has given that prefix block to a specific 1700 autonomous system. Receivers use the Authcert to validate 1701 announcements received in BGP UPDATE messages. 1703 The authenticity of Authcerts is verified with a digital signature, 1704 where the public key of the certificate issuer is distributed in an 1705 Entitycert. Before a receiver can verify the Authcert, they MUST 1706 first check that the verifying Entitycert is authentic. 1708 Secure Origin BGP (soBGP) Certificates October, 2003 1710 The Authcert issuer MUST keep an Authcert validation list describing 1711 which certificates are valid, and which are invalid. The receivers 1712 of an Authcert SHOULD consult the Authcert validation list to ensure 1713 that the authorization has not been revoked. 1715 Autonomous systems may need to authorize their own use of prefix 1716 blocks if the autonomous system that issued their prefix blocks does 1717 not issue them an Authcert. However, such self-generated Authcerts 1718 are dangerous, since unrestricted use of self-signed Authcerts 1719 defeats the goal of authorization. Thus an entity MUST accept self- 1720 generated Authcerts only from autonomous systems that have been 1721 explicitly configured as trusted to claim authorization without the 1722 confirmation of a third party. 1724 7.3 PrefixPolicycerts 1726 PrefixPolicycerts bind policy generated by an autonomous system for 1727 prefix blocks that they advertise. This policy is bound to a 1728 particular Authcert, which verifies that they are authorized to 1729 advertise those prefix blocks. 1731 PrefixPolicycerts are verified with a digital signature, where the 1732 public key of the certificate issuer is distributed in an 1733 Entitycert. Before a receiver can verify the PrefixPolicycert, they 1734 MUST first verify that the verifying Entitycert is authentic. 1736 7.4 ASPolicycerts 1738 ASPolicycerts contain policy generated by an autonomous system, and 1739 contain policy about the autonomous system itself. The policy 1740 includes its neighbor autonomous systems, which can be used by other 1741 entities to validate valid inter-connections. The policy can also 1742 include revocation and validation lists (Authcert, 1743 PrefixPolicycert). 1745 ASPolicycerts are verified with a digital signature, where the 1746 public key of the certificate issuer is distributed in an 1747 Entitycert. Before a receiver can verify the ASPolicycerts, they 1748 MUST first verify that the verifying Entitycert is authentic. 1750 7.5 Entitycert Uniform Resource Locators 1752 Authcerts, PrefixPolicycerts, and ASPolicycerts may contain a URL 1753 that references the Entitycert used to validate it. Care should be 1754 taken in evaluating the URL since it is not yet known to be valid 1755 and could be used to propagate a denial of service attack. 1757 8.0 IANA Considerations 1759 This document defines three certificate types, each of which contains 1760 a series of TLVs. IANA is expected to maintain a registry of all the 1761 values defined, according to the following sections. 1763 Secure Origin BGP (soBGP) Certificates October, 2003 1765 8.1 Authorization Certificate 1767 The Authorization Certificate Type Field: 1769 o Type values 1 through 4, 14 and 65535 are assigned in this 1770 document. 1772 o Type values 5 through 13 and 15 through 16575 MUST be assigned 1773 using the "IETF Consensus" policy defined in RFC 2434 1774 [RFC2434]. 1776 o Type values 16576 through 32895 SHOULD be assigned using the 1777 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1779 o Type values 32896 through 65534 are for "Private Use" as defined 1780 in RFC 2434 [RFC2434]. 1782 8.1.1 Signature Type 1784 The Signature TLV Signature Type field: 1786 o Type values 1 is assigned in this document. 1788 o Type values 2 through 16575 MUST be assigned using the "IETF 1789 Consensus" policy defined in RFC 2434 [RFC2434]. 1791 o Type values 16576 through 32895 SHOULD be assigned using the 1792 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1794 o Type values 32896 through 65534 are for "Private Use" as defined 1795 in RFC 2434 [RFC2434]. 1797 8.2 Prefix Policy Certificate 1799 o Type values 1 through 5, 14 and 65535 are assigned in this 1800 document. 1802 o Type values 6 through 13 and 15 through 16575 MUST be assigned 1803 using the "IETF Consensus" policy defined in RFC 2434 1804 [RFC2434]. 1806 o Type values 16576 through 32895 SHOULD be assigned using the 1807 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1809 o Type values 32896 through 65534 are for "Private Use" as defined 1810 in RFC 2434 [RFC2434]. 1812 8.2.1 Policies Type 1813 Secure Origin BGP (soBGP) Certificates October, 2003 1815 The Policies Type has two name spaces: Options flags and SubTVs. 1817 The Options Field: 1819 o Bits 0 and 1 are assigned in this document. 1821 o Bits 2 thru 7 MUST be assigned using the "IETF Consensus" 1822 policy defined in RFC 2434 [RFC2434]. 1824 o Bits 8 thru 15 are for "Private Use" as defined in RFC 2434 1825 [RFC2434]. 1827 The subTV TV Type field: 1828 o TV Type values 1 through 3 are assigned in this document. 1830 o TV Type values 4 through 16575 MUST be assigned using the "IETF 1831 Consensus" policy defined in RFC 2434 [RFC2434]. 1833 o TV Type values 16576 through 32895 SHOULD be assigned using the 1834 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1836 o TV Type values 32896 through 65534 are for "Private Use" as 1837 defined in RFC 2434 [RFC2434]. 1839 8.2.2 Signature Type 1841 The Signature TLV Signature Type field: 1843 o Type values 1 is assigned in this document. 1845 o Type values 2 through 16575 MUST be assigned using the "IETF 1846 Consensus" policy defined in RFC 2434 [RFC2434]. 1848 o Type values 16576 through 32895 SHOULD be assigned using the 1849 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1851 o Type values 32896 through 65534 are for "Private Use" as defined 1852 in RFC 2434 [RFC2434]. 1854 8.3 AS Policy Certificate 1856 o Type values 1 through 9, 14 and 65535 are assigned in this 1857 document. 1859 o Type values 10 through 16575 MUST be assigned using the "IETF 1860 Consensus" policy defined in RFC 2434 [RFC2434]. 1862 o Type values 16576 through 32895 SHOULD be assigned using the 1863 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1865 o Type values 32896 through 65534 are for "Private Use" as defined 1866 in RFC 2434 [RFC2434]. 1868 Secure Origin BGP (soBGP) Certificates October, 2003 1870 8.3.1 Validity Ranges 1872 o Type values 1 through 2 are assigned in this document. 1874 o Type values 3 through 16575 MUST be assigned using the "IETF 1875 Consensus" policy defined in RFC 2434 [RFC2434]. 1877 o Type values 16576 through 32895 SHOULD be assigned using the 1878 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1880 o Type values 32896 through 65534 are for "Private Use" as defined 1881 in RFC 2434 [RFC2434]. 1883 8.3.2 Signature Type 1885 The Signature TLV Signature Type field: 1887 o Type values 1 is assigned in this document. 1889 o Type values 2 through 16575 MUST be assigned using the "IETF 1890 Consensus" policy defined in RFC 2434 [RFC2434]. 1892 o Type values 16576 through 32895 SHOULD be assigned using the 1893 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1895 o Type values 32896 through 65534 are for "Private Use" as defined 1896 in RFC 2434 [RFC2434]. 1898 9.0 Acknowledgments 1900 A large number of people contributed to or provided valuable feedback 1901 on this document; we've tried to include all of them here (in no 1902 particular order), but might have missed a few: James Ng, Russ White, 1903 Alvaro Retana, Dave Cook, John Scudder, David Ward, Martin Djernaes, 1904 Max Pritikin, Chris Lonvick, Tim Gage, Scott Fanning, Barry Friedman, 1905 Jim Duncan, Yi Yang, Robert Adams, Tony Tauber, Iljitsch van Beijnum, 1906 Ed Lewis, and Jonathan Natale. 1908 10.0 References 1910 10.1 Normative References 1912 [ADDR-EXT] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP 1913 Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn- 1914 03.txt, September 2003. 1916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1917 Requirement Level", BCP 14, RFC 2119, March 1997. 1919 Secure Origin BGP (soBGP) Certificates October, 2003 1921 [RFC2434] Narten, T., and H. Alvestrand,, "Guidelines for Writing an 1922 IANA Considerations Section in RFCs", RFC 2434, October 1998. 1924 [RFC2858] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1925 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 1927 [RFC3279] Polk, T., et. al., " Algorithms and Identifiers for the 1928 Internet X.509 Public Key Infrastructure Certificate and Certificate 1929 Revocation List (CRL) Profile", RFC 3279, April 2002. 1931 [RFC3280] Housley, R., et. al., "Internet X.509 Public Key 1932 Infrastructure Certificate and CRL Profile", RFC 3280, April 2002. 1934 [SOBGP-BGP] Ng, J. (editor), "Extensions to BGP to Support Secure 1935 Origin BGP (soBGP)", draft-ng-sobgp-extensions-01.txt, June 2003. 1937 [SOBGP-DEPLOY] White, R. (editor), ?Deployment Considerations for 1938 Secure Origin BGP (soBGP)?, draft-white-sobgp-bgp-deployment-01.txt, 1939 June 2003. 1941 [SOBGP-RADIUS] Lonvick, C., ?RADIUS Attributes for soBGP Support?, 1942 draft-lonvick-sobgp-radius-03.txt, August 19, 2003. 1944 [X.690] International Telecommunication Union, "ITU-T Recommendation 1945 X.660 Information Technology - ASN.1 encoding rules: Specification 1946 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and 1947 Distinguished Encoding Rules (DER), 1997. 1949 10.2 Informative References 1951 [IAB-SC] Rescorla, E., B. Korver, and the Internet Architecture 1952 Board, "Guidelines for Writing RFC Text on Security Considerations", 1953 http://www.ietf.org/internet-drafts/draft-iab-sec-cons-03.txt, Work 1954 in progress, 2003. 1956 [RFC3281] Farrell, S., and R. Housley, " An Internet Attribute 1957 Certificate Profile for Authorization", RFC 3281, April 2002. 1959 Editor's Address 1961 Brian Weis 1962 Cisco Systems 1963 170 W. Tasman Drive, 1964 San Jose, CA 95134-1706, USA 1965 (408) 526-4796 1966 bew@cisco.com