Features / requirements for future IsoApplet version

[philipWendland]

Hello everyone,

recently there have been some requests of missing features that should be implemented with the planned future version of IsoApplet (that targets JC 3.0.4), e.g, #18, #22.

I created a "project" to gather all additional sensible requirements for a new version that I could think of:
https://github.com/philipWendland/IsoApplet/projects/1

You are kindly invited to suggest additional requirements or discuss the existing ones.

--
One note regarding the time frame:
I won't have much spare time this year (as I am trying to finish a thesis). I expect the development to speed up sometime in H1/2021. But let's see. The motivation for this is currently only altruistic, and sometimes (or often) things get in the way.

Regarding OpenSC: I think it would be best to move common driver features to a separate file, and implement specific stuff in isoApplet-1 and isoApplet-2 specific files. Backwards compatibility (new versions of OpenSC with old applet versions) is a priority for me.

[ghaithsabba]

Hi, i have question regarding the new version, is it going to support Attestation?

[philipWendland]

Hi, what exactly do you mean by attestation?

[mistial-dev]

Hi, what exactly do you mean by attestation?

Attestation (as used in devices like the YubiKey) allows a device to have a key loaded, or a certificate issued to a generated key. This key is then used to certify (or "attest") that a key was generated on-device. It's generally used when the manufacturer of the device is more trusted than the user.

As an example, Adobe requires that keys used with their Adobe PDF Signing trust list are generated and remain on-module. The YubiKey device will only attest keys that are generated on device. It has essentially an intermediate certificate authority specifically for attestation, and it will generate X509 certificates for keys that were created on-device.

These attestation certificates serve as proof to CAs that the Adobe trust requirements are met, and allows them to issue certificates to keys generated on a YubiKey.

As an example of an implementation, theirs is described here.

https://developers.yubico.com/yubico-piv-tool/Attestation.html

https://developers.yubico.com/PIV/Introduction/PIV_attestation.html

In their case, they also include OIDs that indicate things like the firmware version, FIPS compliance, and PIN and Touch policies.

[KingCZE]

Hi, does it change anything if I change the target from 3.0.4 to 3.0.5? Would it add any benefits? Would it even work?
Thanks.

[s4d-quantum]

noot really a feature or anything like that but itd be very nice to be able to just download the .cap file rather than having to maul through trying to build it ourselves,

is there actually a reason for not providing pre compiled cap files? i get there may be some folk with security concerns but even if its just for tesing purposes itd save a lot of folk who arent regularly building javacard apps a good chunk of time and messing about installing a build system they will likely never use again

[mistial-dev]

I've got a github actions build working somewhere, could probably put together a pull request to build the artifacts (.cap files).

[martinpaljak]

noot really a feature or anything like that but itd be very nice to be able to just download the .cap file rather than having to maul through trying to build it ourselves,

is there actually a reason for not providing pre compiled cap files? i get there may be some folk with security concerns but even if its just for tesing purposes itd save a lot of folk who arent regularly building javacard apps a good chunk of time and messing about installing a build system they will likely never use again

Is it difficult? What should be improved? It should be pretty straightforward:

• do git checkout of right branch
• have java and set $JAVA_HOME
• have ant and type "ant"