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
#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);
Both RFC 3779 extensions require additional checking in the
certification path validation.
- The initial set of allowed IP address and AS number resources is defined
in the trust anchor, where inheritance is not allowed.
- An issuer may only delegate subsets of resources present in its RFC 3779
extensions or subsets of resources inherited from its issuer.
- If an RFC 3779 extension is present in a certificate, the same type of
extension must also be present in its issuer.
- 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.
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.
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
These functions first appeared in OpenSSL 0.9.8e and have been
available since OpenBSD 7.1.