Standard path validation policy

The standard path validation policy determines how the certificate, OCSP, and CRL policy types interact with each other to determine if a certificate chain is valid. Standard policy checking conforms to RFC 5280.

Path validation uses the following concepts:

  • A certification path of length n, where the trust point or root certificate is certificate 1, and the EE is n.
  • A set of initial policy identifiers (each comprising a sequence of policy element identifiers), that identifies one or more certificate policies, any one of which is acceptable for the purposes of certification path processing, or the special value "any-policy". Currently this is always set to "any-policy". Note: IBM MQ for UNIX, Linux and Windows systems only supports policy identifiers that are created by IBM MQ for UNIX, Linux and Windows systems.
  • Acceptable policy set: a set of certificate policy identifiers comprising the policy or policies recognized by the public key user, together with policies deemed equivalent through policy mapping. The initial value of the acceptable policy set is the special value "any-policy".
  • Constrained subtrees: a set of root names defining a set of subtrees within which all subject names in subsequent certificates in the certification path can fall. The initial value is "unbounded".
  • Excluded subtrees: a set of root names defining a set of subtrees within which no subject name in subsequent certificates in the certification path can fall. The initial value is "empty".
  • Explicit policy: an integer which indicates if an explicit policy identifier is required. The integer indicates the first certificate in the path where this requirement is imposed. When set, this variable can be decreased, but cannot be increased. (That is, if a certificate in the path requires explicit policy identifiers, a later certificate cannot remove this requirement.) The initial value is n+1.
  • Policy mapping: an integer which indicates if policy mapping is permitted. The integer indicates the last certificate on which policy mapping may be applied. When set, this variable can be decreased, but cannot be increased. (That is, if a certificate in the path specifies policy mapping is not permitted, it cannot be overridden by a later certificate.) The initial value is n+1.

The validation of a chain is performed in the following manner (but not necessarily the following order):

  1. The information in the following paragraph is consistent with the basic path validation policy described in Basic path validation policy:

    Ensure that the name of the certificate's issuer is equal to the subject name in the previous certificate, and that there is not an empty issuer name in this certificate or the previous certificate subject name. If no previous certificate exists in the path and this is the first certificate in the chain, ensure that the issuer and subject name are identical and that the trust status is set for the certificate 1 .

    If the certificate does not have a subject name, the subjectAltName extension must be present and critical.

  2. The information in the following paragraph is consistent with the basic path validation policy described in Basic path validation policy:

    Ensure that the signature algorithm used to actually sign the certificate matches the signature algorithm indicated within the certificate, by ensuring that the issuer signature algorithm identifier in the certificate matches the algorithm identifier in the signature data.

    If both the certificate's issuersUniqueID and the issuer's subjectUniqueID are present, ensure they match.

  3. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    Ensure that the certificate was signed by the issuer, using the subject public key from the previous certificate in the path to verify the signature on the certificate. If no previous certificate exists and this is the first certificate, use the subject public key of the certificate to verify the signature on it.

  4. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    Ensure that the certificate is a known X509 version, unique IDs are not present for version 1 certificates and extensions are not present for version 1 and version 2 certificates.

  5. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    Ensure that the certificate has not expired, or not been activated yet, and that its validity period is good 2

  6. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    Ensure that there are no unknown critical extensions, nor any duplicate extensions.

  7. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    Ensure that the certificate has not been revoked. Here, the following operations apply:
    1. If the OCSP connection is enabled and a Responder Address is configured or the Certificate has a valid AuthorityInfoAccess extension specifying an HTTP format GENERALNAME_uniformResourceID check revocation status with OCSP.
      1. IBM MQ for UNIX and Windows systems allows the OCSP Request to be optionally signed for preconfigured responders but this has otherwise no impact on OCSP Response processing.

    2. If revocation status from 7a is undetermined the CRLDistributionPoints extension is checked for a list of X.500 distinguished name GENERALNAME_directoryname and URI GENERALNAME_uniformResourceID. If the extension is not present, the certificate's issuer's name is used. A CRL database (LDAP) is then queried for CRLs. If the certificate is not the last certificate, or if the last certificate has the basic constraint extension with the "isCA" flag turned on, the database is queried for ARL's and CRL's instead. If CRL checking is enabled, and no CRL database can be queried, the certificate is treated as revoked. Currently, the X500 directory name form and the LDAP/HTTP/FILE URI forms are the only supported name forms used to look up CRLs and ARLs15. Note: RelativeDistinguishedNames are not supported.

  8. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    If the subjectAltName extension is marked critical, ensure that the name forms are recognized. The following general name forms are currently recognized:

    • rfc822
    • DNS
    • directory
    • URI
    • IPAddress(v4/v6)

  9. Ensure that the subject name and subjectAltName extension (critical or noncritical) is consistent with the constrained and excluded subtrees state variables.
  10. If the EmailAddress OID is present in the subject name field as an IA5 string, and there is no subjectAltName extension, the EmailAddress must be consistent with the constrained and excluded subtrees state variable.
  11. Ensure that policy information is consistent with the initial policy set :
    1. If the explicit policy state variable is less than or equal to the current certificate's numeric sequence value, a policy identifier in the certificate shall be in the initial policy set.
    2. If the policy mapping variable is less than or equal to the current certificate's numeric sequence value, the policy identifier cannot be mapped.

  12. Ensure that policy information is consistent with the acceptable policy set:
    1. If the certificate policies extension is marked critical 3, the intersection of the policies extension and the acceptable policy set is non-null.
    2. The acceptable policy set is assigned the resulting intersection as its new value.

  13. Ensure that the intersection of the acceptable policy set and the initial policy set is non-null. If the special Policy of anyPolicy is present then allow it only if it has not been inhibited by the inhibitAnyPolicy extension at this chain position.
  14. If an inhibitAnyPolicy extension is present ensure that it is marked Critical and, if so, set the inhibitAnyPolicy state and chain position to the value of the integer value of the extension provided it is not greater than the current value. This is the number of certificates to allow with an anyPolicy Policy before disallowing the anyPolicy Policy.
  15. The following steps are performed for all certificates except the last one:
    1. If the issuerAltName extension is marked critical, ensure that the name forms are recognized. The following general name forms are currently recognized:

      • rfc822
      • DNS
      • directory
      • URI
      • IPAddress(v4/v6)

      1. If the BasicConstraints extension is not present, the certificate is only valid as an EE certificate.
      2. If the BasicConstraints extension is present, ensure that the "isCA" flag is true. Note that "isCA" is always checked to ensure it is true to be as part of the chain building itself, however this specific test is still made. If the pathLength field is present, ensure the number of certificates until the last certificate is not greater than the pathLength field.

    3. If the KeyUsage extension is critical, ensure that the keyCertSign flag is on, and ensure that if the BasicConstraints extension is present, that the "isCA" flag is true 4 .
    4. If a policy constraints extension is included in the certificate, modify the explicit policy and policy mapping state variables as follows:

      • i. If requireExplicitPolicy is present and has value r, the explicit policy state variable is set to the minimum of its current value and the sum of r and i (the current certificate in the sequence).
      • ii. If inhibitPolicyMapping is present and has value q, the policy mapping state variable is set to the minimum of its current value and the sum of q and i (the current certificate in the sequence).

    5. If the policyMappings extension is present (see 12(b)), ensure that it is not critical, and if policy mapping is allowed, these mappings are used to map between this certificate's policies and its signee's policies.
    6. If the nameConstraints extension is present , ensure that it is critical, and that the permitted and excluded subtrees adhere to the following rules before updating the chain's subtree's state in accordance with the algorithm described in RFC 5280 section 6.1.4 part (g):
      1. The minimum field is set to zero.
      2. The maximum field is not present.
      3. The base field name forms are recognized. The following general name forms are currently recognized:

        • rfc822
        • DNS
        • directory
        • URI
        • IPAddress(v4/v6)

  16. The ExtendedKeyUsage extension is not checked by IBM MQ.

  17. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    The AuthorityKeyID extension is not used for path validation, but is used when building the certificate chain.

  18. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    The SubjectKeyID extension is not used for path validation, but is used when building the certificate chain.

  19. The following information is consistent with the basic path validation policy described in Basic path validation policy:

    The PrivateKeyUsagePeriod extension is ignored by the validation engine, because it cannot determine when the CA actually signed the certificate. The extension is always non-critical and therefore can be safely ignored.

Parent topic: Certificate validation and trust policy design on UNIX, Linux and Windows systems 1 Trust status is an administrative setting in the key database file. We can access and alter the trust status of a particular signer certificate in strmqikm. Select the required certificate from the signer list and click View/Edit. The Set the certificate as a trusted root check box on the resulting panel indicates the trust status. We can also set Trust status using runmqckm with the -trust flag on the -cert -modify command. For further information about this command, see Manage keys and certificates.2 There are no checks to ensure the subject's validity is within bounds of the issuer's validity. This is not required, and certificates from some CAs have been shown to not pass such a check.3 This is maintained as a legacy requirement from RFC2459 (6.1 (e)(1))4 This check is in fact redundant because of step (b), but the check is still made.