Change Details

scdaemon uses CCID Class protocol. It's defined by USB forum and the background is smartcard technology. The major problem (these days) is that the interaction is designed by the use case of smartcard and its data processing limitation. We can see OpenSSH larger data issue for its authentication. Consider the hypothetical case of sending (larger) data from a host, calculating hash of data by a device, which returns the digest. In CCID like protocol, whole data have to be sent to a device as a single object. There is no good way for a device to receive each chunk of data and process each chunk at a time, and lastly send back the digest to a host (w/ CCID Protocol). Smartcard data-chaining could be used in this case, but it's in upper-layer. In future, it's good for new device to use Vendor Specific Class and Protocol to take advantage of (larger) data handling. Perhaps, then, it's good to handle those devices by new <SOME-GOOD-NAME>d, in parallel to scdaemon and tpm2d.

scdaemon uses CCID Class protocol. It's defined by USB forum and the background is smartcard technology. The major problem (these days) is that the interaction is designed by the use case of smartcard and its data processing limitation. We can see OpenSSH larger data issue for its authentication. Consider the hypothetical case of sending (larger) data from a host, calculating hash of data by a device, which returns the digest. In CCID like protocol, whole data have to be sent to a device as a single object. There is no good way for a device to receive each chunk of data and process that each chunk at a time, and lastly send back the digest to a host (w/ CCID Protocol). Smartcard data-chaining could be used in this case, but it's in upper-layer. In future, it's good for new device to use Vendor Specific Class and Protocol to take advantage of (larger) data handling. Perhaps, then, it's good to handle those devices by new <SOME-GOOD-NAME>d, in parallel to scdaemon and tpm2d.

scdaemon uses CCID Class protocol. It's defined by USB forum and the background is smartcard technology. The major problem (these days) is that the interaction is designed by the use case of smartcard and its data processing limitation. We can see OpenSSH larger data issue for its authentication. Consider the hypothetical case of sending (larger) data from a host, calculating hash of data by a device, which returns the digest. In CCID like protocol, whole data have to be sent to a device as a single object. There is no good way for a device to receive each chunk of data and process that each chunk at a time, and lastly send back the digest to a host (w/ CCID Protocol). Smartcard data-chaining could be used in this case, but it's in upper-layer. In future, it's good for new device to use Vendor Specific Class and Protocol to take advantage of (larger) data handling. Perhaps, then, it's good to handle those devices by new <SOME-GOOD-NAME>d, in parallel to scdaemon and tpm2d.