WDIFF

draft-ietf-pkix-x509-ipaddr-as-extn-00.txt --> draft-ietf-pkix-x509-ipaddr-as-extn-03.txt

Internet Draft Stephen Kent
draft-ietf-pkix-x509-ipaddr-as-extn-00.txt
draft-ietf-pkix-x509-ipaddr-as-extn-03.txt Karen Seo
Expires August 2002 March 2004 BBN Technologies
February 2002
September 2003

X.509 Extensions for IP Addresses and AS Identifiers

Status of this Memo

This document is an Internet Draft Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. Internet Drafts Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet Drafts.

Internet Drafts Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts Internet-Drafts as reference
material or to cite them other than as "work in progress".

The list of current Internet Drafts Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of current Internet Draft Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document defines two private 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 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 autonomous system identifiers contained in the
extensions.

Please send comments on this draft to the ietf-pkix@imc.org mail
list.

Expires March 2004 Lynn, Kent, Seo [Page 1]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

Table of Contents

Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 1 2

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3

Expires August 2002 Lynn, Kent, Seo [Page 1]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4

2. IP Address Delegation Extension . . . . . . . . . . . . . . . 4 6
2.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6
2.1.1. Encoding of an IP Address or Prefix . . . . . . . . . . . 6
2.1.2. Encoding of a Range of IP Addresses . . . . . . . . . . . 8
2.2. Specification . . . . . . . . . . . . . . . . . . . . . . . 4 9
2.2.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 9
2.2.2. Criticality. Criticality . . . . . . . . . . . . . . . . . . . . . . . 5 9
2.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 10
2.2.3.1. Type IPAddrBlocks . . . . . . . . . . . . . . . . . . . 6 10
2.2.3.2. Type IPAddressFamily . . . . . . . . . . . . . . . . . . 6 10
2.2.3.3. Element addressFamily . . . . . . . . . . . . . . . . . 6 10
2.2.3.4. Element ipAddressChoice and Type IPAddressChoice . . . . 6 11
2.2.3.5. Element inherit . . . . . . . . . . . . . . . . . . . . 6 11
2.2.3.6. Element addressesOrRanges . . . . . . . . . . . . . . . 7 11
2.2.3.7. Type IPAddressOrRange . . . . . . . . . . . . . . . . . 7 12
2.2.3.8. Element addressPrefix and Type IPAddress . . . . . . . . 7 12
2.2.3.9. Element addressRange and Type IPAddressRange . . . . . . 8 12
2.3. IP Address Delegation Extension Certification Path
Validation . . 9 13

3. Autonomous System Identifier Delegation Extension . . . . . . 9 13
3.1. Context. Context . . . . . . . . . . . . . . . . . . . . . . . . . . 9 14
3.2. Specification. Specification . . . . . . . . . . . . . . . . . . . . . . . 10 14
3.2.1. OID. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 14
3.2.2. Criticality . . . . . . . . . . . . . . . . . . . . . . . 10 14
3.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 10 15
3.2.3.1. Type ASIdentifiers . . . . . . . . . . . . . . . . . . . 11 15
3.2.3.2. Elements asnum, rdi, and Type ASIdentifierChoice . . . . 11 15
3.2.3.3. Element inherit . . . . . . . . . . . . . . . . . . . . 11 15
3.2.3.4. Element asIdOrRanges . . . . . . . . . . . . . . . . . . 12 16
3.2.3.5. Type ASIdOrRange . . . . . . . . . . . . . . . . . . . . 12 16
3.2.3.6. Element id . . . . . . . . . . . . . . . . . . . . . . . 12 16
3.2.3.7. Element range . . . . . . . . . . . . . . . . . . . . . 12 16
3.2.3.8. Type ASRange . . . . . . . . . . . . . . . . . . . . . . 12 16
3.2.3.9. Elements min and max . . . . . . . . . . . . . . . . . . 12 16
3.2.3.10. Type ASId . . . . . . . . . . . . . . . . . . . . . . . 12 16
3.3. Autonomous System Identifier Delegation Extension
Certification Path Validation . . 12 16

4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 17

5. Acknowledgements . . IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13

Appendix A -- Examples of IP Address Delegation 17

Expires March 2004 Lynn, Kent, Seo [Page 2]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

6. Acknowledgments . . . . 13
Appendix B -- Example of an AS Identifier Delegation Extension . . 17
References . . . . . . . . . . . . . . . . . 17

Appendix A -- ASN.1 Module . . . . . . . . . . . 18
Disclaimer . . . . . . . . . 18

Appendix B -- Examples of IP Address Delegation Extensions . . . . 20

Appendix C -- Example of an AS Identifier Delegation Extension . . 23

Appendix D -- Use of X.509 Attribute Certificates . . . . . . . . 24

References . . . . . 18 . . . . . . . . . . . . . . . . . . . . . . . 27
Normative References . . . . . . . . . . . . . . . . . . . . . . . 27
Informational References . . . . . . . . . . . . . . . . . . . . . 27

Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 28

Intellectual Property Rights . . Statement . . . . . . . . . . . . . . . . . 19 29

Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 20 29

Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 2] 3]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002 September 2003

1. Introduction

This document defines two private X.509 v3 certificate extensions. extensions that
authorize the transfer of the right to use 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, or often
represented as IP address prefixes, to the subject (private key
holder) of a certificate. The second binds a list of Autonomous System autonomous
system (AS) Identifiers identifiers to the subject (private key holder) of a
certificate. These extensions convey that the subject "owns" or is
authorized to use the IP address blocks and AS Identifiers contained
in the extensions. The issuer of the certificate would typically be
the is an entity (e.g., the
IANA, a regional Internet registry, or an ISP) who owns that has the authority
to transfer custodianship ("allocate") of the set of IP address
blocks and AS Identifiers from which the subject's IP
address blocks or AS Identifiers have been taken and who made identifiers to the
delegation subject of the resources to the subject. certificate. These
certificates provide a scalable means of verifying the ownership usage right of
IP address prefixes and AS Identifiers, e.g., they can identifiers, and may be used by routing
protocols
protocols, such as Secure BGP [S-BGP] [S-BGP], to verify legitimacy/correctness legitimacy and
correctness of routing information.

It is assumed 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 reply parties do
not need either to sort the information, or to implement extra code
in the subset checking algorithms to handle several boundary cases
(adjacent, overlapping, or subsumed allocations).

1.1. Terminology

It is assumed that the reader is familiar with the terms and concepts
described in [PKIX-1], [RFC2459] (PKIX "Internet X.509 certificate profile),
[RFC791] (IPv4), [RFC2373] (IPv6). Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC3280], "INTERNET
PROTOCOL" [RFC791], "Internet Protocol Version 6 (IPv6) Addressing
Architecture" [RFC3513], and "INTERNET REGISTRY IP ALLOCATION
GUIDELINES" [RFC2050] and related regional Internet registry address
management policy documents. Some relevant terms include:

advertise

Autonomous System (AS) - (see [RFC1771]). 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.

Expires March 2004 Lynn, Kent, Seo [Page 4]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

Autonomous System number - a 32-bit number that identifies an
autonomous system.

delegate - Transfer ownership of custodianship (that is, the usage right) of an
IP address block or AS identifier through issuance of a
certificate to the new owner.

downstream service provider (DSP) - Second or lower tier internet
service provider. an entity.

initial octet - the first octet in the value of a DER encoded BIT
STRING [X.690].

IP v4 address (IPv4) - a 32-bit identifier written as four decimal numbers,
each in the range 0 to 255, separated by "."s. a ".". 10.5.0.5 is an example.
example of an IPv4 address.

IP v6 address (IPv6) - a 128-bit identifier written as eight hexadecimal
quantities, each in the range 0 to ffff, separated by
":"s. 2001:0:2:3:0:0:0:1 a ":".
2001:0:200:3:0:0:0:1 is an example. example of an IPv6 address. One string
of :0:
quantities fields may be replaced by "::", thus 2001:0:2:3::1 2001:0:200:3::1
represents the same address as the immediately preceding example.
(See
[RFC2373]).

own [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 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 advertisement of the prefix throughout
the Internet. For an Autonomous System Identifier, autonomous system identifier, being
authorized to operate a network(s) that identifies itself to other
network operators using that Autonomous System Identifier. Or, for
either, being authorized to delegate ownership to another entity.

Expires August 2002 Lynn, Kent, Seo [Page 3]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002 autonomous system identifier.

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].

Expires March 2004 Lynn, Kent, Seo [Page 5]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

2. IP Address Delegation Extension

This extension conveys the delegation of ownership allocation of IP addresses to
the subject an entity by
binding those addresses to a public key belonging to the subject. entity.

2.1. Context

IP address space is currently managed by a hierarchy nominally rooted
at ICANN, IANA, but managed by Internet Regional Registries (e.g., APNIC,
ARIN, and RIPE). ICANN delegates the RIRs. IANA allocates IP address space to
the Registries, RIRs, who in turn delegate allocate IP address space to internet Internet service
providers (ISPs), who delegate may allocate IP address space to down stream providers
(DSPs),
providers, customers, etc. Any level in the hierarchy can The RIRs may also delegate assign IP address space
to organizations who are end entities, i.e., organizations who will
not be re-delegating 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 this ownership the proper delegation of IP address blocks, i.e., of
the authorization of an entity to use or delegate sub-allocate IP address
space. Accordingly, it makes sense to take advantage of the inherent
authoritativeness of the existing hierarchy administrative framework for
delegating IP address space. Thus the PKI hierarchy for issuing certificates with As described in Section 1 above, this
extension SHOULD parallel the IP address delegation hierarchy. The
roots of the PKI hierarchy will be the regional Internet Registries
(i.e., APNIC, ARIN, RIPE, etc.), the next level down
will be achieved by issuing certificates carrying the
ISPs, etc. extension
described in this section. An example of one use of the information
in this extension is a router 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 block; see, e.g., [RFC1771], [S-BGP].

2.2. Specification

2.2.1. OID

The OID for this extension is id-pe-ipAddrBlock.

id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }

where [RFC2459] defines

Expires August 2002 Lynn, Kent, Seo [Page 4]

Internet Draft X.509 Extensions for

2.1.1. Encoding of an IP Addr and AS ID February 2002

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 }

2.2.2. Criticality

This extension can be CRITICAL Address or NOT CRITICAL at the discretion of
the CA issuing the certificate. The intended use Prefix

There are two families of this extension IP addresses: IPv4 and IPv6.

An IPv4 address is to connote ownership of a 32-bit quantity that is written as four decimal
numbers, each in the block(s) of IP addresses identified in
the extension. A CA might well mark the extension as CRITICAL to
convey the notion that range 0 through 255, separated by a relying party must understand the semantics dot (".");
10.5.0.5 is an example of an IPv4 address.

An IPv6 address is a 128-bit quantity that is written as eight
hexadecimal numbers, each in the extension to make use range 0 through ffff, separated by a
semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of the certificate. Newly created
applications that would make use an IPv6
address. IPv6 addresses frequently have adjacent fields whose value
is 0. One such group of certificates containing this
extension would 0 fields may be expected to recognize the extension. However,
many common application implementations (e.g., browsers) that might
make use of certificates that contain this extension, (as clients not
as replying parties) do not tolerate CRITICAL private extensions, and abbreviated by two
semicolons ("::"). The previous example may thus be represented by
2001:0:200:3::1.

An address prefix is a CA may choose to not mark this extension as CRITICAL, to avoid
compatibility problems with these application implementations.

2.2.3. Syntax

id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }

IPAddrBlocks ::= SEQUENCE OF IPAddressFamily

IPAddressFamily ::= SEQUENCE {
addressFamily OCTET STRING (SIZE (2..3)), -- AFI & opt SAFI
ipAddressChoice IPAddressChoice }

IPAddressChoice ::= CHOICE {
inherit BOOLEAN, -- Inherit set of 2^k continuous addresses whose more-
significant bits are identical. For example, the set of 512 IPv4
addresses from Issuer
addressesOrRanges SEQUENCE OF IPAddressOrRange }

IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }

IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }

IPAddress ::= BIT STRING 10.5.0.0 through 10.5.1.255 all have the same 23 most-

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 5] 6]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

2.2.3.1. Type IPAddrBlocks September 2003

significant bits. The IPAddrBlocks type is a sequence set of IPAddressFamily types.

2.2.3.2. Type IPAddressFamily

The IPAddressFamily type addresses is written by appending a sequence containing an addressFamily
slash ("/") and ipAddressChoice element.

2.2.3.3. Element addressFamily the number of constant bits to the lowest address in
the set. The addressFamily element prefix for the example set 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).
AFI's and SAFI's are specified in [IANA] and [RFC2283], respectively.

There MUST be only one IPAddressFamily sequence per unique
combination of AFI 10.5.0.0/23, 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 a SAFI. When both IPv4 and
2^(32-23) = 2^9 addresses. The set of IPv6 addresses are specified,
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 IPv4 addresses MUST precede less-significant zero fields, but there should be enough
fields to contain the IPv6 addresses (since indicated number of constant bits. The
abbreviated forms of the example IPv4
AFI of 0001 prefix is less than 10.5.0/23 and of the
example IPv6 AFI of 0002).

2.2.3.4. Element ipAddressChoice and Type IPAddressChoice

The ipAddressChoice element 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 IPAddressChoice. (0x03), followed by (an
encoding of) the number of value octets, followed by the value. The
IPAddressChoice type is a CHOICE
value consists of either an inherit or
addressesOrRanges element.

2.2.3.5. Element inherit

If "initial octet" that specifies the IPAddressChoice choice contains number of
unused bits in the inherit element, then last value octet, followed by the
BOOLEAN MUST be TRUE. In this case, "subsequent
octets" that contain the set octets of authorized the bit string. (For IP
addresses for
addresses, the specified AFI and optional SAFI is taken from encoding of the
Issuer's certificate, or length will be just the Issuer's Issuer's certificate,
recursively, until length.)

In the case of a certificate containing an IPAddressChoice
containing single address, all the bits are constant, so the
bit string for an addressesOrRanges element 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 located. If no
authorization 0x00. The octets in the DER-encoded BIT STRING is being granted for a particular AFI and optional
SAFI, then 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

In this case the three subsequent octets contain 24 bits, but the
prefix only uses 23, so there SHOULD NOT be an IPAddressFamily member for that
AFI/SAFI is one unused bit in the IPAddrBlocks sequence; i.e., last octet,
thus the AFI/SAFI should initial octet is 1 (the DER require that all unused bits
MUST be
omitted rather than setting inherit BOOLEAN set to FALSE. 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:

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 6] 7]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

2.2.3.6. Element addressesOrRanges

The addressesOrRanges element is September 2003

Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02

2.1.2. Encoding of a sequence Range of IPAddressOrRange
types. The addressPrefixes and addressRange elements MUST be sorted
using the representation IP address/prefix length. Note that the
bytes in this Addresses

While any contiguous range of IP addresses can be represented by a
set of contiguous prefixes, a more concise representation (a.b.c.d/length for IPv4 or
s:t:u:v:w:x:y:z/length for IPv6) are not in is achieved
by encoding the same order range as occurs
in a DER SEQUENCE containing the lowest address and
the highest address, where each address is encoded as a BIT STRING. For example, given two addressPrefixes:

IP addr/length DER encoding
-------------- --------------
10.32.0.0/12 03 03 04 0a 20
10.64.0.0/16 03 03 00 0a 40
Within the prefix 10.32.0.0/12 MUST come before SEQUENCE, the prefix 10.64.0.0/16
since 32 bit string representing the lowest address
in the range is less than 64; whereas if one were to sort 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
STRINGs, the order would be reversed as STRING encoding requires that all 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 last octet MUST be combined into set to zero-bits. Note that a prefix
can always be expressed as a range, but a single range or, when
possible, cannot always be
expressed as a single prefix.

2.2.3.7. Type IPAddressOrRange

The IPAddressOrRange type is a CHOICE of either an addressPrefix (an
IP address Prefix) or an addressRange (an IP address range) element.

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 represented by the most significant (left-
most) N bits 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 remain constant while ends in nine one-bits that are removed. The DER-
encoding of the remaining bits
(32 - N for IPv4, or 128 - N for IPv6) may be either zero or one. A resulting twenty-three-bit string is:

Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00

The prefix is written 2001:0:200/39 can be encoded as the constant octets followed by a "/" and range where the
number DER-
encoding of constant bits (N). For example, the IPv4 prefix 10.64/12
corresponds to 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 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
unused. DER encoding specifies that these unused bits MUST be set to
zero. 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
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 -- 0x03,
0x01, 0x00. Note that the number of trailing zero bits is
significant for IP addresses. For example, the DER encoding of octets:

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 7] 8]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

10.64/12, 0x03, 0x03, 0x04, 0x0a, 0x40, September 2003

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 10.64/11,
encoded as 0x03, 0x03, 0x05, 0x0a, 0x40.

2.2.3.9. Element addressRange and the DER-encoding of 10.64.0/20:

Type IPAddressRange Len Unused Bits ...
0x03 0x04 0x04 0x0a 0x40 0x00

2.2. Specification
2.2.1. OID

The addressRange element OID for this extension is of type IPAddressRange. id-pe-ipAddrBlock.

id-pe-ipAddrBlock 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 }

2.2.2. Criticality

This extension SHOULD be CRITICAL. The
IPAddressRange type consists intended use of a SEQUENCE containing a minimum
(element min) and maximum (element max) IP address. Each IP address this
extension is encoded as to connote a BIT STRING. The semantic interpretation of usage right to the
minimum address block(s) of IP addresses
identified in an IPAddressRange is that all the unspecified bits
(for extension. A CA marks the full length of extension as CRITICAL to
convey the IP address) are zero-bits (0). The
semantic interpretation notion that a relying party MUST understand the semantics
of the maximum address is that all extension to make use of the
unspecified bits are one-bits (1).

Note that an IP address prefix can be encoded as a range, where the
minimum and maximum values would be identical. However, a range of
IP addresses MUST, whenever possible, be encoded as a single prefix
and NOT be encoded as a range.

1) Address ranges (bit strings) should be sorted into ascending order
by most-significant address bits

2) Contiguous prefixes and/or ranges MUST be combined into a single
prefix (whenever possible) or range.

Let "LMBx" denote the "Left Most Bits of x".

3) If a range is of the form minimum IP address = <n LMBp><zeros>
and maximum IP address = <n LMBp><ones>,
where n >= 0, then the prefix form MUST be used:
BIT STRING ((8 - (n mod 8)) mod 8) <n LMBp><zero pad last byte>
else the min/max form MUST be used.

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 4 128 -- 1000

4) A min/max form with minimum IP address = <(i - 1) LMBn><1><zeros>
and maximum IP address = <(j - 1) LMBx><0><ones>
MUST be encoded as:
SEQUENCE {
BIT STRING ((8 - (i mod 8)) mod 8) <i LMBn><zero pad last byte>
BIT STRING ((8 - (j mod 8)) mod 8) <j LMBx><zero pad last byte>
}

I.e., all trailing zero bits are removed from certificate for the min and all
trailing 1 bits purpose it
was issued. Newly created applications that use certificates
containing this extension are removed from expected to recognize the max.

Example: extension.

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 8] 9]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

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 September 2003

2.2.3. Syntax

id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }

IPAddrBlocks ::= SEQUENCE OF IPAddressFamily

IPAddressFamily ::= SEQUENCE {
BIT STRING 6 129 64 -- 1000 0001.01
BIT STRING 4 128 AFI & optional SAFI -- 1000
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }

To simplify the comparison of IP address blocks when performing
certificate path validation, a maximum IP address MUST contain at
least one bit whose value is 1, i.e., the subsequent octets may
neither be omitted nor all zero.

NOTE: this specification could require that the least
significant bit in the encoding of the

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 be a 1.
This would insure that

2.2.3.1. Type IPAddrBlocks

The IPAddrBlocks type is a broken ASN.1 DER encoder that removes
all trailing zero bits, when DER encoding SEQUENCE OF IPAddressFamily types.

2.2.3.2. Type IPAddressFamily

The IPAddressFamily type is a BIT STRING, does
not silently change the semantics of the max SEQUENCE containing an addressFamily
and ipAddressChoice element.

SHOULD THE SPECIFICATION REQUIRE THIS DEFENSIVE ACTION?

2.3. IP Address Delegation Extension Certification Path Validation

Certification path validation of a certificate

2.2.3.3. Element addressFamily

The addressFamily element is an OCTET STRING containing the IP
address delegation extension requires additional processing. As each
certificate a two-octet
Address Family Identifier (AFI), in network byte order, optionally
followed by a path one-octet Subsequent Address Family Identifier (SAFI).
AFIs and SAFIs are specified in [IANA-AFI] and [IANA-SAFI],
respectively.

If no authorization is validated, the IP addresses being granted for a particular AFI and
optional SAFI, then there MUST NOT be an IPAddressFamily member for
that AFI/SAFI in the IP
address delegation extension IPAddrBlocks SEQUENCE.

There MUST be only one IPAddressFamily SEQUENCE per unique
combination of that certificate must AFI and SAFI. Each SEQUENCE MUST be subsumed ordered by
IP addresses in
ascending addressFamily values (treating the IP address delegation extension in the issuer's
certificate.

3. Autonomous System Identifier Delegation Extension

This extension conveys the delegation of ownership of Autonomous
System (AS) identifiers to the subject by binding those AS
identifiers to a public key belonging to the subject.

3.1. Context

AS identifier delegation is currently managed by a hierarchy with
roots at ICANN and the Internet Registries (APNIC, ARIN, RIPE, etc.).
ICANN delegates AS identifiers to the Registries, who in turn
delegate AS identifiers to organizations who are end entities, i.e.,
will not be re-delegating any of their identifiers to other
organizations. The AS identifier delegation extension is intended to
enable verification of this ownership 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 hierarchy for delegating AS identifiers. Thus the PKI
hierarchy for issuing certificates with this extension SHOULD octets as unsigned

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 9] 10]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

parallel September 2003

quantities). An addressFamily without a SAFI MUST precede one that
contains a SAFI. When both IPv4 and IPv6 addresses are specified,
the AS identifier delegation hierarchy. The roots of IPv4 addresses MUST precede the
PKI hierarchy will be IPv6 addresses (since the regional Internet Registries (i.e., APNIC,
ARIN, RIPE, etc.). An example IPv4
AFI of one use 0001 is less than the IPv6 AFI of this extension 0002).

2.2.3.4. Element ipAddressChoice and Type IPAddressChoice

The ipAddressChoice element is of type IPAddressChoice. The
IPAddressChoice type is a
router using it to verify the authorization CHOICE of either an organization to
prepend an AS Number to inherit or
addressesOrRanges element.

2.2.3.5. Element inherit

If the AS_PATH attribute IPAddressChoice CHOICE contains the inherit element, then the
set of a BGP UPDATE
[S-BGP].

3.2. Specification

3.2.1. OID

The OID authorized IP addresses for this extension is id-pe-autonomousSysId.

id-pe-autonomousSysId OBJECT IDENTIFIER ::= { id-pe 8 }

where [RFC2459] 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 }

3.2.2. Criticality

This extension can be CRITICAL or NOT CRITICAL at the discretion of specified AFI and optional
SAFI is taken from the CA issuing issuer's certificate, or the certificate. 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 intended use of this extension addressesOrRanges element is to connote ownership of a SEQUENCE OF IPAddressOrRange
types. The addressPrefix and addressRange elements MUST be sorted
using the AS identifiers binary representation of:

where "|" represents concatenation. Note that the extension. A CA
might well mark the extension as CRITICAL to convey 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 notion octets that a
relying party must understand are in the semantics of DER-encoded BIT STRING
value. For example, given two addressPrefix:

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 extension 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 make
use of sort by the certificate. Newly created applications that would make
use of certificates containing this extension DER BIT
STRINGs, the order would be expected to
recognize reversed as the extension. However, many common application
implementations (e.g., browsers) that might make use unused bits octet would
sort in the opposite order. Any pair of certificates
that contain this extension, (as clients not as replying parties) do
not tolerate CRITICAL private extensions, and thus a CA may choose to
not mark this IPAddressOrRange choices in
an extension as CRITICAL, to avoid compatibility problems
with these application implementations.

3.2.3. Syntax MUST NOT overlap each other. Any contiguous address
prefixes or ranges MUST be combined into a single range or, whenever
possible, a single prefix.

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 10] 11]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

id-pe -autonomousSysId OBJECT IDENTIFIER ::= { id-pe 8 }

ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}

ASIdentifierChoice ::= CHOICE {
inherit BOOLEAN, -- 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. September 2003

2.2.3.7. Type ASIdentifiers IPAddressOrRange

The ASIdentifiers IPAddressOrRange type is a SEQUENCE containing one CHOICE of either an addressPrefix (an
IP prefix or more forms address) or an addressRange (an IP address range)
element.

This specification requires that any range of
Autonomous System identifiers -- AS numbers (in addresses that can be
encoded as 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 asnum element) or
Routing Domain Identifiers (in
encoding of a given range of addresses.

LET N = the rdi element). When number of matching most-significant bits in the
ASIdentifiers type contains multiple forms
lowest and highest addresses of identifiers, the asnum
entry will precede range
IF all the rdi entry. AS numbers are used by BGP and
Routing Domain Identifiers remaining bits in the lowest address are specified zero-bits
AND all the remaining bits in the IDRP.

3.2.3.2. Elements asnum, rdi, 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 ASIdentifierChoice IPAddress

The asnum and rdi elements are both of type ASIdentifierChoice. addressPrefix element is an IPAddress type. The
ASIdentifierChoice IPAddress type is
defines a CHOICE range of either the inherit or
asIdsOrRanges element.

3.2.3.3. Element inherit

If the ASIdentifierChoice choice contains the inherit element, then
the BOOLEAN MUST be TRUE. In this case, IP addresses in which the set most-significant (left-
most) N bits of authorized AS
identifiers is taken from the Issuer's certificate, or address remain constant while the Issuer's
Issuer's certificate, recursively, until a certificate containing an
ASIdentifierChoice containing an sasIdsOrRanges element is located.
If no authorization is being granted remaining bits
(32 - N bits for a particular form of AS
identifier then there SHOULD NOT IPv4, or 128 - N bits for IPv6) may be an asnum/rdi member in either zero
or one. For example, the
ASIdentifiers sequence; i.e., IPv4 prefix 10.64/12 corresponds to the member should be omitted rather
than setting inherit BOOLEAN
addresses 10.64.0.0 to FALSE.

Expires August 2002 Lynn, Kent, Seo [Page 11]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

3.2.3.4. Element asIdsOrRanges 10.79.255.255 while 10.64/11 corresponds to
10.64.0.0 to 10.95.255.255. The asIdsOrRanges element 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 SEQUENCE BIT STRING. The DER encoding of ASIdOrRange types. Any
pair
a BIT STRING uses the initial octet of items in the asIdsOrRanges SEQUENCE MUST NOT overlap.

3.2.3.5. Type ASIdOrRange

The ASIdOrRange type is a CHOICE string to specify how many
of either a single integer (ASId) or
a single sequence (ASRange).

3.2.3.6. Element id the least-significant bits of the last subsequent octet are
unused. The id element has type ASId.

3.2.3.7. 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 range

The range element has type ASRange.

3.2.3.8. addressRange and Type ASRange IPAddressRange

The ASRange type is a SEQUENCE of a min and a max addressRange 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 elements specifies the value of the maximum AS identifier in the
range.

3.2.3.10. Type ASId IPAddressRange. The ASId
IPAddressRange type is an INTEGER.

3.3. Autonomous System Identifier Delegation Extension Certification
Path Validation

Certification path validation consists of a certificate SEQUENCE 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. minimum
(element min) and maximum (element max) IP address. Each IP address

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 12]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

4. Security Considerations

This specification describes two private X.509 extensions. Since
X.509 certificates are digitally signed, no additional integrity
service September 2003

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., ownership
of IP addresses and/or AS identifiers. They were developed to
support encoded as a secure version BIT STRING. The semantic interpretation of BGP, but may be employed in other
contexts. In the secure BGP context, certificates containing these
extensions function as capabilities, i.e., the certificate asserts
minimum address in an IPAddressRange is that all the holder of unspecified bits
(for the private key (the Subject) owns full length of the IP
addresses and/or AS identifiers represented in the extension(s). As
a result address) are zero-bits. The semantic
interpretation of this capability model, the Subject field maximum address is largely
irrelevant that all the unspecified
bits are one-bits. The BIT STRING for security purposes, contrary to common PKI conventions.

5. Acknowledgements the minimum address results
from removing all the least-significant zero-bits from the minimum
address. The authors would like to acknowledge BIT STRING for the contributions 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 this
specification by Charles Gardiner and Russ Housley.

Providing feedback could get your name here!

Appendix A -- Examples 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 Delegation Extensions

A non-critical X.509 v3 address blocks when performing
certificate extension that specifies:
IPv4 unicast path validation, a maximum IP 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 MUST contain at
least one bit whose value is 1, i.e., 10.3.0.0 to 10.3.255.255
and
7) inherits the subsequent octets may
neither be omitted nor all IPv6 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 from in the Issuer's IP
address delegation extension of that certificate
would MUST be (in hexadecimal): 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
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.

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 13]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

30 44 Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
critical FALSE (thus omitted)
04 38 extnValue {
30 36 IPAddrBlocks {
30 2b IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice {
30 24 addressesOrRanges {
IPAddressOrRange {
03 04 04 0a0020 addressPrefix 10.0.32/20
} -- IPAddressOrRange
IPAddressOrRange {
03 04 00 0a0040 addressPrefix 10.0.64/24
} -- IPAddressOrRange
IPAddressOrRange {
03 03 00 0a01 addressPrefix 10.1/16
} -- IPAddressOrRange
IPAddressOrRange {
30 0c addressRange {
03 04 04 0a0230 min 10.2.48.0
03 04 00 0a0240 max 10.2.64.255
} -- addressRange
} -- IPAddressOrRange
IPAddressOrRange {
03 03 00 0a03 addressPrefix 10.3/16
} -- IPAddressOrRange
} -- addressesOrRanges
} -- IPAddressChoice
} -- IPAddressFamily
30 07 IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice {
01 01 ff inherit: TRUE from Issuer
} -- IPAddressChoice
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension

This example illustrates how September 2003

3.1. Context

AS identifier delegation is currently managed by a hierarchy
nominally rooted at IANA, but managed by the prefixes and ranges are sorted.

+ Prefix 1 precedes prefix 2, even though RIRs. IANA allocates AS
identifiers to the number of unused bits
(4) RIRs, who in prefix 1 turn allocate AS identifiers to
organizations who are end entities, i.e., will not be re-delegating
any of their AS identifiers to other organizations. The AS
identifier delegation extension is larger than the number intended to enable verification of unused bits (0) in
prefix 2.

+ Prefix 2 precedes prefix 3 even though
the number proper delegation of octets (4) in
the BIT STRING encoding AS identifiers, i.e., of prefix 2 is larger than the number authorization
of
octets (3) in the BIT STRING encoding an entity to use these AS identifiers. Accordingly, it makes
sense to take advantage of prefix 3.

+ Prefixes 4 and 5 are adjacent (representing the range inherent authoritativeness of address

Expires August 2002 Lynn, Kent, Seo [Page 14]

Internet Draft X.509 Extensions the
existing administrative framework for IP Addr and delegating AS ID February 2002

from 10.2.48.0 to 10.2.64.255), so MUST identifiers. As
described in Section 1 above, this will be combined into a range
(since the range cannot be encoded achieved by a single prefix).

+ Note that issuing
certificates carrying the six trailing zero bits extension described in the max element this section. An
example of one use of the
range are significant information in this extension is an entity
using it to verify the semantic interpretation authorization of the value
(as all unused bits are interpreted an organization to be 1's, not 0's). The four
trailing zero bits in the min element are not significant and MUST
be removed (thus manage the (4) unused bits
AS identified by an AS identifier in the encoding extension.

3.2. Specification
3.2.1. OID

The OID for this extension is id-pe-autonomousSysId.

id-pe-autonomousSysId 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 }

3.2.2. Criticality

This extension SHOULD be CRITICAL. The intended use of this
extension is to connote usage right to the min
element). (DER encoding requires that unused bits AS identifiers in the last
subsequent octet be set
extension. A CA marks the extension as CRITICAL to zero.)

+ The range formed by prefixes 4 and 5 precedes prefix 6 even though convey the SEQUENCE encoding for notion
that a range (30) is larger than relying party must understand the encoding
for a BIT STRING (03) used to encode a prefix.

+ The IPv4 information precedes semantics of the IPv6 information since extension
to make use of the
address family identifier certificate for IPv4 (0001) is less than the
identifier for IPv6 (0002).

An purpose it was issued. Newly
created applications that use certificates containing this extension specifying the IPv6 prefix 2001:0:2/48 and
are expected to recognize the IPv4
prefixes 10/8 and 172.16/12, and which inherits all IPv4 multicast
addresses from the issuer's certificate would be: extension.

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 15] 14]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

30 3b Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
critical FALSE (thus omitted)
04 2f extnValue {
30 2d IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice {
30 09 addressesOrRanges {
IPAddressOrRange {
03 02 00 0a addressPrefix 10/8
} -- IPAddressOrRange
IPAddressOrRange September 2003

3.2.3. Syntax

id-pe-autonomousSysId OBJECT IDENTIFIER ::= {
03 03 04 b010 addressPrefix 172.16/12
} -- IPAddressOrRange
} -- addressesOrRanges
} -- IPAddressChoice id-pe 8 } -- IPAddressFamily
30 08 IPAddressFamily

ASIdentifiers ::= SEQUENCE {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}

ASIdentifierChoice ::= CHOICE {
01 01 ff inherit: TRUE
inherit NULL, -- inherit from Issuer
} issuer -- IPAddressChoice
asIdsOrRanges SEQUENCE OF ASIdOrRange } -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice {
30 09 addressesOrRanges {
IPAddressOrRange

ASIdOrRange ::= CHOICE {
03 07 00 200100000002 addressPrefix 2001:0:2/48
} -- IPAddressOrRange
} -- addressesOrRanges
} -- IPAddressChoice
} -- IPAddressFamily
} -- IPAddrBlocks
id ASId,
range ASRange } -- extnValue

ASRange ::= SEQUENCE {
min ASId,
max ASId } -- Extension

Expires August 2002 Lynn, Kent, Seo [Page 16]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

Appendix B -- Example

ASId ::= INTEGER

3.2.3.1. Type ASIdentifiers

The ASIdentifiers type is a SEQUENCE containing one or more forms of an AS Identifier Delegation Extension

An extension that specifies
autonomous system identifiers -- AS Numbers 135, 3000 to 3999, and 5001,
and which inherits all Routing Domain Identifiers from numbers (in the issuers
certificate would be asnum element) or
routing domain identifiers (in hexadecimal):

30 29 Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
critical FALSE (thus omitted)
04 1d extnValue {
30 1b the rdi element). When the
ASIdentifiers {
a0 14 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 {
30 12 asIdsOrRanges {
ASIdOrRange {
02 02 0087 ASId
} -- ASIdOrRange
ASIdOrRange {
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
} -- ASIdOrRange
ASIdOrRange {
02 02 1389 ASId
} -- ASIdOrRange
} -- asIdsOrRanges
} -- ASIdentifierChoice
} --

The asnum
a1 03 and rdi { elements are both of type ASIdentifierChoice. The
ASIdentifierChoice {
01 01 ff type is a CHOICE of either the inherit
} -- or
asIdsOrRanges element.

3.2.3.3. Element inherit

If the ASIdentifierChoice
} -- rdi
} -- choice contains the inherit element, then
the set of authorized AS identifiers is taken from the issuer's
certificate, or 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
an asnum/rdi member in the ASIdentifiers
} -- extnValue
} -- Extension sequence.

Expires March 2004 Lynn, Kent, Seo [Page 15]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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 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 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.

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

Expires March 2004 Lynn, Kent, Seo [Page 16]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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.

These extensions represent authorization information, i.e., a usage
right to 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. IANA Considerations

This specification does not introduce any additional IANA
considerations.

Insert the RFC number at the beginning of the ASN.1 module in
Appendix A.

6. Acknowledgments

The authors would like to acknowledge the contributions to this
specification by Charles Gardiner, Russ Housley, James Manger, and
Jim Schaad.

Expires March 2004 Lynn, Kent, Seo [Page 17]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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 (2003). This --
-- version of this ASN.1 module is part of RFC xxxx; --
-- 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-ipAddrBlock 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

Expires March 2004 Lynn, Kent, Seo [Page 18]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

-- Autonomous System Identifier Delegation Extension OID --

id-pe-autonomousSysId 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

Expires March 2004 Lynn, Kent, Seo [Page 19]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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 {
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.

Expires March 2004 Lynn, Kent, Seo [Page 20]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

+ 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.)

+ 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).

Expires March 2004 Lynn, Kent, Seo [Page 21]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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:

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

Expires March 2004 Lynn, Kent, Seo [Page 22]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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 issuers
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

Expires March 2004 Lynn, Kent, Seo [Page 23]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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" 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 an AS identifier receive the authorization directly from an RIR.
Organizations with a right-to-use 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 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 why the use of ACs
might be preferable to 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

Expires March 2004 Lynn, Kent, Seo [Page 24]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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.

RFC 3281 specifies several requirements that a conformant Attribute
Certificates 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."

Delegation from IANA to RIRs to ISPs to DSPs to end organizations
would require the use of chains, at least for IP address block
delegation. A description of how the superior's AC should be
located and its processed would have to provide. 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 the extensions be critical so that the
certificates that contain 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

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 17] 25]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002

References

[IANA] IANA web page, http://www.iana.org, has assignments September 2003

AC to the AC verifier when the holder wants to substantiate an
attribute or authorization. The intended usage for
several number spaces, including "Address Family Numbers".

[PKIX-1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509
Public Key Infrastructure Certificate the extensions
defined herein does not have a direct interaction between an AC
verifier (a NOC) and CRL Profile",
draft-ietf-pkix-new-part1-08.txt, July 2001.

[PKIX-ALG] Bassham, L., Housley, R., the AC issuers (all RIRs and W. Polk, "Internet X.509
Public Key Infrastructure Representation NOCs). Given a
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 Public Keys
and Digital Signatures,"
draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000.

[RFC1700] Reynolds, J., right to use an IP address block,
which is delegated through a hierarchy. Path validation of the AC
will require chaining up through the delegation hierarchy. Having
to configure each replying party (NOC) to "trust" every other NOC
does not scale, and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. (see also
http://www.iana.org/iana/assignments.html) 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 S-BGP
extensions in the PKCs. There are twice as many certificates to
be validated, in addition to the ACs. There could be considerable
increase in the management burden required to support ACs.

Expires March 2004 Lynn, Kent, Seo [Page 26]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

References

Normative References

[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.

[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 00009, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.

[RFC2373]

[RFC3279] W. Polk, R. Housley, and L. Bassham, " Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.

[RFC3280] R. Housley, W. Polk, W. Ford, 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)".

Informational References

[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol",
February 1990.

[RFC1771] Y. Rekhter, T. Li, Eds., "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.

[RFC2050] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J.
Postel, "Internet Registry IP Allocation Guidelines", RFC
2050, BCP 00012, November 1996.

[RFC3513] R. Hinden, S. Deering, "IP "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 2373, July 1998.

[RFC2459] 3513, April 2003.

[RFC3280] R. Housley, R., Ford, W., Polk, W., W. Ford, D. Solo, D., "Internet X.509
Public Key Infrastructure Certificate and CRL Certificate
Revocation List (CRL) Profile", RFC 2459, January 1999. 3280, April 2002.

[RFC3281] S. Farrell, and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April

Expires March 2004 Lynn, Kent, Seo [Page 27]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

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.

[X.509] ITU-T Recommendation X.509 (1997 E): "Information
Technology - Open Systems Interconnection - The
Directory: Authentication Framework", June 1997.

Disclaimer

The views and specification here are those of the authors and are not
necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems

Expires August 2002 Lynn, Kent, Seo [Page 18]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002
arising from correct or incorrect implementation or use of this
specification.

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

Expires March 2004 Lynn, Kent, Seo [Page 28]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

Intellectual Property Rights Statement

The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurance 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 implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any

Expires August 2002 Lynn, Kent, Seo [Page 19]

Internet Draft X.509 Extensions for IP Addr and AS ID February 2002
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

Expires August 2002 March 2004 Lynn, Kent, Seo [Page 20] 29]

Internet Draft X.509 Extensions for IP Addr and AS ID September 2003

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Expires March 2004 Lynn, Kent, Seo [Page 30]
----