From the Chrome bug report:
Estonian IDs issued between September 2014 to September 2015 are broken and use negative moduli.
Not content with signing negative RSA moduli, still other Estonian IDs have too many leading zeros.
In Estonia there are 100 000+ such ID-cards and without any change with chrome 46 those card owners could not use chrome any more for every day usage.
ASN.1 DER encoding specifies that positive integer [having msb of MSB set] has to be encoded with 0-byte prefix. However, the certificates in question omit 0-byte prefix for RSA public key modulus and therefore standards complying Chrome DER decoder interprets public key value as an [invalid] negative integer.
Google developer hints that SK’s recently passed annual audit falsely attests that SK operations confirm to the standards:
It would seem each of these certificates fails to conform to the ETSI TS 102 042 policies (for which sk.ee was audited), which would invalidate them for use as QCP-SSD/QCP/NCP, nor would they conform to the sk.ee CPS in force at this time. If so, wouldn’t all of these certificates need to be revoked, per sk.ee’s CPS?
First SK asked for a “temporary” workaround, later committing to recall the ID cards in question in the next 6 months:
Is there possible to make temporary (for 5 years) workaround for such cards in chrome 46 and beyond?
AFAIK, no more certificates with incorrect encoding are being generated and the renewal of the issued ones is being planned. It shall require time, less than 5 years but obviously not a month or two, due to the sheer number of the cards out there.
6 months seems like a realistic target.
Translation of Postimees article:
Due to a software failure by Estonian ID card software vendor AS Sertifitseerimiskeskus about 250 000 ID cards have an error that may in the future cause its usage problem. ID cards with software faulty certificates were issued for one year since September 2014 and if error is not fixed in the following six month, then people will not be able to authenticate themselves anymore in the future versions of the world’s second most popular web browser Google Chrome.
“This is certainly non-compliance with standards on our side. We let error through in our software development. Reason, why this error went through and was permanent is that no browser had discovered it until now and our ID card so far works with them excellent” head of SK Kalev Pihl explains to Postimees. The thing come to light when Google made a big software update which controls subtlety, what no other software have done so far. “It came out that some certificates on Estonian ID cards do not conform to requirements,” says Kalev Pihl, who says that the error came out during the beta-testing of the new browser software.
Pihl confirms that SK agreed with Google for a half year long transition period. Result is that Chrome will not add the new software at the moment and people can use this browser for authentication with no problem. “That half a year of development time should be really enough in order to provide to a person a solution where he/she can renew ID card certificates behind the computer with one button press,” adds Pihl. “Usually during our testing we discover bugs introduced by browser developers, this time they discovered error on our side,” summarized Pihl.
RIA plans a remote update feature for Estonian ID cards / e-residency cards:
The functionality, prompting card owners to update the certificates online, has once been part of the Estonian ID card software suite and will now be re-implemented. The procedure of initiating the remote update procedure on the certificates is to be implemented in a way that is both easy to use and secure. Veinthal said the security and risk of the new functionality were to be analysed before implementation. “The eID framework has to be aware that interoperation glitches are becoming more frequent in the world of technology, increasing the necessity to create fast and convenient solutions,” commented Veinthal.
According to SK CPS they are using commercial “KeyOne certification software” which apparently had this bug.
I am wandering whether Google will not break a lot more software out there:
“Some Microsoft software will generate negative values about 50% of the time whenever it encodes anything as an INTEGER because it ignores the fact that the top bit of an integer is the sign bit (this is still occurring in programs released as recently as early 1998).”
Yes, other certificates are impacted. At least one root certificate has this problem, and certificates generated by the latest version of Microsoft MakeCert (shipped with VS2008) can also have this problem.