Could someone please explain the difference between
Policy Constraints and
It appears to me that they are either redundant, or two names for the same thing. I would love some clarification as Google searches aren't helping.
First, let's tackle "Basic Constraints" (RFC 5280, Section 126.96.36.199). These are mostly for the sake of certificates issued for CAs. RFC 5280 only defines two such "constraints":
This one is pretty straightforward. A CA certificate, by definition, must have a basic constraints extension with this
cA boolean value set to "true" in order to be a CA.
This is the
pathLenConstraint value, which is a number whose value is zero or greater. Let's say I wanted to issue to you a CA certificate using my CA certificate, but I wanted to make sure you in turn could not use that CA certificate to issue other CA certificates. I would add the basic constraints extension to your CA certificate, with the
cA value of "true" and the
pathLenConstraint value of "0".
pathLenConstraint is the number of "non-self-issued intermediate certificates" that could follow from your CA. Note that the end certificate (usually a server or client certificate) does not count as part of this number. So by using a
pathLenConstraint of "0" in the CA certificate I issue to you, you can use that certificate to issue other end certificates, but not any intermediate certificates. If no
pathLenConstraint value is defined in the basic constraints extension, then no such limit is imposed.
Now, let's look at "Policy Constraints" (RFC 5280, Section 188.8.131.52). The policy constraints extension, per RFC 5280, is for certificates that are issued to CAs; this extension is thus not really useful for end certificates (e.g. client/server certificates). The RFC says that this extension is for constraining path validation to the CA in terms of "policies"; what then are these policies?
Now, each different CA organization will have slightly (to wildly) different policies, but folks will ask a CA "how do your policy X relate to that other CA's policy Y?" Especially when it comes to X509 cross signing (see RFC 4158 for gory details). Thus there is the need for a CA certificate to be able to say "my certificate policy X is equivalent to that certificate policy Y"; this is done using the policy mapping extension, which "maps" the OID of certificate policy X to the OID of certificate policy Y.
Now we have certificate policies, and we have mappings from one certificate policy to another. The policy constraints extension, then, uses these to set limits/requirements, in terms of policies (and mappings of policies), when walking the list of certificates, from end certificate through the intermediate CAs to the root/trusted CA. One of the limits,
inhibitPolicyMappings, says "ignore any policy mappings after the Nth intermediate certificate in the path"; the other,
requireExplicitPolicy, says "if there are more than N intermediate certificates in that path, require that all of them have X policy".
So, to sum up: basic constraints determine if you are a CA (
cA = true), and if so, how long of a trust path can you create (limited by
pathLenConstraint). Policy constraints are all about how walking that trust path happens: how many of the intermediates certificates are allowed to have policy mappings, after which the policy mappings of intermediate certificates are ignored (
inhibitPolicyMapping = ...), and/or how long can the trust path be, before a specific policy is required (
requireExplicitPolicy = ...).
Back to that CA certificate I issued to you, whose
pathLenConstraint basic constraint was set to zero. That would prohibit you from issuing your own intermediate certificates. And in that case, placing any policy constraints in that CA certificate would be rather useless, as policy constraints modify the handling of intermediate certificates (which you would be unable to issue/create). Likewise, policy constraints on a non-CA certificate (and end certificate for a client/server) would be useless, for the same reason: they cannot issue/create intermediate certificates.
Now the above is all of the theory; for more information on the actual reality of all of this, in terms of implementations and such, I can highly recommend Peter Gutmann's materials on PKI, such as his X509 Style Guide.
Hope this helps!