Numero di protocollo e firma digitale

Prendendo spunto da un post riguardo la marca temporale, pongo a voi il quesito
“Come vi comportate con il numero di protocollo su un documento firmato digitalmente?”

Come ben sappiamo, il numero di protocollo viene appostto SUCCESSIVAMENTE alla firma dell’atto.
Con la firma digitale questa cosa non è possibile in quanto invaliderebbe il documento stesso (da un punto di vista informatico).
Voi come vi comportate in questo caso? Specialmente lo chiedo sull’aspetto pratico, ovvero come renderlo semplice e fruibile a colleghi e cittadini.

Grazie

ciao @Alessandro_Carloni ,

ti dico la mia esperienza con il MISE, che ha risposto ad un mio quesito con un pdf firmato PADES.
Loro procedono così: chi forma il documento lo firma. Successivamente il documento viene inviato via protocollo. Il protocollo, usando un certificato self-signed, appona al documento un altra firma pades in cui viene riportata praticamente la segnatura di protocollo: numero, AOO, data, entrata/uscita ecc…

E’ un sistema che devo dire quasi mi piace… salta all’occhio il warning del reader pdf che ti dice che una delle due firme non è valide (quella self-signed)… ma così non si intacca la validità della prima firma.

Se vuoi ti mando il documento in questione via mail… forse così si capisce meglio.

La tecnica del sistema di protocollo che aggiunge una signature contenente i dati di segnatura sarebbe un’applicazione perfetta del sigillo elettronico previsto dal regolamento eIDAS. L’uso di un sigillo qualificato eviterebbe anche la warning al momento dell’apertura del documento.
Le informazioni relative alla segnatura dovrebbero essere immodificabili, andrebbero pertanto riportate all’interno di signed attributes, e non solo nella parte grafica della firma PAdES.

Riporto qui una parte di una discussione avuta (anche con @perrcla ) in un differente contesto:
Ci sono tre motivi per i quali, personalmente, preferirei il formato CAdES:

  1. mi consente di protocollare documenti in qualsiasi formato e non solo in PDF
    Gli altri due, che andrebbero meglio approfonditi, sono:
  2. Il signed attribute al quale faccio riferimento è il content-identifier (5.10.2 content-identifier Attribute)
    Purtroppo la specifica PAdES proibisce l’uso di tale attributo.

The content-identifier attribute provides an identifier for the signed content, for use when a reference may be later required to that content; for example, in the content-reference attribute in other signed data sent later.

  1. il formato PDF/A non mi sembra consenta l’inserimento dei campi necessari a inserire numero e data di protocollo

Riporto infine uno stralcio di un parere del Consiglio nazionale del notariato circa un Certificato di destinazione Urbanistica digitale emesso da un nostro cliente che conteneva i dati di protocollazione nel file di segnatura e non all’interno del documento (si legga con attenzione la parte in grassetto):

Venendo al caso di specie, si precisa che la produzione del file “segnatura.xml” consiste soltanto in una frazione della procedura di protocollazione informatica ovverosia in un mero file di processo ad uso interno, del tutto modificabile e non certificato, che, quindi, di per sé, non può assumere rilevanza esterna. Il file xml di segnatura non è pertanto sufficiente a certificare la protocollazione ed il riferimento temporale in esso contenuto. Ne è dimostrazione la circostanza che, nella Circolare AgID n. 60 del 23 gennaio 2013, in tema di formato e definizioni dei tipi di informazioni minime ed accessorie associate ai messaggi scambiati tra le pubbliche amministrazioni, si legge che “La firma digitale apposta sui documenti informatici inclusi nel messaggio protocollato garantisce i requisiti di autenticità, integrità e non ripudio dei singoli documenti. Ulteriori aspetti, quali l’integrità delle parti non firmate – come ad esempio la segnatura – e la riservatezza dell’intero messaggio protocollato richiedono l’adozione di altre soluzioni”.
Ai fini che qui rilevano, occorre evidenziare che qualora il documento venga rilasciato all’esterno - non valendo unicamente ad uso interno nell’ambito della Pubblica Amministrazione – per la verificabilità della sua autenticità ed integrità e, dunque, per l’opponibilità ai terzi, lo stesso deve essere “autoportante” ovverosia completo di tutte le sue componenti essenziali, come il riferimento temporale, con la conseguenza che il numero di protocollo e la data devono essere inclusi nel documento e certificati.

Chi volesse il documento con l’intero parere può scrivermi in privato.

Quindi tutti voi applicate già questa tecnica di aggiungere un certificato self-signed?
A me più la teoria, piacerebbe un riscontro pratico di come procedete.
Grazie!

si magari… il fatto è che la teoria si scontra col software che usiamo tuttii giorni…

Ad ogni modo, noi di solito procediamo in questo modo: inviamo entrambi i file: il pdf originale firmato e il pdf con sopra il timbro di protocollo “virtuale” apposto dal software… che invalida la firma.
Ovviamente nel protocollo conserviamo il file originale senza timbro. Il file col timbro lo generiamo alla bisogna…
Bruttissimo… lo so… ma per ora è così.

La mia azienda non sviluppa software di protocollo, e nella mia storia non ne ho trovato ancora uno perfettamente “a norma”. Ma se riuscite a convincere il vostro fornitore a realizzarlo questa potrebbe essere una soluzione:

Il documento principale e i suoi eventuali allegati sono già stati firmati da tutti quelli che li dovevano firmare. Il protocollo semplicemente aggiunge la propria “firma” (sigillo) al documento inserendo il numero appena staccato come signed attribute

  1. Si dota il sistema di protocollo di un certificato (magari di un sigillo eIDAS?)
  2. Al momento della protocollazione il sistema di protocollo firma il documento principale e tutti gli allegati usando il certificato in questione e inserendo numero e data di protocollo come signed attributes.
    In questo modo non si corrompono le firme già apposte e si generano documenti autoportanti (vedi articolo dead lock)
  3. Qualsiasi software di verifica firme che legga i signed attributes può leggere le informazioni di protocollazione.

Quello del Consiglio nazionale del notariato, mi sembra un parere all’Italiana, ovvero un sovrapporsi di normative poco chiare e che non definiscono in maniera univoca la modalità operative effettive per procedere correttamente alla protocollazione informatica dei documenti digitali, creano ambiguità. Dunque ogni Ente, sentita la propria softwarehouse di riferimento, procede a tentoni, sperando di far bene e poi incappa in una di queste sentenze.
Mi chiedo allora a cosa serva Il registro giornaliero di protocollo e tutte le meticolose istruzioni fornite da AgID per la sua produzione e conservazione, se non ha consentire la verificabilità dell’autenticità ed integrità dei documenti digitali firmati protocollati in un determinato giorno?
Sinceramente penso che l’unica esigenza di avere il numero/data di protocollo presente su un documento digitale firmato, sia collegata solo al fatto di volerlo stampare e quindi gestire su supporto cartaceo piuttosto che digitalmente, ma per questo esistono le copie di cortesia o le minute di accompagnamento.
Infine in linea con il parere del Consiglio nazionale del notariato, permettetemi una provocazione: mi raccomando protocollate anche il registro giornaliero di protocollo e, ancora più importante, inserite all’interno di questo documento digitale anche il numero e data di protocollo, altrimenti non sarà verificabile la sua autenticità ed integrità.
Buona serata

2 Mi Piace

Purtroppo questo è il tipico caso “all’italiana” in cui la normativa non sta al passo con la tecnologia. E di casi come questi ne abbiamo davvero tanti.

Quand’è che il legislatore si deciderà ad abrogare norme assurde, in constrasto o adeguarle a quelle più recenti?

1 Mi Piace

Scusate se disturbo, però a me le cose incuriosiscono e solitamente si impara sempre qualcosa di nuovo, essendo un programmatore ho subito detto … la marca temporale è alla fine una firma digitale e esiste ovviamente il sistema delle firme in catena … e quindi non riesco a capire il problema (l’unico problema che mi verrebbe in mente sarebbe la situazione che si venissero a creare diversi files, quindi ovviamente ogni volta ci sarebbe da firmare ‘tutto il gruppo’ magari creando ogni volta, ad esempio un file .zip) … cmq ti riporto questo url magari fa comodo, sembra smentire le limitazioni di firma e di timbratura ai file PDF/A … e cmq parla di “firme + marche temporali” (2.1.9 Possibilità di associare una marca temporale alla firma) …
spero che ti sia utile:

A me pare che la risposta di Adobe Italia non chiarisca il dubbio se i campi grafici di firma siano o meno compatibili con la specifica ISO 19005-1 (formato PDF/A).

COncordo con le perplessità di @luca.dainese e @Alessandro_Carloni, ma credo che il parere del notariato abbia un senso e non debba essere sottovalutato.

I notai sono preoccupati che un documento (in questo caso un CDU) allegato a un atto sia autoportante, vale a dire che le sue caratteristiche di qualità, sicurezza, integrità ed immodificabilità siano verificabili senza dover consultare altri archivi.

Ora, in un documento dove il numero e la data di protocollo sono inseriti in un file esterno non firmato (segnatura.xml) anziché all’interno del documento stesso la possibilità che questi dati possano essere alterati è concreta.

La necessità di avere data e numero di protocollo firmati (e magari marcati temporalmente) all’interno del documento io credo che sussista. Occorre quindi individuare meccanismi che, nel rispetto della normativa vigente consentano di dare una soluzione al problema.

La soluzione di inserire queste informazioni come SignedAttributes mi pare che garantisca il rispetto del TUDA e la costruzione di un file autoportante.

scusa, non riesco a capire perché continui a parlare di campi grafici (a me fanno venire in mente 'immaginette stile Paint Brush) … io ti parlo da programmatore … la firma digitale (e tutti i derivati che si fondano sulla stessa logica) si basano sul concetto di prendere un mucchio di bytes e calcolare un’impronta che ne attesta l’autenticità … però a vostro aiuto c’è questo …
il .pdf ha una sezione ‘nascosta/fatta ad hoc’ per i metadati_d_informazione_aggiuntiva … è come un sacco messo in spalla ‘a quello che vedi’ (quindi documento_visibile + sacco_d_informazioni_che_non_vedi) dove l’utente ha la possibilità di farcirlo con quello che vuole (ovviamente seguendo lo standard, di salvataggio e incorporazione delle sezioni dei dati che vai ad aggiungere) …

quindi se i tuoi dati ‘grafici’ sono visibili … bhè sono validati dalla firma … se sono invisibili … cmq teoricamente se ‘i vostri programmi possono’ ci sarebbe da inserirli nella sezione metadati … e ovviamente rifirmare (con marca temporale o nuova firma) il nuovo documento…

ovviamente io non sono un protocollatore informatico, quindi non voglio insegnare niente a nessuno, e magari non ho capito nei dettagli il vostro problema

https://help.adobe.com/it_IT/acrobat/using/WS58a04a822e3e50102bd615109794195ff-7c67.w.html)

Attenzione che credo che qua stiamo un attimo andando da un altra parte.
Mi permetto di ricapitolare.
In primis togliamo il discorso “marca temporale” che qua non è di interesse.
Quale è il problema “vero”?
Diciamo che fino ad oggi, il documento - per normativa - deve essere protocollato, ovvero deve essere applicata la segnatura di protocollo, solamente DOPO che viene apposta la firma del responsabile/dirigente.
Ora, se col cartaceo il problema si risolveva apponendo a penna il numero successivamente alla firma autografa, col digitale sorge un problema : se il documento viene modificato dopo che la firma digitale è apposta, lo stesso non è più valido poichè si invalida la firma.
Quindi la domanda è: siccome la numerazione sul documento viene apposta DOPO la firma, come posso avere un documento digitalmente firmato che sia - come dicono i notai - autoportante, ovvero abbia il numero di protocollo segnato sullo stesso e anche, ovviamente, la firma?

Oltre alla soluzione sopra, mi era stata esposta la possibilità delle versioni di pdf: una caratteristica del pdf che consente di avere una successiva revisione che mantiene al suo interno il documento originale firmato alla quale si aggiunge, nella versione successiva, il numero di protocollo (o altre note).
Tuttavia è molto “scomoda” per l’utente finale perchè acrobat segnala errori sulla firma e non molto intuitiva.

Spero di avere chiarito il problema e dove cerco la soluzione.

Io avrei pensato a una soluzione diversa, ovvero che quando si appone la firma digitale all’interno di un campo si inserisca il numero di protocollo, ad esempio
“Documento firmato digitalmente da Alessandro Carloni con numero di procollo 1234/A”.
in questo modo la protocollazione è contestuale alla firma.
Poi andrebbe da capire come automatizzare il processo…

la possibilità della catene di firme (che sono altro rispetto alla catena di certificati, almeno a livello di logica semantica, poi magari si basano sulla stessa logica di implementazione, ma è un’altra cosa) … allora ‘il sistema di firme multiple dovrebbe permettere appunto questo’ …

le cose sono 2 … o si ha un (Doc_A) … lo si (Firma_X) … quindi si avrà ((Doc_A)+(Firma_X)) … e poi si “rifirma” con (marca_temporale) … teoricamente 'la (Firma_X) non corrisponderebbe più a (((Doc_A)+(Firma_X)) + (Firma_Marca_Temporale)) però appunto, ho visto che c’è la possibilità di firmare più volte un documento quindi sicuramente hanno pensato a riconoscere la situzione di gestire firme multiple … e questo a livello logico dovrebbe essere forse risolto così …

  1. valutare (marca_temporale) per validare ((Doc_A)+(Firma_X))
  2. valutare (Firma_X) per validare (Doc_A)

oltretutto se nel sistema di firme multiple hanno pensato di 'poter aggiornare la Firma_X), sempre che sia possibile, teoricamente sia la (Firma_X) che la (marca_temporale) validerebbero tutto … adesso nei dettagli non so cosa avviene di preciso dovrei andare a cercare informazioni su internet

comunque come dice anche l’url che allego … indipendentemente che ci sia un file firmato o più file … al massimo ‘si crea un nuovo ulteriore file completo’ (magari uno .zip) e lo si rifirma con la marca temporale … quindi addirittura ‘si svincolano le 2 firme rendendole indipendenti’ quindi la (marca_temporale) validerà il file .zip … e il/i file/s firma (contenuti nello .zip, o che siano contenuti nei file a loro volta contenuti nello .zip… quindi più semplicemente che siano ‘detached o nested’) validerà i singoli documenti contenuti nello zip …

(PROCEDURA PER LA DOPPIA FIRMA ELETTRONICA CON CRS DI UN DOCUMENTO)
http://trend.finlombarda.it/c/document_library/get_file?uuid=000de59f-b4d9-4f2f-aab2-7aa9d1f50cf2&groupId=1274640

comunque come ricordavo della catena dei certificati … sono quasi sicuro che esiste il sistema di firme multiple sullo stesso/i documento/i … quindi il problema non si pone o meglio è gestibile

  • la marca temporale è essenzialmente una firma e se è possibile gestire più firme sullo stesso documento il problema teoricamente non c’è

  • il problema sopra proposto di ‘tenere un unico file’ o più files … non è un problema … è solo un modo di gestire correttamente ‘un file unico’ oppure di riconoscere ‘un file + il suo file di riconoscimento’ … ecco quindi la stessa cosa …

Nel tuo ragionamento però manca ancora una cosa: il numero di protocollo, fisicamente, dove è apposto?
Questo manca, che sul documento originale ci siano SIA la firma digitale che il numero di protocollo.

Non riesco a comprendere il punto delle firme multiple, se vuoi ne parliamo in privato prima di andare ulteriormente qua.

ne sarei felice, se non disturbo (r.boffelli@comune.crema.cr.it) …
anche se non è la mia mansione principale, essendo appassionato di programmazione e avendo già smanettato con la questione certificati è una questione che mi interessa e affascina anche a livello matematico …

però, sinceramete ‘se il numero di protocollo’, seguisse la logica delle marche temporali e delle firme digitali in genere, il problema non ci sarebbe e cmq pensavo che fosse così … anche perché se non fosse così, per inferenza, il numero di protocollo non avrebbe valenza legale.

Aggiungo ulteriori requisiti che mi paiono importanti:

  • Il documento sarà sempre più frequentemente un documento digitale non necessariamente costituito da un file PDF

  • È opportuno che sia garantita l’immodificabilità non solamente del documento, ma anche delle informazioni di protocollazione

  • Le informazioni di protocollazione devono essere apposte sia al documento principale che a tutti i suoi allegati

La soluzione che propongo mi pare abbia il pregio di risolvere anche questi due ulteriori requisiti.

  1. Il documento viene predisposto e sottoscritto prima della protocollazione.
  2. Il sistema di protocollo, dotato di un certificato di firma o (meglio ancora) di un sigillo aggiunge la propria firma CAdES al documento principale e a tutti i suoi allegati inserendo data e numero di protocollo come signed attribute. Il signed attribute più adatto è il content-identifier, dalla descrizione che ne fa la specifica ETSI sembra pensato apposta per accogliere le informazioni di protocollazione:

The minimal content-identifier attribute should contain a concatenation of user-specific identification information (such as a user name or public keying material identification information), a GeneralizedTime string, and a random number.

I vantaggi che vedo nell’uso di questo metodo sono numerosi:

  • assoluto rispetto dell’ articolo 53 del Testo unico della documentazione amministrativa
  • i documenti così protocollati non generano errori o warning al momento del controllo delle firme
  • qualsiasi software di controllo firme in grado di leggere i signed attributes consente la visualizzazione dei dati di protocollo
  • possono essere protocollati documenti informatici in qualsiasi formato
  • una opportuna formattazione del content identifier consente il trattamento automatico dei documenti tramite un semplice parsing della stringa
  • le informazioni di protocollazione non possono essere alterate successivamente
  • il documento è autoportante
  • le informazioni di protocollazione possono essere apposte anche agli allegati

Mi inserisco, con un po’ di contributi pratici. Come ha già osservato qualcuno l’esigenza di visualizzare il numero di protocollo (la segnatura) sul documento stesso tradisce la concezione del documento informatico come qualcosa di irrimediabilmente destinato a essere stampato.
Le soluzioni di rendere visibili i dati di segnatura appagano le richieste dei detrattori o malfidati del digitale ma non spostano di molto la questione. Come già detto poi sono applicabili solo su PDF (o immagini) ma non su altri tipi di file. Su un file XML (una fattura elettronica per esempio) dove lo applichiamo? E anche su un PDF - tornando a essere tremendamente pratici - siamo sicuri che ci sia sempre posto? Chi ha mai segnato un documento cartaceo sa che alle volte non c’è posto nemmeno per il timbro.

Tornando al generale, quale “autoportanza” è possibile per un documento digitale una volta che esce dal sistema documentale che lo ha prodotto? La stessa firma digitale, realizzata come volete, dopo 3 (6?) anni scade, va quindi verificata a una certa data, la data di registrazione di protocollo appunto (metodo primo di valutazione temporale in ambito pubblico): ma se gli stessi dati di segnatura sono affidati a una firma come posso ritenerli validi? Del resto col digitale mi pare che ci stiamo facendo ossessionare dal fatto che un documento deve dare prova sempre e comunque di essere autentico in ogni momento a chiunque lo ha fra le mani. ma quando mai un documento ha avuto questa proprietà?

Bisogna comunque capire che il documento, in ambiente digitale (ma non solo) non è solo la parte che ci interessa ma tutto, compreso ciò che riguarda la sua trasmissione: non abbiamo l’abitudine, per esempio, di conservare le buste delle raccomandate?

Dipende poi a che livello si voglia questa “autoportanza”. Mediamente un’amministrazione invia i documenti digitali per mail o pec. Il protocollo che uso io, che non è perfetto, per esempio invia i documenti “protocollati” come allegato di una mail/pec, nel corpo della quale riporta il numero di protocollo (“Invio prot. n. …”). In allegato va il file segnatura.xml. Ecco, se il file segnatura.xml contenesse, come mi pare la norma imponga, l’elenco di tutti i file inseriti nella registrazione con la loro impronta, una volta considerato come documento l’intero invio (corpo mail, segnatura.xml, file vari) si ottiene un buon livello di “autoportanza”, che di certo non ha niente da invidiare alla tradizionale “autoportanza” cartacea. Un numero di protocollo scritto a mano non può essere facilmente manomesso? La stessa segnatura di protocollo, inanalogico, non è posta solo sulla prima pagina del documento principale?

L’immodificabilità complessiva, e soprattutto la capacità di dimostrarla, è a mio avviso una chimera irraggiungibile che sottrae energie ad altro: tradizionalmente il documento è al sicuro, si presume autentico, fin tanto che resta nell’archivio di chi lo ha prodotto (quindi anche in quello di chi, dotato di un sistema di gestione documentale - non per forza informatico - affidabile, lo abbia ricevuto). Quando il documento esce dal sistema archivio la sua autenticità è tradizionalmente a rischio. Io credo che si possa convivere con questa presunta imperfezione.

1 Mi Piace

Tutti belli spunti, ma io credo che il problema sia molto più “banale”.
Spesso nelle lettere si trova “con riferimento al Vs. protocollo n…”
Che questo funziona se abbiamo super mega gestionali di protocollo e documentale, ma pensa al povero pirla che ha un piccolo ufficio e deve rispondere a una PEC di una PA. e si è solo salvato il documento .p7m

Quindi io credo che la semplicità di avere un numero di protocollo sullo stesso sia una semplificazione del procedimento digitale amministrativo.

Ti pongo l’esempio di come (credo) lavori il ns software di protocollo “PiTre”.

Quando allego il documento digitalmente firmato al protocollo, lui ne crea una copia priva di firma e ci applica una nota pdf in alto con i riferimenti di protocollo. Nel sistema convivono così il documento p7m e il documento pdf (senza firma) con numero di protocollo.

Ovviamente questo internamente funziona… ma verso l’esterno c’è unicamente l’xml allegato con i riferimenti di protocollo che sono, come ipotizzavo prima, di complicanza estrema per il povero cittadino.

1 Mi Piace

Ci e Alessandro.
In pratica noi facciamo protocollare il documento apponendo la segnatura contestuale alla firma. Ovvero il documento in pdf A viene firmato da chi lo protocolla subito dopo la sua formazione, all’interno della scheda del protocollo. Contestuale alla firma il sistema chiude e salva la scheda è rende il tutto non più modificabili i file da parte degli operatori diversi dal responsabile del protocollo. Il sistema permette di spedire il link alla scheda e al documento all’interno del ente e di inviare copia dello stesso via email al destinatario. Chi compie le operazioni di estrazione della copia è certificato dal sistema come dipendente autorizzato a fare copie conformi all’originale.