{"id":69,"date":"1998-09-10T07:55:51","date_gmt":"1998-09-10T06:55:51","guid":{"rendered":"http:\/\/www.alcei.org\/index.php\/archives\/69"},"modified":"2005-08-23T07:57:47","modified_gmt":"2005-08-23T06:57:47","slug":"69","status":"publish","type":"post","link":"https:\/\/www.alcei.it\/?p=69","title":{"rendered":"Documento del 10 settembre 1998"},"content":{"rendered":"

Osservazioni sulle Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici ai sensi dell’articolo 3, comma 1, del Decreto del Presidente della Repubblica, 10 novembre 1997, n. 513.<\/strong><\/p>\n

In risposta all’invito pubblico formulato dall’Autorit\u00e0\u00a0 per l’Informatica nella Pubblica Amministrazione per l’invio di contributi sulla bozza di regolamento tecnico di cui al DPR 513\/97, ALCEI ha realizzato una schematica analisi di alcuni fra gli aspetti giuridici che vengono in maggiore evidenza. In linea generale, la regolamentazione proposta – pur apprezzabile quanto all’evidente sforzo di osservare il massimo rigore tecnico – risulta appesantita da eccessiva burocraticit\u00e0\u00a0 che nell’applicazione concreta limiterebbe fortemente l’applicazione concreta.<\/p>\n

Perplessit\u00e0\u00a0 sorgono, inoltre, relativamente all’inserimento fra norme di natura tecnica, anche di previsioni giuridiche non perfettamente collegate con il DPR 513\/97. Ferma restando dunque una valutazione in linea di massima positiva del documento analizzato, non ci si pu\u00f2 esimere dalle considerazioni che seguono:<\/p>\n

Art.I.1.
\nLettere (d) ed (e)<\/p>\n

da un punto di vista giuridico risulta essere non perfettamente coerente utilizzare una definizione come”\u00a6praticamente impossibile”\u00a6.. Il concetto di “applicazione in pratica” dovrebbe essere lasciato all’eventuale interpretazione del giudicante, e non inserito in un testo avente valore di legge, anche se non di rango primario. A stretto rigore, infatti, per un testo legislativo una cosa o \u00e8 possibile oppure non lo \u00e8: alternative non ve ne sono.<\/p>\n

Art.I.3
\nn.1: la generazione dell’impronta deve essere effettuata “\u00a6..etc.;
\nn.2 : …possono essere utilizzate”\u00a6<\/p>\n

Anche in questo caso, si pone un quesito: la possibile utilizzazione di algoritmi diversi da quelli specificati al punto 1, deve essere necessariamente subordinata alla compatibilit\u00e0\u00a0 con sistemi preesistenti, oppure introduce un criterio generale di possibile utilizzo di algoritmi diversi? Le conseguenze potrebbero essere molto differenti fra loro.<\/p>\n

Art.I.4,
\ncomma 2: eliminazione della distinzione delle chiavi;<\/p>\n

Il documento sottoscritto con la chiave privata (quindi quella di sottoscrizione) deve contenere al proprio interno necessariamente anche l’indicazione dell’ora di utilizzazione della chiave, pena la non certezza giuridica del documento stesso.<\/p>\n

Art.I.4,
\ncomma 4: E’ responsabilit\u00e0\u00a0 del certificatore”\u00a6..:<\/p>\n

La norma abbisognerebbe di una profonda revisione. Quale \u00e8 il tipo di responsabilit\u00e0\u00a0 alla quale va incontro il certificatore ? Le conseguenze dell’eventuale omissione sono di carattere civile oppure anche penali ? E, nel campo della responsabilit\u00e0\u00a0 civile, quale graduazione di “diligenza” deve essere applicata ?<\/p>\n

Art.I.5:,
\ncomma 1: “\u00a6che offrano le pi\u00f9 elevate garanzie possibili”\u00a6.;<\/p>\n

Anche in questo caso, quale \u00e8 il parametro di riferimento ? L’art. 15 della Legge 675\/96 almeno statuisce espressamente che le misure di s icurezza devono essere “allo stato dell’arte”, ma in questo caso non ne esiste alcuno. In ordine alla responsabilit\u00e0\u00a0 si pongono quindi problemi analoghi a quelli di cui al punto precedente.<\/p>\n

Art.I.5:, comma 3, (b):<\/p>\n

Come e chi deve effettuare la verifica ? In generale, in tutta la bozza dovrebbe essere inserito il condizionale laddove si parla di controllo. L’uso del condizionale implicherebbe infatti la mera possibilit\u00e0\u00a0 giuridica del controllo, che per\u00f2 non necessariamente dovrebbe essere attuato, allegerendo fortemente l’impatto applicativo della norma. L’uso, al contrario, dell’imperativo porterebbe ad interpretare la norma nel senso che sia sempre e comunque necessaria l’effettuazione del controllo per poter “essere in regola”. Un esempio concreto pu\u00f2 essere la sostituzione delle parole deve essere verificata con le parole deve essere verificabile al comma 4 dell’articolo in questione.<\/p>\n

Pi\u00f9 in generale, si ritiene auspicabile l’eliminazione – o quantomeno lo snellimento – della normativa concernente la gener azion e delle chiavi di certificazione, in quantodi scarsa utilit\u00e0\u00a0. In effetti, la sottoscrizione mediante procedimento digitale serve per sostituire alla firma autografa quella digitale. Il creare un sotto – sistema per certificare la firma che poi sar\u00e0\u00a0 quella con la quale l’utente potr\u00e0\u00a0 sottoscrivere gli atti aventi valore giuridico, ex<\/p>\n

artt. 2 e 10 del DPR 513\/97<\/p>\n

appare un inutile appesantimento del sistema.
\nLo stesso art. 1 del DPR 513\/97 definisce, alla lettera (h), la certificazione come “il risultato di un procedimento”; trattasi quindi – per parlare in termini amministrativi – di un sub procedimento al quale non \u00e8 necessario dare rilevanza autonoma, se non nei limiti fissati dalla norma.
\nCi\u00f2 che conta ai fini del DPR 513\/97, \u00e8 che si possa giungere ad una corrispondenza biunivoca tra soggetto fisico reale e sottoscrizione informatica.
\nTrasponendo la questione in termini non informatici \u00e8 come se si volesse accertare la veridicit\u00e0\u00a0 della sottoscrizione autografa proprio al fine di poter poi certificare la stessa sottoscrizione.
\nIn realt\u00e0\u00a0 si tratta di una distorsione della necessit\u00e0\u00a0 di avere esatta cognizione delle generalit\u00e0\u00a0 del soggetto che richiede l’attribuzione di una chiave; \u00e8 del tutto evidente che, nella fase di prima applicazione del sistema, il riconoscimento del soggetto non possa operare che in modo diretto e – comunque – non informatico, mancando appunto i presupposti relativi alla pos sibilit\u00e0\u00a0 di attribuire valore giuridico a documenti informatici.<\/p>\n

Comunque, tale necessit\u00e0\u00a0 non dovrebbe essere eliminata neanche nel prosieguo, ponendosi il problema soltanto a livello del certificatore, che naturalmente dovr\u00e0\u00a0 avere una distribuzione sul territorio la pi\u00f9 capillare possibile, onde evitare discriminazioni tra i cittadini. Anzi, potrebbe essere inserita nel regolamento attuativo una norma che imponga ai vari certificatori una diffusione sul territorio quanto meno parificabile a quella dei Comuni.<\/p>\n

Art.II.7: Mutua certificazione<\/p>\n

La certificazione mutua tra i certificatori dovrebbe essere un obbligo e non una facolt\u00e0\u00a0, posto che tali soggetti, nel sistema delineato dalla legge, pur svolgendo attivit\u00e0\u00a0 d’impresa, di fatto vanno a svolgere anche delle funzioni per cos\u00e0\u00ac dire “pubbliche”. Inoltre non vi dovrebbe essere alcun onere aggiuntivo per l’utente finale per ottenere la certificazione una chiave presso un solo certificatore oppure presso altri certificatori con i quali sia avvenuta la “mutua certificazione”.
\nAnche in questo caso, trasponendo la questione in termini non informatici, \u00e8 come se un Comune decidesse di non accettare un documento la cui sottoscrizione \u00e8 stata autenticata dal segretario di altro comune !<\/p>\n

Art.II.10: Anonimato.<\/p>\n

Solleva forti perplessit\u00e0\u00a0 la possibilit\u00e0\u00a0 di avere la certificazione di uno pseudonimo al fine di mantenere l’anonimato; in effetti, nel diritto positivo vigente, accade proprio tutto il contrario: lo pseudonimo pu\u00f2 essere tranquillamente utilizzato in sostituzione del vero nome SOLTANTO qualora abbia raggiunto una notoriet\u00e0\u00a0 tale da non ingenerare incertezze sul soggetto al quale appartiene lo pseudonimo.
\nNel caso in questione, al contrario, si permetterebbe, di fatto, la sottoscrizione di documenti in forma anonima; tra l’altro, l’articolo appare di difficile applicazione pratica, in quanto non sarebbe possibile, per esempio, ricorrere all’anonimato tutte le volte in cui si debba sottoscrivere un contratto.<\/p>\n

Art. II.18:<\/p>\n

Anche in questo caso andiamo incontro ad una eccessiva farraginosit\u00e0\u00a0 del sistema, derivante dall’utilizzo di chiavi con finalit\u00e0\u00a0 ed utilizzi diversi. Sarebbe sufficiente stabilire che la richiesta di revoca debba pervenire con i mezzi “ordinari” e con sottoscrizione autenticata del titolare della chiave revocanda.<\/p>\n

Art. II.18, comma 4:<\/p>\n

Anche in questo caso devono essere effettuate le medesime osservazioni relative all’art.I.4, comma 4: in quale tipo di responsabilit\u00e0\u00a0 incorre il certificatore ?
\nSotto il profilo procedurale manca nel regolamento attuativo ogni specificazione in ordine alle regole necessarie per adire l’autorit\u00e0\u00a0 giudiziaria competente in relazione alle eventuali omissioni e\/o diatribe scaturenti dall’applicazione delle regole tecniche medesime.
\nAnche se in prima istanza appare del tutto probabile il ricorso all’Autorit\u00e0\u00a0 Giudiziaria ordinaria, sia in sede civile che in sede penale, sarebbe quanto mai opportuno che tale circostanza sia chiaramente indicata nel regolamento, o prevedere una sorta di arbitrato a cura dell’AIPA con funzione di giudice primo grado, alternativo all’autorit\u00e0\u00a0 giudiziaria ordinaria.
\nA proposito dei termini previsti nel regolamento manca l’indicazione della loro natura (ordinatoria oppure perentoria). L’interpretazione dovrebbe portare a far propendere per la prima ipotesi, dovendosi in generale ritenere che i termini siano perentori soltanto quando la legge espressamente lo preveda ma, anche in questo caso – e visto anche il tipo di conseguenze possibili dal mancato rispetto degli oneri imposti dal DPR 513\/97 e dal regolamento tecnico – sarebbe quanto mai opportuno che tale circostanza sia specificata, e che i termini siano espressamente previsti come perentori, con conseguenti sanzioni per il mancato rispetto degli stessi.<\/p>\n

Manca del tutto nel regolamento un qualsiasi cenno alle sanzioni (che, naturalmente, ben potrebbero essere comminate “per riferimento”) conseguenti al mancato rispetto di quanto imposto dal regolamento stesso, salvo sporadici riferimenti alla legge 675\/96, troppo esigui per poter correttamente operare nel caso in esame.<\/p>\n

Come ben sa qualsiasi operatore del diritto, una norma senza sanzione \u00e8 una norma monca, perch\u00e9 manca della parte applicativa e per cos\u00e0\u00ac dire “operativa” della stessa.
\nVolendo considerare con maggiore attenzione la questione concernente l’autorit\u00e0\u00a0 giudiziaria competente a conoscere delle questioni inerenti l’applicazione delle “regole tecniche”, non va sottaciuta la necessit\u00e0\u00a0 – non menzionata nella bozza – di una precisa indicazione sia dell’autorit\u00e0\u00a0 competente.<\/p>\n

Una ipotesi pu\u00f2 essere quella di prevedere Roma come unico foro competente stante la complessit\u00e0\u00a0 dei temi trattati, ovvero – in caso di una interpretazione pi\u00f9 vicina agli utenti finali – l’indicazione per legge del foro competente con riguardo alla residenza dell’utente stesso, in piena applicazione analogica degli a rtt. 1469 bis e segg. del codice civile.<\/p>\n

D’altra parte, le indicazioni sopra specificate non sono per nulla in contrapposizione n\u00e8 mutuamente esclusive l’una dell’altra; potrebbero ben coesistere, potendosi applicare la prima nei rapporti diversi da quelli tra certificatore ed utenti, e la seconda nei soli rapporti tra certificatori ed utenti.<\/p>\n","protected":false},"excerpt":{"rendered":"

Osservazioni sulle Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici ai sensi dell’articolo 3, comma 1, del Decreto del Presidente della Repubblica, 10 novembre 1997, n. 513. In risposta all’invito pubblico formulato dall’Autorit\u00e0\u00a0 per l’Informatica nella Pubblica Amministrazione per l’invio di contributi… Continue reading Documento del 10 settembre 1998<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[14,4,12],"tags":[],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.alcei.it\/index.php?rest_route=\/wp\/v2\/posts\/69"}],"collection":[{"href":"https:\/\/www.alcei.it\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alcei.it\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alcei.it\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alcei.it\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=69"}],"version-history":[{"count":0,"href":"https:\/\/www.alcei.it\/index.php?rest_route=\/wp\/v2\/posts\/69\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.alcei.it\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=69"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alcei.it\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=69"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alcei.it\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=69"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}