Source: https://www.id.ee/?lang=ru&id=38693
Timestamp: 2019-10-15 09:56:45
Document Index: 159854191

Matched Legal Cases: ['arts 1', 'art 1', 'art 2', 'art 3', 'art 4', 'art 5']

Changes in the new ID-card > New ID-card > Testing the services > FOR DEVELOPER > ID.ee
Обновлено: 02.04.19 15:33
At the end of 2018, the ID-card manufacturer will change. Instead of the current manufacturer Gemalto, the Police and Border Guard Board will start working with IDEMIA. This means that there will be a number of changes both in the card and the accompanying software and services. The change in the manufacturer means new standards.
It is important to keep in mind that with the new partner, new cards will be added to the ID-card ecosystem and used in parallel with the existing ones, marking the start of a 5-year transitional period where ID-cards of both the current and new manufacturer are used.
Changes related to the new ID-card
In the certificate of the new card, the personal identification code is written on the SN (SerialNumber) field as PNOEE-1234567890, not 1234567890 (as it is now). If the information system reads the personal identification code from the SN field (not CN (CommonName) field or the PersonalData file) and looks for the personal identification code in a specific format; there may be errors in using such a card both when entering services and using them. Read more HERE.
The structure of the PersonalData file and the commands for accessing them have changed, which is why the new cards cannot be used, for example, in some client card systems. Read more HERE.
Certificate validation services AIA-OCSP and OCSP – read more in chapter ‘Card validity confirmation service check through OCSP’.
The ASICE format will be the default format in the DigiDoc4 client software. Outdated JDIGIDOC library do not support ASICE envelopes, more information here.
Changes in the document type descriptions in the certificate (OID). The certificate profile description is being approved.
The LDAP address and structure will change. Different types of documents (Digi-ID, ID-card, etc.) are easier to distinguish in LDAP. The location of the access point of the LDAP service must be checked and tested in systems that use the LDAP service (for example, to create encrypted documents) to check whether the LDAP search works (the specification is being approved). The LDAP address will change – the new address will be ldaps://esteid.ldap.sk.ee.
CRL URL will disappear from the certificates – this may mainly affect those systems which use certificate revocation lists (CRLs) for verifying the validity of the certificate in the authentication process.
The CRL address is available here: https://www.sk.ee/en/repository/CRL/
Which services are affected by the changes?
All information systems supporting the use of the electronic component of ID-cards issued in Estonia are affected. The main functionalities affected by the changes are the following:
Identifying users when entering the information system (authentication).
Identifying users when logging into Windows (domain).
Managing signed documents (asice as the default format).
Encrypting documents to ID-card.
Using the ID card as a client card.
What impact can the changes have?
Depending on the functionality offered by the particular information system and the used solutions, any of the effects listed below should be considered:
Authentication in online services
Card drivers on all platforms. New card drivers will be added.
This change is covered by the Information System Authority’s software support and in the context of EID ecosystem testing, the risks associated with this change can be considered to be hedged.
When checking the validity of certificates through CRL, keep in mind that with the new CA ESTEID2018, the CRL URL is no longer included in the certificate. The new CA CRL URL is available here.
When checking the validity of certificates with access restriction from the SK validity confirmation service, remember that for certificates issued under ESTEID2018, ocsp.sk.ee confirms the replies with the SK OCSP RESPONDER 2011 certificate in the service. SK OCSP RESPONDER 2011 is already in use for all other certifications. More detailed information about validity confirmation services with access restrictions is available on the home page of SK ID Solutions AS.
When checking certificate validation information through the AIA-OCSP service with unrestricted access, you must use the AIA-OCSP service URL in the certificate. For new cards, the URL is http://aia.sk.ee/esteid2018. More detailed information about the certificates, CRL and OCSP profile, and AIA-OCSP conditions is available on the home page of SK Solutions AS.
More information about checking the validity of certificates is also available in chapter ‘Card validity confirmation service check through OCSP’.
This may affect information systems and services using information on the certificate’s SN (SerialNumber) field to identify the personal identification code in the authentication process. The change is due to the standard: TS 119 412-1 p.5.1.3 http://www.etsi.org/deliver/etsi_ts/119400_119499/11941201/
Many companies and institutions use centrally managed computer networks where users are authenticated with ID-cards. Logging into the Windows domain or authenticating to the server over RDP are very common. In both cases, the user authentication certificate (protected with PIN1) is used to identify the user and associate them with the account.
Possible changes in the LDAP response structure.
May affect systems where the programmatically available LDAP service is used to obtain user certificates and update information.
Certificate validity confirmation – see the previous clause and the description on confirming certificate validity in chapter ‘Card validity confirmation service check through OCSP’.
The format for the certificate SN (SerialNumber) field will change (the prefix ‘PNOEE-’ will be added).
May affect systems which programmatically use the information on the ‘Serial no’ field of the certificate. The change is due to the standard: TS 119 412-1 p.5.1.3 http://www.etsi.org/deliver/etsi_ts/119400_119499/11941201/
The Estonian ID-card authentication certificate also supports its use for encrypting and decrypting data. As the certificates on the ID-card have a relatively short validity period of 5 years, the use of the certificate may be prohibited due to the physical problems of the ID-card (deterioration, loss). Therefore, this kind of data encryption method is not appropriate for long-term data storage. The primary use of ID-card encryption is ensuring the confidentiality of data during transport (correspondence). Data encryption on an ID-card certificate can be used in many ways: document encryption using the EID Desktop Application, encryption of information forwarded from the information system to a person, or encryption of e-mail messages in e-mail clients.
The testing of the functionality of encryption/decryption of EID desktop application(s) is covered by the Information System Authority’s testing of the EID components and is not in the scope of this testing.
It is important to pay attention to information systems encrypting data on ID-card certificates to ensure safer exchange of information between ID-card holders.
The LDAP address will change and there will be possible changes to the response structure. For LDAP, there is a change to the LDAP server address. The new address will be ldaps://esteid.ldap.sk.ee. The catalogue is served over a more secure LDAPS (Lightweight Directory Access Protocol (LDAP) over Secure Sockets Layer (SSL) / Transport Layer Security (TLS)) protocol.
The format of the certificate SN (SerialNumber) field will change (the prefix ‘PNOEE-’ will be added)
OCSP – read more about confirming the validity of certificates through OCSP from chapter ‘Card validity confirmation service check through OCSP’. However, when creating signatures, it must be remembered that the AIA-OCSP service with unrestricted access must be used for only creating timestamp (TS) signatures. Creating timemark (TM) signatures is not allowed with this service.
Changing the default format in the eID software to ASICE – this affects information systems which use an older Java library (Jdigidoc) which do not support this format.
Information systems that use the ID-card only to obtain personal information (personal identification code) and where the user does not need to identify themselves using the PIN1 code can be summarised as client card systems. This includes different trading companies, passage systems, and ticket systems.
Structure of personal data and commands to obtain personal data from the card.
This affects systems which use the personal data file on the ID-card to obtain information.
This may affect systems which use the personal identification code information on the certificate’s ‘serial no’ field to obtain the personal identification code.
This may also affect systems which also read e-mail addresses.
How do I know if my system will be affected by the changes?
The easiest and quickest way is to:
Apply for a test card of the new ID-card from the Information System Authority.
Read through the testing instruction manual, which is available here.
When testing, be sure to use a test system which supports the test circuits.
Create a file with test signatures with the DigiDoc4 beta software in the ASICE format and try to upload it to your system similarly to other digitally signed files (more information about the formats of different envelopes is available here).
We also recommend BDOC signing with several signatures and confirming the validity of the signatures of such files. The file should be created so that it has both BDOC-TM (TimeMark) and BDOC-TS (TimeStamp) signatures.
Read about the descriptions of the changes in this guide.
30 June 2018: information day on the eID and starting to distribute the test cards.
September: Technical training for developers.
Second half of October: start of the distribution of the new version of the eID base software and drivers of the new card manufacturer. Release of the DD4j library.
End of the year 2018: New eIDs will be issued
January 2019: the default format for digitally signed envelopes in the eID base software will be ASICE.
Changes in the physical ID-card
Major changes in the card (chip and chip applications):
New chip: NXP secure microcontroller SmartMX2 CPU – P60D145. Memory ROM (kB) 512/586. More technical details are available on the home page of the manufacturer.
The chip has an ID-One™ Cosmo v8.1 platform, certified at level CC EAL5+.
Cosmo meets the latest international standards:
ISO/IEC 7816 parts 1, 2, 3, 4, 5, 6, 8, and 9
The ISD (​Issuer Security Domain​) has authentication and signing applications meeting IAS-ECC standards. The applications meet IAS-ECC standards
CEN/TS 15480-1:2012 Identification card systems – European Citizen Card – Part 1: Physical, electrical and transport protocol characteristics
CEN/TS 15480-2:2012 Identification card systems – European Citizen Card – Part 2: Logical data structures and security services
CEN/TS 15480-2:2012 Identification card systems – European Citizen Card – Part 3: European Citizen Card Interoperability using an application interface
CEN/TS 15480-4:2012 Identification card systems – European Citizen Card – Part 4: Recommendations for European Citizen Card issuance, operation and use
CEN/TS 15480-4:2012 Identification card systems – European Citizen Card – Part 5: General Introduction
Commands for reading data from the personal data file (application protocol data unit – APDU) and the format for returned information.
More information about the chip, applications, APDU examples, and the format of data included on the card is available here.
Developments of Information System Authority applications and libraries
The plan for releasing the software is as follows. The plan is preliminary and can be changed, if necessary.
Changes to the base software:
The base software will sign and decrypt over the driver.
ASICE will be the default format in creating a signed envelope.
The ATR feature of the new card is added to the extension so that the system can use the correct driver.
Base software – the second half of October:
New card drivers
Windows versions: mini-driver with support for the new card.
Ubuntu Linux versions IDEMIA PKCS11
Updates to the web browser extensions
The IE extension will not change.
The Edge extension will not change.
Firefox – will change in the Linux environment. (The mini-driver is used in Windows).
Software component upgrades according to the feedback from the testers of the new eIDs.
Base software – December 2018:
OSX: IDEMIA TokenD (Chrome and Safari authentication) and Idemia PKCS11 driver
Ubuntu PKCS 11 driver.
Safari and Firefox support in the OSX environment.
Software component upgrades according to the feedback from the users of the new eIDs and information systems developers
Libraries, Java library DD4J – second half of October:
Jdigidoc’s restructuring DDOC4J – the signing functionality will be removed; errors related to DDOC validation will be corrected. The validation functionality will remain. The interface will not be changed.
Additions resulting from ID-1 (if necessary).
To attest the new ID-card on web servers during the authentication process
To attest the new ID-card on web servers, the CA root and intermediate certificate of the new card must be added.
https://sk.ee/en/Repository/certs/certificates-for-testing
Using an ID-card for logging into a Windows domain
The effects of the new ID-card on authentication in the Windows domain are currently being tested.
Card validity confirmation service check through OCSP
No changes are planned for the validity confirmation service check with restricted access provided by SK.
Users (owners of e-services) will be able to use AIA-OCSP with unrestricted access for validity confirmations, i.e. from now on, the user must decide whether they use the AIA-OCSP with unrestricted access or the OCSP with restricted access service for authentication or signing for a specific service.
If they start using the AIA-OCSP service, however, the following must be considered:
There are restrictions to the use of nonce – they cannot be used for creating TM signatures.
The URLs necessary for using the service must be read from the certificate.
Each CA chain has its own URL. Cross-usage is not recommendatory (it does work at the moment but may not in the future).
NB! Some of the old certificates do not have it; in this case, the following list must be followed:
The certificates used for signing an AIA-OCSP request with unrestricted access are short-term (1 month).