X.509 Extensions for IP Addresses and AS Identifiers
Extracted elements (24)
The encoding rules were designed to produce a unique canonical encoding so that two extension instances can be compared for equality octet-by-octet, to achieve minimal size, and to allow relying parties to use one-pass subset-checking algorithms during path validation without needing to sort or handle adjacent/overlapping/subsumed ranges.
The Subject and Issuer names in these PKCs are used only for chaining during certification path validation and need not correspond to any physical entity. The Subject name may be randomly assigned by the issuing CA, allowing the resource holder limited anonymity while still supporting the right-to-use model.
X.509 public key certificates with extensions were chosen over attribute certificates (RFC 3281) because: the PKC lifetime corresponds exactly to the authorization lifetime; the certificate issuer is authoritative for the authorization information; AC chains are not recommended by RFC 3281 but are required for IP address sub-allocation hierarchies; and the critical extensions could not be placed in ACs without violating the profile.
The addressesOrRanges SEQUENCE MUST be sorted by the binary representation of the lowest IP address concatenated with prefix length — NOT by the DER BIT STRING encoding. These orderings differ: for example, 10.32.0.0/12 (unused bits=4) sorts before 10.64.0.0/16 (unused bits=0) by address, but the DER encoding sorts them in reverse order due to the unused-bits octet.
These extensions were developed to support Secure BGP (S-BGP) for verifying the legitimacy and correctness of routing information, but may be employed in other contexts such as Internet routing registries. The use of the AS identifier extension is not intended to alter existing procedures for AS identifier management.
A maximum IP address in an IPAddressRange MUST contain at least one bit whose value is 1; the subsequent octets may not be omitted or all zero. This ensures unambiguous semantic interpretation that all unspecified high-address bits are ones.
A range of addresses that can be encoded as a prefix MUST be encoded using an IPAddress BIT STRING element; a range that cannot be encoded as a prefix MUST be encoded using an IPAddressRange SEQUENCE of two BIT STRINGs.
Any pair of IPAddressOrRange choices in an extension MUST NOT overlap. Any contiguous address prefixes or ranges MUST be combined into a single range or, whenever possible, a single prefix. The addressesOrRanges SEQUENCE MUST be sorted by the binary representation of the lowest IP address concatenated with the prefix length.
Both the IP address delegation extension and the AS identifier delegation extension SHOULD be marked CRITICAL so that relying parties that do not understand the extension cannot use the certificate for the purpose it was issued.
During certification path validation of a certificate containing the AS identifier delegation extension, the AS identifiers MUST be subsumed by those in the issuer's certificate. Validation MUST fail otherwise, and every certificate in the path and the trust anchor MUST each contain the AS identifier delegation extension.
If no authorization is being granted for a particular AFI and optional SAFI, there MUST NOT be an IPAddressFamily member for that AFI/SAFI in the IPAddrBlocks SEQUENCE. Similarly, if no authorization is being granted for a particular AS identifier form, there MUST NOT be a corresponding asnum/rdi member in the ASIdentifiers SEQUENCE.
In the ASIdentifiers SEQUENCE, the asnum entry MUST precede the rdi entry when both are present. Any pair of items in asIdsOrRanges MUST NOT overlap; contiguous AS identifiers MUST be combined into a single range; AS identifiers MUST be sorted by increasing numeric value.
There MUST be only one IPAddressFamily SEQUENCE per unique combination of AFI and SAFI, and each SEQUENCE MUST be ordered by ascending addressFamily values (treating octets as unsigned). An addressFamily without a SAFI MUST precede one with a SAFI; IPv4 MUST precede IPv6.
The AS Identifier Delegation Extension (id-pe-autonomousSysIds, OID { id-pe 8 }) binds a list of autonomous system identifiers to the subject of an X.509 v3 certificate, conveying authorization to operate networks using those AS identifiers.
The ASIdentifierChoice CHOICE contains either an inherit element (NULL) or an asIdsOrRanges element (SEQUENCE OF ASIdOrRange). The inherit mechanism recursively delegates AS identifier authorization up the certificate chain.
The IP Address Delegation Extension (id-pe-ipAddrBlocks, OID { id-pe 7 }) binds a list of IP address blocks or prefixes to the subject of an X.509 v3 certificate, conveying authorization to use or sub-allocate that IP address space.
The IPAddressChoice CHOICE contains either an inherit element (NULL) or an addressesOrRanges element (SEQUENCE OF IPAddressOrRange). When inherit is present, the authorized IP addresses are taken from the issuer's certificate chain recursively until an addressesOrRanges element is found.
This document allocates two OIDs in the id-pe arc of the PKIX OID hierarchy: id-pe-ipAddrBlocks (id-pe 7) for the IP address delegation extension, and id-pe-autonomousSysIds (id-pe 8) for the AS identifier delegation extension.
Since X.509 certificates are digitally signed, no additional integrity service is required for these extensions. Certificates need not be kept secret, and unrestricted anonymous access has no security implications. However, the assurance provided depends critically on security factors outside this specification's scope.
These extensions represent authorization information functioning as capabilities: the certificate asserts that the holder of the private key is authorized to use the IP addresses or AS identifiers in the extension. As a result, the Subject field is largely irrelevant for security purposes, contrary to common PKI conventions.
A range of IP addresses is encoded as a SEQUENCE of two BIT STRINGs: the minimum address with all trailing zero-bits removed, and the maximum address with all trailing one-bits removed. The special all-addresses prefix '0/0' MUST be encoded with length octet 1, initial octet 0, and no subsequent octets.
An IP address or prefix is encoded as a DER-encoded ASN.1 BIT STRING. The initial octet specifies the number of unused bits in the last value octet; unused bits MUST be set to zero. An IPv4 address uses 32 bits (4 subsequent octets); an IPv6 address uses 128 bits (16 subsequent octets); a prefix uses only the constant most-significant bits.
ASIdentifiers is a SEQUENCE with an optional asnum element (tag [0]) of type ASIdentifierChoice and an optional rdi element (tag [1]) of type ASIdentifierChoice. Each ASId is encoded as an INTEGER; an ASRange is a SEQUENCE of min and max ASId INTEGERs.
The addressFamily element is an OCTET STRING of size 2 to 3 containing a two-octet AFI in network byte order, optionally followed by a one-octet SAFI. IPv4 unicast uses AFI 0001 SAFI 01; IPv6 uses AFI 0002.