As you may know, Common Criteria (AKA ISO/IEC15408: A standard for IT Security Evaluation) have provided some security base-line documents named "Protection Profile" for software developers and product manufacturers. Developers and manufacturers can use these documents to got an idea about which security requirements they have to meet in their products.

I was checking two Protection Profiles (One for Network Devices, and another one for Server Applications), and I found the following security requirements:

From Network Devices' protection profile

enter image description here and enter image description here

From Server Applications PP-Module:

enter image description here

My question: Considering that the requirement to check the certificates until reaching a trusted anchor is also explicitly mentioned in the above documents, what is the purpose of the above rules? I mean, what security improvement we may achieve by defining "a minimum path length" for certification validation?

1 Answer 1


I'm confident that you're misinterpreting this statement. It's a functional requirement: the TSF1 must be capable of doing something. Specifically, the TSF must support validating certificates, and it must support a path length of any number up to 3, and possibly more. (There's an implicit assumption that if it's capable of supporting 3, it's also capable of supporting less.)

Semantically, the word “minimum” is about the support, not about the path length. The sentence is badly worded because “minimum” is syntactically attached to the path length instead of the verb.

A better wording would be

RFC 5280 certificate validation and certificate path validation supporting, at a minimum, a path length of three certificates.

A product that only supports shorter path lengths might still be secure, but it wouldn't be considered in scope of that protection profile.

In terms of security architecture, a longer path length has no advantage for the security of the device itself, but it has an advantage for the security of the network as a whole, because it allows delegation and compartmentalization. To take an extreme example, if the device only supported verification against a fixed signature, and not signatures by a certificate authority, then the administrator would have to provision the public key of every entity that the device communicates with, which would be a maintenance nightmare, with a high risk of mistakes and security bugs, and it would make it hard to track credentials and authorizations. Two levels allow for an offline root CA (very well defended but costly to use), an online operational CA (usable but at risk of online attacks) and the end entity. Three levels allow one more level of indirection with an organization-wide CA and a department CA.

1 Translated from commoncriterese: the system whose security is being evaluated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .