Giacomo Tesio <giacomo@tesio.it> writes:
On August 22, 2020 7:32:47 AM UTC, Marco Scialdone <marcoscialdone@gmail.com> wrote:
La ricevuta completa della pec (quella che include anche il messaggio inviato e i suoi allegati e che tipicamente si usa nel pct o nelle notifiche processuali)) garantisce anche che quello che è stato ricevuto è esattamente quello che ho mandato (compresi gli allegati) nella remota ipotesi di contestazioni.
Cosa impedisce al ricevente della ricevuta di modificarne il contenuto prima di allegarla agli atti di un procedimento?
La ricevuta di consegna della PEC di cui parla Marco è un messaggio di tipo multipart/signed firmato con S/MIME dal provider del destinatario del messaggio PEC A meno che io stia prendendo una sonora cantonata (ho verificato su un paio di messaggi PEC) tutto il contenuto della ricevuta, compresi gli allegati, è inglobato in questo: --8<---------------cut here---------------start------------->8--- Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-1; boundary="----=_Part_281003588_807314074.1588076720058" --8<---------------cut here---------------end--------------->8--- Quindi può alterare il contenuto del messaggio solo chi è in grado di firmare con lo stesso certificato X.509: il provider del destinatario o un attaccante con sufficiente determinazione e possibilità tecniche.
Se la risposta è "nulla" (come ricordo dall'ultima volta che l'ho studiata), allora anche il ricevente potrebbe fare lo stesso accusando il mittente di averlo fatto.
No perché anche il messaggio consegnato è sono firmato con S/MIME come il messaggio di avvenuta consegna visto sopra. (sempre a meno di cantonate mie)
Poi non so se altri sistemi possano funzionare meglio
TUTTO dipende da quali criteri si utilizzano per giudicare le qualità dei sistemi. Chi ha deciso per PEC, TECNICAMENTE, ha valutato che la "certification by authority" della PKI (Public Key Infrastructure) X.509 usata in S/MIME è meglio del "web of trust" usato in OpenPGP; altri come me (e Giacomo AFAIU) la pensano diversamente. Ora non voglio andare troppo lontano con questo discorso, ma AFAIU è ormai sufficientemente condiviso nella comunità di chi si occupa di sicurezza IT che l'ecosistema PKI ha degli insanabili bachi [1]… architetturali :-O (cioè non "normali" bachi del software a cui FORSE bene o male si può rimediare)
La cosa incredibile è che non lo sapevano nemmeno i tecnici governativi che hanno realizzato o comunque approvato la PEC.
No dai, non la metterei così :-)
Perché sì, esistono molti sistemi più semplici, efficienti e semplici da implementare.
Sì ma *pare* che anche in EU, con eIDAS, non la pensino come me e te: https://www.forumpa.it/pa-digitale/il-futuro-europeo-della-pec-necessarie-nu... Cioè le regole tecniche del Registered Electronic Delivery (RED) non mi paiono (stando a quanto leggo) meno complicate di quelle PEC. Facciamocene una ragione :-D
Non è un caso che ad oggi non esistano implementazioni libere funzionanti della PEC.
Non so se sia funzionante (oggi *pare* un progetto abbandonato) ma esiste http://openpec.sourceforge.net Comunque sia a cosa serve se per poter implementare un server per ricevere o inviare email PEC occorre accreditarsi presso il CNIPA *e* avere un capitale sociale interamente versato di almeno un milione di EUR? [...]
quello che so è quanto questo sistema abbia migliorato enormemente lo svolgimento di una serie di attività che prima passavano da lunghe trafile burocratiche (in primis, le notifiche processuali)
Io non festeggerei la sostituzione di una montagna di scartoffie con fragile castello di carte. ;-)
Beh, per l'utilizzatore finale potersi dimenticare di procedure farragginose e montagne di scartoffie "solo" per poter dimostrare di aver inviato o meno una certa comunicazione è ESTREMAMENTE conveniente, laddove funziona [2]. Diciamo che secondo te e me si potrebbe fare di meglio e meno complicato. Saluti, Giovanni. [1] https://en.wikipedia.org/wiki/X.509#Security [2] tipo NON nei casi in cui gli enti ti chiedono di inviare via PEC una comunicazione *e* di protocollare presso l'ufficio la stampa fisica della ricevuta PEC :-O -- Giovanni Biscuolo