La bozza del regolamento tecnico: un passo indietro?
di Corrado Giustozzi - 10.09.98

La bozza di articolato approvata dall'AIPA nella seduta del 6 agosto mi sembra costituisca un passo indietro rispetto a quanto l'AIPA stessa aveva fatto in precedenza, e mi riferisco all'ottimo lavoro compiuto nella messa a punto del testo di quello che poi è diventato il DPR 10 novembre 1997 n. 513, il quale ha lucidamente dato validità giuridica al documento informatico ed alla firma digitale.
In particolare la bozza di articolato evidenzia secondo me la classica "sindrome da comitato": un'ansia di generalismo mirante a comprendere quante più caratteristiche possibili, per non farsi forse tacciare di aver dimenticato qualcosa. Manca tuttavia un disegno complessivo, non si percepiscono le linee guida della costruzione sottesa dalle norme, che quindi si perde e sfugge; mentre le norme, spesso inutilmente puntigliose e talora invece sfacciatamente vaghe, rimangono quasi fini a sé stesse in quanto private del substrato finalizzante che dovrebbe amalgamarle e renderle attive.

Fra le obiezioni di carattere generale che si possono muovere alla bozza, la principale mi sembra che essa così com'è non delinei alcuna infrastruttura per la gestione delle chiavi pubbliche (PKI); nel documento invece ci si limita a descrivere cosa deve fare una Certification Authority (CA) senza definire cosa sia in realtà una CA, che ruolo abbia verso gli utenti e quali rapporti formali debbano esistere fra le varie eventuali CA. Ciò sembra prefigurare un modello di PKI monolitico per cui tutte le CA debbano afferire all'AIPA senza ulteriori articolazioni gerarchiche, ossia un modello sostanzialmente "piatto" che in qualche modo contrasta con la filosofia ispiratrice del modello descritto nello standard X.509, cui peraltro la bozza si richiama.
Ad esempio non si configura alcuna differenza fra una CA privata (ossia non una Pubblica Amministrazione) che "informalmente" intenda rilasciare certificati ai propri dipendenti o clienti per consentire loro di usufruire di un servizio (banca, assicurazione, .) ed una che intenda offrire a terzi certificazioni ufficiali con validità generale. Gli ambiti sono ovviamente molto diversi, ma la bozza non li qualifica come sarebbe opportuno.
In quest'ottica mi sembra anche rilevante il disinteresse verso quanto si sta facendo in ambiti europei per giungere a definizioni comuni e all'armonizzazione delle normative. Le esperienze ed i suggerimenti nati dal dibattito fra le varie autorità nazionali sono preziosi ed importanti, ma la bozza non fa alcun riferimento ai documenti omologhi approvati o dibattuti nelle sedi comunitarie, ed alle relative proposte da essi emerse.

Un'altra critica di natura generale riguarda l'esclusione del modello di certificato utilizzato da PGP dal novero degli standard impiegabili. PGP è uno standard di fatto ormai largamente utilizzato in tutto il mondo, e benché si basi su un modello di PKI sostanzialmente opposto a quello previsto dallo standard X.509 in quanto a relazioni fra le CA (in PGP il concetto di CA è totalmente degerarchizzato, dato che ogni utente può svolgere il ruolo di CA verso gli altri utenti), tuttavia il formato dei certificati che implementa è compatibile con quello previsto dall'X.509 e le funzionalità sono le medesime.

La bozza di articolato mi sembra dunque orientata soprattutto alla definizione di una PKI "piatta" e monolitica, e ad un modello di certificato molto "CA-centrico", nel quale la CA oltre a emanare i certificati genera anche le chiavi (privata e pubblica) degli utenti. Un modello essenzialmente simile a quello adottato da VeriSign, che installa chiavi e certificati nei browser degli utenti i quali diventano fruitori passivi e addirittura ignari del servizio. Inoltre la descrizione che l'articolato dà degli apparati materiali ("dispositivo di firma", ecc.) sembra riferita essenzialmente ad oggetti fisici più che a dati astratti e pezzi di software, facendo pensare che i suoi mandati si riferiscano soprattutto ad implementazioni utilizzanti componenti materiali quali smartcard o simili; il che crea ambiguità ed imprecisioni laddove si pensi di implementare sistemi realizzati esclusivamente in software.

Alcuni passaggi della bozza sono straordinariamente puntigliosi, quali quelli che descrivono le reinizializzazioni di sistema e gli azzeramenti delle memorie centrali e di massa dopo ogni generazione di chiavi (e in caso di generazioni di interi lotti di migliaia di chiavi?.). Altri sono estremamente vaghi, come le richieste di conformità degli apparati alle norme di sicurezza ITSEC e TCSEC (in Italia tra l'altro non esistono laboratori autorizzati a rilasciare certificazioni del genere).

* * *

Passando ad un'analisi più puntuale, mi sembra di poter rilevare alcune imprecisioni di natura tecnica o semplicemente pratica in molteplici articoli della bozza. Ecco una breve descrizione dei punti principali.

I.3: Nel punto 1 si dice che la generazione dell'impronta deve essere effettuata mediante uno dei due algoritmi a norma ISO 10118-3, salvo affermare nel punto 2 che la stessa può essere anche effettuata con altri tre algoritmi differenti. Mi sembra una contraddizione, di cui oltretutto mi sfugge il senso pratico.

I.4.1: Non si capisce, e non viene ulteriormente specificato, quali sono gli eventuali servizi diversi o istanze multiple dello stesso servizio per cui non possa essere usata una medesima coppia di chiavi.

II.1.3: Non si vede perché le Pubbliche Amministrazioni sui propri siti Web debbano pubblicare i certificati relativi alle chiavi pubbliche dell'AIPA anziché quelli relativi alle proprie chiavi.

II.7: Stante il modello di PKI sotteso dalla bozza, corrispondente ad una struttura ad un solo livello in cui tutte le CA sono certificate dall'AIPA, non si capisce il senso di prevedere una mutua certificazione tra CA.

I.8.1: Dalle definizioni iniziali non si capisce, e non viene ulteriormente specificato, cosa sia in pratica un dispositivo di firma. Tutto lascia pensare che, oltre all'ovvia smartcard, possa ad esempio essere un browser contenente le chiavi VeriSign e quindi in definitiva un computer. In questo caso però due punti successivi sono problematici: il 3 stabilisce infatti che non è possibile ad esempio avere due copie delle proprie chiavi contemporaneamente sul PC di casa e sul notebook, ed il 5.c stabilisce che l'intero computer che custodisce le chiavi vada distrutto nel caso in cui risulti difettoso.

II.9.1: Non capisco il senso dell'avverbio "almeno". L'identificazione mediante documento di riconoscimento può non essere sufficiente? E in quali casi?

II.10: Mi sfugge completamente il motivo per cui si debba prevedere una norma specifica per il rilascio di un certificato di identità per utenti anonimi ("certificato di anonimità"?) quando l'uso di pseudonimi non è lecito "qualora dalla legge sia richiesta l'identificazione del soggetto" (cioè praticamente sempre).

II.15.1: Il comma c) richiede che il certificatore verifichi che la chiave pubblica di cui si chiede la certificazione non sia già stata utilizzata, ma non si vede come possa il certificatore eseguire la verifica (deve consultare tutti gli elenchi di chiavi pubbliche di tutti i certificatori esistenti?)

II.15.6: Il codice riservato che il certificatore deve consegnare al titolare per validare le richieste di revoca sembra non essere utilizzato. Al punto II.18.4 si dice che la richiesta di revoca va inoltrata con le modalità di cui al punto II.18.2, che fa a sua volta riferimento al sistema di comunicazione sicuro descritto al punto II.12, il quale non fa menzione del codice riservato di cui al punto II.15.6; quest'ultimo viene citato solo nel punto II.22.5 che però si riferisce alla sospensione e non alla revoca.

II.20, 21, 22: Mi sfugge la differenza fra "revoca" e "sospensione" di un certificato. Secondo buon senso la "revoca" sembra essere irreversibile e la "sospensione" reversibile, ma la bozza non dice nulla a riguardo né in termini di pura definizione né in termini operativi.

II.28: Al comma c) si richiede che il sistema che gestisce il registro dei certificati sia conforme alla classe C2 delle specifiche TCSEC, ma al punto II.30.4 si richiede che tale sistema sia accessibile per via telematica (secondo le modalità del punto I.13, che elencano perfino lo specifico protocollo di accesso); questa è una contraddizione, perché la classe C2 fa esplicito riferimento e si applica solo a sistemi "stand-alone", ovvero non connessi in rete.

II.29.6: La richiesta equivale ad inibire a tutto il personale del certificatore l'accesso alla sala macchine, perché è ovvio che la chiave privata del certificatore si troverà di norma in un computer collocato nella sala macchine comune.

II.31.6: La richiesta di disponibilità su base mensile è sensata, ma la norma non indica né chi sia l'ente che deve provvedere a verificare l'effettivo adempimento alla norma da parte del certificatore, né quali siano le misure da prendere verso il certificatore che non adempia all'obbligo di disponibilità.

II.32.3: L'obbligo per il certificatore di rendere pubbliche informazioni critiche e riservate riguardanti le proprie procedure di sicurezza (quali quelle richieste ai punti n, o, p) consente ad eventuali malintenzionati di pianificare nei dettagli il proprio attacco!

III.3: Premesso che non si comprende bene cosa siano in pratica le chiavi di validazione temporale, e perché debbano essere differenti dalle chiavi di certificazione, la richiesta della loro sostituzione con cadenza almeno mensile (punto 2) obbliga ogni utilizzatore del servizio a dotarsi di una propria contabilità per stabilire con quale chiave di validazione temporale sia stata validata una data evidenza informatica! Le chiavi di validazione temporale dovrebbero avere la stessa validità di quelle di certificazione, ossia essere "eterne" fino a revoca esplicita e motivata.

III.8.2: Mi sfugge totalmente il senso della norma.

III.8.4: Vale quanto detto per il punto II.31.6: chi verifica l'effettiva disponibilità e quali sono le sanzioni per chi non adempie alla norma?

III.9: Dato che il servizio di validazione temporale di un'evidenza informatica ha lo scopo di certificare l'evidenza anche sotto il profilo temporale, il servizio di deposito è del tutto superfluo.

V.1: Si apre la pericolosa possibilità che ciascuna Pubblica Amministrazione emetta per proprio conto chiavi non iscritte al registro pubblico per "fornire servizi ai propri utenti" (i cittadini), e che quindi ogni cittadino sia costretto a gestire un "parco" di molteplici chiavi ciascuna delle quali necessaria per il colloquio con la sola PA che l'ha emessa. In questo modo si vanificherebbe ogni sforzo di razionalizzazione e di semplificazione dei rapporti fra cittadini e PA. Idealmente ciascun cittadino dovrebbe disporre di una ed una sola chiave, la quale deve essere universalmente valida per il colloquio con qualsiasi PA.

* * *

Per fortuna è solo una bozza, e si può ragionevolmente sperare che l'Autorità per l'informatica nella pubblica amministrazione si comporti come ha già fatto per il testo che ha dato origine al DPR 513/97: raccolte le osservazioni al primo, discutibile testo pubblicato su Internet, ha poi prodotto un articolato definitivo sul quale resta difficile esprimere critiche sostanziali.