The minimum number of supported trust anchors is defined. Contrary the minimum supported path length is not. This relates to the local storage of the certification path information on end devices, as this information is provided per peer during the handshake.
Proposal
Accepted during FDIS comment resolution. Proposed text was not provided.
Proposal to add a new clause in 6.4.4 covering the intended functionality:
6.4.4.2 Support of certificate hierarchies
A PKI typically organizes certificates in a hierarchical scheme. The root CA builds the base and intermediate CAs or issuing CAs may be derived from this root CA. The hierarchy has an influence on the certificate path validation as it comprises the path from the trust anchor (the root CA certificate) via the intermediate CAs to the end entity certificate. The actual depth of the PKI hierarchy depends on the target use case.
An implementation claiming conformance to this document shall support at least two intermediate CAs. This results in support of a path length of at least 2 and also aligns with the clause 7.4.4.10.5 in IEC 62351-9:2023 requiring the same value via the pathLenConstraint in the basic constraints of the certificate.
The design and number of CA hierarchies is out-of-scope of this document.
Discussion
Created
Status
- Approved during WG15 Meeting 10/2023, based on previous FDIS comment resolution discussion
- Proposal accepted
19 Oct 23
Approval (Future Improvement)
I am OK with the proposal. I have no additional comments
08 Aug 23
Discussion (red)
Proposal according to FDIS comment resolution
26 Jul 23
Discussion (red)
Accepted in FDIS comment resolution an WG15 meeting in May 2023