doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc3779.txt b/doc/rfc/rfc3779.txt
new file mode 100644
index 0000000..1f29416
--- /dev/null
+++ b/doc/rfc/rfc3779.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                            C. Lynn
+Request for Comments: 3779                                       S. Kent
+Category: Standards Track                                         K. Seo
+                                                        BBN Technologies
+                                                               June 2004
+
+
+          X.509 Extensions for IP Addresses and AS Identifiers
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines two X.509 v3 certificate extensions.  The first
+   binds a list of IP address blocks, or prefixes, to the subject of a
+   certificate.  The second binds a list of autonomous system
+   identifiers to the subject of a certificate.  These extensions may be
+   used to convey the authorization of the subject to use the IP
+   addresses and autonomous system identifiers contained in the
+   extensions.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  IP Address Delegation Extension. . . . . . . . . . . . . . . .  5
+       2.1.  Context. . . . . . . . . . . . . . . . . . . . . . . . .  5
+             2.1.1.  Encoding of an IP Address or Prefix. . . . . . .  5
+             2.1.2.  Encoding of a Range of IP Addresses. . . . . . .  7
+       2.2.  Specification. . . . . . . . . . . . . . . . . . . . . .  8
+             2.2.1.  OID. . . . . . . . . . . . . . . . . . . . . . .  8
+             2.2.2.  Criticality. . . . . . . . . . . . . . . . . . .  9
+             2.2.3.  Syntax . . . . . . . . . . . . . . . . . . . . .  9
+                     2.2.3.1.  Type IPAddrBlocks. . . . . . . . . . .  9
+                     2.2.3.2.  Type IPAddressFamily . . . . . . . . .  9
+                     2.2.3.3.  Element addressFamily. . . . . . . . . 10
+                     2.2.3.4.  Element ipAddressChoice and Type
+                               IPAddressChoice. . . . . . . . . . . . 10
+
+
+
+Lynn, et al.                Standards Track                     [Page 1]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+                     2.2.3.5.  Element inherit. . . . . . . . . . . . 10
+                     2.2.3.6.  Element addressesOrRanges. . . . . . . 10
+                     2.2.3.7.  Type IPAddressOrRange. . . . . . . . . 11
+                     2.2.3.8.  Element addressPrefix and Type
+                               IPAddress. . . . . . . . . . . . . . . 11
+                     2.2.3.9.  Element addressRange and Type
+                               IPAddressRange . . . . . . . . . . . . 12
+       2.3.  IP Address Delegation Extension Certification Path
+             Validation . . . . . . . . . . . . . . . . . . . . . . . 12
+   3.  Autonomous System Identifier Delegation Extension. . . . . . . 13
+       3.1.  Context  . . . . . . . . . . . . . . . . . . . . . . . . 13
+       3.2.  Specification. . . . . . . . . . . . . . . . . . . . . . 13
+             3.2.1.  OID. . . . . . . . . . . . . . . . . . . . . . . 13
+             3.2.2.  Criticality. . . . . . . . . . . . . . . . . . . 14
+             3.2.3.  Syntax . . . . . . . . . . . . . . . . . . . . . 14
+                     3.2.3.1.  Type ASIdentifiers . . . . . . . . . . 14
+                     3.2.3.2.  Elements asnum, rdi, and Type
+                               ASIdentifierChoice . . . . . . . . . . 14
+                     3.2.3.3.  Element inherit. . . . . . . . . . . . 15
+                     3.2.3.4.  Element asIdsOrRanges. . . . . . . . . 15
+                     3.2.3.5.  Type ASIdOrRange . . . . . . . . . . . 15
+                     3.2.3.6.  Element id . . . . . . . . . . . . . . 15
+                     3.2.3.7.  Element range. . . . . . . . . . . . . 15
+                     3.2.3.8.  Type ASRange . . . . . . . . . . . . . 15
+                     3.2.3.9.  Elements min and max . . . . . . . . . 15
+                     3.2.3.10. Type ASId. . . . . . . . . . . . . . . 15
+   3.3.  Autonomous System Identifier Delegation Extension
+         Certification Path Validation. . . . . . . . . . . . . . . . 16
+   4.  Security Considerations. . . . . . . . . . . . . . . . . . . . 16
+   5.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
+   Appendix A -- ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
+   Appendix B -- Examples of IP Address Delegation Extensions . . . . 18
+   Appendix C -- Example of an AS Identifier Delegation Extension . . 21
+   Appendix D -- Use of X.509 Attribute Certificates. . . . . . . . . 21
+   References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+   Normative References . . . . . . . . . . . . . . . . . . . . . . . 24
+   Informative References . . . . . . . . . . . . . . . . . . . . . . 25
+   Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
+
+
+
+
+
+
+
+
+
+
+
+
+Lynn, et al.                Standards Track                     [Page 2]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+1.  Introduction
+
+   This document defines two X.509 v3 certificate extensions that
+   authorize the transfer of the right-to-use for a set of IP addresses
+   and autonomous system identifiers from IANA through the regional
+   Internet registries (RIRs) to Internet service providers (ISPs) and
+   user organizations.  The first binds a list of IP address blocks,
+   often represented as IP address prefixes, to the subject (private key
+   holder) of a certificate.  The second binds a list of autonomous
+   system (AS) identifiers to the subject (private key holder) of a
+   certificate.  The issuer of the certificate is an entity (e.g., the
+   IANA, a regional Internet registry, or an ISP) that has the authority
+   to transfer custodianship of ("allocate") the set of IP address
+   blocks and AS identifiers to the subject of the certificate.  These
+   certificates provide a scalable means of verifying the right-to-use
+   for a set of IP address prefixes and AS identifiers.  They may be
+   used by routing protocols, such as Secure BGP [S-BGP], to verify
+   legitimacy and correctness of routing information, or by Internet
+   routing registries to verify data that they receive.
+
+   Sections 2 and 3 specify several rules about the encoding of the
+   extensions defined in this specification that MUST be followed.
+   These encoding rules serve the following purposes.  First, they
+   result in a unique encoding of the extension's value; two instances
+   of an extension can be compared for equality octet-by-octet.  Second,
+   they achieve the minimal size encoding of the information.  Third,
+   they allow relying parties to use one-pass algorithms when performing
+   certification path validation; in particular, the relying parties do
+   not need to sort the information, or to implement extra code in the
+   subset checking algorithms to handle several boundary cases
+   (adjacent, overlapping, or subsumed ranges).
+
+1.1.  Terminology
+
+   It is assumed that the reader is familiar with the terms and concepts
+   described in "Internet X.509 Public Key Infrastructure Certificate
+   and Certificate Revocation List (CRL) Profile" [RFC3280], "INTERNET
+   PROTOCOL" [RFC791], "Internet Protocol Version 6 (IPv6) Addressing
+   Architecture" [RFC3513], "INTERNET REGISTRY IP ALLOCATION GUIDELINES"
+   [RFC2050], and related regional Internet registry address management
+   policy documents.  Some relevant terms include:
+
+   allocate - the transfer of custodianship of a resource to an
+      intermediate organization (see [RFC2050]).
+
+   assign - the transfer of custodianship of a resource to an end
+      organization (see [RFC2050]).
+
+
+
+
+Lynn, et al.                Standards Track                     [Page 3]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   Autonomous System (AS) - a set of routers under a single technical
+      administration with a uniform policy, using one or more interior
+      gateway protocols and metrics to determine how to route packets
+      within the autonomous system, and using an exterior gateway
+      protocol to determine how to route packets to other autonomous
+      systems.
+
+   Autonomous System number - a 32-bit number that identifies an
+      autonomous system.
+
+   delegate - transfer of custodianship (that is, the right-to-use) of
+      an IP address block or AS identifier through issuance of a
+      certificate to an entity.
+
+   initial octet - the first octet in the value of a DER encoded BIT
+      STRING [X.690].
+
+   IP v4 address - a 32-bit identifier written as four decimal numbers,
+      each in the range 0 to 255, separated by a ".".  10.5.0.5 is an
+      example of an IPv4 address.
+
+   IP v6 address - a 128-bit identifier written as eight hexadecimal
+      quantities, each in the range 0 to ffff, separated by a ":".
+      2001:0:200:3:0:0:0:1 is an example of an IPv6 address.  One string
+      of :0: fields may be replaced by "::", thus 2001:0:200:3::1
+      represents the same address as the immediately preceding example.
+      (See [RFC3513]).
+
+   prefix - a bit string that consists of some number of initial bits of
+      an address, written as an address followed by a "/", and the
+      number of initial bits.  10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64
+      (or 2001:0:200:3::/64) are examples of prefixes.  A prefix is
+      often abbreviated by omitting the less-significant zero fields,
+      but there should be enough fields to contain the indicated number
+      of initial bits.  10.5/16 and 2001:0:200:3/64 are examples of
+      abbreviated prefixes.
+
+   Regional Internet Registry (RIR) - any of the bodies recognized by
+      IANA as the regional authorities for management of IP addresses
+      and AS identifiers.  At the time of writing, these include
+      AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC.
+
+   right-to-use - for an IP address prefix, being authorized to specify
+      the AS that may originate advertisements of the prefix throughout
+      the Internet.  For an autonomous system identifier, being
+      authorized to operate a network(s) that identifies itself to other
+      network operators using that autonomous system identifier.
+
+
+
+
+Lynn, et al.                Standards Track                     [Page 4]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   subsequent octets - the second through last octets in the value of a
+      DER encoded BIT STRING [X.690].
+
+   trust anchor - a certificate that is to be trusted when performing
+      certification path validation (see [RFC3280]).
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, and MAY, and OPTIONAL, when they appear in
+   this document, are to be interpreted as described in [RFC2119].
+
+2.  IP Address Delegation Extension
+
+   This extension conveys the allocation of IP addresses to an entity by
+   binding those addresses to a public key belonging to the entity.
+
+2.1.  Context
+
+   IP address space is currently managed by a hierarchy nominally rooted
+   at IANA, but managed by the RIRs.  IANA allocates IP address space to
+   the RIRs, who in turn allocate IP address space to Internet service
+   providers (ISPs), who may allocate IP address space to down stream
+   providers, customers, etc.  The RIRs also may assign IP address space
+   to organizations who are end entities, i.e., organizations who will
+   not be reassigning any of their space to other organizations.  (See
+   [RFC2050] and related RIR policy documents for the guidelines on the
+   allocation and assignment process).
+
+   The IP address delegation extension is intended to enable
+   verification of the proper delegation of IP address blocks, i.e., of
+   the authorization of an entity to use or sub-allocate IP address
+   space.  Accordingly, it makes sense to take advantage of the inherent
+   authoritativeness of the existing administrative framework for
+   allocating IP address space.  As described in Section 1 above, this
+   will be achieved by issuing certificates carrying the extension
+   described in this section.  An example of one use of the information
+   in this extension is an entity using it to verify the authorization
+   of an organization to originate a BGP UPDATE advertising a path to a
+   particular IP address block; see, e.g., [RFC1771], [S-BGP].
+
+2.1.1.  Encoding of an IP Address or Prefix
+
+   There are two families of IP addresses: IPv4 and IPv6.
+
+   An IPv4 address is a 32-bit quantity that is written as four decimal
+   numbers, each in the range 0 through 255, separated by a dot (".").
+   10.5.0.5 is an example of an IPv4 address.
+
+
+
+
+
+Lynn, et al.                Standards Track                     [Page 5]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   An IPv6 address is a 128-bit quantity that is written as eight
+   hexadecimal numbers, each in the range 0 through ffff, separated by a
+   semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6
+   address.  IPv6 addresses frequently have adjacent fields whose value
+   is 0.  One such group of 0 fields may be abbreviated by two
+   semicolons ("::").  The previous example may thus be represented by
+   2001:0:200:3::1.
+
+   An address prefix is a set of 2^k continuous addresses whose most-
+   significant bits are identical.  For example, the set of 512 IPv4
+   addresses from 10.5.0.0 through 10.5.1.255 all have the same 23
+   most-significant bits.  The set of addresses is written by appending
+   a slash ("/") and the number of constant bits to the lowest address
+   in the set.  The prefix for the example set is 10.5.0.0/23, and
+   contains 2^(32-23) = 2^9 addresses.  The set of IPv6 addresses
+   2001:0:200:0:0:0:0:0 through 2001:0:3ff:ffff:ffff:ffff:ffff:ffff
+   (2^89 addresses) is represented by 2001:0:200:0:0:0:0:0/39 or
+   equivalently 2001:0:200::/39.  A prefix may be abbreviated by
+   omitting the least-significant zero fields, but there should be
+   enough fields to contain the indicated number of constant bits.  The
+   abbreviated forms of the example IPv4 prefix is 10.5.0/23, and of the
+   example IPv6 prefix is 2001:0:200/39.
+
+   An IP address or prefix is encoded in the IP address delegation
+   extension as a DER-encoded ASN.1 BIT STRING containing the constant
+   most-significant bits.  Recall [X.690] that the DER encoding of a BIT
+   STRING consists of the BIT STRING type (0x03), followed by (an
+   encoding of) the number of value octets, followed by the value.  The
+   value consists of an "initial octet" that specifies the number of
+   unused bits in the last value octet, followed by the "subsequent
+   octets" that contain the octets of the bit string.  (For IP
+   addresses, the encoding of the length will be just the length.)
+
+   In the case of a single address, all the bits are constant, so the
+   bit string for an IPv4 address contains 32 bits.  The subsequent
+   octets in the DER-encoding of the address 10.5.0.4 are 0x0a 0x05 0x00
+   0x04.  Since all the bits in the last octet are used, the initial
+   octet is 0x00.  The octets in the DER-encoded BIT STRING is thus:
+
+         Type Len  Unused Bits ...
+         0x03 0x05  0x00  0x0a 0x05 0x00 0x04
+
+   Similarly, the DER-encoding of the prefix 10.5.0/23 is:
+
+         Type Len  Unused Bits ...
+         0x03 0x04  0x01  0x0a 0x05 0x00
+
+
+
+
+
+Lynn, et al.                Standards Track                     [Page 6]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   In this case, the three subsequent octets contain 24 bits, but the
+   prefix only uses 23, so there is one unused bit in the last octet,
+   thus the initial octet is 1 (the DER require that all unused bits
+   MUST be set to zero-bits).
+
+   The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:
+
+         Type Len  Unused Bits ...
+         0x03 0x11  0x00  0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
+                          0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
+
+   and the DER-encoding of the prefix 2001:0:200/39, which has one
+   unused bit in the last octet, is:
+
+         Type Len  Unused Bits ...
+         0x03 0x06  0x01  0x20 0x01 0x00 0x00 0x02
+
+2.1.2.  Encoding of a Range of IP Addresses
+
+   While any contiguous range of IP addresses can be represented by a
+   set of contiguous prefixes, a more concise representation is achieved
+   by encoding the range as a SEQUENCE containing the lowest address and
+   the highest address, where each address is encoded as a BIT STRING.
+   Within the SEQUENCE, the bit string representing the lowest address
+   in the range is formed by removing all the least-significant zero-
+   bits from the address, and the bit string representing the highest
+   address in the range is formed by removing all the least-significant
+   one-bits.  The DER BIT STRING encoding requires that all the unused
+   bits in the last octet MUST be set to zero-bits.  Note that a prefix
+   can always be expressed as a range, but a range cannot always be
+   expressed as a prefix.
+
+   The range of addresses represented by the prefix 10.5.0/23 is
+   10.5.0.0 through 10.5.1.255.  The lowest address ends in sixteen
+   zero-bits that are removed.  The DER-encoding of the resulting
+   sixteen-bit string is:
+
+         Type Len  Unused Bits ...
+         0x03 0x03  0x00  0x0a 0x05
+
+   The highest address ends in nine one-bits that are removed.  The DER-
+   encoding of the resulting twenty-three-bit string is:
+
+         Type Len  Unused Bits ...
+         0x03 0x04  0x01  0x0a 0x05 0x00
+
+
+
+
+
+
+Lynn, et al.                Standards Track                     [Page 7]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   The prefix 2001:0:200/39 can be encoded as a range where the DER-
+   encoding of the lowest address (2001:0:200::) is:
+
+         Type Len  Unused Bits ...
+         0x03 0x06  0x01  0x20 0x01 0x00 0x00 0x02
+
+   and the largest address (2001:0:3ff:ffff:ffff:ffff:ffff:ffff), which,
+   after removal of the ninety least-significant one-bits leaves a
+   thirty-eight bit string, is encoded as:
+
+         Type Len  Unused Bits ...
+         0x03 0x06  0x02  0x20 0x01 0x00 0x00 0x00
+
+   The special case of all IP address blocks, i.e., a prefix of all
+   zero-bits -- "0/0", MUST be encoded per the DER with a length octet
+   of one, an initial octet of zero, and no subsequent octets:
+
+         Type Len  Unused Bits ...
+         0x03 0x01  0x00
+
+   Note that for IP addresses the number of trailing zero-bits is
+   significant.  For example, the DER-encoding of 10.64/12:
+
+         Type Len  Unused Bits ...
+         0x03 0x03  0x04  0x0a 0x40
+
+   is different than the DER-encoding of 10.64.0/20:
+
+         Type Len  Unused Bits ...
+         0x03 0x04  0x04  0x0a 0x40 0x00
+
+2.2.  Specification
+
+2.2.1.  OID
+
+   The OID for this extension is id-pe-ipAddrBlocks.
+
+      id-pe-ipAddrBlocks  OBJECT IDENTIFIER ::= { id-pe 7 }
+
+   where [RFC3280] defines:
+
+      id-pkix  OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+               dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+      id-pe    OBJECT IDENTIFIER ::= { id-pkix 1 }
+
+
+
+
+
+
+Lynn, et al.                Standards Track                     [Page 8]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+2.2.2.  Criticality
+
+   This extension SHOULD be CRITICAL.  The intended use of this
+   extension is to connote a right-to-use for the block(s) of IP
+   addresses identified in the extension.  A CA marks the extension as
+   CRITICAL to convey the notion that a relying party MUST understand
+   the semantics of the extension to make use of the certificate for the
+   purpose it was issued.  Newly created applications that use
+   certificates containing this extension are expected to recognize the
+   extension.
+
+2.2.3.  Syntax
+
+   id-pe-ipAddrBlocks      OBJECT IDENTIFIER ::= { id-pe 7 }
+
+   IPAddrBlocks        ::= SEQUENCE OF IPAddressFamily
+
+   IPAddressFamily     ::= SEQUENCE {    -- AFI & optional SAFI --
+      addressFamily        OCTET STRING (SIZE (2..3)),
+      ipAddressChoice      IPAddressChoice }
+
+   IPAddressChoice     ::= CHOICE {
+      inherit              NULL, -- inherit from issuer --
+      addressesOrRanges    SEQUENCE OF IPAddressOrRange }
+
+   IPAddressOrRange    ::= CHOICE {
+      addressPrefix        IPAddress,
+      addressRange         IPAddressRange }
+
+   IPAddressRange      ::= SEQUENCE {
+      min                  IPAddress,
+      max                  IPAddress }
+
+   IPAddress           ::= BIT STRING
+
+2.2.3.1.  Type IPAddrBlocks
+
+   The IPAddrBlocks type is a SEQUENCE OF IPAddressFamily types.
+
+2.2.3.2.  Type IPAddressFamily
+
+   The IPAddressFamily type is a SEQUENCE containing an addressFamily
+   and ipAddressChoice element.
+
+
+
+
+
+
+
+
+Lynn, et al.                Standards Track                     [Page 9]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+2.2.3.3.  Element addressFamily
+
+   The addressFamily element is an OCTET STRING containing a two-octet
+   Address Family Identifier (AFI), in network byte order, optionally
+   followed by a one-octet Subsequent Address Family Identifier (SAFI).
+   AFIs and SAFIs are specified in [IANA-AFI] and [IANA-SAFI],
+   respectively.
+
+   If no authorization is being granted for a particular AFI and
+   optional SAFI, then there MUST NOT be an IPAddressFamily member for
+   that AFI/SAFI in the IPAddrBlocks SEQUENCE.
+
+   There MUST be only one IPAddressFamily SEQUENCE per unique
+   combination of AFI and SAFI.  Each SEQUENCE MUST be ordered by
+   ascending addressFamily values (treating the octets as unsigned
+   quantities).  An addressFamily without a SAFI MUST precede one that
+   contains an SAFI.  When both IPv4 and IPv6 addresses are specified,
+   the IPv4 addresses MUST precede the IPv6 addresses (since the IPv4
+   AFI of 0001 is less than the IPv6 AFI of 0002).
+
+2.2.3.4.  Element ipAddressChoice and Type IPAddressChoice
+
+   The ipAddressChoice element is of type IPAddressChoice.  The
+   IPAddressChoice type is a CHOICE of either an inherit or
+   addressesOrRanges element.
+
+2.2.3.5.  Element inherit
+
+   If the IPAddressChoice CHOICE contains the inherit element, then the
+   set of authorized IP addresses for the specified AFI and optional
+   SAFI is taken from the issuer's certificate, or from the issuer's
+   issuer's certificate, recursively, until a certificate containing an
+   IPAddressChoice containing an addressesOrRanges element is located.
+
+2.2.3.6.  Element addressesOrRanges
+
+   The addressesOrRanges element is a SEQUENCE OF IPAddressOrRange
+   types.  The addressPrefix and addressRange elements MUST be sorted
+   using the binary representation of:
+
+      <lowest IP address in range> | <prefix length>
+
+   where "|" represents concatenation.  Note that the octets in this
+   representation (a.b.c.d | length for IPv4 or s:t:u:v:w:x:y:z | length
+   for IPv6) are not the octets that are in the DER-encoded BIT STRING
+   value.  For example, given two addressPrefix:
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 10]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+      IP addr | length  DER encoding
+      ----------------  ------------------------
+                        Type Len  Unused Bits...
+      10.32.0.0 | 12     03   03    04   0a 20
+      10.64.0.0 | 16     03   03    00   0a 40
+
+   the prefix 10.32.0.0/12 MUST come before the prefix 10.64.0.0/16
+   since 32 is less than 64; whereas if one were to sort by the DER BIT
+   STRINGs, the order would be reversed as the unused bits octet would
+   sort in the opposite order.  Any pair of IPAddressOrRange choices in
+   an extension MUST NOT overlap each other.  Any contiguous address
+   prefixes or ranges MUST be combined into a single range or, whenever
+   possible, a single prefix.
+
+2.2.3.7.  Type IPAddressOrRange
+
+   The IPAddressOrRange type is a CHOICE of either an addressPrefix (an
+   IP prefix or address) or an addressRange (an IP address range)
+   element.
+
+   This specification requires that any range of addresses that can be
+   encoded as a prefix MUST be encoded using an IPAddress element (a BIT
+   STRING), and any range that cannot be encoded as a prefix MUST be
+   encoded using an IPAddressRange (a SEQUENCE containing two BIT
+   STRINGs).  The following pseudo code illustrates how to select the
+   encoding of a given range of addresses.
+
+         LET  N = the number of matching most-significant bits in the
+                  lowest and highest addresses of the range
+         IF   all the remaining bits in the lowest address are zero-bits
+          AND all the remaining bits in the highest address are one-bits
+         THEN the range MUST be encoded as an N-bit IPAddress
+         ELSE the range MUST be encoded as an IPAddressRange
+
+2.2.3.8.  Element addressPrefix and Type IPAddress
+
+   The addressPrefix element is an IPAddress type.  The IPAddress type
+   defines a range of IP addresses in which the most-significant (left-
+   most) N bits of the address remain constant, while the remaining bits
+   (32 - N bits for IPv4, or 128 - N bits for IPv6) may be either zero
+   or one.  For example, the IPv4 prefix 10.64/12 corresponds to the
+   addresses 10.64.0.0 to 10.79.255.255, while 10.64/11 corresponds to
+   10.64.0.0 to 10.95.255.255.  The IPv6 prefix 2001:0:2/48 represents
+   addresses 2001:0:2:: to 2001:0:2:ffff:ffff:ffff:ffff:ffff.
+
+   An IP address prefix is encoded as a BIT STRING.  The DER encoding of
+   a BIT STRING uses the initial octet of the string to specify how many
+   of the least-significant bits of the last subsequent octet are
+
+
+
+Lynn, et al.                Standards Track                    [Page 11]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   unused.  The DER encoding specifies that these unused bits MUST be
+   set to zero-bits.
+
+   Example:
+             128.0.0.0       = 1000 0000.0000 0000.0000 0000.0000 0000
+          to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111
+        bit string to encode = 1000
+              Type Len  Unused Bits ...
+   Encoding = 0x03 0x02  0x04  0x80
+
+2.2.3.9.  Element addressRange and Type IPAddressRange
+
+   The addressRange element is of type IPAddressRange.  The
+   IPAddressRange type consists of a SEQUENCE containing a minimum
+   (element min) and maximum (element max) IP address.  Each IP address
+   is encoded as a BIT STRING.  The semantic interpretation of the
+   minimum address in an IPAddressRange is that all the unspecified bits
+   (for the full length of the IP address) are zero-bits.  The semantic
+   interpretation of the maximum address is that all the unspecified
+   bits are one-bits.  The BIT STRING for the minimum address results
+   from removing all the least-significant zero-bits from the minimum
+   address.  The BIT STRING for the maximum address results from
+   removing all the least-significant one-bits from the maximum address.
+
+   Example:
+             129.64.0.0       = 1000 0001.0100 0000.0000 0000.0000 0000
+          to 143.255.255.255  = 1000 1111.1111 1111.1111 1111.1111 1111
+           minimum bit string = 1000 0001.01
+           maximum bit string = 1000
+   Encoding = SEQUENCE {
+               Type Len  Unused Bits ...
+        min    0x03 0x03  0x06  0x81      0x40
+        max    0x03 0x02  0x04  0x80
+              }
+
+   To simplify the comparison of IP address blocks when performing
+   certification path validation, a maximum IP address MUST contain at
+   least one bit whose value is 1, i.e., the subsequent octets may not
+   be omitted nor all zero.
+
+2.3.  IP Address Delegation Extension Certification Path Validation
+
+   Certification path validation of a certificate containing the IP
+   address delegation extension requires additional processing.  As each
+   certificate in a path is validated, the IP addresses in the IP
+   address delegation extension of that certificate MUST be subsumed by
+   IP addresses in the IP address delegation extension in the issuer's
+   certificate.  Validation MUST fail when this is not the case.  A
+
+
+
+Lynn, et al.                Standards Track                    [Page 12]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   certificate that is a trust anchor for certification path validation
+   of certificates containing the IP address delegation extension, as
+   well as all certificates along the path, MUST each contain the IP
+   address delegation extension.  The initial set of allowed address
+   ranges is taken from the trust anchor certificate.
+
+3.  Autonomous System Identifier Delegation Extension
+
+   This extension conveys the allocation of autonomous system (AS)
+   identifiers to an entity by binding those AS identifiers to a public
+   key belonging to the entity.
+
+3.1.  Context
+
+   AS identifier delegation is currently managed by a hierarchy
+   nominally rooted at IANA, but managed by the RIRs.  IANA allocates AS
+   identifiers to the RIRs, who in turn assign AS identifiers to
+   organizations who are end entities, i.e., will not be re-allocating
+   any of their AS identifiers to other organizations.  The AS
+   identifier delegation extension is intended to enable verification of
+   the proper delegation of AS identifiers, i.e., of the authorization
+   of an entity to use these AS identifiers.  Accordingly, it makes
+   sense to take advantage of the inherent authoritativeness of the
+   existing administrative framework for management of AS identifiers.
+   As described in Section 1 above, this will be achieved by issuing
+   certificates carrying the extension described in this section.  An
+   example of one use of the information in this extension is an entity
+   using it to verify the authorization of an organization to manage the
+   AS identified by an AS identifier in the extension. The use of this
+   extension to represent assignment of AS identifiers is not intended
+   to alter the procedures by which AS identifiers are managed, or when
+   an AS should be used c.f., [RFC1930].
+
+3.2.  Specification
+
+3.2.1.  OID
+
+   The OID for this extension is id-pe-autonomousSysIds.
+
+      id-pe-autonomousSysIds  OBJECT IDENTIFIER ::= { id-pe 8 }
+
+   where [RFC3280] defines:
+
+      id-pkix  OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+               dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+      id-pe    OBJECT IDENTIFIER ::= { id-pkix 1 }
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 13]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+3.2.2.  Criticality
+
+   This extension SHOULD be CRITICAL.  The intended use of this
+   extension is to connote a right-to-use for the AS identifiers in the
+   extension.  A CA marks the extension as CRITICAL to convey the notion
+   that a relying party must understand the semantics of the extension
+   to make use of the certificate for the purpose it was issued.  Newly
+   created applications that use certificates containing this extension
+   are expected to recognize the extension.
+
+3.2.3.  Syntax
+
+   id-pe-autonomousSysIds  OBJECT IDENTIFIER ::= { id-pe 8 }
+
+   ASIdentifiers       ::= SEQUENCE {
+       asnum               [0] EXPLICIT ASIdentifierChoice OPTIONAL,
+       rdi                 [1] EXPLICIT ASIdentifierChoice OPTIONAL}
+
+   ASIdentifierChoice  ::= CHOICE {
+      inherit              NULL, -- inherit from issuer --
+      asIdsOrRanges        SEQUENCE OF ASIdOrRange }
+
+   ASIdOrRange         ::= CHOICE {
+       id                  ASId,
+       range               ASRange }
+
+   ASRange             ::= SEQUENCE {
+       min                 ASId,
+       max                 ASId }
+
+   ASId                ::= INTEGER
+
+3.2.3.1.  Type ASIdentifiers
+
+   The ASIdentifiers type is a SEQUENCE containing one or more forms of
+   autonomous system identifiers -- AS numbers (in the asnum element) or
+   routing domain identifiers (in the rdi element).  When the
+   ASIdentifiers type contains multiple forms of identifiers, the asnum
+   entry MUST precede the rdi entry.  AS numbers are used by BGP, and
+   routing domain identifiers are specified in the IDRP [RFC1142].
+
+3.2.3.2.  Elements asnum, rdi, and Type ASIdentifierChoice
+
+   The asnum and rdi elements are both of type ASIdentifierChoice.  The
+   ASIdentifierChoice type is a CHOICE of either the inherit or
+   asIdsOrRanges element.
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 14]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+3.2.3.3.  Element inherit
+
+   If the ASIdentifierChoice choice contains the inherit element, then
+   the set of authorized AS identifiers is taken from the issuer's
+   certificate, or from the issuer's issuer's certificate, recursively,
+   until a certificate containing an ASIdentifierChoice containing an
+   asIdsOrRanges element is located.  If no authorization is being
+   granted for a particular form of AS identifier, then there MUST NOT
+   be a corresponding asnum/rdi member in the ASIdentifiers sequence.
+
+3.2.3.4.  Element asIdsOrRanges
+
+   The asIdsOrRanges element is a SEQUENCE of ASIdOrRange types.  Any
+   pair of items in the asIdsOrRanges SEQUENCE MUST NOT overlap.  Any
+   contiguous series of AS identifiers MUST be combined into a single
+   range whenever possible.  The AS identifiers in the asIdsOrRanges
+   element MUST be sorted by increasing numeric value.
+
+3.2.3.5.  Type ASIdOrRange
+
+   The ASIdOrRange type is a CHOICE of either a single integer (ASId) or
+   a single sequence (ASRange).
+
+3.2.3.6.  Element id
+
+   The id element has type ASId.
+
+3.2.3.7.  Element range
+
+   The range element has type ASRange.
+
+3.2.3.8.  Type ASRange
+
+   The ASRange type is a SEQUENCE consisting of a min and a max element,
+   and is used to specify a range of AS identifier values.
+
+3.2.3.9.  Elements min and max
+
+   The min and max elements have type ASId.  The min element is used to
+   specify the value of the minimum AS identifier in the range, and the
+   max element specifies the value of the maximum AS identifier in the
+   range.
+
+3.2.3.10.  Type ASId
+
+   The ASId type is an INTEGER.
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 15]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+3.3.  Autonomous System Identifier Delegation Extension Certification
+      Path Validation
+
+   Certification path validation of a certificate containing the
+   autonomous system identifier delegation extension requires additional
+   processing.  As each certificate in a path is validated, the AS
+   identifiers in the autonomous system identifier delegation extension
+   of that certificate MUST be subsumed by the AS identifiers in the
+   autonomous system identifier delegation extension in the issuer's
+   certificate.  Validation MUST fail when this is not the case.  A
+   certificate that is a trust anchor for certification path validation
+   of certificates containing the autonomous system identifier
+   delegation extension, as well as all certificates along the path,
+   MUST each contain the autonomous system identifier delegation
+   extension.  The initial set of allowed AS identifiers is taken from
+   the trust anchor certificate.
+
+4.  Security Considerations
+
+   This specification describes two X.509 extensions.  Since X.509
+   certificates are digitally signed, no additional integrity service is
+   necessary.  Certificates with these extensions need not be kept
+   secret, and unrestricted and anonymous access to these certificates
+   has no security implications.
+
+   However, security factors outside the scope of this specification
+   will affect the assurance provided to certificate users.  This
+   section highlights critical issues that should be considered by
+   implementors, administrators, and users.
+
+   These extensions represent authorization information, i.e., a right-
+   to-use for IP addresses or AS identifiers.  They were developed to
+   support a secure version of BGP [S-BGP], but may be employed in other
+   contexts.  In the secure BGP context, certificates containing these
+   extensions function as capabilities: the certificate asserts that the
+   holder of the private key (the Subject) is authorized to use the IP
+   addresses or AS identifiers represented in the extension(s).  As a
+   result of this capability model, the Subject field is largely
+   irrelevant for security purposes, contrary to common PKI conventions.
+
+5.  Acknowledgments
+
+   The authors would like to acknowledge the contributions to this
+   specification by Charles Gardiner, Russ Housley, James Manger, and
+   Jim Schaad.
+
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 16]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+Appendix A -- ASN.1 Module
+
+   This normative appendix describes the IP address and AS identifiers
+   extensions used by conforming PKI components in ASN.1 syntax.
+
+   IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6)
+            internet(1) security(5) mechanisms(5) pkix(7) mod(0)
+            id-mod-ip-addr-and-as-ident(30) }
+       DEFINITIONS EXPLICIT TAGS ::=
+   BEGIN
+        -- Copyright (C) The Internet Society (2004). This    --
+        -- version of this ASN.1 module is part of RFC 3779;  --
+        -- see the RFC itself for full legal notices.         --
+
+   -- EXPORTS ALL --
+
+   IMPORTS
+
+   -- PKIX specific OIDs and arcs --
+       id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+                  id-mod(0) id-pkix1-explicit(18) };
+
+   -- IP Address Delegation Extension OID --
+
+   id-pe-ipAddrBlocks  OBJECT IDENTIFIER ::= { id-pe 7 }
+
+   -- IP Address Delegation Extension Syntax --
+
+   IPAddrBlocks        ::= SEQUENCE OF IPAddressFamily
+
+   IPAddressFamily     ::= SEQUENCE { -- AFI & opt SAFI --
+      addressFamily        OCTET STRING (SIZE (2..3)),
+      ipAddressChoice      IPAddressChoice }
+
+   IPAddressChoice     ::= CHOICE {
+      inherit              NULL, -- inherit from issuer --
+      addressesOrRanges    SEQUENCE OF IPAddressOrRange }
+
+   IPAddressOrRange    ::= CHOICE {
+      addressPrefix        IPAddress,
+      addressRange         IPAddressRange }
+
+   IPAddressRange      ::= SEQUENCE {
+      min                  IPAddress,
+      max                  IPAddress }
+
+   IPAddress           ::= BIT STRING
+
+
+
+Lynn, et al.                Standards Track                    [Page 17]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   -- Autonomous System Identifier Delegation Extension OID --
+
+   id-pe-autonomousSysIds  OBJECT IDENTIFIER ::= { id-pe 8 }
+
+   -- Autonomous System Identifier Delegation Extension Syntax --
+
+   ASIdentifiers       ::= SEQUENCE {
+       asnum               [0] ASIdentifierChoice OPTIONAL,
+       rdi                 [1] ASIdentifierChoice OPTIONAL }
+
+   ASIdentifierChoice  ::= CHOICE {
+      inherit              NULL, -- inherit from issuer --
+      asIdsOrRanges        SEQUENCE OF ASIdOrRange }
+
+   ASIdOrRange         ::= CHOICE {
+       id                  ASId,
+       range               ASRange }
+
+   ASRange             ::= SEQUENCE {
+       min                 ASId,
+       max                 ASId }
+
+   ASId                ::= INTEGER
+
+   END
+
+Appendix B -- Examples of IP Address Delegation Extensions
+
+   A critical X.509 v3 certificate extension that specifies:
+   IPv4 unicast address prefixes
+       1)  10.0.32/20     i.e., 10.0.32.0 to 10.0.47.255
+       2)  10.0.64/24     i.e., 10.0.64.0 to 10.0.64.255
+       3)  10.1/16        i.e., 10.1.0.0  to 10.1.255.255
+       4)  10.2.48/20     i.e., 10.2.48.0 to 10.2.63.255
+       5)  10.2.64/24     i.e., 10.2.64.0 to 10.2.64.255
+       6)  10.3/16        i.e., 10.3.0.0  to 10.3.255.255, and
+       7)  inherits all IPv6 addresses from the issuer's certificate
+   would be (in hexadecimal):
+
+   30 46                       Extension {
+      06 08 2b06010505070107     extnID        1.3.6.1.5.5.7.1.7
+      01 01 ff                   critical
+      04 37                      extnValue {
+         30 35                     IPAddrBlocks {
+            30 2b                    IPAddressFamily {
+               04 03 0001  01          addressFamily: IPv4 Unicast
+                                       IPAddressChoice
+               30 24                     addressesOrRanges {
+
+
+
+Lynn, et al.                Standards Track                    [Page 18]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+                                           IPAddressOrRange
+                  03 04 04 0a0020            addressPrefix 10.0.32/20
+                                           IPAddressOrRange
+                  03 04 00 0a0040            addressPrefix 10.0.64/24
+                                           IPAddressOrRange
+                  03 03 00 0a01              addressPrefix    10.1/16
+                                           IPAddressOrRange
+                  30 0c                      addressRange {
+                     03 04 04 0a0230           min        10.2.48.0
+                     03 04 00 0a0240           max        10.2.64.255
+                                             } -- addressRange
+                                           IPAddressOrRange
+                  03 03 00 0a03              addressPrefix    10.3/16
+                                         } -- addressesOrRanges
+                                     } -- IPAddressFamily
+            30 06                    IPAddressFamily {
+               04 02 0002              addressFamily: IPv6
+                                       IPAddressChoice
+               05 00                     inherit from issuer
+                                     } -- IPAddressFamily
+                                   } -- IPAddrBlocks
+                                 } -- extnValue
+                               } -- Extension
+
+   This example illustrates how the prefixes and ranges are sorted.
+
+   +  Prefix 1 MUST precede prefix 2, even though the number of unused
+      bits (4) in prefix 1 is larger than the number of unused bits (0)
+      in prefix 2.
+
+   +  Prefix 2 MUST precede prefix 3 even though the number of octets
+      (4) in the BIT STRING encoding of prefix 2 is larger than the
+      number of octets (3) in the BIT STRING encoding of prefix 3.
+
+   +  Prefixes 4 and 5 are adjacent (representing the range of addresses
+      from 10.2.48.0 to 10.2.64.255), so MUST be combined into a range
+      (since the range cannot be encoded by a single prefix).
+
+   +  Note that the six trailing zero bits in the max element of the
+      range are significant to the semantic interpretation of the value
+      (as all unused bits are interpreted to be 1's, not 0's).  The four
+      trailing zero bits in the min element are not significant and MUST
+      be removed (thus the (4) unused bits in the encoding of the min
+      element).  (DER encoding requires that any unused bits in the last
+      subsequent octet MUST be set to zero.)
+
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 19]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   +  The range formed by prefixes 4 and 5 MUST precede prefix 6 even
+      though the SEQUENCE tag for a range (30) is larger than the tag
+      for the BIT STRING (03) used to encode prefix 6.
+
+   +  The IPv4 information MUST precede the IPv6 information since the
+      address family identifier for IPv4 (0001) is less than the
+      identifier for IPv6 (0002).
+
+   An extension specifying the IPv6 prefix 2001:0:2/48 and the IPv4
+   prefixes 10/8 and 172.16/12, and which inherits all IPv4 multicast
+   addresses from the issuer's certificate would be (in hexadecimal):
+
+   30 3d                       Extension {
+      06 08 2b06010505070107     extnID        1.3.6.1.5.5.7.1.7
+      01 01 ff                   critical
+      04 2e                      extnValue {
+         30 2c                     IPAddrBlocks {
+            30 10                    IPAddressFamily {
+               04 03 0001 01           addressFamily: IPv4 Unicast
+                                       IPAddressChoice
+               30 09                     addressesOrRanges {
+                                           IPAddressOrRange
+                  03 02 00 0a                addressPrefix    10/8
+                                           IPAddressOrRange
+                  03 03 04 b010              addressPrefix    172.16/12
+                                         } -- addressesOrRanges
+                                     } -- IPAddressFamily
+            30 07                    IPAddressFamily {
+               04 03 0001 02           addressFamily: IPv4 Multicast
+                                       IPAddressChoice
+               05 00                     inherit from issuer
+                                     } -- IPAddressFamily
+            30 0f                    IPAddressFamily {
+               04 02 0002              addressFamily: IPv6
+                                       IPAddressChoice
+               30 09                     addressesOrRanges {
+                                           IPAddressOrRange
+                  03 07 00 200100000002      addressPrefix   2001:0:2/47
+                                         } -- addressesOrRanges
+                                     } -- IPAddressFamily
+                                   } -- IPAddrBlocks
+                                 } -- extnValue
+                                  } -- Extension
+
+
+
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 20]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+Appendix C -- Example of an AS Identifier Delegation Extension
+
+   An extension that specifies AS numbers 135, 3000 to 3999, and 5001,
+   and which inherits all routing domain identifiers from the issuer's
+   certificate would be (in hexadecimal):
+
+   30 2b                       Extension {
+      06 08 2b06010505070108     extnID        1.3.6.1.5.5.7.1.8
+      01 01 ff                   critical
+      04 1c                      extnValue {
+         30 1a                     ASIdentifiers {
+            a0 14                    asnum
+                                       ASIdentifierChoice
+               30 12                     asIdsOrRanges {
+                                           ASIdOrRange
+                  02 02 0087                 ASId
+                                           ASIdOrRange
+                  30 08                      ASRange {
+                     02 02 0bb8                min
+                     02 02 0f9f                max
+                                             } -- ASRange
+                                           ASIdOrRange
+                  02 02 1389                 ASId
+                                         } -- asIdsOrRanges
+                                     } -- asnum
+            a1 02                    rdi {
+                                       ASIdentifierChoice
+               05 00                     inherit from issuer
+                                     } -- rdi
+                                   } -- ASIdentifiers
+                                 } -- extnValue
+                               } -- Extension
+
+
+Appendix D -- Use of X.509 Attribute Certificates
+
+   This appendix discusses issues arising from a proposal to use
+   attribute certificates (ACs, as specified in [RFC3281]) to convey,
+   from the Regional Internet Registries (RIRs) to the end-user
+   organizations, the "right-to-use" for IP address blocks or AS
+   identifiers.
+
+   The two resources, AS identifiers and IP address blocks, are
+   currently managed differently.  All organizations with the right-to-
+   use for an AS identifier receive the authorization directly from an
+   RIR.  Organizations with a right-to-use for an IP address block
+   receive the authorization either directly from an RIR, or indirectly,
+   e.g., from a down stream service provider, who might receive its
+
+
+
+Lynn, et al.                Standards Track                    [Page 21]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   authorization from an Internet service provider, who in turn gets its
+   authorization from a RIR.  Note that AS identifiers might be sub-
+   allocated in the future, so the mechanisms used should not rely upon
+   a three level hierarchy.
+
+   In section 1 of RFC 3281, two reasons are given for why the use of
+   ACs might be preferable to the use of public key certificates (PKCs)
+   with extensions that convey the authorization information:
+
+      "Authorization information may be placed in a PKC extension or
+      placed in a separate attribute certificate (AC).  The placement of
+      authorization information in PKCs is usually undesirable for two
+      reasons.  First, authorization information often does not have the
+      same lifetime as the binding of the identity and the public key.
+      When authorization information is placed in a PKC extension, the
+      general result is the shortening of the PKC useful lifetime.
+      Second, the PKC issuer is not usually authoritative for the
+      authorization information.  This results in additional steps for
+      the PKC issuer to obtain authorization information from the
+      authoritative source."
+
+      "For these reasons, it is often better to separate authorization
+      information from the PKC.  Yet, authorization information also
+      needs to be bound to an identity.  An AC provides this binding; it
+      is simply a digitally signed (or certified) identity and set of
+      attributes."
+
+   In the case of the IP address and AS identifier authorizations, these
+   reasons do not apply.  First, the public key certificates are issued
+   exclusively for authorization, so the certificate lifetime
+   corresponds exactly to the authorization lifetime, which is often
+   tied to a contractual relationship between the issuer and entity
+   receiving the authorization.  The Subject and Issuer names are only
+   used for chaining during certification path validation, and the names
+   need not correspond to any physical entity.  The Subject name in the
+   PKCs may actually be randomly assigned by the issuing CA, allowing
+   the resource holder limited anonymity.  Second, the certificate
+   hierarchy is constructed so that the certificate issuer is
+   authoritative for the authorization information.
+
+   Thus the two points in the first cited paragraph above are not true
+   in the case of AS number and IP address block allocations.  The point
+   of the second cited paragraph is also not applicable as the resources
+   are not being bound to an identity but to the holder of the private
+   key corresponding to the public key in the PKC.
+
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 22]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+   RFC 3281 specifies several requirements that a conformant Attribute
+   Certificate must meet.  In relation to S-BGP, the more-significant
+   requirements are:
+
+   1  from section 1: "this specification does NOT RECOMMEND the use of
+      AC chains.  Other (future) specifications may address the use of
+      AC chains."
+
+      Allocation from IANA to RIRs to ISPs to DSPs and assignment to end
+      organizations would require the use of chains, at least for IP
+      address blocks.  A description of how the superior's AC should be
+      located and how it should be processed would have to be provided.
+      Readers of this document are encouraged to propose ways the
+      chaining might be avoided.
+
+   2  from section 4.2.9: "section 4.3 defines the extensions that MAY
+      be used with this profile, and whether or not they may be marked
+      critical.  If any other critical extension is used, the AC does
+      not conform to this profile.  However, if any other non-critical
+      extension is used, the AC does conform to this profile."
+
+      This means that the delegation extensions defined in this
+      specification, which are critical, could not be simply placed into
+      an AC.  They could be used if not marked critical, but the
+      intended use requires that the extensions be critical so that the
+      certificates containing them cannot be used as identity
+      certificates by an unsuspecting application.
+
+   3  from section 4.5: "an AC issuer, MUST NOT also be a PKC issuer.
+      That is, an AC issuer cannot be a CA as well."
+
+      This means that for each AC issuer there would need to be a
+      separate CA to issue the PKC that contains the public key of the
+      AC holder.  The AC issuer cannot issue the PKC of the holder, and
+      the PKC issuer cannot sign the AC.  Thus, each entity in the PKI
+      would need to operate an AC issuer in addition to its CA.  There
+      would be twice as many certificate issuers and CRLs to process to
+      support Attribute certificates than are needed if PKCs are used.
+      The possibility of mis-alignment also arises when there are two
+      issuers issuing certificates for a single purpose.
+
+      The AC model of RFC 3281 implies that the AC holder presents the
+      AC to the AC verifier when the holder wants to substantiate an
+      attribute or authorization.  The intended usage for the extensions
+      defined herein does not have a direct interaction between an AC
+      verifier (a NOC) and the AC issuers (all RIRs and NOCs).  Given a
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 23]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+      signature on a claimed right-to-use object, the "AC verifier" can
+      locate the AC holder's PKC, but there is no direct way to locate
+      the Subject's AC(s).
+
+   4  from section 5: "4.  The AC issuer MUST be directly trusted as an
+      AC issuer (by configuration or otherwise)."
+
+      This is not true in the case of a right-to-use for an IP address
+      block, which is allocated through a hierarchy.  Certification path
+      validation of the AC will require chaining up through the
+      delegation hierarchy.  Having to configure each relying party
+      (NOC) to "trust" every other NOC does not scale, and such "trust"
+      has resulted in failures that the proposed security mechanisms are
+      designed to prevent.  A single PKI with a trusted root is used,
+      not thousands of individually trusted per-ISP AC issuers.
+
+      The amount of work that would be required to properly validate an
+      AC is larger than for the mechanism that places the certificate
+      extensions defined in this document in the PKCs.  There would be
+      twice as many certificates to be validated, in addition to the
+      ACs.  There could be a considerable increase in the management
+      burden required to support ACs.
+
+References
+
+Normative References
+
+   [IANA-AFI]  http://www.iana.org/assignments/address-family-numbers.
+
+   [IANA-SAFI] http://www.iana.org/assignments/safi-namespace.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Level", BCP 14, RFC 2119, March 1997.
+
+   [RFC3280]   Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+               X.509 Public Key Infrastructure Certificate and
+               Certificate Revocation List (CRL) Profile", RFC 3280,
+               April 2002.
+
+   [X.690]     ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
+               "Information Technology - ASN.1 Encoding Rules:
+               Specification of Basic Encoding Rules (BER), Canonical
+               Encoding Rules (CER) and Distinguished Encoding Rules
+               (DER)".
+
+
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 24]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+Informational References
+
+   [RFC791]    Postel, J., "Internet Protocol -- DARPA Internet Program
+               Protocol Specification", RFC 791, September 1981.
+
+   [RFC1142]   D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol",
+               RFC 1142, February 1990.
+
+   [RFC1771]   Rekhter, Y. and T. Li, Eds., "A Border Gateway Protocol 4
+               (BGP-4)", RFC 1771, March 1995.
+
+   [RFC1930]   Hawkinson, J. and T. Bates, "Guidelines for creation,
+               selection, and registration of an Autonomous System
+               (AS)", BCP 6, RFC 1930, March 1996.
+
+   [RFC2050]   Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and
+               J. Postel, "Internet Registry IP Allocation Guidelines",
+               BCP 12, RFC 2050, November 1996.
+
+   [RFC3513]   Hinden, R. and S. Deering, "Internet Protocol Version 6
+               (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [RFC3281]   Farrell, S. and R. Housley, "An Internet Attribute
+               Certificate Profile for Authorization", RFC 3281, April
+               2002.
+
+   [S-BGP]     S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
+               Protocol (S-BGP)," IEEE JSAC Special Issue on Network
+               Security, April 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 25]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+Authors' Address
+
+   Charles Lynn
+   BBN Technologies
+   10 Moulton St.
+   Cambridge, MA 02138
+   USA
+
+   Phone: +1 (617) 873-3367
+   EMail: CLynn@BBN.Com
+
+
+   Stephen Kent
+   BBN Technologies
+   10 Moulton St.
+   Cambridge, MA 02138
+   USA
+
+   Phone: +1 (617) 873-3988
+   EMail: Kent@BBN.Com
+
+
+   Karen Seo
+   BBN Technologies
+   10 Moulton St.
+   Cambridge, MA 02138
+   USA
+
+   Phone: +1 (617) 873-3152
+   EMail: KSeo@BBN.Com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 26]
+
+RFC 3779         X.509 Extensions for IP Addr and AS ID        June 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Lynn, et al.                Standards Track                    [Page 27]
+