Dear MDSP community, We would like to share an update to our initial post-mortem of 03/13/2019 and our subsequent updates of 03/19/2019 and 03/22/2019
Following the discussions on MDSP Logius has determined that the following G3 TSP CAs (Issuing CA certificates) are not compliant with BR 7.1 and/or the current valid section of the Mozilla CA Policy and will therefore be replaced within 2 months: Cleverbase ID PKIoverheid Burger CA - G3; Digidentity BV PKIoverheid Organisatie Persoon CA - G3; Digidentity BV PKIoverheid Organisatie Server CA - G3; Digidentity BV PKIoverheid Burger CA - G3; KPN BV PKIoverheid Organisatie Server CA - G3; MinIenW PKIoverheid Organisatie Services CA - G3; MinIenW PKIoverheid Organisatie Persoon CA - G3; QuoVadis PKIoverheid Organisatie Server CA - G3; UZI-register Medewerker op naam CA G3; UZI-register Zorgverlener CA G3; UZI-register Medewerker niet op naam CA G3. The TSP CAs in question will be replaced by CAs with a serial number length of 128 bits or higher. The following roadmap will be used for remediation of the end user certificates as outlined in our previous post: KPN has already switched to serial numbers with a 96-bit length on March 5. New certificates issued by them after this date are not affected. Of the 22.000 TLS certificates in scope ~3900 have been marked as being in use for browser use cases (websites e.g.) and will be replaced after the new issuing CA has been brought into operation. The replacement of the TLS certificates will take 6 months so the total replacement will take 8 months. The remainder of the certificates (~18K) will be regularly (re)checked to confirm that they are in use for private systems and machine-to-machine traffic. They will be replaced by compliant or private SSL certificates when possible. Logius has decided not to replace the TLS certificates issued by CIBG as these ~4500 certificates will expire before the end of March 2020 and will automatically be replaced by private certificates. The following roadmap will be used for S/MIME certificates as outlined in our previous post: We will let the current S/MIME certificates expire. All other end-user certificates issued by PKIoverheid have a serial number of sufficient length. In addition, we have formulated the following new measures to ensure this particular type of issue will not be repeated in the future and which will improve the resilience of our PKI setup: Technical constraints/use of Private CAs PKIoverheid has found that for certain types of use, the supplied types of certificates could be technically restrained without affecting its intended use. We will further research this area and will strive to technically restrain EE certificates as much as possible. Increase in technical monitoring/oversight PKIoverheid runs a program called VTT (verbeterd technisch toezicht; improved techical supervision) which closely follows developing industry practices concerning technical oversight tooling (e.g. linting tools). We will increase resources for this program to enhance our insight into the quality of certificates issued within the PKIoverheid scope and as such catch potential issues earlier. Self-service (re)provisioning/automated issuance Although we cannot control how end users implement the certificates issued by PKIoverheid TSPs, we think it prudent to distribute PKI implementation best practises for end-users, using newly developed or existing self-service (re)provisioning tooling. Regards, Jochem -----Oorspronkelijk bericht----- Van: dev-security-policy <[email protected]> Namens Berge, J. van den (Jochem) - Logius via dev-security-policy Verzonden: vrijdag 22 maart 2019 16:16 Aan: [email protected] Onderwerp: RE: Pre-Incident report: PKIoverheid Serial Number Entropy Dear MDSP community, 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: Weve formulated the following starting points: 1. 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. Were 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 its different involved parties 1. PKIoverheid has issued several domain (intermediate) and TSP (issuing) CAs 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 Requirements. 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) dont 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 isnt 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: 1. We conclude that our current G3 TSP CAs (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 dont conform to the entropy requirements from the Mozilla CA Policy. Considerations 1. The 64 bit serial issue is a compliancy issue, not a security issue. Its 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 maximum transparency. 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 interest. 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 (security) risks. 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 replacement plan. 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. Kind regards, Jochem van den Berge CISSP Logius PKIoverheid Public Key Infrastructure for the Dutch government ........................................................................ Logius Ministry of the Interior and Kingdom Relations (BZK) Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague PO Box 96810 | 2509 JE | The Hague ........................................................................ [email protected] http://www.logius.nl -----Oorspronkelijk bericht----- Van: dev-security-policy <[email protected]> Namens Berge, J. van den (Jochem) - Logius via dev-security-policy Verzonden: woensdag 13 maart 2019 17:56 Aan: [email protected] Onderwerp: Pre-Incident report: PKIoverheid Serial Number Entropy Hello MDSP, Logius PKIoverheid wants to report a potential issue that we've found with one of our TSPs issuing certificates under the Staat der Nederlanden Root CAs All times are in UTC +1 ________________________________ 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. 3/8/2019 12.30, due to reviewing discussions in mozilla.dev.security.policy. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 30/9/2016 Ballot 364 came into effect. The CP of Logius PKIoverheid already stipulated the use of 64-bit serial numbers and as such, no change was deemed necessary to the CP. Our CP (Programme of Requirements) is a baseline document, stating the absolute minimum. This ballot predates the incident which PKIoverheid had about serial numbers with one of her other TSP's in 2017 [1]. Measures which were taken then didn't apply retroactively. 3/8/2019 12.30 While reading MSDP the Logius PKIoverheid started an investigation if it was possible that her TSP's had this implementation/interpretation issue 3/8/2019 13.15 Logius PKIoverheid suspects that this issue could potentially impact one or more of the TSPs under PKIoverheid. Logius PKIoverheid asked the TSP KPN to launch an investigation if said issue was applicable to certificates issued by KPN. 3/11/2019 09:53 Logius PKIoverheid asked KPN for an update following statements from both Google and Mozilla representatives stating that in their view the matter as reported by several other CAs violates the BRG. 3/11/2019 16:55 KPN answers that this issue is potentially impacting all of their issued TLS certificates issued between September 30, 2016 and March 5, 2019. On March 5, 2019 KPN switched to using 96 bit serial numbers (already planned a while ago, this was not related to the current issue at hand). 3/12/2019 10:30 Due to the potential impact of revoking (and replacing) the PKIoverheid certificates from KPN issued in the period an incident is raised within Logius. KPN PKIoverheid certificates are in use by many Dutch government parties including the national ID system (DigiD), the tax services and Dutch customs. Because of this a crisis team is formed (also due to the fact that March/April is the month in which most tax returns need to be filed and the ever increasing change of a no-deal Brexit, which would greatly impact Dutch Customs) . 3/13/2019 12:00 Logius PKIoverheid orders KPN to further investigate which certificates are exactly affected and order KPN to revoke the certificates in question. 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. All certificates issued by KPN after March 5 08:30 are using 96-bit serial numbers. As mentioned this was a change unrelated to the current issue. As far as we know there are no TSPs within PKIoverheid other than KPN were up to recently issuing certificates with this issue. Further investigation is ongoing to see if there are possible historic issuance that might be impacted by this issue. We will post an update when we have more information. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. Potentially 22.000 TLS certificates issued by KPN CAs https://crt.sh/?id=63094369 and https://crt.sh/?id=16678400. Also potentially ~350 EV certificate issued by CA https://crt.sh/?id=15971988. Investigation is still ongoing to which certificates are exactly affected. 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. Still being collected. Will update when available. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. As stated in the timeline, the Programme of Requirements (PoR, CP) PKIoverheid already stipulated the use of a serial number with a 64-bit length. When ballot 264 went into effect, both the PA and the TSPs determined that PKIoverheid was already compliant. The conversations about the underlying thoughts or intent of the ballot were seen at the time but not taken into account when deciding the final impact. The final text of the ballot after it was passed was used to check if implementations were correct. In this case the TSP also relied on the configuration of EJBCA and assumed that this was the correct implementation (again, also based on their interpretation of the text). 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. Still being worked on. The intention is to revoke all affected certificates within 30 days. Will update when we have more information. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4 oZ__BwAJ Kind regards, Jochem van den Berge CISSP Logius PKIoverheid Public Key Infrastructure for the Dutch government ........................................................................ Logius Ministry of the Interior and Kingdom Relations (BZK) Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague PO Box 96810 | 2509 JE | The Hague ........................................................................ [email protected]<mailto:[email protected]> http://www.logius.nl<http://www.logius.nl/> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
