Optional support for transactions when performing operations that modify card content

[dmercer-google]

There should be a mechanism which allows for the use of transactions when performing multi step operations which result in changes to the data managed by the applet.

An example where this may be useful would be when credentials are renewed. The card would generate a new keypair and the service side would form and sign a certificate and write it to the card. This may be done in a not strictly controlled environment (e.g. at a reception desk when issuing a visitor badge) and there may be cases where it fails for any number of reasons (e.g. an issue with a cloud based CA, etc).

[makinako]

@dmercer-google @spaikmos I'm thinking about how to get this in to suit your use case easily.
I don't think this is useful for initial card pre-perso and perso given the large quantities of data involved and the fact that it's usually done in a pretty contained environment.

So this leaves the example above which is key/cert renewal. This makes sense because you can never update the key without updating the corresponding certificate.

So some options could be:

1. Have generic extension commands for Begin/Commit/Abort transaction that just maps through to the JC functions. I think this has the potential to be incorrectly or over-used, but on the other hand it is very easy to implement.
2. Add a configuration parameter to automatically start a transaction (if supported) when GENERATE ASYMMETRIC KEYPAIR is called. Then have the PUT DATA command check if there is a transaction, update the data object and commit it. This would presume that the next PUT DATA you send is for the appropriate CERT object (which is probably a safe bet). Anything else would abort the transaction.

I like option 1 because the intent is clear but it is prone to incorrect or excessive use.
I like option 2 because potentially it requires no knowledge by the key renewal system beyond standard PIV.