Il 22/10/20 11:53, Giovanni Biscuolo ha scritto:
Ciao Roberto,
Roberto Resoli <roberto@resolutions.it> writes:
Il 21/10/20 19:13, Giovanni Biscuolo ha scritto:
[...]
Scusa se ne approfitto, ma qual'è la ratio che ha portato il legislatore a differenziare tra "firma semplice" e "firma qualificata"? Siccome dal punto di vista tecnico sempre di certificati X.509 si tratta, ho come l'impressione che la distinzione sia puramente burocratico-certificatoria: vorrei tanto essere smentito.
Non direi. E' il grado diverso di forza probatoria, a sua volta dipendente sia dalle tecnologie utilizzate che dal soggetto che attesta l'identità del firmatario.
Non ho capito in cosa sia tecnologicamente inferiore il certificato X.509 della "firma semplice" rispetto a quello della "firma qualificata", ovviamente a parità di soggetto attestante (tutti i sggetti sono approvati dall'autorità pubblica).
In nulla, dal punto di vista tecnologico. Dal punto di vista di chi emette il certificato, invece, si tratta di certificati emessi con scopi diversi, cito dal precedente messaggio:
La differenza tra le due coppie di chiavi è dovuta al fatto che si ritiene inopportuno per evitare attacchi crittografici utilizzare la stessa coppia di chiavi per la firma di documenti (Non Repudiation), e per quantità generate automaticamente (all'interno di un protocollo di comunicazione come TLS, ad esempio) (Digital Signature).
Come conseguenza, le due root CA in cima alla catena dei due certificati sono diverse. E la "Infocert Servizi di Certificazione ...", ad esempio, *non* è tra quelle di firma Qualificata (non è esposta come tale nella TSL italiana).
Però la cosa si sta facendo molto tecnica: mi fido del tuo giudizio se mi dici che differenziare "fa senso".
vedi sopra.
La normativa in merito è raccolta principalmente nel regolamento europeo eIDAS[1], entrato in vigore nel 2016.
All'Art.25, comma 2 (scusa il burocratese) si legge:
2. A qualified electronic signature shall have the equivalent legal effect of a handwritten signature.
Ecco appunto: distinzione *puramente* de jure, la distinzione tecnica tra un X.509 "qualificato" e uno "semplice" mi sfugge, CA certificate usato a parte.
La differnza è negli scopi di utilizzo delle chiavi, e si sostanzia nella CA utilizzata per l'emissione.
[...]
Ahimè, non avrei creduto di essere ancora qui a parlarne dopo ben più di 10 anni ...
É da 15 anni che il solo e UNICO problema che ho con l'utilizzo del software libero è quello che mi viene impedito di usare l'hardware (per mezzo dei "driver" proprietari). Ogni volta che voglio usare un dispositivo - dalla scheda video allo scanner - devo faticare come un forsennato per trovare quello che funziona con il kernel Linux mainline e il software user space per dialogare con il dispositivo.
Sono esausto. E io faccio il sistemista da anni, per lavoro.
... sfondi portoni spalancati ... :((
[...]
Come in TLS, insomma.
Sì mi era chiaro grazie.
[...]
Per quanto ne so, nessun fornitore italiano supporta IAS-ECC per i dispositivi di firma, anche perchè nessuno gli l'ha chiesto.
Mavà?!? Sono solo io che noto l'ormai insopportabile e insostenibile leggerezza del Codice dell'Amministrazione Digitale?
La soluzione tecnica c'è, basterebbero tre righe in un DPCM :-O
Eh sì ... ma non ci sono queste righe, e intanto girano milioni di dispositivi non interoperabili.
Dovrebbe essere IAS-ECC la nostra CIE, che però non ha certificati di firma a bordo.
Quindi per poter apporre una "firma qualificata" come desidero io dovrei chiedere asilo politico alla Francia?
:-) Non sono aggiornato. Ma ai miei tempi sarebbe stato meglio Finlandia o Estonia. Ah, tra l'altro attualmente è possibile chiedere la e-residenza in Estonia, ricevendo la relativa carta d'identità: https://e-resident.gov.ee/become-an-e-resident/ Naturalmente dovresti poi convincere chi riceve il tuo documento che la firma fatta con la carta estone è valida (lo è).
dato che da noi è invalsa l'abitudine di annegare chiavi simmetriche 3DES nel binario dell'applicazione per crittare il colloquio tra token e terminale (Secure Messaging).
...e a che pro? Per evitare un attacco MITM tra il token e il terminale?
Esatto, nessuna ironia.
Oh mamma. Se ho capito bene, siccome il solo e unico mezzo de facto per connettere il token al terminale (il mio computer) è l'USB, l'unico vettore di attacco per un MITM (escludendo me ovviamente) è il sistema operativo e per proteggere la comunicazione tra token e computer da possibile malware si usa un canale simil-TLS?
Ho capito bene o mi sfugge qualcosa?
Hai capito bene, ma la normativa astrae dal tipo di canale. Ad esempio ci sono soluzioni che remotizzano l'accesso al dispositivo.
Ironia a parte: tu che ne pensi?
Che dopo 15 anni siamo ancora qui a parlarne.
E saremo qui ancora a parlarne tra 10 anni, magari non proprio dei token per la firma di altro hardware.
Probabilmente sì, anche se credo che nel mondo attuale, invece di permetter l'accesso paritario all'hardware, semplicemente si elimini l'hardware (vedi firma remota), aumentando enormemente il lock-in.
[...]
Tra parentesi ho messo esattamente i due flag dell'attributo KeyUsage che distinguono i due certificati.
Nella normativa tecnica italiana si prescriveva che le chiavi per firma riportassero nel certificato corrispondente l'attributo KeyUsage marcato critico con il solo flag "nonRepudiation". Non so se sia ancora così.
OK, non ne so abbastanza di X.509... uff
Basta che apri un qualsiasi certificato ssl, anche dal browser, e trovi tutto.
[...]
PS: pur aggiungendo la libreria pkcs11 proprietaria corretta sono riuscito a firmare in libo solo con le chiavi di Autenticazione, mentre con quelle di sottoscrizione il programma si blocca.
La butto lì: incompatibilità ABI?!?
Non saprei, devo indagare. Forse Antonio ne sa di più. Proverò a chiedere anche a Giuseppe Castagno che è il guru di LibO.
In bocca al lupo su questa cosa!
Per quanto mi riguarda, installare un driver proprietario o l'intero DIKE proprietario non fa differenza: se sarò costretto farò così, subirò protestando (al vento, perché con chi protesto?!?) come in tante altre cose.
Ti ho scritto in privato su questo, per non appesantire troppo la lista. Di fatto ti basta solo la libreria PKCS11, per il resto puoi usare sw libero. Questo è il massimo che si possa fare, con il token che hai in mano, al momento. Ciao, rob
Saluti, Giovanni.
[1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.0...