Standard path validation policy

 

• 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".

  WebSphere MQ for UNIX and Windows systems only support policy identifiers that are created by WebSphere MQ for UNIX 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 can not be increased. (That is, if a certificate in the path requires explicit policy identifiers, a later certificate can not 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 can not be increased. (That is, if a certificate in the path specifies policy mapping is not permitted, it can not 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¹.

   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²

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. The CRLDistributionPoints extension is checked for a list of X500 distinguished names. If the extension is not present, the name of the certificate's issuer 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 ARLs and CRLs 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 is the only supported name form used to look up CRLs and ARLs³.

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 numerical 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 numerical sequence value, the policy identifier can not be mapped.

12. Ensure that policy information is consistent with the acceptable policy set:

    1. If the certificate policies extension is marked critical⁶, 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.

14. The following is 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)

    2. If the BasicConstraints extension is present, ensure that the "isCA" flag is true⁷. 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 on not the last certificate, ensure that the keyCertSign flag is on, and ensure that if the BasicConstraints extension is present, that the "isCA" flag is true⁸.

    4. If a policy constraints extension is included in the certificate, modify the explicit policy and policy mapping state variables as follows:

    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. f. If the nameConstraints extension is present⁹, ensure that it is critical, and that the permitted and excluded subtrees adhere to the following before updating the chain's subtree's state in accordance with the algorithm described in RFC 3280 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)

15. 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.

16. 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.

17. 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 and Windows systems

¹ 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 iKeyman. Select the required certificate from the signer list and click the View/Edit... button. 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 IKEYCMD or GSKCapiCmd with the -trust flag on the -cert -modify command. For further information about this command, see Chapter 18, "Managing keys and certificates" in the WebSphere MQ System Administration Guide.

² There are no checks to ensure the subject's validity is within bounds of the issuer's validity. This is not required, and Verisign certificates have been shown to not pass such a check.

³ When retrieved from the database, ARLs are evaluated in exactly the same way as CRLs. Many CAs do not issue ARLs at all. However, WebSphere MQ for UNIX and Windows systems will look for ARLs and CRLs if checking a CA certificate for revocation status.

⁴ WebSphere MQ for UNIX and Windows systems only support nameConstraint Extensions that are created by WebSphere MQ for UNIX and Windows systems

⁵ WebSphere MQ for UNIX and Windows systems only support Policy Extensions that are created by WebSphere MQ for UNIX and Windows systems.

⁶ This is maintained as a legacy requirement from RFC2459 (6.1 (e)(1))

⁷ “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.

⁸ This check is in fact redundant because of step (b), but the check is still made.

⁹ WebSphere MQ for UNIX and Windows systems only support nameConstraint Extensions that are created by WebSphere MQ

sy12850_