If a user clicks on the "i" button as per the attached, mock-up screenshot, a pop-up will open and show as ASCII Text
a. origin URI, protocol, SHA256, SHA1, ... of the downloaded (or uploaded) file
b. CN, Issuer-CN, SHA256, SHA1 of remote public key (if the transfer was encrypted)
for 1b) not only the meta info is shown, but the certificate (assuming x509 for once) and its chain down to the root can be opened
the pop-up and public key (certs) are put into a PDF that is signed with a dummy certificate and rfc3161 time-stamped (e.g. with http://tsa.pki.admin.ch/tsa - configurable)
the same as 3) but the signature can also come out of a SuisseID or alike
the same as 4) but the pdf complies with the PDF/A standard ==> the certificate can no longer be put as a file-attachment in .cer or .pem .crt or similar format to the pdf, but the base64 encoded certs need to be printed as base64 PEM into the trailing pages of the PDF
The goal is that evidence of an upload is visible (best even rfc3161 timestamped) that can be understood / used by a non-technical person like a "lawyer" who is increasingly trained by the authorities to work with pdf/a and digital signatures/timestamps.
#10255 closed as duplicate.
Okay thanks - my proposal was similar to this. As it doesn't stipulate currently in the uploads panel that all the files were checksum'd on prior to upload and transfer completion can I therefore assume that CyberDuck has done so and therefore wouldn't display "completed" unless this test has also been completed successfully and that the files on B2 are definitely identical copies of the local files? I can live without the feature if this is the case.