idnits 2.17.1 draft-ietf-pkix-x509-ipaddr-as-extn-03.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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 16 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 2003) is 7501 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) == Missing Reference: 'RFC791' is mentioned on line 157, but not defined -- Looks like a reference, but probably isn't: '0' on line 828 -- Looks like a reference, but probably isn't: '1' on line 829 == Unused Reference: 'RFC3279' is defined on line 1134, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AFI' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 1142 (Obsoleted by RFC 7142) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 2050 (Obsoleted by RFC 7020) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Charles Lynn 2 Internet Draft Stephen Kent 3 draft-ietf-pkix-x509-ipaddr-as-extn-03.txt Karen Seo 4 Expires March 2004 BBN Technologies 5 September 2003 7 X.509 Extensions for IP Addresses and AS Identifiers 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]. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society 2003. All Rights Reserved. 32 Abstract 34 This document defines two X.509 v3 certificate extensions. The first 35 binds a list of IP address blocks, or prefixes, to the subject of a 36 certificate. The second binds a list of autonomous system 37 identifiers to the subject of a certificate. These extensions may be 38 used to convey the authorization of the subject to use the IP 39 addresses and autonomous system identifiers contained in the 40 extensions. 42 Please send comments on this draft to the ietf-pkix@imc.org mail 43 list. 45 Table of Contents 47 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 48 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 49 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. IP Address Delegation Extension . . . . . . . . . . . . . . . 6 55 2.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1.1. Encoding of an IP Address or Prefix . . . . . . . . . . . 6 57 2.1.2. Encoding of a Range of IP Addresses . . . . . . . . . . . 8 58 2.2. Specification . . . . . . . . . . . . . . . . . . . . . . . 9 59 2.2.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 2.2.2. Criticality . . . . . . . . . . . . . . . . . . . . . . . 9 61 2.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 2.2.3.1. Type IPAddrBlocks . . . . . . . . . . . . . . . . . . . 10 63 2.2.3.2. Type IPAddressFamily . . . . . . . . . . . . . . . . . . 10 64 2.2.3.3. Element addressFamily . . . . . . . . . . . . . . . . . 10 65 2.2.3.4. Element ipAddressChoice and Type IPAddressChoice . . . . 11 66 2.2.3.5. Element inherit . . . . . . . . . . . . . . . . . . . . 11 67 2.2.3.6. Element addressesOrRanges . . . . . . . . . . . . . . . 11 68 2.2.3.7. Type IPAddressOrRange . . . . . . . . . . . . . . . . . 12 69 2.2.3.8. Element addressPrefix and Type IPAddress . . . . . . . . 12 70 2.2.3.9. Element addressRange and Type IPAddressRange . . . . . . 12 71 2.3. IP Address Delegation Extension Certification Path 72 Validation . . 13 74 3. Autonomous System Identifier Delegation Extension . . . . . . 13 75 3.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 3.2. Specification . . . . . . . . . . . . . . . . . . . . . . . 14 77 3.2.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 3.2.2. Criticality . . . . . . . . . . . . . . . . . . . . . . . 14 79 3.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 3.2.3.1. Type ASIdentifiers . . . . . . . . . . . . . . . . . . . 15 81 3.2.3.2. Elements asnum, rdi, and Type ASIdentifierChoice . . . . 15 82 3.2.3.3. Element inherit . . . . . . . . . . . . . . . . . . . . 15 83 3.2.3.4. Element asIdOrRanges . . . . . . . . . . . . . . . . . . 16 84 3.2.3.5. Type ASIdOrRange . . . . . . . . . . . . . . . . . . . . 16 85 3.2.3.6. Element id . . . . . . . . . . . . . . . . . . . . . . . 16 86 3.2.3.7. Element range . . . . . . . . . . . . . . . . . . . . . 16 87 3.2.3.8. Type ASRange . . . . . . . . . . . . . . . . . . . . . . 16 88 3.2.3.9. Elements min and max . . . . . . . . . . . . . . . . . . 16 89 3.2.3.10. Type ASId . . . . . . . . . . . . . . . . . . . . . . . 16 90 3.3. Autonomous System Identifier Delegation Extension 91 Certification Path Validation . . 16 93 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 98 Appendix A -- ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 100 Appendix B -- Examples of IP Address Delegation Extensions . . . . 20 102 Appendix C -- Example of an AS Identifier Delegation Extension . . 23 104 Appendix D -- Use of X.509 Attribute Certificates . . . . . . . . 24 106 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 Normative References . . . . . . . . . . . . . . . . . . . . . . . 27 108 Informational References . . . . . . . . . . . . . . . . . . . . . 27 110 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 112 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 Intellectual Property Statement . . . . . . . . . . . . . . . . . 29 116 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 29 118 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . 30 120 1. Introduction 122 This document defines two X.509 v3 certificate extensions that 123 authorize the transfer of the right to use IP addresses and 124 autonomous system identifiers from IANA through the regional Internet 125 registries (RIRs) to Internet service providers (ISPs) and user 126 organizations. The first binds a list of IP address blocks, often 127 represented as IP address prefixes, to the subject (private key 128 holder) of a certificate. The second binds a list of autonomous 129 system (AS) identifiers to the subject (private key holder) of a 130 certificate. The issuer of the certificate is an entity (e.g., the 131 IANA, a regional Internet registry, or an ISP) that has the authority 132 to transfer custodianship ("allocate") of the set of IP address 133 blocks and AS identifiers to the subject of the certificate. These 134 certificates provide a scalable means of verifying the usage right of 135 IP address prefixes and AS identifiers, and may be used by routing 136 protocols, such as Secure BGP [S-BGP], to verify legitimacy and 137 correctness of routing information, or by Internet routing registries 138 to verify data that they receive. 140 Sections 2 and 3 specify several rules about the encoding of the 141 extensions defined in this specification that MUST be followed. 142 These encoding rules serve the following purposes. First, they 143 result in a unique encoding of the extension's value; two instances 144 of an extension can be compared for equality octet-by-octet. Second, 145 they achieve the minimal size encoding of the information. Third, 146 they allow relying parties to use one-pass algorithms when performing 147 certification path validation; in particular, the reply parties do 148 not need either to sort the information, or to implement extra code 149 in the subset checking algorithms to handle several boundary cases 150 (adjacent, overlapping, or subsumed allocations). 152 1.1. Terminology 154 It is assumed that the reader is familiar with the terms and concepts 155 described in "Internet X.509 Public Key Infrastructure Certificate 156 and Certificate Revocation List (CRL) Profile" [RFC3280], "INTERNET 157 PROTOCOL" [RFC791], "Internet Protocol Version 6 (IPv6) Addressing 158 Architecture" [RFC3513], and "INTERNET REGISTRY IP ALLOCATION 159 GUIDELINES" [RFC2050] and related regional Internet registry address 160 management policy documents. Some relevant terms include: 162 Autonomous System (AS) - a set of routers under a single technical 163 administration with a uniform policy, using one or more interior 164 gateway protocols and metrics to determine how to route packets 165 within the autonomous system, and using an exterior gateway 166 protocol to determine how to route packets to other autonomous 167 systems. 169 Autonomous System number - a 32-bit number that identifies an 170 autonomous system. 172 delegate - Transfer of custodianship (that is, the usage right) of an 173 IP address block or AS identifier through issuance of a 174 certificate to an entity. 176 initial octet - the first octet in the value of a DER encoded BIT 177 STRING [X.690]. 179 IP v4 address - a 32-bit identifier written as four decimal numbers, 180 each in the range 0 to 255, separated by a ".". 10.5.0.5 is an 181 example of an IPv4 address. 183 IP v6 address - a 128-bit identifier written as eight hexadecimal 184 quantities, each in the range 0 to ffff, separated by a ":". 185 2001:0:200:3:0:0:0:1 is an example of an IPv6 address. One string 186 of :0: fields may be replaced by "::", thus 2001:0:200:3::1 187 represents the same address as the immediately preceding example. 188 (See [RFC3513]). 190 prefix - a bit string that consists of some number of initial bits of 191 an address, written as an address followed by a "/", and the 192 number of initial bits. 10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64 193 (or 2001:0:200:3::/64) are examples of prefixes. A prefix is 194 often abbreviated by omitting the less-significant zero fields, 195 but there should be enough fields to contain the indicated number 196 of initial bits. 10.5/16 and 2001:0:200:3/64 are examples of 197 abbreviated prefixes. 199 Regional Internet Registry (RIR) - any of the bodies recognized by 200 IANA as the regional authorities for management of IP addresses 201 and AS identifiers. At time of writing these include AfriNIC, 202 APNIC, ARIN, LACNIC, and RIPE NCC. 204 right to use - for an IP address prefix, being authorized to specify 205 the AS that may originate advertisement of the prefix throughout 206 the Internet. For an autonomous system identifier, being 207 authorized to operate a network(s) that identifies itself to other 208 network operators using that autonomous system identifier. 210 subsequent octets - the second through last octets in the value of a 211 DER encoded BIT STRING [X.690]. 213 trust anchor - a certificate that is to be trusted when performing 214 certification path validation (see [RFC3280]). 216 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 217 SHOULD NOT, RECOMMENDED, and MAY, and OPTIONAL, when they appear in 218 this document, are to be interpreted as described in [RFC2119]. 220 2. IP Address Delegation Extension 222 This extension conveys the allocation of IP addresses to an entity by 223 binding those addresses to a public key belonging to the entity. 225 2.1. Context 227 IP address space is currently managed by a hierarchy nominally rooted 228 at IANA, but managed by the RIRs. IANA allocates IP address space to 229 the RIRs, who in turn allocate IP address space to Internet service 230 providers (ISPs), who may allocate IP address space to down stream 231 providers, customers, etc. The RIRs may also assign IP address space 232 to organizations who are end entities, i.e., organizations who will 233 not be reassigning any of their space to other organizations. (See 234 [RFC2050] and related RIR policy documents for the guidelines on the 235 allocation and assignment process). 237 The IP address delegation extension is intended to enable 238 verification of the proper delegation of IP address blocks, i.e., of 239 the authorization of an entity to use or sub-allocate IP address 240 space. Accordingly, it makes sense to take advantage of the inherent 241 authoritativeness of the existing administrative framework for 242 delegating IP address space. As described in Section 1 above, this 243 will be achieved by issuing certificates carrying the extension 244 described in this section. An example of one use of the information 245 in this extension is an entity using it to verify the authorization 246 of an organization to originate a BGP UPDATE advertising a path to a 247 particular IP address block; see, e.g., [RFC1771], [S-BGP]. 249 2.1.1. Encoding of an IP Address or Prefix 251 There are two families of IP addresses: IPv4 and IPv6. 253 An IPv4 address is a 32-bit quantity that is written as four decimal 254 numbers, each in the range 0 through 255, separated by a dot ("."); 255 10.5.0.5 is an example of an IPv4 address. 257 An IPv6 address is a 128-bit quantity that is written as eight 258 hexadecimal numbers, each in the range 0 through ffff, separated by a 259 semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6 260 address. IPv6 addresses frequently have adjacent fields whose value 261 is 0. One such group of 0 fields may be abbreviated by two 262 semicolons ("::"). The previous example may thus be represented by 263 2001:0:200:3::1. 265 An address prefix is a set of 2^k continuous addresses whose more- 266 significant bits are identical. For example, the set of 512 IPv4 267 addresses from 10.5.0.0 through 10.5.1.255 all have the same 23 most- 268 significant bits. The set of addresses is written by appending a 269 slash ("/") and the number of constant bits to the lowest address in 270 the set. The prefix for the example set is 10.5.0.0/23, and contains 271 2^(32-23) = 2^9 addresses. The set of IPv6 addresses 272 2001:0:200:0:0:0:0:0 through 2001:0:3ff:ffff:ffff:ffff:ffff:ffff 273 (2^89 addresses) is represented by 2001:0:200:0:0:0:0:0/39 or 274 equivalently 2001:0:200::/39. A prefix may be abbreviated by 275 omitting the less-significant zero fields, but there should be enough 276 fields to contain the indicated number of constant bits. The 277 abbreviated forms of the example IPv4 prefix is 10.5.0/23 and of the 278 example IPv6 prefix is 2001:0:200/39. 280 An IP address or prefix is encoded in the IP address delegation 281 extension as a DER-encoded ASN.1 BIT STRING containing the constant 282 most-significant bits. Recall [X.690] that the DER encoding of a BIT 283 STRING consists of the BIT STRING type (0x03), followed by (an 284 encoding of) the number of value octets, followed by the value. The 285 value consists of an "initial octet" that specifies the number of 286 unused bits in the last value octet, followed by the "subsequent 287 octets" that contain the octets of the bit string. (For IP 288 addresses, the encoding of the length will be just the length.) 290 In the case of a single address, all the bits are constant, so the 291 bit string for an IPv4 address contains 32 bits. The subsequent 292 octets in the DER-encoding of the address 10.5.0.4 are 0x0a 0x05 0x00 293 0x04. Since all the bits in the last octet are used, the initial 294 octet is 0x00. The octets in the DER-encoded BIT STRING is thus: 296 Type Len Unused Bits ... 297 0x03 0x05 0x00 0x0a 0x05 0x00 0x04 299 Similarly, the DER-encoding of the prefix 10.5.0/23 is: 301 Type Len Unused Bits ... 302 0x03 0x04 0x01 0x0a 0x05 0x00 304 In this case the three subsequent octets contain 24 bits, but the 305 prefix only uses 23, so there is one unused bit in the last octet, 306 thus the initial octet is 1 (the DER require that all unused bits 307 MUST be set to zero-bits). 309 The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is: 311 Type Len Unused Bits ... 312 0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03 313 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 315 and the DER-encoding of the prefix 2001:0:200/39, which has one 316 unused bit in the last octet, is: 318 Type Len Unused Bits ... 319 0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02 321 2.1.2. Encoding of a Range of IP Addresses 323 While any contiguous range of IP addresses can be represented by a 324 set of contiguous prefixes, a more concise representation is achieved 325 by encoding the range as a SEQUENCE containing the lowest address and 326 the highest address, where each address is encoded as a BIT STRING. 327 Within the SEQUENCE, the bit string representing the lowest address 328 in the range is formed by removing all the least-significant zero- 329 bits from the address, and the bit string representing the highest 330 address in the range is formed by removing all the least-significant 331 one-bits. The DER BIT STRING encoding requires that all the unused 332 bits in the last octet MUST be set to zero-bits. Note that a prefix 333 can always be expressed as a range, but a range cannot always be 334 expressed as a prefix. 336 The range of addresses represented by the prefix 10.5.0/23 is 337 10.5.0.0 through 10.5.1.255. The lowest address ends in sixteen 338 zero-bits that are removed. The DER-encoding of the resulting 339 sixteen-bit string is: 341 Type Len Unused Bits ... 342 0x03 0x03 0x00 0x0a 0x05 344 The highest address ends in nine one-bits that are removed. The DER- 345 encoding of the resulting twenty-three-bit string is: 347 Type Len Unused Bits ... 348 0x03 0x04 0x01 0x0a 0x05 0x00 350 The prefix 2001:0:200/39 can be encoded as a range where the DER- 351 encoding of the lowest address (2001:0:200::) is: 353 Type Len Unused Bits ... 354 0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02 356 and the largest address (2001:0:3ff:ffff:ffff:ffff:ffff:ffff), which, 357 after removal of the ninety least-significant one-bits leaves a 358 thirty-eight bit string, is encoded as: 360 Type Len Unused Bits ... 361 0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00 363 The special case of all IP address blocks, i.e., a prefix of all 364 zero-bits -- "0/0", MUST be encoded per the DER with a length octet 365 of one, an initial octet of zero, and no subsequent octets: 367 Type Len Unused Bits ... 368 0x03 0x01 0x00 370 Note that for IP addresses the number of trailing zero-bits is 371 significant. For example, the DER-encoding of 10.64/12: 373 Type Len Unused Bits ... 374 0x03 0x03 0x04 0x0a 0x40 376 is different than the DER-encoding of 10.64.0/20: 378 Type Len Unused Bits ... 379 0x03 0x04 0x04 0x0a 0x40 0x00 381 2.2. Specification 382 2.2.1. OID 384 The OID for this extension is id-pe-ipAddrBlock. 386 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 388 where [RFC3280] defines: 390 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 391 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 393 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 395 2.2.2. Criticality 397 This extension SHOULD be CRITICAL. The intended use of this 398 extension is to connote a usage right to the block(s) of IP addresses 399 identified in the extension. A CA marks the extension as CRITICAL to 400 convey the notion that a relying party MUST understand the semantics 401 of the extension to make use of the certificate for the purpose it 402 was issued. Newly created applications that use certificates 403 containing this extension are expected to recognize the extension. 405 2.2.3. Syntax 407 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 409 IPAddrBlocks ::= SEQUENCE OF IPAddressFamily 411 IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI -- 412 addressFamily OCTET STRING (SIZE (2..3)), 413 ipAddressChoice IPAddressChoice } 415 IPAddressChoice ::= CHOICE { 416 inherit NULL, -- inherit from issuer -- 417 addressesOrRanges SEQUENCE OF IPAddressOrRange } 419 IPAddressOrRange ::= CHOICE { 420 addressPrefix IPAddress, 421 addressRange IPAddressRange } 423 IPAddressRange ::= SEQUENCE { 424 min IPAddress, 425 max IPAddress } 427 IPAddress ::= BIT STRING 429 2.2.3.1. Type IPAddrBlocks 431 The IPAddrBlocks type is a SEQUENCE OF IPAddressFamily types. 433 2.2.3.2. Type IPAddressFamily 435 The IPAddressFamily type is a SEQUENCE containing an addressFamily 436 and ipAddressChoice element. 438 2.2.3.3. Element addressFamily 440 The addressFamily element is an OCTET STRING containing a two-octet 441 Address Family Identifier (AFI), in network byte order, optionally 442 followed by a one-octet Subsequent Address Family Identifier (SAFI). 443 AFIs and SAFIs are specified in [IANA-AFI] and [IANA-SAFI], 444 respectively. 446 If no authorization is being granted for a particular AFI and 447 optional SAFI, then there MUST NOT be an IPAddressFamily member for 448 that AFI/SAFI in the IPAddrBlocks SEQUENCE. 450 There MUST be only one IPAddressFamily SEQUENCE per unique 451 combination of AFI and SAFI. Each SEQUENCE MUST be ordered by 452 ascending addressFamily values (treating the octets as unsigned 453 quantities). An addressFamily without a SAFI MUST precede one that 454 contains a SAFI. When both IPv4 and IPv6 addresses are specified, 455 the IPv4 addresses MUST precede the IPv6 addresses (since the IPv4 456 AFI of 0001 is less than the IPv6 AFI of 0002). 458 2.2.3.4. Element ipAddressChoice and Type IPAddressChoice 460 The ipAddressChoice element is of type IPAddressChoice. The 461 IPAddressChoice type is a CHOICE of either an inherit or 462 addressesOrRanges element. 464 2.2.3.5. Element inherit 466 If the IPAddressChoice CHOICE contains the inherit element, then the 467 set of authorized IP addresses for the specified AFI and optional 468 SAFI is taken from the issuer's certificate, or the issuer's issuer's 469 certificate, recursively, until a certificate containing an 470 IPAddressChoice containing an addressesOrRanges element is located. 472 2.2.3.6. Element addressesOrRanges 474 The addressesOrRanges element is a SEQUENCE OF IPAddressOrRange 475 types. The addressPrefix and addressRange elements MUST be sorted 476 using the binary representation of: 478 | 480 where "|" represents concatenation. Note that the octets in this 481 representation (a.b.c.d | length for IPv4 or s:t:u:v:w:x:y:z | length 482 for IPv6) are not the octets that are in the DER-encoded BIT STRING 483 value. For example, given two addressPrefix: 485 IP addr | length DER encoding 486 ---------------- ------------------------ 487 Type Len Unused Bits... 488 10.32.0.0 | 12 03 03 04 0a 20 489 10.64.0.0 | 16 03 03 00 0a 40 491 the prefix 10.32.0.0/12 MUST come before the prefix 10.64.0.0/16 492 since 32 is less than 64; whereas if one were to sort by the DER BIT 493 STRINGs, the order would be reversed as the unused bits octet would 494 sort in the opposite order. Any pair of IPAddressOrRange choices in 495 an extension MUST NOT overlap each other. Any contiguous address 496 prefixes or ranges MUST be combined into a single range or, whenever 497 possible, a single prefix. 499 2.2.3.7. Type IPAddressOrRange 501 The IPAddressOrRange type is a CHOICE of either an addressPrefix (an 502 IP prefix or address) or an addressRange (an IP address range) 503 element. 505 This specification requires that any range of addresses that can be 506 encoded as prefix MUST be encoded using an IPAddress element (a BIT 507 STRING), and any range that cannot be encoded as a prefix MUST be 508 encoded using an IPAddressRange (a SEQUENCE containing two BIT 509 STRINGs). The following pseudo code illustrates how to select the 510 encoding of a given range of addresses. 512 LET N = the number of matching most-significant bits in the 513 lowest and highest addresses of the range 514 IF all the remaining bits in the lowest address are zero-bits 515 AND all the remaining bits in the highest address are one-bits 516 THEN the range MUST be encoded as an N-bit IPAddress 517 ELSE the range MUST be encoded as an IPAddressRange 519 2.2.3.8. Element addressPrefix and Type IPAddress 521 The addressPrefix element is an IPAddress type. The IPAddress type 522 defines a range of IP addresses in which the most-significant (left- 523 most) N bits of the address remain constant while the remaining bits 524 (32 - N bits for IPv4, or 128 - N bits for IPv6) may be either zero 525 or one. For example, the IPv4 prefix 10.64/12 corresponds to the 526 addresses 10.64.0.0 to 10.79.255.255 while 10.64/11 corresponds to 527 10.64.0.0 to 10.95.255.255. The IPv6 prefix 2001:0:2/48 represents 528 addresses 2001:0:2:: to 2001:0:2:ffff:ffff:ffff:ffff:ffff. 530 An IP address prefix is encoded as a BIT STRING. The DER encoding of 531 a BIT STRING uses the initial octet of the string to specify how many 532 of the least-significant bits of the last subsequent octet are 533 unused. The DER encoding specifies that these unused bits MUST be 534 set to zero-bits. 536 Example: 537 128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000 538 to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111 539 bit string to encode = 1000 540 Type Len Unused Bits ... 541 Encoding = 0x03 0x02 0x04 0x80 543 2.2.3.9. Element addressRange and Type IPAddressRange 545 The addressRange element is of type IPAddressRange. The 546 IPAddressRange type consists of a SEQUENCE containing a minimum 547 (element min) and maximum (element max) IP address. Each IP address 548 is encoded as a BIT STRING. The semantic interpretation of the 549 minimum address in an IPAddressRange is that all the unspecified bits 550 (for the full length of the IP address) are zero-bits. The semantic 551 interpretation of the maximum address is that all the unspecified 552 bits are one-bits. The BIT STRING for the minimum address results 553 from removing all the least-significant zero-bits from the minimum 554 address. The BIT STRING for the maximum address results from 555 removing all the least-significant one-bits from the maximum address. 557 Example: 558 129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000 559 to 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111 560 minimum bit string = 1000 0001.01 561 maximum bit string = 1000 562 Encoding = SEQUENCE { 563 Type Len Unused Bits ... 564 min 0x03 0x03 0x06 0x81 0x40 565 max 0x03 0x02 0x04 0x80 566 } 568 To simplify the comparison of IP address blocks when performing 569 certificate path validation, a maximum IP address MUST contain at 570 least one bit whose value is 1, i.e., the subsequent octets may 571 neither be omitted nor all zero. 573 2.3. IP Address Delegation Extension Certification Path Validation 575 Certification path validation of a certificate containing the IP 576 address delegation extension requires additional processing. As each 577 certificate in a path is validated, the IP addresses in the IP 578 address delegation extension of that certificate MUST be subsumed by 579 IP addresses in the IP address delegation extension in the issuer's 580 certificate. Validation MUST fail when this is not the case. A 581 certificate that is a trust anchor for certification path validation 582 of certificates containing the IP address delegation extension, as 583 well as all certificates along the path, MUST each contain the IP 584 address delegation extension. The initial set of allowed address 585 ranges is taken from the trust anchor certificate. 587 3. Autonomous System Identifier Delegation Extension 589 This extension conveys the allocation of autonomous system (AS) 590 identifiers to an entity by binding those AS identifiers to a public 591 key belonging to the entity. 593 3.1. Context 595 AS identifier delegation is currently managed by a hierarchy 596 nominally rooted at IANA, but managed by the RIRs. IANA allocates AS 597 identifiers to the RIRs, who in turn allocate AS identifiers to 598 organizations who are end entities, i.e., will not be re-delegating 599 any of their AS identifiers to other organizations. The AS 600 identifier delegation extension is intended to enable verification of 601 the proper delegation of AS identifiers, i.e., of the authorization 602 of an entity to use these AS identifiers. Accordingly, it makes 603 sense to take advantage of the inherent authoritativeness of the 604 existing administrative framework for delegating AS identifiers. As 605 described in Section 1 above, this will be achieved by issuing 606 certificates carrying the extension described in this section. An 607 example of one use of the information in this extension is an entity 608 using it to verify the authorization of an organization to manage the 609 AS identified by an AS identifier in the extension. 611 3.2. Specification 612 3.2.1. OID 614 The OID for this extension is id-pe-autonomousSysId. 616 id-pe-autonomousSysId OBJECT IDENTIFIER ::= { id-pe 8 } 618 where [RFC3280] defines: 620 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 621 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 623 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 625 3.2.2. Criticality 627 This extension SHOULD be CRITICAL. The intended use of this 628 extension is to connote usage right to the AS identifiers in the 629 extension. A CA marks the extension as CRITICAL to convey the notion 630 that a relying party must understand the semantics of the extension 631 to make use of the certificate for the purpose it was issued. Newly 632 created applications that use certificates containing this extension 633 are expected to recognize the extension. 635 3.2.3. Syntax 637 id-pe-autonomousSysId OBJECT IDENTIFIER ::= { id-pe 8 } 639 ASIdentifiers ::= SEQUENCE { 640 asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL, 641 rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL} 643 ASIdentifierChoice ::= CHOICE { 644 inherit NULL, -- inherit from issuer -- 645 asIdsOrRanges SEQUENCE OF ASIdOrRange } 647 ASIdOrRange ::= CHOICE { 648 id ASId, 649 range ASRange } 651 ASRange ::= SEQUENCE { 652 min ASId, 653 max ASId } 655 ASId ::= INTEGER 657 3.2.3.1. Type ASIdentifiers 659 The ASIdentifiers type is a SEQUENCE containing one or more forms of 660 autonomous system identifiers -- AS numbers (in the asnum element) or 661 routing domain identifiers (in the rdi element). When the 662 ASIdentifiers type contains multiple forms of identifiers, the asnum 663 entry MUST precede the rdi entry. AS numbers are used by BGP and 664 routing domain identifiers are specified in the IDRP [RFC1142]. 666 3.2.3.2. Elements asnum, rdi, and Type ASIdentifierChoice 668 The asnum and rdi elements are both of type ASIdentifierChoice. The 669 ASIdentifierChoice type is a CHOICE of either the inherit or 670 asIdsOrRanges element. 672 3.2.3.3. Element inherit 674 If the ASIdentifierChoice choice contains the inherit element, then 675 the set of authorized AS identifiers is taken from the issuer's 676 certificate, or the issuer's issuer's certificate, recursively, until 677 a certificate containing an ASIdentifierChoice containing an 678 asIdsOrRanges element is located. If no authorization is being 679 granted for a particular form of AS identifier then there MUST NOT be 680 an asnum/rdi member in the ASIdentifiers sequence. 682 3.2.3.4. Element asIdsOrRanges 684 The asIdsOrRanges element is a SEQUENCE of ASIdOrRange types. Any 685 pair of items in the asIdsOrRanges SEQUENCE MUST NOT overlap. Any 686 contiguous AS identifiers MUST be combined into a single range 687 whenever possible. The AS identifiers in the asIdsOrRanges element 688 MUST be sorted by increasing numeric value. 690 3.2.3.5. Type ASIdOrRange 692 The ASIdOrRange type is a CHOICE of either a single integer (ASId) or 693 a single sequence (ASRange). 695 3.2.3.6. Element id 697 The id element has type ASId. 699 3.2.3.7. Element range 701 The range element has type ASRange. 703 3.2.3.8. Type ASRange 705 The ASRange type is a SEQUENCE of a min and a max element and is used 706 to specify a range of AS identifier values. 708 3.2.3.9. Elements min and max 710 The min and max elements have type ASId. The min element is used to 711 specify the value of the minimum AS identifier in the range and the 712 max element specifies the value of the maximum AS identifier in the 713 range. 715 3.2.3.10. Type ASId 717 The ASId type is an INTEGER. 719 3.3. Autonomous System Identifier Delegation Extension Certification 720 Path Validation 722 Certification path validation of a certificate containing the 723 autonomous system identifier delegation extension requires additional 724 processing. As each certificate in a path is validated, the AS 725 identifiers in the autonomous system identifier delegation extension 726 of that certificate MUST be subsumed by the AS identifiers in the 727 autonomous system identifier delegation extension in the issuer's 728 certificate. Validation MUST fail when this is not the case. A 729 certificate that is a trust anchor for certification path validation 730 of certificates containing the autonomous system identifier 731 delegation extension, as well as all certificates along the path, 732 MUST each contain the autonomous system identifier delegation 733 extension. The initial set of allowed AS identifiers is taken from 734 the trust anchor certificate. 736 4. Security Considerations 738 This specification describes two X.509 extensions. Since X.509 739 certificates are digitally signed, no additional integrity service is 740 necessary. Certificates with these extensions need not be kept 741 secret, and unrestricted and anonymous access to these certificates 742 has no security implications. 744 However, security factors outside the scope of this specification 745 will affect the assurance provided to certificate users. This 746 section highlights critical issues that should be considered by 747 implementors, administrators, and users. 749 These extensions represent authorization information, i.e., a usage 750 right to IP addresses or AS identifiers. They were developed to 751 support a secure version of BGP [S-BGP], but may be employed in other 752 contexts. In the secure BGP context, certificates containing these 753 extensions function as capabilities: the certificate asserts that the 754 holder of the private key (the Subject) is authorized to use the IP 755 addresses or AS identifiers represented in the extension(s). As a 756 result of this capability model, the Subject field is largely 757 irrelevant for security purposes, contrary to common PKI conventions. 759 5. IANA Considerations 761 This specification does not introduce any additional IANA 762 considerations. 764 Insert the RFC number at the beginning of the ASN.1 module in 765 Appendix A. 767 6. Acknowledgments 769 The authors would like to acknowledge the contributions to this 770 specification by Charles Gardiner, Russ Housley, James Manger, and 771 Jim Schaad. 773 Appendix A -- ASN.1 Module 775 This normative appendix describes the IP address and AS identifiers 776 extensions used by conforming PKI components in ASN.1 syntax. 778 IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6) 779 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 780 id-mod-ip-addr-and-as-ident(30) } 781 DEFINITIONS EXPLICIT TAGS ::= 782 BEGIN 783 -- Copyright (C) The Internet Society (2003). This -- 784 -- version of this ASN.1 module is part of RFC xxxx; -- 785 -- see the RFC itself for full legal notices. -- 787 -- EXPORTS ALL -- 789 IMPORTS 791 -- PKIX specific OIDs and arcs -- 792 id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) 793 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 794 id-mod(0) id-pkix1-explicit(18) }; 796 -- IP Address Delegation Extension OID -- 798 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 800 -- IP Address Delegation Extension Syntax -- 802 IPAddrBlocks ::= SEQUENCE OF IPAddressFamily 804 IPAddressFamily ::= SEQUENCE { -- AFI & opt SAFI -- 805 addressFamily OCTET STRING (SIZE (2..3)), 806 ipAddressChoice IPAddressChoice } 808 IPAddressChoice ::= CHOICE { 809 inherit NULL, -- inherit from issuer -- 810 addressesOrRanges SEQUENCE OF IPAddressOrRange } 812 IPAddressOrRange ::= CHOICE { 813 addressPrefix IPAddress, 814 addressRange IPAddressRange } 816 IPAddressRange ::= SEQUENCE { 817 min IPAddress, 818 max IPAddress } 820 IPAddress ::= BIT STRING 821 -- Autonomous System Identifier Delegation Extension OID -- 823 id-pe-autonomousSysId OBJECT IDENTIFIER ::= { id-pe 8 } 825 -- Autonomous System Identifier Delegation Extension Syntax -- 827 ASIdentifiers ::= SEQUENCE { 828 asnum [0] ASIdentifierChoice OPTIONAL, 829 rdi [1] ASIdentifierChoice OPTIONAL } 831 ASIdentifierChoice ::= CHOICE { 832 inherit NULL, -- inherit from issuer -- 833 asIdsOrRanges SEQUENCE OF ASIdOrRange } 835 ASIdOrRange ::= CHOICE { 836 id ASId, 837 range ASRange } 839 ASRange ::= SEQUENCE { 840 min ASId, 841 max ASId } 843 ASId ::= INTEGER 845 END 847 Appendix B -- Examples of IP Address Delegation Extensions 849 A critical X.509 v3 certificate extension that specifies: 850 IPv4 unicast address prefixes 851 1) 10.0.32/20 i.e., 10.0.32.0 to 10.0.47.255 852 2) 10.0.64/24 i.e., 10.0.64.0 to 10.0.64.255 853 3) 10.1/16 i.e., 10.1.0.0 to 10.1.255.255 854 4) 10.2.48/20 i.e., 10.2.48.0 to 10.2.63.255 855 5) 10.2.64/24 i.e., 10.2.64.0 to 10.2.64.255 856 6) 10.3/16 i.e., 10.3.0.0 to 10.3.255.255, and 857 7) inherits all IPv6 addresses from the Issuer's certificate 858 would be (in hexadecimal): 860 30 46 Extension { 861 06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7 862 01 01 ff critical 863 04 37 extnValue { 864 30 35 IPAddrBlocks { 865 30 2b IPAddressFamily { 866 04 03 0001 01 addressFamily: IPv4 Unicast 867 IPAddressChoice 868 30 24 addressesOrRanges { 869 IPAddressOrRange 870 03 04 04 0a0020 addressPrefix 10.0.32/20 871 IPAddressOrRange 872 03 04 00 0a0040 addressPrefix 10.0.64/24 873 IPAddressOrRange 874 03 03 00 0a01 addressPrefix 10.1/16 875 IPAddressOrRange 876 30 0c addressRange { 877 03 04 04 0a0230 min 10.2.48.0 878 03 04 00 0a0240 max 10.2.64.255 879 } -- addressRange 880 IPAddressOrRange 881 03 03 00 0a03 addressPrefix 10.3/16 882 } -- addressesOrRanges 883 } -- IPAddressFamily 884 30 06 IPAddressFamily { 885 04 02 0002 addressFamily: IPv6 886 IPAddressChoice 887 05 00 inherit from issuer 888 } -- IPAddressFamily 889 } -- IPAddrBlocks 890 } -- extnValue 891 } -- Extension 893 This example illustrates how the prefixes and ranges are sorted. 895 + Prefix 1 MUST precede prefix 2, even though the number of unused 896 bits (4) in prefix 1 is larger than the number of unused bits (0) 897 in prefix 2. 899 + Prefix 2 MUST precede prefix 3 even though the number of octets 900 (4) in the BIT STRING encoding of prefix 2 is larger than the 901 number of octets (3) in the BIT STRING encoding of prefix 3. 903 + Prefixes 4 and 5 are adjacent (representing the range of addresses 904 from 10.2.48.0 to 10.2.64.255), so MUST be combined into a range 905 (since the range cannot be encoded by a single prefix). 907 + Note that the six trailing zero bits in the max element of the 908 range are significant to the semantic interpretation of the value 909 (as all unused bits are interpreted to be 1's, not 0's). The four 910 trailing zero bits in the min element are not significant and MUST 911 be removed (thus the (4) unused bits in the encoding of the min 912 element). (DER encoding requires that any unused bits in the last 913 subsequent octet MUST be set to zero.) 915 + The range formed by prefixes 4 and 5 MUST precede prefix 6 even 916 though the SEQUENCE tag for a range (30) is larger than the tag 917 for the BIT STRING (03) used to encode prefix 6. 919 + The IPv4 information MUST precede the IPv6 information since the 920 address family identifier for IPv4 (0001) is less than the 921 identifier for IPv6 (0002). 923 An extension specifying the IPv6 prefix 2001:0:2/48 and the IPv4 924 prefixes 10/8 and 172.16/12, and which inherits all IPv4 multicast 925 addresses from the issuer's certificate would be: 927 30 3d Extension { 928 06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7 929 01 01 ff critical 930 04 2e extnValue { 931 30 2c IPAddrBlocks { 932 30 10 IPAddressFamily { 933 04 03 0001 01 addressFamily: IPv4 Unicast 934 IPAddressChoice 935 30 09 addressesOrRanges { 936 IPAddressOrRange 937 03 02 00 0a addressPrefix 10/8 938 IPAddressOrRange 939 03 03 04 b010 addressPrefix 172.16/12 940 } -- addressesOrRanges 941 } -- IPAddressFamily 942 30 07 IPAddressFamily { 943 04 03 0001 02 addressFamily: IPv4 Multicast 944 IPAddressChoice 945 05 00 inherit from issuer 946 } -- IPAddressFamily 947 30 0f IPAddressFamily { 948 04 02 0002 addressFamily: IPv6 949 IPAddressChoice 950 30 09 addressesOrRanges { 951 IPAddressOrRange 952 03 07 00 200100000002 addressPrefix 2001:0:2/47 953 } -- addressesOrRanges 954 } -- IPAddressFamily 955 } -- IPAddrBlocks 956 } -- extnValue 957 } -- Extension 959 Appendix C -- Example of an AS Identifier Delegation Extension 961 An extension that specifies AS numbers 135, 3000 to 3999, and 5001, 962 and which inherits all routing domain identifiers from the issuers 963 certificate would be (in hexadecimal): 965 30 2b Extension { 966 06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8 967 01 01 ff critical 968 04 1c extnValue { 969 30 1a ASIdentifiers { 970 a0 14 asnum 971 ASIdentifierChoice 972 30 12 asIdsOrRanges { 973 ASIdOrRange 974 02 02 0087 ASId 975 ASIdOrRange 976 30 08 ASRange { 977 02 02 0bb8 min 978 02 02 0f9f max 979 } -- ASRange 980 ASIdOrRange 981 02 02 1389 ASId 982 } -- asIdsOrRanges 983 } -- asnum 984 a1 02 rdi { 985 ASIdentifierChoice 986 05 00 inherit from issuer 987 } -- rdi 988 } -- ASIdentifiers 989 } -- extnValue 990 } -- Extension 992 Appendix D -- Use of X.509 Attribute Certificates 994 This appendix discusses issues arising from a proposal to use 995 attribute certificates (ACs, as specified in [RFC3281]) to convey, 996 from the Regional Internet Registries (RIRs) to the end-user 997 organizations, the "right-to-use" IP address blocks or AS 998 identifiers. 1000 The two resources, AS identifiers and IP address blocks, are 1001 currently managed differently. All organizations with the right-to- 1002 use an AS identifier receive the authorization directly from an RIR. 1003 Organizations with a right-to-use an IP address block receive the 1004 authorization either directly from an RIR, or indirectly, e.g., from 1005 a down stream service provider, who might receive its authorization 1006 from an Internet service provider, who in turn gets its authorization 1007 from a RIR. Note that AS identifiers might be sub-allocated in the 1008 future, so the mechanisms used should not rely upon a three level 1009 hierarchy. 1011 In section 1 of RFC 3281, two reasons are given why the use of ACs 1012 might be preferable to use of public key certificates (PKCs) with 1013 extensions that convey the authorization information: 1015 "Authorization information may be placed in a PKC extension or 1016 placed in a separate attribute certificate (AC). The placement of 1017 authorization information in PKCs is usually undesirable for two 1018 reasons. First, authorization information often does not have the 1019 same lifetime as the binding of the identity and the public key. 1020 When authorization information is placed in a PKC extension, the 1021 general result is the shortening of the PKC useful lifetime. 1022 Second, the PKC issuer is not usually authoritative for the 1023 authorization information. This results in additional steps for 1024 the PKC issuer to obtain authorization information from the 1025 authoritative source." 1027 "For these reasons, it is often better to separate authorization 1028 information from the PKC. Yet, authorization information also 1029 needs to be bound to an identity. An AC provides this binding; it 1030 is simply a digitally signed (or certified) identity and set of 1031 attributes." 1033 In the case of the IP address and AS identifier authorizations, these 1034 reasons do not apply. First, the public key certificates are issued 1035 exclusively for authorization, so the certificate lifetime 1036 corresponds exactly to the authorization lifetime, which is often 1037 tied to a contractual relationship between the issuer and entity 1038 receiving the authorization. The Subject and Issuer names are only 1039 used for chaining during certification path validation, and the names 1040 need not correspond to any physical entity. The Subject name in the 1041 PKCs may actually be randomly assigned by the issuing CA, allowing 1042 the resource holder limited anonymity. Second, the certificate 1043 hierarchy is constructed so that the certificate issuer is 1044 authoritative for the authorization information. 1046 Thus the two points in the first cited paragraph above are not true 1047 in the case of AS number and IP address block allocations. The point 1048 of the second cited paragraph is also not applicable as the resources 1049 are not being bound to an identity but to the holder of the private 1050 key corresponding to the public key in the PKC. 1052 RFC 3281 specifies several requirements that a conformant Attribute 1053 Certificates must meet. In relation to S-BGP, the more-significant 1054 requirements are: 1056 1 from section 1: "this specification does NOT RECOMMEND the use of 1057 AC chains. Other (future) specifications may address the use of 1058 AC chains." 1060 Delegation from IANA to RIRs to ISPs to DSPs to end organizations 1061 would require the use of chains, at least for IP address block 1062 delegation. A description of how the superior's AC should be 1063 located and its processed would have to provide. Readers of this 1064 document are encouraged to propose ways the chaining might be 1065 avoided. 1067 2 from section 4.2.9: "section 4.3 defines the extensions that MAY 1068 be used with this profile, and whether or not they may be marked 1069 critical. If any other critical extension is used, the AC does 1070 not conform to this profile. However, if any other non-critical 1071 extension is used, the AC does conform to this profile." 1073 This means that the delegation extensions defined in this 1074 specification, which are critical, could not be simply placed into 1075 an AC. They could be used if not marked critical, but the 1076 intended use requires the extensions be critical so that the 1077 certificates that contain them cannot be used as identity 1078 certificates by an unsuspecting application. 1080 3 from section 4.5: "an AC issuer MUST NOT also be a PKC Issuer. 1081 That is, an AC issuer cannot be a CA as well." 1083 This means that for each AC issuer there would need to be a 1084 separate CA to issue the PKC that contains the public key of the 1085 AC holder. The AC issuer cannot issue the PKC of the holder, and 1086 the PKC issuer cannot sign the AC. Thus each entity in the PKI 1087 would need to operate an AC issuer in addition to its CA. There 1088 would be twice as many certificate issuers and CRLs to process, to 1089 support Attribute certificates than are needed if PKCs are used. 1090 The possibility of mis-alignment also arises when there are two 1091 issuers issuing certificates for a single purpose. 1093 The AC model of RFC 3281 implies that the AC holder presents the 1094 AC to the AC verifier when the holder wants to substantiate an 1095 attribute or authorization. The intended usage for the extensions 1096 defined herein does not have a direct interaction between an AC 1097 verifier (a NOC) and the AC issuers (all RIRs and NOCs). Given a 1098 signature on a claimed right-to-use object, the "AC verifier" can 1099 locate the AC holder's PKC, but there is no direct way to locate 1100 the Subject's AC(s). 1102 4 from section 5: "4. The AC issuer MUST be directly trusted as an 1103 AC issuer (by configuration or otherwise)." 1105 This is not true in the case of right to use an IP address block, 1106 which is delegated through a hierarchy. Path validation of the AC 1107 will require chaining up through the delegation hierarchy. Having 1108 to configure each replying party (NOC) to "trust" every other NOC 1109 does not scale, and such "trust" has resulted in failures that the 1110 proposed security mechanisms are designed to prevent. A single 1111 PKI with a trusted root is used, not thousands of individually 1112 trusted per-ISP AC issuers. 1114 The amount of work that would be required to properly validate an 1115 AC is larger than for the mechanism that places the S-BGP 1116 extensions in the PKCs. There are twice as many certificates to 1117 be validated, in addition to the ACs. There could be considerable 1118 increase in the management burden required to support ACs. 1120 References 1122 Normative References 1124 [IANA-AFI] http://www.iana.org/assignments/address-family-numbers. 1126 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace. 1128 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1129 3", RFC 2026, BCP 00009, October 1996. 1131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1132 Requirement Level", BCP 14, RFC 2119, March 1997. 1134 [RFC3279] W. Polk, R. Housley, and L. Bassham, " Algorithms and 1135 Identifiers for the Internet X.509 Public Key 1136 Infrastructure Certificate and Certificate Revocation 1137 List (CRL) Profile", RFC 3279, April 2002. 1139 [RFC3280] R. Housley, W. Polk, W. Ford, D. Solo, "Internet X.509 1140 Public Key Infrastructure Certificate and Certificate 1141 Revocation List (CRL) Profile", RFC 3280, April 2002. 1143 [X.690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, 1144 "Information Technology - ASN.1 Encoding Rules: 1145 Specification of Basic Encoding Rules (BER), Canonical 1146 Encoding Rules (CER) and Distinguished Encoding Rules 1147 (DER)". 1149 Informational References 1151 [RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol", 1152 February 1990. 1154 [RFC1771] Y. Rekhter, T. Li, Eds., "A Border Gateway Protocol 4 1155 (BGP-4)", RFC 1771, March 1995. 1157 [RFC2050] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. 1158 Postel, "Internet Registry IP Allocation Guidelines", RFC 1159 2050, BCP 00012, November 1996. 1161 [RFC3513] R. Hinden, S. Deering, "Internet Protocol Version 6 1162 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1164 [RFC3280] R. Housley, W., Polk, W. Ford, D. Solo, "Internet X.509 1165 Public Key Infrastructure Certificate and Certificate 1166 Revocation List (CRL) Profile", RFC 3280, April 2002. 1168 [RFC3281] S. Farrell, and R. Housley, "An Internet Attribute 1169 Certificate Profile for Authorization", RFC 3281, April 1170 2002. 1172 [S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway 1173 Protocol (S-BGP)," IEEE JSAC Special Issue on Network 1174 Security, April 2000. 1176 [X.509] ITU-T Recommendation X.509 (1997 E): "Information 1177 Technology - Open Systems Interconnection - The 1178 Directory: Authentication Framework", June 1997. 1180 Disclaimer 1182 The views and specification here are those of the authors and are not 1183 necessarily those of their employers. The authors and their 1184 employers specifically disclaim responsibility for any problems 1185 arising from correct or incorrect implementation or use of this 1186 specification. 1188 Authors' Address 1190 Charles Lynn 1191 BBN Technologies 1192 10 Moulton St. 1193 Cambridge, MA 02138 1194 USA 1196 Phone: +1 (617) 873-3367 1197 Email: CLynn@BBN.Com 1199 Stephen Kent 1200 BBN Technologies 1201 10 Moulton St. 1202 Cambridge, MA 02138 1203 USA 1205 Phone: +1 (617) 873-3988 1206 Email: Kent@BBN.Com 1208 Karen Seo 1209 BBN Technologies 1210 10 Moulton St. 1211 Cambridge, MA 02138 1212 USA 1214 Phone: +1 (617) 873-3152 1215 Email: KSeo@BBN.Com 1217 Intellectual Property Statement 1219 The IETF takes no position regarding the validity or scope of any 1220 intellectual property or other rights that might be claimed to 1221 pertain to the implementation or use of the technology described in 1222 this document or the extent to which any license under such rights 1223 might or might not be available; neither does it represent that it 1224 has made any effort to identify any such rights. Information on the 1225 IETF's procedures with respect to rights in standards-track and 1226 standards-related documentation can be found in BCP-11. Copies of 1227 claims of rights made available for publication and any assurances of 1228 licenses to be made available, or the result of an attempt made to 1229 obtain a general license or permission for the use of such 1230 proprietary rights by implementors or users of this specification can 1231 be obtained from the IETF Secretariat. 1233 The IETF invites any interested party to bring to its attention any 1234 copyrights, patents or patent applications, or other proprietary 1235 rights which may cover technology that may be required to practice 1236 this standard. Please address the information to the IETF Executive 1237 Director. 1239 Full Copyright Statement 1241 Copyright (C) The Internet Society (2003). All Rights Reserved. 1243 This document and translations of it may be copied and furnished to 1244 others, and derivative works that comment on or otherwise explain it 1245 or assist in its implementation may be prepared, copied, published 1246 and distributed, in whole or in part, without restriction of any 1247 kind, provided that the above copyright notice and this paragraph are 1248 included on all such copies and derivative works. However, this 1249 document itself may not be modified in any way, such as by removing 1250 the copyright notice or references to the Internet Society or other 1251 Internet organizations, except as needed for the purpose of 1252 developing Internet standards in which case the procedures for 1253 copyrights defined in the Internet Standards process must be 1254 followed, or as required to translate it into languages other than 1255 English. 1257 The limited permissions granted above are perpetual and will not be 1258 revoked by the Internet Society or its successors or assignees. 1260 This document and the information contained herein is provided on an 1261 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1262 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1263 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1264 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1265 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1267 Acknowledgment 1269 Funding for the RFC Editor function is currently provided by the 1270 Internet Society.