Proviamo a descrivere le caratteristiche operative che consentiranno la realizzazione pratica dei SERC (servizio elettronico di recapito certificato) a livello comunitario. Passaggi importanti per cogliere meglio il futuro della Pec, dopo Eidas, in Italia e in Europa, anche in ottica di convergenza su domicilio digitale. La Pec ad oggi è l’unico strumento a norma di legge nazionale per eleggere il proprio domicilio digitale. mancano la norma operativa per attivare i Sercq (Serc qualificati).
Gli standard per i Serc
Come è noto, il Regolamento europeo 910/2014 noto anche come eIDAS, abbia introdotto il servizio elettronico di recapito certificato come un “servizio che consente la trasmissione di dati fra terzi per via elettronica e fornisce prove relative al trattamento dei dati trasmessi, fra cui prove dell’avvenuto invio e dell’avvenuta ricezione dei dati, e protegge i dati trasmessi dal rischio di perdita, furto danni o di modifiche non autorizzate”.
Tra le attività di standardizzazione che si svolgono in ambito ETSI, è giunto alla conclusione il procedimento di redazione ed emissione degli specifici standard.
In particolare, sono stati pubblicati gli standard per i servizi elettronici di recapito certificato (SERC) sia di natura postale che di natura web services.
Ne abbiamo già scritto in questo articolo e in relazione alle evoluzioni della Pec.
In particolare, gli standard sui SERC definiscono gli aspetti operativi per le architetture basate sui web services, una serie di standard sono dedicati alla posta elettronica “registrata” ovvero alla raccomandata elettronica, che è un particolare SERC e nel seguito è referenziata con l’acronimo REM (Registered Electronic Mail).
Nello specifico, questi standard ai quali fare riferimento sono:
- ETSI EN 319 522-1 Electronic Registered Delivery Services; Part 1: Framework and architecture.
- ETSI EN 319 532-1 Registered Electronic Mail (REM) Services. Part 1: Framework and architecture.
La coesistenza tra Pec e Sercdi Andrea Sassetti, responsabile dei Servizi di Certificazione di Aruba E’ possibile arrivare alla coesistenza di servizi quali la PEC – Posta Elettronica Certificata – e il SERCQ – Servizio di Recapito Certificato Qualificato, che come sappiamo, hanno implicazioni importanti sia dal punto di vista tecnico, che strategico ed economico. Sono diversi gli scenari futuri ai quali potremmo assistere:
In definitiva, esistono una serie di scenari. La migliore strategia potrebbe essere quella di far coesistere i due servizi PEC e SERCQ (standard REM), monitorare i casi di utilizzo e i processi che ne scaturiscono, per poi valutare in funzione della loro reale diffusione se far confluire i due servizi oppure lasciarli separati, per una gestione più specifica e complessa quando servono garanzie e identificazioni di livello più approfondito, e un processo più semplificato nei casi in cui la casella PEC è sufficiente a soddisfare le specifiche esigenze di chi la utilizza. . |
Analisi del documento 522-1
Un servizio elettronico di recapito certificato (SERC) è – ai sensi del regolamento eIDAS – un servizio che consente la trasmissione di dati in modalità elettronica tra un mittente e un destinatario e fornisce prove relative al trattamento dei dati trasmessi, fra cui prove dell’avvenuto invio e dell’avvenuta ricezione dei dati, e protegge i dati trasmessi dal rischio di perdita, furto, danni o di modifiche non autorizzate.
Un SERC è fornito da un prestatore. I prestatori cooperano quando il servizio è offerto da prestatori differenti.
Questo prestatore può essere un prestatore di servizi fiduciari (Trust Service Provider) ai sensi del regolamento europeo 910/2014 (eIDAS) e volontariamente può scegliere di ottenere la qualificazione.
Questo standard preso in esame, introduce un preciso modello logico descrittivo, sintetizzato qui di seguito.
Un SERC fornisce prove sugli eventi accaduti durante il trasferimento di dati tra le parti (ad esempio prova che i dati sono stati effettivamente consegnati al destinatario); il tutto in modo analogo ai tradizionali servizi postali fisici per documenti cartacei, come “posta raccomandata” con la “ricevuta di ritorno”.
Questa prova può essere utilizzata per dimostrare a terzi, se necessario anche in procedimenti legali, che la transazione è avvenuta nel momento e tra le parti come indicato nelle prove (le ricevute). I requisiti legali per un SERC e le prove che deve supportare possono variare nei diversi contesti realizzativi.
In un SERC una prova è un attestato, fornito dal medesimo, del fatto che un evento specifico relativo al processo di trasferimento di alcuni dati specifici tra il mittente e il destinatario (ad esempio, la presentazione di un messaggio, la consegna di un messaggio, il rifiuto di un messaggio) è successo in un certo momento. Una prova di questo scenario può essere immediatamente consegnata al mittente / destinatario o può essere conservata in un repository per un successivo accesso da parte degli interessati. È prassi comune implementare le prove del SERC come dati firmati elettronicamente al fine di garantire la provenienza e l’integrità degli stessi.
La consegna sicura e affidabile a un destinatario richiede che il destinatario sia identificato in modo univoco. Lo standard quindi affronta il tema dell’identificazione univoca del mittente (che è un requisito, ad esempio, per far valere la responsabilità legale), anche se in alcuni casi la sua identità non viene (non deve essere) rivelata al destinatario.
L’identificazione univoca può essere ottenuta mediante un identificatore univoco o da una serie di attributi che insieme identificano univocamente l’utente. Lo standard in esame supporta le regole per la consegna mediante il SERC tra mittenti e destinatari che sono persone fisiche o giuridiche; tuttavia, in linea di massima qualsiasi entità identificata in modo univoco (sistema, servizio, funzione, ecc.), che può essere indirizzata attraverso un SERC, può essere un mittente o un destinatario.
Questo standard in esame affronta anche la delega, ovvero la capacità di un mittente o di un destinatario di delegare un’entità diversa ad agire per suo conto.
Un SERC può usufruire di parti esterne e fidate per l’autenticazione.
I principi del SERC sin qui descritti possono essere realizzati in diversi modi, utilizzando diversi formati per gli identificatori e le prove utili per i processi all’interno del SERC, utilizzando diversi protocolli per la messaggistica e persino diversi modelli di consegna dei messaggi.
Lo standard propone modelli astratti generali. Infatti lo standard vuole fornire un modello generale che includa tutte le caratteristiche rilevanti, con il vincolo di astrazione dalle tematiche di realizzazione.
Un modello a “scatola nera”
A tal fine lo standard introduce un modello a “scatola nera” sintetizzabile in tre passaggi:
- Un modello a “scatola nera”, che si occupa di un singolo SERC. Le complessità interne del medesimo non sono rilevanti in quanto possono essere viste come un sistema unico sotto la responsabilità di un singolo prestatore. Il modello della scatola nera descrive le interazioni del SERC con il mittente e i destinatari attraverso un livello di applicazione al di fuori del confine del SERC.
- Un modello definito a “4 angoli”, che si occupa dello scambio di dati e prove del SERC tra due SERC: uno sul lato del mittente, l’altro sul lato del destinatario. L’interazione dei SERC con il mittente e il destinatario (interfacce) è la stessa del modello della scatola nera.
- Un modello esteso, che si occupa della trasmissione di dati e prove dei SERC attraverso una catena di SERC.
Lo standard 522-1 poi sviluppa in modo completo le interazioni tra entità e soggetti, gli eventi che devono essere trattati per garantire le funzionalità previste e i modelli funzionali dei protocolli da realizzare.
La REM
I temi di dettaglio per i metadati e le materie XML per i web services sono trattati nei documenti 522-2 e 522-3. Si tratta di documenti con contenuti di profilo specialistico, aventi lo scopo di realizzare il modello funzionale e architetturale descritto nel 522-1.
Tutto quanto detto sino ad ora è ripreso nello standard ETSI EN 319 532-1 che ha lo scopo di definire le specifiche regole infrastrutturali e architetturali per un SERC di tipo postale (la REM).
Il servizio di posta elettronica registrato (REM) è un tipo specifico di SERC, che si basa su formati, protocolli e meccanismi utilizzati nella normale messaggistica di posta elettronica.
L’accesso al sistema REM viene generalmente effettuato da uno “user agent” (ad esempio un’applicazione che interagisce direttamente con un utente), che può essere un software client di posta elettronica ordinario o un software REM personalizzato, o da un’applicazione generica (cioè un sistema automatico), che può essere, a titolo esemplificativo, un sistema di gestione dei documenti, un sistema di contabilità, ecc.
In ogni caso, il software client può usare i protocolli di posta elettronica standard (ad esempio SMTP e POP / IMAP) e protocolli web (ad esempio HTTP) per accedere al servizio REM.
In generale è possibile l’uso di altri protocolli (per esempio l’instant messaging) ma lo standard non affronta, per scelta, questa tematica.
Come richiesto per tutti i SERC, il mittente e i destinatari hanno ciascuno un identificatore univoco, con il quale sono indicati nel sistema REM i messaggi e le prove del SERC.
Per la REM l’identificativo univoco degli utenti è ovviamente un indirizzo di posta elettronica.
Ai fini della trasmissione dei messaggi devono essere forniti dal mittente al sistema REM una serie di metadati, (ad es. indirizzo del destinatario, tipologia di operazione richiesta, opzioni di consegna. Questi metadati sono convogliati nell’intestazione del messaggio di posta elettronica.
Come nel caso del gruppo di standard 522, la serie 532 specifica nei documenti 532-2, 532-3 e 532-4 la semantica del sistema e dei messaggi, i formati dei messaggi dei protocolli di interscambio e i profili di interoperabilità indispensabili per le corrette funzionalità del sistema.
Le due modalità di funzionamento della REM
Per concludere questa sintesi sulla standardizzazione della REM è indispensabile sottolineare come siano previste due modalità di funzionamento: la store and forward (S&F) e la store and notify (S&N).
Nello scambio tra due gestori REM operanti in S&F lo scambio avviene nel modo che tutti conosciamo e che è alla base della PEC: il messaggio originale, incluso in un nuovo messaggio creato appositamente dal gestore del mittente (proprio come si fa con la PEC), è inviato al gestore del destinatario e poi depositato nella casella del destinatario stesso.
Nello scambio tra due gestori REM in modalità S&N il messaggio che viene inoltrato è di notifica al destinatario. Il messaggio è conservato dal gestore REM del mittente che invia al destinatario un messaggio di notifica che contiene la URL dove è possibile copiare il messaggio del mittente. Il messaggio di notifica è inviato ovviamente con la tecnica dello S&F.
E’ possibile lo scambio di messaggi utente con modalità miste (Es. S&F – S&N).
Concludendo questa nostra analisi ricordiamo al lettore di leggere questo articolo con a mente quanto scritto negli altri due articoli referenziati all’inizio.
In particolare di rileggere le possibili evoluzioni della PEC verso i SERC di tipo REM per gestire al meglio l’equivalenza giuridica (ex CAD) tra la PEC e i SERC qualificati e la circostanza che la PEC oggi è l’unico strumento a norma di Legge nazionale per eleggere il proprio domicilio digitale.
Articolo parte di un progetto di comunicazione sviluppato tra Agendadigitale.eu e Aruba, su norme e utilizzi della Pec, presenti e futuri
