class ara::crypto::x509::CertificateValidationCtx

use

The method AddOcspResponse of the class ara::crypto::x509::CertificateValidationCtx validates a passed OCSP response (ocspResponse) and, if valid, adds it to the set of already stored OCSP responses in the validation context [SWS_CRYPT_50124]. Multiple responses can be added to a context [SWS_CRYPT_50124]. Via the optional parameter trustedOcspIssuerCertificate, a specific certificate can be passed that is considered trusted during the check of the OCSP response; if this parameter is omitted, the validation draws on the certificates previously configured by means of AddTrustedCertificate [SWS_CRYPT_50124].

The synchronous call returns a ara::core::Result<CertificateValidationStatus>, which contains the status kValid upon successful acceptance or otherwise represents the result of the OCSP validation or an error [SWS_CRYPT_50124].

Error handling

The specification does not define any standardized error codes for this call [SWS_CRYPT_50124]. If the operation fails, either the corresponding validation status is conveyed in the result or an implementation-specific error is signaled via the Result object [SWS_CRYPT_50124].

Concurrency and Limitations

The operation is specified as thread-safe and exception-safe [SWS_CRYPT_50124]. For the validation of the OCSP response to succeed, one of the following conditions must be met [SWS_CRYPT_50124]:

• The issuer was previously stored in the context as a trusted or untrusted certificate [SWS_CRYPT_50124].
• The signature originates from a certificate with set extension id-kp-OCSPSigning of the same certificate authority (CA) [SWS_CRYPT_50124].
• The signature originates from a trusted CA that was passed directly via trustedOcspIssuerCertificate [SWS_CRYPT_50124].

Interaction

The registered OCSP responses are incorporated into downstream validation checks, such as those performed by [SWS_CRYPT_50122] (ValidateCertificate) and [SWS_CRYPT_50123] (ValidateCertificateChain). Interpretation: The OCSP responses likely have to be added before starting the path validation so that the revocation status of the certificates can be taken into account. Question Q-fbb0711617fd7895 (open)

The method AddTrustedCertificate of class ara::crypto::x509::CertificateValidationCtx adds another certificate to the set of trusted certificates for subsequent validations [SWS_CRYPT_50117].

use

The call is made via the interface in ara/crypto/x509/certificate_validation_ctx.h. As parameter, trustedCertificate of type Certificate::Sptrc is passed, which is considered trusted during certificate path validation [SWS_CRYPT_50117]. Upon successful execution, the function returns an empty ara::core::Result<void> [SWS_CRYPT_50117].

Error handling

The specification defines no standardized error codes for this function [SWS_CRYPT_50117]. If an error occurs during processing, an implementation-specific error is reported via the ara::core::Result [SWS_CRYPT_50117].

Concurrency and Limitations

The method is declared as noexcept=0, is considered exception safe (exception safe), and is explicitly specified as thread-safe (thread-safe) [SWS_CRYPT_50117].

Interaction

The registered trusted certificates interact with other functions of the validation context:

• In ValidateCertificateChain, a certificate chain is validated according to RFC 5280 against the trusted certificates previously stored via AddTrustedCertificate, while untrusted certificates are ignored [SWS_CRYPT_50123].
• In AddOcspResponse, a trusted certificate previously set in the context can be used as an issuer to check the validity of the OCSP response [SWS_CRYPT_50124].

The method AddUntrustedCertificate of context type ara::crypto::x509::CertificateValidationCtx adds an untrusted certificate to the set of previously registered certificates so that it can be taken into account during certificate path validation [SWS_CRYPT_50118]. Inclusion is done via header file #include "ara/crypto/x509/certificate_validation_ctx.h" [SWS_CRYPT_50118]. A smart pointer to the certificate to be considered (Certificate::Sptrc untrustedCertificate) is passed as a parameter [SWS_CRYPT_50118]. Since the method immediately returns an ara::core::Result<void>, the registration should presumably be handled synchronously [SWS_CRYPT_50118]. Question Q-879b384ff6efe687 (open)

Regarding error handling, AUTOSAR specifies no standardized error codes for this interface [SWS_CRYPT_50118]. In the success case, the returned ara::core::Result contains no value (void); in the error case, it returns an implementation-specific error code [SWS_CRYPT_50118]. Callers must therefore check the result object for errors before further use of the validation context. The method is declared as noexcept and classified as exception-safe (exception safe), meaning that no C++ exceptions are propagated across the interface boundary [SWS_CRYPT_50118].

The operation is explicitly declared as thread-safe (thread-safe) [SWS_CRYPT_50118]. Multiple threads can thus concurrently feed certificates into the same validation context. The call should reasonably take place before the start of path validation to ensure that all required certificates are available for the validation algorithm [SWS_CRYPT_50118].

use

The method IgnoreCriticalExtension on [SWS_CRYPT_50119] configures the instance of ara::crypto::x509::CertificateValidationCtx so that a specific certificate extension is ignored during the verification of certificates and OCSP responses. This also applies if the extension is marked as critical and is not originally supported by the validation context. Parameter ignoredExtensionOid accepts the OID of the extension to be ignored as ara::core::StringView. Multiple calls result in all passed extension OIDs being ignored. Execution is synchronous and declared as noexcept.

Error Handling and Concurrency

The function specifies no standardized error codes; in the success case, it returns an empty ara::core::Result<void>, whereas in the error case, an implementation-specific error code is contained [SWS_CRYPT_50119]. Regarding concurrency, the interface is specified as thread-safe (thread-safe) and exception-safe (exception safe).

Restrictions and Interaction

If a critical extension is ignored, the functional validation of this extension is entirely the responsibility of the application [SWS_CRYPT_50119]. If the validation option kIgnoreUnknownCriticalExtensions is set, the call has no additional effect. Ignoring unsupported critical extensions should prevent subsequent path verification within [SWS_CRYPT_40203] (for instance, when determining the CertificateValidationStatus) from failing. Question Q-a087c9a9543c092a (open)

use

According to [SWS_CRYPT_50120], the method SetValidationOptions of class ara::crypto::x509::CertificateValidationCtx is used to define the options for performing a certificate validation. As parameter, the pure virtual function expects CertificateValidationOptions, a bitmask for identifying the desired validation options. The call is provided via the header ara/crypto/x509/certificate_validation_ctx.h.

Error handling

According to [SWS_CRYPT_50120], the interface returns a ara::core::Result<void>. Upon successful execution, the result contains no value (empty result). If an invalid value is passed for the options, the operation fails with the error code ara::crypto::CryptoErrc::kInvalidArgument. Here, rollback semantics apply. If another error occurs, an implementation-specific error code can be returned.

Concurrency and Limitations

According to [SWS_CRYPT_50120], the method is specified as thread-safe (thread-safe) and may be called concurrently. It is also declared as exception-safe (exception safe) as well as with noexcept, which is why no exceptions may be thrown across the interface boundary.

The method ValidateCertificate of the class ara::crypto::x509::CertificateValidationCtx from the header ara/crypto/x509/certificate_validation_ctx.h performs a synchronous certificate path validation according to RFC 5280 [SWS_CRYPT_50122]. The validation check is performed based on the prior configuration of the instance context. As the only input parameter, the certificate to be validated is passed via the pointer certificate of type Certificate::Sptrc [SWS_CRYPT_50122].

ara::core::Result<CertificateValidationResult::Sptrc> serves as the return type, which contains a pointer to the validation result in the event of success or provides an error code in the event of an error [SWS_CRYPT_50122]. In addition to implementation-specific errors, the specific error code ara::crypto::CryptoErrc::kIncompatibleArguments can occur [SWS_CRYPT_50122]. This has rollback semantics and is returned if an OCSP response was stored by means of AddOcspResponse, but the configured CertificateValidationOptions do not specify any OCSP behavior.

Regarding execution safety and concurrency, the method is specified as thread-safe (thread-safe) as well as exception-safe (exception safe) and does not throw any exceptions (noexcept) [SWS_CRYPT_50122]. As an ordering prerequisite, it must be noted that the validation context must be initialized and configured beforehand, as the check builds directly on its presets [SWS_CRYPT_50122].

The method ValidateCertificateChain in the context ara::crypto::x509::CertificateValidationCtx performs a synchronous path validation of a certificate chain according to RFC 5280 [SWS_CRYPT_50123].

Usage and Parameters

As input, the function expects a chain of type ara::core::Span<Certificate::Sptrc> via the parameter certificateChain. Here, element 0 represents the leaf certificate, whereas each subsequent element must contain the issuer of the respective preceding certificate [SWS_CRYPT_50123]. The function ignores certificates that were previously registered via AddUntrustedCertificate, and validates the passed chain exclusively against trust anchors deposited via AddTrustedCertificate [SWS_CRYPT_50123].

Error handling

The result is provided encapsulated as ara::core::Result<CertificateValidationResult::Sptrc>, which contains either a pointer to the validation result or an error code [SWS_CRYPT_50123]. The error ara::crypto::CryptoErrc::kIncompatibleArguments occurs with rollback semantics if an OCSP response was previously set via AddOcspResponse, but the current CertificateValidationOptions do not define any OCSP behavior [SWS_CRYPT_50123]. Other error causes are reported back as implementation-specific error codes [SWS_CRYPT_50123].

Concurrency and Execution Safety

The interface is declared as noexcept, is considered exception safe, and is classified as thread-safe for concurrent access [SWS_CRYPT_50123].