One feature of a Basic Constraint when applied to a certificate (CA or end certificate) is that I can specify the maximum number of CAs that are permitted in the chain.

I'm planning on having a 2 tier CA system and setting the basic constraints path=1 on the Root CA, path=0 on the Intermediate CA.

What would happen if there was a policy mapping between my PKI and a second PKI? How would the path length be affected if the two PKIs had different values for "path="?

I'm asking so that I don't prevent interoperability with other CAs.


Certificate policies and basic constraints are completely orthogonal issues. Policy mappings impact the processing of the "policy tree" but do not change the length of the path, and do not make a CA certificate a non-CA or vice versa.

Are you sure you want to use an explicit path length in the Basic Constraints ? This is rarely done; as such, it is quite possibly mis-implemented by some certificate validation engines. Setting an explicit length is used to give to a sub-CA the power to be a CA (i.e. issue certificates) but to prevent them from delegating that power to a sub-sub-CA. It takes some effort to find a situation where such a restriction makes sense: if a CA considers its sub-CA as a potential attacker, then there is something definitely rotten in the kingdom. Said otherwise, an hostile sub-CA already has tremendous power of nuisance even if it cannot issue a sub-sub-CA.

I would advise, for better interoperability, not to include an explicit length in the Basic Constraints extension. Mark CAs as CAs and non-CAs as non-CAs, and that should be enough.

  • I see... so if I'm dealing with a untrusted PKI I should cross certify and use a policy map.... right? Jan 5 '13 at 14:46
  • You use policy mappings to establish the link between two distinct but "equivalent" policies. It is not a matter of trust, rather a matter of translation, in a way similar to the equivalence of diplomas across borders: e.g. my PhD, awarded by a French university, has been declared equivalent to a Canadian PhD by the Canadian immigration services. Policy mappings are like that. Jan 5 '13 at 19:01
  • 2
    As for dealing with an "untrusted" PKI: basically, in X.509, the only way to deal with hostile CA is to use revocation (or abstain to cross-certify). The extension which would be useful to delegate part of the CA power to a sub-CA with limited scope is Name Constraints. Unfortunately, name constraints have very obscure semantics and almost nobody supports them. Jan 5 '13 at 19:04
  • Does that mean that anyone who signs up for a Trusted Root Singing from say Comodo or any other vendor, that there are no name constraints and they can issue certs for any domain? Jan 6 '13 at 15:09
  • 1
    The CA who issues the sub-CA may try to add name constraints, but these will not be reliably enforced by applications. They may also put legal limitations on your sub-CA -- not limitations which verifiers will automatically check, but contractually binding limitations nonetheless. The über-CA always has the power to revoke your sub-CA if it finds out that you do not keep within the agreed-upon boundaries of the trust delegation. Jan 6 '13 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.