*** UNIX MANUAL PAGE BROWSER ***

X509V3_ADDR_VALIDATE_PATH(3) FreeBSD Library Functions Manual NAME X509v3_addr_validate_path, X509v3_addr_validate_resource_set, X509v3_asid_validate_path, X509v3_asid_validate_resource_set - RFC 3779 path validation for IP address and AS number delegation SYNOPSIS #include <openssl/x509v3.h> int X509v3_addr_validate_path(X509_STORE_CTX *ctx); int X509v3_addr_validate_resource_set(STACK_OF(X509) *chain, IPAddrBlocks *addrblocks, int allow_inherit); int X509v3_asid_validate_path(X509_STORE_CTX *ctx); int X509v3_asid_validate_resource_set(STACK_OF(X509) *chain, ASIdentifiers *asid, int allow_inherit); DESCRIPTION Both RFC 3779 extensions require additional checking in the certification path validation. 1. The initial set of allowed IP address and AS number resources is defined in the trust anchor, where inheritance is not allowed. 2. An issuer may only delegate subsets of resources present in its RFC 3779 extensions or subsets of resources inherited from its issuer. 3. If an RFC 3779 extension is present in a certificate, the same type of extension must also be present in its issuer. 4. All RFC 3779 extensions appearing in the validation path must be in canonical form according to X509v3_addr_is_canonical(3) and X509v3_asid_is_canonical(3). X509v3_addr_validate_path() and X509v3_asid_validate_path() are called from X509_verify_cert(3) as part of the verification chain building. On encountering an error or a violation of the above rules, error, error_depth, and current_cert are set on ctx and the verify callback is called with ok set to 0. X509_V_ERR_INVALID_EXTENSION indicates a non- canonical resource, X509_V_ERR_UNNESTED_RESOURCE indicates a violation of the other rules above. In rare circumstances, the error can be X509_V_ERR_UNSPECIFIED and for IP address resources X509_V_ERR_OUT_OF_MEM is also possible. X509v3_addr_validate_resource_set() validates the resources in addrblocks against a specific certificate chain. After checking that addrblocks is canonical, its IP addresses are checked to be covered in the certificate at depth 0, then the chain is walked all the way to the trust anchor until an error or a violation of the above rules is encountered. addrblocks is allowed to use inheritance according to X509v3_addr_inherits(3) if and only if allow_inherit is non-zero. X509v3_asid_validate_resource_set() performs similar checks as X509v3_addr_validate_resource_set() for asid. RETURN VALUES All these functions return 1 on successful validation and 0 otherwise. For X509v3_addr_validate_path() and X509v3_asid_validate_path() a non- empty chain and a verify_cb must be present on ctx, otherwise they fail and set the error on ctx to X509_V_ERR_UNSPECIFIED. The verify_cb is called with the error codes described above on most errors encountered during validation. Some malformed extensions can lead to an error that cannot be intercepted by the callback. With the exception of an allocation error, no error codes are set on the error stack. X509v3_addr_validate_resource_set() accepts a NULL addrblocks and X509v3_asid_validate_resource_set() accepts a NULL asid as valid. They fail if chain is NULL or empty. If allow_inherit is 0, addrblocks or asid is checked for inheritance with X509v3_addr_inherits(3) or X509v3_asid_inherits(3). The remaining failure cases are the same as for X509v3_addr_validate_path() and X509v3_asid_validate_path(). They cannot and do not attempt to communicate the cause of the error to the caller. SEE ALSO ASIdentifiers_new(3), crypto(3), IPAddressRange_new(3), X509_new(3), X509_STORE_CTX_get_error(3), X509_verify_cert(3), X509v3_addr_add_inherit(3), X509v3_addr_inherits(3), X509v3_asid_add_id_or_range(3) STANDARDS RFC 3779: X.509 Extensions for IP Addresses and AS Identifiers: - section 2.3: IP Address Delegation Extension Certification Path Validation - section 3.3: Autonomous System Identifier Delegation Extension Certification Path Validation RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile - section 6: Certification Path Validation HISTORY These functions first appeared in OpenSSL 0.9.8e and have been available since OpenBSD 7.1. FreeBSD 14.1-RELEASE-p8 September 30, 2023 FreeBSD 14.1-RELEASE-p8