Guide for testing the new ID-card

Introduction

This document is intended for preparing for the introduction of the new ID-card for the owners or administrations of information systems supporting the use of the ID-card. The changes and the possible effects of the changes on information systems related to the introduction of ID-cards by a new manufacturer are described in more detail here.

The target group of the document is people who are actually engaged in managing and configuring information systems.

Below are listed the recommended testing activities, possible test cases, and the necessary tools for testing based on the most commonly used service types in the EID ecosystem and the changes accompanying the introduction of the new ID-card.

 

Authentication in web services

Authentication in online services has been resolved by establishing an SSL/TLS/HTTPS connection between the user’s web browser and the web service provider’s web server on the basis of the ID-card authentication certificate. The OCSP service or CRL lists can be used to verify the validity of the user’s certificate.

The new ID-card affects the online authentication service in the following ways:

  • New ID-card drivers will be added to end-user computers on all platforms. This change is covered by software by RIA and the risk should be minimal and hedged for the information system managers.
  • OCSP with restricted access (address: http://ocsp.sk.ee/, test address: http://demo.sk.ee/ocsp)
    • The service will work under the old conditions. A respective contract with SK must be concluded for using the service. The service works for both new and old certificates.
  • An additional AIA-OCSP with unrestricted access is added for confirming the validity of the certificates. The URL for the AIA-OCSP with unrestricted access can usually be found in the certificate. Each CA branch has its own URL and certificate to sign OCSP responses. NB! For older certificates, this URL may not be present in the certificate, in which case the URL should be found in the following list:

 

Live chain service URL

Test chain service URL

http://aia.sk.ee/esteid2018

http://aia.sk.ee/eid2016

http://aia.sk.ee/esteid2011

http://aia.sk.ee/nq2016

http://aia.sk.ee/eid2011

http://aia.sk.ee/klass3-2016

http://aia.sk.ee/klass3-2010

http://aia.sk.ee/klass3-2016

http://aia.sk.ee/esteid2015

http://aia.sk.ee/klass3-2016

http://aia.sk.ee/eid2016

http://aia.sk.ee/klass3-2016

http://aia.sk.ee/nq2016

http://aia.sk.ee/klass3-2016

http://aia.sk.ee/klass3-2016

http://aia.sk.ee/klass3-2016

Information agreed upon for the signature in the nonce field (BDOC-TM (TimeMark) should not be used in the AIA-OCSP service with unrestricted access.

NB! The certificates used for signing responses of AIA-OCSP with unrestricted access have a short validity.

  • The new ESTEID2018 certificates do not have a CRL address. If necessary, the CRL address can be found here.
  • The format of the certificate SN (SerialNumber) field will change (the prefix ‘PNOEE-’ will be added).
    • This may affect information systems and services which use information on the certificate’s ‘Serial no’ field to identify the personal identification code in the authentication process.
  • Signing through the PKCS11 interface may change.
  • May affect information systems which use application layer signing as the solution for authentication, as referenced here and carried out here.

Recommended activities for developers/administrators of information systems using the online authentication service to hedge the risks associated with the changes:

  • Configure the certificate (test) chain necessary to support the new manufacturer’s (test) card in the (test) online service.
  • Make the necessary changes to correctly identify the personal identification code from the user certificate.
  • Make the necessary changes to confirm the validity of the certificate. Either OCSP with restricted access or AIA-OCSP or CRL with unrestricted access.

To test the online authentication service, the service manager or developer must obtain the new manufacturer’s test card and the EID software package supporting the test card and perform at least the following tests:

  • Successful authentication with the current manufacturer’s card and the new EID software package.
  • Successful authentication with the new manufacturer’s card and the new EID software package.
  • Successful authentication with the current manufacturer’s card and the current EID software package (backward compatibility).
  • Authentication with a card with certificates revoked or suspended by the current manufacturer. *
  • Authentication with a card with certificates revoked or suspended by the new manufacturer. *

It is recommended to carry out the successful authentication tests on all web browsers supported by EID software with at least one computer running Windows, MacOS, and Ubuntu.

To verify that the software installed on your computer is working with a new ID card, it is possible to test the authentication here.

* To revoke or suspend the card certificate, enter the https://demo.sk.ee/upload_cert/ test environment.

 

ID-card authentication on Windows domains or individual machines

Very 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.

The new ID-card will probably affect the identification of users on computer networks in the following ways:

  • Possible changes in the LDAP address and the response structure.
    • May affect systems where the programmatically available LDAP service is used to obtain user certificates and update information. If possible, the AIA-OCSP service should be used instead of the LDAP service.
  • OCSP and AIA-OCSP – see the previous chapter.
  • Removing the CRL URL from the certificate. If necessary, the CRL address can be found here.
  • The format of the certificate ‘Serial no’ field will change (the prefix ‘PNOEE-’ will be added)
    • May affect systems which programmatically use the personal identification code information on the ‘Serial no’ field of the certificate.

We recommend the following activities for the managers of computer networks where users are authenticated with an ID-card to cope with the changes in the ecosystem associated with the introduction of the new manufacturer’s ID-card:

  • Configure the certificate (test) chain necessary to support the new manufacturer’s (test) card. The necessary certificates are available here.
  • Make the necessary changes to find the correct certificate on the basis of the user’s personal identification code (if the personal identification code value is used on the ‘Serial no’ field on the certificate).
  • Make the necessary changes in confirming the validity of the certificate (either OCSP with restricted access or AIA-OCSP or CRL with unrestricted access).

To test whether the user can log into the network/computer with an ID-card, the system administrator must obtain a test card of the new manufacturer from the Information System Authority and the EID software package supporting the test card and carry out at least the following tests:

  • Adding a user using the new manufacturer’s ID card to the system.
  • Adding a user with the current manufacturer’s ID card to the system.
  • Transferring the user form the current manufacturer’s card to the new manufacturer’s card*
  • Successful login/authentication with the current manufacturer’s card.
  • Successful login/authentication with the new manufacturer’s card.
  • Authentication with a card with certificates revoked or suspended by the current manufacturer*
  • Authentication with a card with certificates revoked or suspended by the new manufacturer*
 

Encryption solutions

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, encryption of e-mail messages in e-mail clients.

The encryption/decryption of EID desktop application(s) 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. 

It is important to pay attention to information systems which encrypt data on ID-card certificates to ensure safer exchange of information between ID-card holders.

It is also important to pay attention to ID-card owners who use the encryption and decryption of correspondence in the email client.

The new ID-card will probably affect ID-card encryption in the following ways:

  • Changes in the LDAP address and 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 ‘Serial no’ field will change (the prefix ‘PNOEE-’ will be added).
  • The format of the e-mail address on the certificate will change. The new format is ‘12345678901@eesti.ee’.

In information systems using encryption to ID-card certificates, it is important to pay attention to the possible change needs in relation to requesting certificates from LDAP and the format change of the information on the certificate’s ‘Serial no’ field. If information is also automatically transmitted by e-mail to ID-card in encrypted from the information system, the format change of the e-mail address may also be important.

Administrators of such systems should obtain from the Information System Authority the new manufacturer’s test card and the EID software package supporting the test card and carry out at least the following tests:

  • Encrypting data to the owner of the current manufacturer’s ID-card and decrypting the data with an ID-card.
  • Encrypting data to the owner of the new manufacturer’s ID-card and decrypting the data with an ID-card.
  • Transferring data to the owner of the current manufacturer’s ID-card as an encrypted e-mail and decrypting the e-mail with the email client (if used in the information system).
  • Transferring data to the owner of the new manufacturer’s ID-card as an encrypted e-mail and decrypting the e-mail with the email client (if used in the information system).

In encrypting correspondence with the ID-card certificate, attention must be paid to the fact that the form of the e-mail contained in the certificate will change: the name of the person is replaced with their personal identification code. To keep encrypting/decrypting in the email client, e-mail must now be sent to the e-mail address containing the personal identification code.

To test the encryption/decryption of e-mails encrypted to ID-cards in the email client, the following tests should be performed:

  • Sending an e-mail encrypted to an ID-card to an owner of the current manufacturer’s ID-card and decrypting the e-mail with the email client.
  • Sending an e-mail encrypted to an ID-card to an owner of the new manufacturer’s ID-card and decrypting the e-mail with the email client.

It is recommended to carry out the tests with all email clients supporting the decryption of e-mails encrypted to an ID-card on at least one computer operating on Windows, macOS, and Ubuntu.

 

Signing and conforming the validity of signatures

In Estonia, various institutions and organisations use local document management systems which also support digital signing with ID-card or mobile-ID. Some systems create signed documents for internal use only and these documents are not forwarded to the public eID ecosystem. Other systems are part of the public eID ecosystem – they create documents which are forwarded to other systems of the ecosystem and at the same time, use documents created and signed elsewhere as input.

In such open systems, it is important to ensure compatibility with other eID ecosystem components and previously created containers.

As the ID-card of the new manufacturer is added to the eID ecosystem, the administrators/developers of information systems using digital signatures must consider the following changes accompanying the new ID-card:

  • AIA-OCSP and OCSP – see chapter ‘Authentication in online services’. The AIA-OCSP cannot be used for creating TM signatures.
  • The format of the certificate ‘Serial no field will change (the prefix ‘PNOEE-’ will be added).
    • May affect information systems which use personal identification code information and read it from the certificate’s ‘Serial no’ field.
  • Signing through the PKCS11 interface may change.
    • This may affect the signing functionality in information systems communicating with the ID-card directly though the driver in the user’s computer.
  • The .ASIC format will be the default format in the EID base software and only signatures with a timestamp (TS) are created. This, however, means that in the future, .BDOC files can also have a TS signature. Information systems using the outdated JDIGIDOC library may encounter problems in processing .ASICE envelopes.

The signing capability of documents greatly depends on the software libraries and card drivers in the eID software package offered by the Information System Authority and these have also been tested by the Information System Authority (look here). However, the Information System Authority cannot be responsible for how the components in the information systems are used and how and with which eID ecosystem background services the systems are interfaced. Therefore, we recommend that the administrator/developer of the system carry out at least the following tests related to signing:

  • Creating and signing a BDOC container with the current manufacturer’s ID-card.
  • Validating the created container with the eID end user’s software.
  • Validating the created container with the eID SIVA service.
  • Creating and signing a BDOC container with the new manufacturer’s ID-card.
  • Validating the created container with the eID end user’s software.
  • Validating the created container with the eID SIVA service.
  • Creating and signing an ASiC-E container with the current manufacturer’s ID-card.
  • Validating the created container with the eID end user’s software.
  • Validating the created container with the eID SIVA service.
  • Creating and signing a BDOC container with the new manufacturer’s ID-card.
  • Validating the created container with the eID end user’s software.
  • Validating the created container with the eID SIVA service.
  • We recommend checking both ‘old’ bdoc files (with TM signatures only) as well as bdoc files with the TS signature.

When carrying out tests with the test cards, it must be made sure that the systems have been configurated to recognise the test certificates.

When testing with the test certificates with the SIVA service, the SIVA test address should be used: https://siva-arendus.eesti.ee/V2test/

To carry out these tests, administrators/developers of the information systems should obtain from the Information System Authority the new manufacturer’s test card and the EID software package supporting the test card.

If the information system is structured in a way that the eID software library interacts in the user’s machine with the ID-card directly through the driver (rather than signing through the web browser plugin), we recommend carrying out the tests on all operating systems supported by the system.

To verify that the software installed on your computer is working with a new ID card, it is possible to test the signing in the browser here.

 

Client card solutions

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.

There are several different ways to obtain a personal identification code from an ID-card: reading information from the personal data file or reading the necessary information from the certificate. 

The new ID-card will probably affect the use of ID-cards as client cards in the following ways:

  • The structure of personal data and commands to obtain personal data from the card.
    • This affects systems using the personal data file on the ID-card to obtain information.
  • The format of the certificate ‘Serial no’ field will change (the prefix ‘PNOEE-’ will be added).
    • This may affect systems using the personal identification code information on the certificate’s ‘Serial no’ field to obtain the personal identification code.
  • The format of the e-mail address on the certificate will change. The new format is ‘12345678901@eesti.ee’.
    • This may also affect systems which also read the official e-mail address for the person’s contact data.

To test the client card solutions, one must obtain the test card of the new manufacturer from the Information System Authority and, depending on the source for obtaining data (personal data file, certificate), make the necessary changes in the systems.

As the new manufacturer’s cards to not replace the existing cards, but are added to them, it must be ensured during the tests that cards of different manufacturers would work at the same time and that the systems are able to, depending on the card, choose the right method for requesting personal data.

It is difficult to define more detailed tests because the systems are very different. However, the main positive applications, as well as the most common errors, must be tested with cards of both the new and current manufacturer.


ASK FOR HELP

If you didn't find an answer to your question, send it to our team.



  • See instructions
  • Please estimate your ability to use the computer, so that we can provide you with the best guidance

         

  • Verification failed

How can we improve the article and be more helpful?
Send Close