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:
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
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
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 }
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.
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.
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.
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
-- 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 {
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.)
+ 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