Download the Cryptlib manual

200
Certificates in Detail
CRYPT_Reduced level of compliance with X.509 and
COMPLIANCELEVEL_ PKIX standards. This omits handling of
PKIX_PARTIAL
problematic extensions such as name and policy
constraints, whose semantics no-one can quite
agree on, and a few other problematic
extensions defined in various certificate
standards, but checks and enforces all other
PKIX requirements. As with CRYPT_COMLPIANCELEVEL_PKIX_FULL, this
level of checking will reject a number of
certificates in use today.
CRYPT_Moderate level of checking equivalent to that
COMPLIANCELEVEL_ performed by most software in use today. Many
STANDARD
of the more complex and/or obscure extensions
are ignored, which makes it possible to process
certificates generated by other software that
similarly ignores them. In addition many X.509
and PKIX compliance requirements are
significantly relaxed, so that (for example) the
mandatory key usage extension, if absent, may
be synthesised from other information present in
the certificate.
CRYPT_Minimal level of checking required to handle
COMPLIANCELEVEL_ severely broken certificates. All extensions
REDUCED
except the ones controlling certificate and
certificate key usage are ignored, allowing
certificates with invalid or garbled contents to
be processed.
CRYPT_No checking of certificate contents except for a
COMPLIANCELEVEL_ minimal check of the certificate key usage. This
OBLIVIOUS
level of checking merely confirms that the
object looks vaguely like a certificate, and that
its signature verifies. This allows expired and
otherwise invalid certificates to be processed.
These reduced levels of checking are required in order to successfully process
certificates generated by other software. Although cryptlib-generated certificates can
be processed at the CRYPT_COMPLIANCELEVEL_PKIX_FULL compliance level,
it may be necessary to lower the level all the way down to CRYPT_COMPLIANCELEVEL_OBLIVIOUS in order to handle certificates from other
applications. If you encounter a certificate that can’t be processed at a given
compliance level, for example one that generates a CRYPT_ERROR_BADDATA on
import or a CRYPT_ERROR_INVALID when checked, you can either request that
the originator of the certificate fix it (this is unlikely to happen) or lower the
compliance level until the certificate can be imported/checked.
At reduced compliance levels, cryptlib skips potentially problematic certificate
extensions, so that these will seem to disappear from the certificate as the compliance
level is lowered. For example, the name constraints extension will be decoded at
CRYPT_COMPLIANCELEVEL_PKIX_FULL, but not at any lower level, so that
unless the certificate is processed at that level the extension will appear to be absent.
In some rare cases CAs may place the user’s email address in the subject altName
instead of the subject DN. Setting the compliance level to one where this extension is
skipped will cause the email address to appear to vanish from the certificate, which
you need to take into account when you add the certificate to a keyset, since you’ll no
longer be able to fetch it from the keyset based on the email address. Conversely,
extra extensions that were skipped at lower levels may appear as the compliance level
is increased and they are processed by cryptlib.