Ville,
In order help explain why the path in 4.12.9 is valid and the path in
4.12.10 is invalid, I have attached a figure that represents the four
inhibitAnyPolicy tests that involve self-issued certificates. Tests
4.12.9 and 4.12.10 correspond to the paths that end with EE3 and EE4,
respectively. The names of the CAs and end entities are different, but
the paths are otherwise the same.
If we use the path validation algorithm from section 6 of RFC 3280, the
path in 4.12.9 will be processed as follows:
- When the first intermediate certificate is processed, inhibit_any-policy
will be set to 1. (section 6.1.4, step j)
- After the second intermediate certificate is processed, inhibit_any-policy
will still be set to 1 since the second intermediate certificate is
self-issued (section 6.1.4, step h)
- Since inhibit_any-policy is greater than 0, the anyPolicy
OID in the third intermediate certificate will be processed. (section
6.1.3, step (d)(2))
- Since the third intermediate certificate is not self-issued, inhibit_any-policy
will be decremented to 0. (section 6.1.4, step h)
- Since the fourth intermediate certificate is self-issued and is
not the final certificate in the path (i < n), the anyPolicy OID in
the fourth intermediate certificate will be processed even though inhibit_any-policy
is 0. (section 6.1.3, step (d)(2))
- The final certificate in the path asserts NIST-test-policy-1.
Since every certificate in the path asserts either NIST-test-policy-1
or anyPolicy, and the anyPolicy OID is processed in every certificate
in which it appears, the path is valid under NIST-test-policy-1.
Using the same path validation algorithm, the path in 4.12.10 will be
processed as follows:
- the path is the same up through step 4 above, leaving just the
end entity certificate to the processed.
- Since inhibit_any-policy is 0 and the certificate being
processed is the final certificate in the path (i = n), the anyPolicy
OID in the final certificate is not processed (even though the
certificate is self-issued). (section 6.1.3, step (d)(2))
- Since the final certificate in the path only asserted the
anyPolicy OID and that OID was not processed, the certificate is
treated the same as if it had not included a certificatePolicies
extension at all. That is, the all nodes in the valid_policy_tree
will be deleted in step (d)(3) of section 6.1.3.
- Since the valid_policy_tree is empty and explicit_policy
will be 0 (if the application can process the requireExplicitPolicy
field of the policyConstraints extension), the path will be rejected.
Hope the above description helps.
Please let me know if you have any other questions,
Dave
Ville Heikkala wrote:
Dear all,
I have some problems trying to understand why the path in 4.12.10 should
not validate succesfully. Comparing to 4.12.9, where the path should
validate (assuming initial-policy-set includes NIST-test-policy-1), the
first difference in the paths (starting from Trust Anchor Root
Certificate) occurs in the self-signed CA certificates of subCA2. They
are both of the Base Intermediate Certificate base type, self-signed by
inhibitAnyPolicy1 subCA2, assert anyPolicy (at an acceptable distance from
inhibitAnyPolicy1 CA Cert, which has inhibitAnyPolicy set to 1). As far as
I can tell, the only differences are in the keyUsageExtension,
SerialNumber, and key information. Then, in 4.12.9, this subCA2
self-signed cert is used to sign the EE cert, and the path should validate
succesfully. But why should the path in 4.12.10, which ends at the subCA2
self-signed cert itself, not validate?
Having studied RFC 3280, I have also not found a reason why 4.12.10 should
not validate. What am I missing here?
Thanks,
Ville Heikkala.
|