Introduction
This draft standard covers cybersecurity requirements for PKI and digital certificate issuance software. One very positive point: the diagram explaining what is in scope and what is out of scope is exceptionally clear, probably the clearest I have seen among the CRA standards reviewed so far.
- My comments focus on several areas:
Use cases: Clarifying the definition of “critical entities” and better covering PKI used by SMEs and for product security, such as secure boot and firmware signing.
Vulnerability management: Clarifying the requirements for vulnerability assessment and their application when placing products on the market.
Logging: Defining more precisely what constitutes a log integrity protection event.
Certificate validity: Considering embedded devices that may remain in storage for years before deployment, where expired certificates can make firmware updates difficult.
Software updates: Requiring manufacturers to document and justify software components that cannot be updated.
Clarity: Correcting ambiguous terminology and the use of informative references. Below are our comments on the draft, reproduced as submitted.
This review was made possible thanks to a grant from the CYBERSTAND programme.
Implementation
- Comment 1 – Clause 4.6 – Undefined “critical entities” and missing use cases
The term “critical entities” is not defined.
Is it aligned with NIS2? The current classification groups most SME and product development use cases together. However, PKI is widely used for product security, for example in secure boot and firmware signing. Due diligence of these systems is important for many products.
=> Proposed change:
Clarify the definition of “critical entities”. Split the use case to cover at least: 1. Internal PKI usage. 2. PKI used for product security, including creation, distribution and storage of signing keys for firmware updates, also covering SMEs.
- Comment 2 – Clause 5.2 – Vulnerability assessment and placement on the market
The NOTE effectively introduces a requirement to perform vulnerability assessment according to [i.17], although the reference is informative.
The requirement also does not specify when the product must be free from exploitable vulnerabilities. Requiring this at all times is impossible.
=> Proposed change:
Add “when placed on the market” to the main requirement. In the NOTE, add “such as” before the reference to [i.17], making it clear that this is one possible approach.
- Comment 3 – Clause 5.3.1 – Incorrect use of EXAMPLE
The EXAMPLE does not provide an actual example. Its content appears to be a NOTE.
=> Proposed change:
Replace EXAMPLE with NOTE.
- Comment 4 – Clause 5.3.2 – Undefined log protection integrity event
The expression “log protection integrity event” is not defined. If it refers to performing a log integrity check and recording the result, as clause 6.3.2 suggests, this should be stated explicitly.
=> Proposed change:
Define “log protection integrity event” or clarify in the requirement that it refers to a log integrity check and the recording of its result.
- Comment 5 – Clause 5.3.4 – Certificate validity in embedded devices
Limiting certificate validity is reasonable, but some embedded devices may remain in storage for years before being deployed as replacements. If their certificates have expired, updating them to the latest firmware version may become difficult or impossible.
=> Proposed change:
Add a NOTE clarifying that longer certificate validity periods may be appropriate when justified by the product’s intended use and lifecycle.
- Comment 6 – Clause 5.4 – REQ-PKI-SU-1 – Undefined technical reasons for immutability
The expression “due to technical reasons” is too broad and could justify almost any exception to software update requirements.
=> Proposed change:
Require the manufacturer to document software components that cannot be updated, explain the technical reasons and justify the associated residual risks in the cybersecurity risk assessment.
