[FlorianFranzen]

PUT DATA with an empty object stored a zero-length file, and the following GET DATA answered 9000 with an empty object. On a YubiKey the empty PUT DATA is the delete primitive: yubikit's delete_certificate is put_object(id) with no data, and ykman then expects the object to be absent. An empty object now removes the stored file, and for a PIN-protected object its sealed key file as well, so GET DATA answers NotFound afterwards and a deleted retired certificate no longer counts in the key history object. Objects with a built-in default (CCC, printed information, discovery object) serve that default again; the CHUID, which is written at initialization, answers NotFound once deleted instead of hitting the panic! that guarded its default.

Tested in command_response.ron: delete of a certificate object, of a retired certificate as seen through the key history, of a PIN-protected object, and of the CHUID.

[FlorianFranzen]

Heads-up for whichever of #52 and #55 lands second: #55's test deletes a retired certificate and then expects the key history object to come back as the synthesised empty one (53 08 C1 01 00 ...); with #52 merged that object is absent and the expectation becomes NotFound. One-line change in command_response.ron, I will push it to the one still open at that point.