Handle certificate decompression in pkcs15 layer, rather than in drivers

[Jakuje]

Problem Description

The certificate decompression is no handled inside of read_binary() functions of particular drivers. It is error-prone, hard to get right and unnecessary code duplication that needs to handle corner many cases.

Proposed Resolution

In #2116 it was suggested we can move the decompression to pkcs15-layer (even though there is no standard for using compressed certificates there) and decompress "on the fly" if the driver will detect the certificate is compressed and sets some flag in sc_pkcs15_object_t.

Steps to reproduce

grep for sc_decompress in drivers. At this time, the drivers cac, cac1, coolkey, dnie, gids, idprime and piv support compressed certificates and each of them handles them a bit differently.

Logs

--

[frankmorgner]

Before leaving sc_pkcs15_read_file() would be a good place to handle decompression with an sc_pkcs15_object_t flagged as compressed. This then should cover certificates and other objects (files) exposed via PKCS#15.

[dengert]

All or most of the driver listed above are emulating pkcs15 They already handle decompression. As I have said before PIV driver need to decompress certificates (which are contained in certificate objects that include other data) to emulate public key and private keys at card and and pkcs15 levels.

There maybe pkcs15 cards with compressed objects. As far as we know, pkcs15 does not say anything about this. Thus any application that knows objects have data that must be decompressed, already knows how to handle it.

I would be very reluctant to try and out guess the cards/applications handling of compressed data.

I do not have a copy of iso 7816-15 to see if it says anything about compression. If it does then we should implement what it supports. If not we should propose how it could be done in pkcs15.