Jochem van den Berge posted the following update to the m.d.s.p. list on 22-March:
Firstly our apologies for the delay in our follow-up response. A joint
analysis of the 64-bit serial issue by Logius and its TSPs took more time
than expected. We would like to share an update to our initial post-mortem
of 03/13/2019 and our subsequent update of 03/19/2019.
In close consultation with Dutch CERT (NCSC) and the politically and
administratively responsible officials of the Dutch Ministry of Interior
Affairs and Kingdom Relations we have conceived the following blueprint:
We’ve formulated the following starting points:
The effort involved in replacing the end-user S/MIME certificates is
severe plus almost half of them will expire and be replaced in the coming
year by either private certificates or newly issued certificates which
comply with the Mozilla CA policy section 5.2.
2. Replacing non-compliant end-user certificates issued by a TSP CA
which needs to be replaced involves a lot of rework. First course of action
should be to replace the issuing (TSP) CAs.
3. We consider compliant end-user certificates issued by a
non-compliant TSP CA to be compliant. The non-compliant issuing TSP CA will
need to be replaced by a TSP CA that has a serial number with sufficient
entropy (128 or 159 bit). After all issued certificates from the previous
TSP CA have expired Logius will revoke the TSP CA in question.
4. We’re working on replacing part of the PKIoverheid certificates
(both TLS and S/MIME) by certificates issued by a Private CA (“Staat der
Nederlanden Private Root CA – G1). This will have to happen on a case by
case basis and will take, unfortunately, some time.
5. Logius PKIoverheid will reach out to other root store operators
about our intended remediation plan.
6. The rate at which TLS certificates will be replaced is dependent on
the importance of the certificates in question for the critical network
infrastructure of the Dutch Government.
To clarify our position, some more context about the setup of PKIoverheid
and it’s different involved parties
PKIoverheid has issued several domain (intermediate) and TSP
(issuing) CA’s under its “Staat der Nederlanden Root CA – G3” Root CA. The
domain CAs (managed by Logius) differentiate between “Burger”, “Organisatie
Persoon”, “Autonome Apparaten” and “Services” (including Server/TLS)
domains. Under the domain CAs Logius signs issuing CAs for TSPs. In case of
the “Services” domain further differentiation takes place between “Services”
and “Server” (TLS), per demands from Microsoft Trusted Root Progamme
2. The “Burger” and “Organisatie Persoon” TSP CAs can be used by
PKIoverheid TSPs to issue S/MIME certificates which can also be used for
placing Qualified Electronic Signatures per eIDAS (also known as Regulation
910/2014 issued by the EC). Services and “Autonome Apparaten” are
certificates used for several services in which the holder is not a natural
person but a legal person. All of these certificates need to be issued on a
SUD or an SSCD/QCSD (token/smartcard) according to ETSI EN 319 411-1/2
policies NCP+ or qcp-n-qscd/qcp-l-qscd.
3. PKIoverheid TLS certificates (issued under the “Server” TSP CAs)
don’t have this requirement (SUD/QSCD) in place and as such are more easily
replaceable. Issuance of PKIoverheid certificates is done manually.
Replacement of certificates takes a lot of effort because vetting needs to
be redone if and when old data isn’t usable anymore (either because of new
requirements or expiration of vetting data).
4. Replacement of these certificates will have a severe impact on Dutch
society. Among other implementations PKIoverheid S/MIME certificates are in
widespread use on smartcards within the Dutch healthcare system. They are
also used on the on-board computers of Dutch taxis.
Result of analysis:
We conclude that our current G3 TSP CA’s (Issuing CA certificates)
are not compliant with ballot 164 and/or the current valid section of the
Mozilla CA Policy. The G2 and EV intermediate CAs are NOT affected.
2. We also conclude that all end-user TLS certificates issued by our
TSPs KPN and CIBG issued after the effective date of ballot 164 are not
compliant. For KPN this concerns approximately 22.000 TLS certificates, for
CIBG approximately 5000 TLS certificates.
3. Furthermore we have to conclude that all personal (S/MIME)
certificates from our TSP CAs KPN, CIBG and IenW issued after the effective
date of Mozilla CA Policy 2.4 don’t conform to the entropy requirements from
the Mozilla CA Policy.
The 64 bit serial issue is a compliancy issue, not a security issue.
It’s not acceptable to introduce security issues in our effort to remediate
a compliance issue.
2. The above means that because of the lack of a imminent security
risk, revoking and replacement within a short timeframe instead of following
a measured approach is not considered a viable option.
3. We consider it very important to be compliant with regulations and
requirements and to resolve any non-compliance as soon as possible with
4. The SSL/TLS certs affected by the 64-bit entropy issue are used in
the Dutch critical network infrastructure. S/MIME Certs are used on a large
scale in, for example, the Dutch Healthcare. Mass revoking and replacing
these certs in a timely manner has severe consequences for the public
5. The issuance of PKIoverheid certificates takes place in a manual,
non-automated manner. So replacing the certs involved will, in all cases,
amount to manual processes.
6. Specialist knowledge is required due to the manual procedures. Our
TSPs have small specialist teams that deal with these procedures. Mass
replacement of the certs involved, will therefore mean we will have to lean
heavily, and for a prolonged period, on the small teams currently in place.
This will lead to the situation that mistakes are made due to fatigue,
introducing additional (security) risks etc.
7. To mitigate the above risk, temporary, new teams can be formed and
interim specialists hired. However to find these specialists, with knowledge
of the specific processes and tooling used by the different TSP
administration/validation teams, will proof very difficult. Even then,
trying to accomplish this task will, without doubt, introduce faults because
these interim specialists lack experience, which will lead to additional
8. The above compounds to: there is no impending security risk, “mass”
revocation is not viable, no leeway to reduce replacement effort, zero
tolerance on (security) risk caused by replacement efforts, zero tolerance
on impact on society caused by replacement efforts. This dictates any
We are working hard on the details of our remediation plan, based on the
constraints, analysis and considerations as mentioned above. This includes
(but is not limited to) looking into measures to reduce future constraints
on mass revocation, to increase certificate replacement speed and looking
into more strict compliancy checks and balances to prevent these kind of
issues in the first place. These will be posted as soon as possible.