Topic: Allegati firmati digitalmente .P7M

[klades]

sisi è installata
ho trovato questo
@mozilla.org/mimecth;1?type=application/pkcs7-mime,{20dabda1-f8b5-11d2-8ee0-00a024a7d144}

Uhmmm... ok, allora in teoria dovrebbe funzionare... puoi provare gentilmente con un nuovo profilo?
Magari appena posso, faccio una prova con la versione debian, che dovrebbe avere la stessa struttura.

[Cri]

Ho provato...niente da fare

[guia78]

Cosa hai migliorato nella versione 0.2.1??

[klades]

Cosa hai migliorato nella versione 0.2.1??

Pochissime cose:
- compatibilità con le versioni di TB di debian e ubuntu (che hanno un'organizzazione dei file diversa)
- qualche commento in più nel codice

Penso che a questo punto non ci sia più nulla di modificare e che questa sia la versione definitiva (facendo gli scongiuri).

[Belgarat]

Salve ragazzi, in ritardo ho letto oggi tutta la discussione, di fretta e furia ho provato l'estensione su una Kubuntu e su una Debian e mi sembra funzioni tutto correttamente.

Ringrazio tutti dell'impegno e soprattutto Klades, questa estensione mi consentirà di non essere colto in contropiede nelle PA quando mi sottoporranno il problema, anzi, comunicherò già a tutti la notizia.

Ritengo sia importante per l'ambienta PA che certi problemi, come in questo caso, non siano sottovalutati se si vuole realmente mostrare che esiste qualcosa di libero e di altrettanto funzionale. Troppe volte mi sono dovuto fermare nell'introduzione di un software Open solo perchè purtroppo si scontrava con una realtà proprietaria dove non si poteva in alcun modo trovare un varco.

Questa discussione dimostra, che dove c'è un rapporto di Comunity all'interno di un progetto le soluzioni si possono trovare in tempi brevi anche senza l'aiuto di chi tira le fila più ampie del progetto, cosa che in altri ambiti closed non è possibile.

Grazie per questo lavoro e per il risultato ottenuto.

[guia78]

Ritengo sia importante per l'ambienta PA che certi problemi, come in questo caso, non siano sottovalutati se si vuole realmente mostrare che esiste qualcosa di libero e di altrettanto funzionale. Troppe volte mi sono dovuto fermare nell'introduzione di un software Open solo perchè purtroppo si scontrava con una realtà proprietaria dove non si poteva in alcun modo trovare un varco.

Finalmente un discorso serio che non sia demagogico. Io che lavoro in una PA ho sempre cercato di far comprendere alla parte politica l'importanza dell'OPEN SOURCE non per la gratuità delle cose ma perchè ad ogni problema c'è sempre una soluzione.

Fai pure pubblicità anche al Forum Mozilla che ha permesso di far collaborare più persone per la risoluzione di questo problema. Speriamo che verrà utilizzato ancora anche per problemi non solo italiani!

[xeal]

Salve a tutti! Ero rimasto un po' indietro in questa discussione, ma vedo con piacere che siete giunti a una soluzione valida 

Mi era venuta voglia di buttar giù due righe di codice e fare qualche esperimento con le estensioni (anche solo per curiosità personale), ma per vari motivi ho rimandato.

Ad ogni modo, sono contento che siate giunti ad un buon punto con l'estensione che modifica la gestione dei p7m; torno ad "intromettermi" con un piccolo suggerimento che spero possa servire nel caso in cui doveste tornare alla "penultima" soluzione (con la modifica dell'eseguibile):
credo che si possa risolvere il problema delle reti con i client che operano aggiornamenti automatici in modo abbastanza semplice (per quanto l'intero meccanismo, effettivamente, è poco ortodosso, quindi l'enstensione è il tampone migliore in attesa dei un aggiornamento efficace del programma).

Mi pare di aver capito che abbiate realizzato un'utility che consente di modificare automaticamente l'eseguibile senza dover effettuare l'operazione a mano, giusto?

Bene: per risolvere il problema degli aggiornamenti potrebbe bastare modificare il collegamento/simlink usato per avviare il programma (eventualmente le chiavi di registro/file di configurazione) in modo che richiami non l'eseguibile di tunderbird, ma lo script di modifica.

Tale script dovrebbe ogni volta cercare la stringa "incriminata", modificarla, salvare il programma e infine avviarlo (una versione più "evoluta" potrebbe salvare da qualche parte la data dell'ultima modifica effettuata su tunderbird via script e confrontarla con la data di ultima modifica dell'eseguibile:

se sono diverse si procede con l'operazione, altrimenti si avvia semplicemente il programma; in entrambi i casi si richiede che l'applicazione venga ogni volta riavviata per rendere effettive le modifiche, quindi servirebbe la "collaborazione" di chi usa la postazione nel caso in cui un qualche aggiornamento consentisse di continuare a lavorare senza chiudere e riaprire tunderbird - l'opzione "più tardi" andrebbe sempre scartata).

Temo, comunque, che in entrambi i casi (estensione - modifica eseguibile) si comprometta inevitabilmente la gestione interna degli allegati criptati/compressi, ma questo lo sappiamo già e a questo stadio sembrerebbe il problema minore, però si potrebbero avere dei problemi nel caso in cui sia necessario inviare e/o ricevere messaggi criptati attraverso tb, con o senza la presenza di allegati firmati digitalmente.

Mi sono fatto l'idea che il problema consista nella diversa interpretazione di cosa sia un file .p7m effettuata da una parte da tb, dall'altra dal CNIPA: quest'ultimo definisce .p7m l'estensione da dare a un file smime da trasmettere con firma digitale, il quale può, successivamente alla firma, essere criptato assumendo un'altra estensione (p7e se non vado errato).

Per TB, invece, credo che .p7m sia l'estensione di un file criptato con o senza firma digitale, anzi, credo sia l'intero messaggio di posta, visto che, abilitando la cifratura del messaggio si ottiene una struttura mime con un allegato, il quale corrisponde proprio al messaggio criptato, mentre apponendo la sola firma si ottiene un messaggio in chiaro con aggiunto, come allegato p7s, il certificato di firma.

Ho fatto alcune prove, e ho verificato che inviando un messaggio come firmato e cifrato, per mezzo della gestione interna di tb, si crea un p7m, il quale può poi essere recuperato - ho usato una web mail proprio per prendere l'allegato - e rispedito come allegato di un messaggio in chiaro e guarda un po', tb lo leggeva tranquillamente.

Sospetto quindi che tb cerchi, da sè, di interpretare un p7m come un file cifrato e, non riuscendoci, generi un errore che impedisce di vedere sia l'allegato firmato, sia i successivi, eventualmente presenti in chiaro e senza firma.

Da cui i problemi possibili nel gestire posta criptata una volta applicato il workaround (che si tratti di un'estensione ad hoc oppure di una modifica "brutale" alle stringhe interne dell'eseguibile poco importa).

Ma c'è anche un'altro possibile problema: francamente non so quale delle due interpretazioni sia corretta, nel senso di più aderente allo standard smime (che non conosco abbastanza, però ho notato che openssl consente di dare a un file l'estensione che si preferisce, quindi può anche darsi che lo standard preveda semplicemente l'interpretazione diretta del contenuto del file e sia tb "in torto", ammesso e non concesso che io abbia ragione);
ma se gli sviluppatori di TB dovessero considerare la loro interpretazione come la più corretta, o la più usata a livello internazionale, potrebbero anche decidere di non modificare un bel nulla...


Del resto, pare che la normativa italiana in tema di firma digitale/elettronica abbia fatto anche un po' di confusione con le direttive europee, ma in ogni caso dubito che qualcuno vada a modificare un programma solo per supportare un'implementazione specifica usata solo in Italia...

Forse si può fare qualche prova per verificare la validità della mia ipotesi: se qualcuno è disposto a seguire la mia follia, dovrebbe firmare un file normalmente con dike, quindi cifrarlo (con dike, che però credo non operi a livello crittografico nella versione base, oppure con openssl, su cui si appoggia anche dike, ma che va usato da linea di comando facendo attenzione a non sbagliare i parametri, quindi potrebbe essere necessario fare più di un test per verificare opzioni diverse) mantenendo l'estensione p7m e autospedirselo, per aprirlo con una versione "pulita" (cioè senza alcun workaround) di TB: se lo vede normalmente, e riconosce la firma e il contenuto (si può verificare impostando il lettore di smartcard come dispositivo di sicurezza al posto di quello software interno), e non crea problemi con altri allegati (ove prima li creava: bisognerebbe testare gli stessi, cioè prendere un file p7m già prodotto con dike, del quale si sa che non viene visto da tb, cifrarlo con dike/openssl, mantenendo l'estensione finale p7m, quindi spedirlo come allegato di prova insieme ad un pdf o un doc che già prima avete verificato essere illegibile insieme a quel p7m), allora la frittata è completa...

Regards


edit by miki64: ho reso il post più leggibile, prima era troppo "monolitico"... 

[guia78]

Cavolo hai fatto un post molto corposo.. potrei offrirmi io per il test riepilogo cosa dovrei fare?
1) creare una mail cifrata e spedirmela in TB senza plug-in per vedere se funziona?
2) creare una mail cifrata con allegato p7m e vedere se funziona
3) provare la cosa con il plug in?

Io comunque non uso dike che è il software per Infocamere la okFirmaGold di poste italiane. Vedrò questo lunedì cosa succede. Penso pure io che TB non verrà mai modificato solo per un problema Italiano. Certo che questo vorrebbe dire anche in parte che siamo tenuti poco in considerazione! Si avevo capito pure io che l'Italia aveva fatto casini con l'interpretazione della normativa europea sulla firma digitale e pec, infatti è stata richiamata a riguardo in questo periodo dall'Unione Europea per problemi anche collegati (non mi dilungo).

[klades]

@xeal: il tuo post è piuttosto complesso e ammetto che certe cose - per mie mancanze - mi sfuggono, però attenzione a una cosa importante, da tenere presente in ogni esperimento: Thunderbird non regola mai i suoi comportamenti in base all'estensione dell'allegato, ma bensì unicamente in base al suo content-type dichiarato nel messaggio.

Quindi se tu crei un messaggio con un allegato con estensione .p7m con un content-type di tipo "application/octet-stream", lo vedi tranquillamente con TB.

Il problema sorge quando l'allegato ha il content-type "application/pkcs7-mime" (di solito associato ai file p7m). Anche se l'allegato fosse - per assurdo - un semplice file di testo, ma con questo content-type, sarebbe uguale.

Quindi è possibile, nel tuo esperimento, che riinviando il messaggio dalla webmail, l'allegato semplicemente avesse un content-type diverso.

Per completezza di informazione, aggiungo solo che il content-type application/pkcs7-mime sembra indicare proprio un allegato con firma "incorporata" (rfc2311).
Il mio sospetto è che TB riesca a decodificare questi allegati solo se nel messaggio c'è anche la firma come entità autonoma (file p7s, o meglio application/pkcs7-signature), ma quando questa manca - non riuscendovi - li nasconde. Comportamento che onestamente non mi sembra regolare, perché questi messaggi sono conformi alla rfc2311.

E' ovviamente possibile - come ho già detto varie volte - che non ci sia un bug di TB al riguardo, però questo lo può confermare solo il team di sviluppo.

Preciso che l'estensione non dovrebbe causare gravi danni, dato che di fatto disabilita l'interpretazione automatica da parte di TB e quindi al limite l'unica controindicazione è che si deve sempre usare un programma esterno per decodificare e verificare gli allegati p7m (ammesso e non concesso che esistano casi in cui TB sia in grado di farlo da solo).
Tra l'altro tutto ciò avviene solo in fase di visualizzazione del messaggio, quindi a livello di invio non credo ci sia alcun problema di nessun genere.

[xeal]

Devo fare qualche precisazione e un mea culpa, perchè ho fatto queste prove qualche settimana fa e non ricordavo alcuni dettagli che ho notato andando a ripescare i messaggi... però, in parte, credo che il risultato sia valido, almeno come stimolo per approfondire con qualche test. Il punto è che il mio allegato di prova conteneva del testo (in realtà, dell'html - avevo messo del corsivo) ed era inserito con disposition inline; però, se non sbaglio, all'inizio della nostra "telenovela" (scusate, ma un po' d'ironia a quest'ora è il minimo per mantenere lucidità :p) avevate fatto delle verifiche con degli allegati p7m contenenti solo testo (a parte la firma), e se non sbaglio gli allegati di testo vengono trattati da tb come inline (o no?  ).

Parto dall'inizio: avevo installato openssl per generare dei certificati da usare con due miei indirizzi email, quindi avevo creato due profili in tb (senza plugin) impostando il dispositivo di sicurezza software e inserendo i certificati (e abilitandoli manualmente all'occorrenza, perchè mi si è presentato anche il bug relativo cui si era accennato nelle scorse puntate); devo aggiungere, per completezza, che in almeno uno dei profili ho caricato entrambi i certificati, con le rispettive coppie di chiavi. A questo punto, tra i vari tentativi per capire un po' la situazione ho notato che abilitando la firma E la cifratura di un messaggio email si ottiene un messaggio non multipart (cosa che non mi piace troppo, ma è un altro discorso, e si finisce per tirare in ballo un altro bug, anche questo accennato in precedenza), con il "corpo" vuoto e un allegato (unica presenza dopo gli header iniziali) di tipo "application/x-pkcs7-mime" e con nome file "smime.p7m". Questo mi ha fatto pensare a qualcosa che avevo letto sul sito di infocamere (o era l'help di dike? boh, non lo so più neanch'io ) riguardo alle prescrizioni del CNIPA sull'apposizione di firma digitale in un file che avrebbe cambiato il nome in <nome_originario>.<estensione_originaria>.p7m (e chiaramente sarebbe diventato un file smime multipart con il file iniziale inserito nella prima sezione, seguito dalla signature). Ed ecco che mi si accende la lampadina: non sia mai che per la PA italiana un pkcs7 rappresenta sempre e solo un file con firma mentre per tb è sempre e solo un file firmato e cifrato? Forse non c'entra niente, però ho voluto fare la prova: ho aperto il messaggio attraverso la webmail (non riuscendo a leggere niente, perchè non supportava smime), ho scaricato in locale l'allegato smime.p7m, e l'ho inviato, attraverso tb (mi viene il dubbio di aver usato la webmail, ma cambia poco o niente), come allegato in un messaggio in chiaro: risultato, ottengo un messaggio multipart con il corpo del messaggio (plain text) seguito dall'allegato, inserito inline, con nome "smime.p7m" e myme-type application/pkcs7-mime (content-disposition: inline e transfer-encoding: base64), illegibile da webmail, ma leggibilissimo da tb! E questo ha fatto crescere i miei sospetti in merito.

Naturalmente potrei essere completamente fuori strada, ma potrebbe anche darsi che, in presenza di un allegato p7m (da inviare) TB pensi che si tratti di un file criptato, e non possedendo (o credendo di non possedere) la chiave privata necessaria a decifrarlo non lo interpreti e si limiti a spedirlo come pkcs7-mime, fidandosi sul contenuto: questo si potrebbe verificare prendendo un qualsiasi file (anche di testo), aggiungendo l'estensione p7m (o modificando quella originaria), e spedendolo, per vedere se il mime type diventa automaticamente application/pkcs7-mime anche senza la presenza di firma nè di crittografia. Veniamo al ricevimento: se davvero tb considerasse come cifrato qualsiasi allegato con mime type facente riferimento al protocollo pkcs7, allora potrebbe incorrere in un problema al momento della decodifica e saltarlo (l'errore potrebbe compromettere anche la corretta interpretazione degli altri allegati, anche se non ho ben capito se il problema si presenta sempre, o in maniera aleatoria, o con alcuni tipi di file in particolare).

E' anche possibile che TB interpreti correttamente i file .p7m e determini il mime-type prima di spedirli (nel qual caso avrebbe dovuto decifrare e poi validare il mio file di prova; in ogni caso credo di aver verificato che per tb un pkcs7-mime è anche un file cifrato, quindi IMHO vale la pena di verificare che non sia sempre e solo un file cifrato), e, come suggerisce klades, il problema sorga per l'assenza di una signature a se stante, all'interno del messaggio ed esterna al p7m (ma allora perchè è riuscito a leggere il mio allegato cifrato e con firma incorporata? oltretutto, sarebbe un'implementazione, credo, molto irregolare, visto che la/e sezione/i pkcs7-signature a livello del messaggio - e non incorporate in un allegato - dovrebbero riferirsi all'intero messaggio, non ad una sua parte, o sbaglio?).

~~~~~~~

Veniamo ai test, visto che guia78 si è offerto come cavia ( ). Intanto, vediamo di intenderci su alcuni punti: mi aspetto che il programma di firma digitale si appoggi ad un lettore di smartcard che all'occorrenza possa essere utilizzato come dispositivo di sicurezza da TB per il supporto interno a smime, o comunque le chiavi siano disponibili sia per il programma esterno sia per TB (inserendole nel "dispositivo di sicurezza software" interno - avendo cura di verifacare, subito dopo, che i certificati siano abilitati, con un segno di spunta, per tutti gli usi - se non erro la procedura è spiegata nelle faq di TB). Forse sarebbe il caso di ripetere le prove su più di un sistema operativo (più che altro per cercare possibili differenze nell'apertura e analisi, se effettuata, del file in locale prima di spedirlo con il giusto mime type - io ho fatto qualche test solo su win). Ma passiamo alle prove che mi sono venute in mente:

1) Profilo pulito (no plugin), nessun certificato utilizzabile da tb (ma è indifferente)

Prendi un file di testo (o di altro tipo, oppure fai più di una prova con file diversi), cambia l'estensione in .p7m (oppure aggiungila alla fine, o fai entrambe le prove ), e spediscilo con tb come allegato a una mail che contiene qualche fesseria tanto per aggiungere del testo, quindi accedi alla casella di posta con tb, apri il messaggio (non dovresti vedere l'allegato) e accedi al sorgente (ctrl + u): se l'allegato è definito come application/pkcs7, allora vuol dire che l'invio si basa sull'estensione del file e non sul contenuto (del resto, potrebbe anche essere un file cifrato che tb non può leggere).


2) Profilo pulito, nessun certificato accessibile a tb

Prendi un file p7m "regolare" già usato in prove precedenti, quindi contenente la firma, cifralo e spediscilo con tb, come allegato ad un messaggio che contiene del testo, possibilmente allegando anche un file (non firmato) che nelle prove precedenti risultava non leggibile, quindi verifica il comportamento di tb in ricezione del messaggio (se ho ragione, non dovresti vedere nulla perchè non hai le chiavi per decifrarlo); controlla (e magari posta) l'header della sezione relativa (in particolare, content-type e disposition).


3) Profilo pulito, certificati accessibili

Come prima, però crea un p7m che contenga solo testo e vedi che succede (posta di nuovo gli header); aggiungi anche l'allegato non firmato.


4) Profilo pulito, certificati accessibili

Come prima, però crea (o riusa) un p7m non di testo (che so, firma un pdf o un doc), sarebbe meglio usare un p7m (non di testo) che abbia dato problemi con un allegato non firmato, da accodare, per verificare il comportamento in questo caso (e riposta gli header degli allegati )


5) Profilo con plug-in, certificati accessibili

Nessun allegato, solo un messaggio di testo firmato e cifrato (o solo cifrato,  o, meglio, entrambi i casi separatamente) per verificare "sul campo" che l'estensione di klades intervenga solo sulla lettura dei messaggi e non, anche, nella loro creazione, laddove serva il supporto nativo a smime (probabilmente non darà problemi, dato che un messaggio cifrato viene prodotto da tb come un application/x-pkcs7-mime, che è il vecchio mime-type per i p7m, e probabilmente vengono gestiti diversamente, ma un test male non fa e non dimenticare gli header ).

Bye

[klades]

Un paio di informazioni più sugli argomenti trattati da xael:

1) quando alleghi un file, per determinare il content-type, TB si affida a quanto gli dice il sistema operativo. Se a livello di sistema operativo, l'estensione p7m è associata a pkcs7-mime, metterà questo, se non c'è nessuna associazione viene usato il generico octet-stream

2) una cosa importante: al momento l'estensione disabilita la gestione nativa di TB solo per il content-type application/pkcs7-mime e lascia inalterata quella per il content-type application/x-pkcs7-mime. Pensavo onestamente che fosse superata, ma quello che dici sui messaggi prodotti da TB nel tuo caso (forse nel tuo sistema operativo l'estensione p7m è associata al vecchio x-pkcs7-mime) mi fa venire il dubbio e quindi penso che aggiungerò anche questo type...
Per essere chiari: al momento p7mHandler fa vedere gli allegati p7m con content-type application/pkcs7-mime, ma non rivela quelli con content-type application/x-pkcs7-mime.

[guia78]

Io non ho capito molto del discorso ma mi sembra che le prove che dici sono state fatte tutte tranne che con una mail firmata digitalmente con allegato p7m. Questo dovrebbe essere l'unico caso non fatto. Provo domani a vi faccio sapere...

[xeal]

Stando all'rfc2311, .p7m è l'estensione tipica di un file il cui contenuto risponde al protocollo PKCS #7 (per massimizzare la compatibilità, il nome del file dovrebbe essere nel formato 8+3 caratteri, preferibilmente smime.p7m, ma non è un requisito mandatorio, quindi un file "miodocumento.pdf.p7m" o "documentocriptato.doc.p7e", come prodotti secondo i dettami del CNIPA sono regolari); .p7c dovrebbe essere l'estensione "base" per i pkcs7 cosiddetti "degeneri", cioè contenenti solo dei certificati da scambiare. Un allegato generico "application/octet-stream" con nome "qualcosa.p7m" andrebbe trattato, di default, come rispondente allo standard smime per il protocollo pkcs7. Un agent che supporti smime dovrebbe cercare di interpretare il file come meglio può, aiutandosi anche con l'estensione (ma per il content-type application/pkcs7-mime può essere qualsiasi cosa) oppure con il parametro opzionale smime-type (che probabilmente non usa nessuno o quasi). Per compatibilità bisognerebbe supportare (e a quanto pare tb lo fa, problemi a parte) anche i mime type "application/x-pkcs7-mime" e "application/x-pkcs10-mime" (il pkcs10 relativo alla richiesta di certificati, secondo il proprio protocollo).

Nello specifico, il protocollo pkcs7 definisce diversi tipi di contenuto; i principali sono "enveloped" (praticamente, gli allegati cifrati - ma è una visione semplificativa) e "signed-data" (allegati con firma incorporata). Per quanto riguarda la firma, in particolare, si può apporre in due modi: o si crea un messaggio multipart/signed, e quindi la firma vale per tutto il messaggio, oppure si crea un allegato pkcs7 come "involucro" binario (quindi da codificare in base64) per il documento firmato, e all'interno dell'involucro ritroveremo la struttura multipart/signed, con una sezione contenente il documento e una contenete il certificato di firma; ma il documento a cui si riferisce la firma potrebbe essere composto da più parti mime (esattamente come un messaggio di posta con una firma "globale"), e una o più di queste potrebbero essere, a loro volta, delle sezioni pkcs7 contenenti una firma, ovvero sia, dovunque si può "infilare" una struttura multipart (e in un allegato pkcs7 si può) si può anche infilare un pkcs7, quindi essenzialmente un allegato con firma incorporata può contenere al suo interno altri allegati con firma, e così via, creando una qualche struttura nidificata (che sia utile o meno è un'altra storia, però almeno in teoria si può fare). Bene: secondo me (e non solo secondo me, mi pare di capire) TB si ferma solo al livello più esterno di questa struttura, vale a dire sa interpretare un messaggio firmato solo se questo coincide con l'intero messaggio, mentre non sa trattare un allegato pkcs7 come un documento firmato (a meno che non sia cifrato, come nel mio esperimento).

Da un lato, bisogna considerare che l'agent che invia il messaggio dovrebbe consentire all'agent che lo riceve (sostanzialmente, il client di posta) di capire di cosa si tratti senza dover fare i salti mortali (e tb potrebbe non essere il solo a non saper trattare un pkcs7 come documento firmato), e il content-type corretto in questi casi dovrebbe essere "application/pkcs7-mime; smime-type=signed-data; name=nomefile.p7m" (però il parametro smime-type è opzionale e probabilmente non lo usa nessuno o quasi); d'altra parte, un pkcs7 potrebbe essere anche un allegato prodotto esternamente di cui il client non può sapere nulla, a meno di tentare un'interpretazione (che potrebbe essere fuorviante), quindi sarebbe quantomeno auspicabile una forma di graceful degradation consistente nel rendere disponibile l'allegato per il download e la gestione con programmi esterni laddove il tentativo di supportare internamente i protocolli smime fallisse (cosa che altri client sembrano saper fare).

D'altra parte, un pkcs7 può contenere anche dei dati (con ciò intendendo anche del semplice testo) cifrati, e secondo me tb tratta tutti gli allegati pkcs7 (ricevuti) come file cifrati (e forse contenenti solo testo, più eventualmente una firma); se non riesce a decifrarli, vuoi perchè non possiede nessuna chiave privata, vuoi perchè le chiavi di cui dispone non sono valide per quel documento e vengono fuori dati non previsti, si genera un errore che preclude la visione dell'allegato. Posso sbagliare, ma ho la netta sensazione che tb adoperi una sorta di "simmetria" nel trattare i pkcs7 sia in invio, sia in ricezione, e, dato il supporto interno a smime, ciò implicherebbe che tb sappia interpretare correttamente (in ricezione) solo ciò che sà produrre. Perchè penso ciò? In primo luogo, perchè il mio eperimento mi ha dimostrato che tb sa leggere correttamente un pkcs7 cifrato (e firmato) di cui possiede le chiavi di lettura, anche se nel mio precedente esperimento l'allegato cifrato conteneva solo testo, e guardacaso, quando si produce con tb un messaggio cifrato e firmato si ottiene proprio un p7m (ovvero un allegato pkcs7) cifrato, contenente al suo interno il messaggio (semplice teso o html), quindi tb sa produrre un pkcs7 con firma incorporata ma lo fa solo per cifrarlo come un blocco unico, e in ricezione sa leggerlo solo se è cifrato (con chiavi che conosce). In secondo luogo, un altro bug noto relativo ai pkcs7 denota un comportamento analogo: quando si produce con tb un messaggio cifrato e firmato, si ottiene un x-pkcs7-mime, che viene allegato al messaggio come sua unica parte (non all'interno di un multipart/mixed di "contorno"), contrariamente a quanto fanno altri client, e quando riceve messaggi cifrati prodotti da questi client non riesce ad interpretarli correttamente (nella fattispecie, non li presenta come file cifrati e non mostra il certificato) proprio perchè non si aspetta di trovarli inseriti in un mime di tipo multipart (in altri termini, è come se si aspettasse di ricevere sempre un messaggio del tutto analogo a quello che produrrebbe in circostanze simili).

Il quadro si complica ulteriormente considerando i risultati di alcuni test che ho appena fatto. Innanzi tutto, ho rinominato un pdf prima in .pdf.p7m, poi in .p7m, notando che per il sistema operativo sono di tipo "MIME PKCS #7", mentre inviandoli come allegati tramite tb ottengo in entrambi i casi un "application/octet-stream", e in entrambi i casi riconosce il file come pdf (quindi si comporta come se ignorasse sia l'estensione, sia il tipo suggerito dal sistema operativo). Ho provato anche a ripetere l'esperimento di prima, solo che stavolta non ho inviato del testo, ma un allegato pdf con firma e cifratura dell'intero messaggio, ho recuperato l'allegato (smime.p7m) da webmail, e l'ho rispedito tramite tb, ottenendo un allegato di tipo octet-stream (nome invariato) che tb vede e presenta come allegato, ma non apre/interpreta, pur possedendo le firme (quindi non ne vedo il contentuto), e in questo non si attiene in maniera propria allo standard, poichè, come dicevo all'inizio, un octet-stream il cui nome abbia suffisso .p7m dovrebbe essere riconosciuto come pkcs7 e trattato come tale, ma potrebbe essere anche una conseguenza del bug cui accennavo.

Credo che l'estensione di klades, disattivando tutti i formati pkcs7 renderà impossibile leggere messaggi interamente cifrati (con o senza firma) direttamente da tb, ma questo dovrebbe essere il male minore, vuoi perchè è uno scenario presumibilmente poco probabile nel contesto delle PA (visto che la cifratura delle comunicazioni non è richiesta espressamente, al contrario della firma digitale), vuoi perchè, comunque, non sarebbe per nulla chiara, per l'utente, la natura di un messaggio proveniente da altri client (e credo che nessuno qui voglia rinunciare all'interoperabilità), anche se riuscirebbe a leggerlo (avendo le chiavi per farlo). Mi scuso per la lunghezza del post, ma l'argomento è piuttosto complesso, e senza mettere mano al codice (cosa che non mi sogno neanche di fare), si possono solo fare delle congetture basandosi su una specie di reverse engineering mirata a partire dall'uso reale.

[xeal]

Devo rettificare una parte del discorso: ho ripetuto anche il vecchio test, con l'allegato smime contenente solo il testo e la firma (prodotto con tb), e stavolta ho ottenuto un octet-stream visibile da tb ma come allegato generico (ma sempre con nome smime.p7m). Mi sono reso conto di aver effettuato la prova in precedenza con dike installato, e gli ultimi test senza dike: può darsi che la presenza di un programma associato al tipo di file ne rafforzi in qualche modo le "caratteristiche" (almeno su windows - mi secca ripetere tutti i test su opensuse, visto che ho cominciato su win continuo qui, oltretutto, le pa usano comunque o dike o un altro software equivalente, quindi, da questo punto di vista, si trovano nella stessa situazione su qualsiasi os) e ne "forzi" il riconoscimento da parte di TB, mentre in assenza di una associazione per così dire forte il client proceda in qualche modo all'analisi del file per verificarne il contenuto, senza tener conto in alcun modo della sua estensione (e non sempre ciò è correttissimo).

Domani ripeto gli ultimi test con dike installato, per avere conferma della visibilità di un pkcs7 cifrato (e firmato all'interno) in presenza di contenuto binario e non solo testo, come in precedenza. Tuttavia, il risultato precedente con il messaggio di testo firmato e cifrato mantiene valide le premesse sulla trattabilità degli application/pkcs7-mime da parte di tb se sono cifrati oltre che firmati, contrariamente ai soli smime firmati, quindi ritengo valida l'idea di fare delle prove con un smime firmato secondo le procedure della PA (cosa che io non posso fare, perchè non conosco le opzioni interne di dike, quindi usando openssl "di testa mia" non otterrei un risultato più valido di quello che ottengo con tb, e non possiedo una smartcard accessibile da dike) e successivamente cifrato, verificando se viene riconosciuto da thunderbird sia con la possibilità di accedere alla smartcard, sia senza cognizione alcuna sulle chiavi; proverò qualcosa di simile anch'io domani, con un altro profilo, sempre senza plugin, solo che non posso replicare esattamente quanto prodotto dai programmi "ufficiali", quindi non posso fugare il dubbio che l'allegato pkcs7 risulta leggibile, o almeno visibile, non solo perchè cifrato, ma perchè al suo interno presenta la stessa struttura di un pkcs7 firmato e cifrato che tb sa leggere (in quanto prodotto proprio da tb).

Ad ogni modo, l'esperimento (fallito a metà) con gli smime riconosciuti come octet-stream mi ha dato da riflettere... il pdf con estensione p7m è stato riconosciuto correttamente (a seguito di decodifica), mentre i pkcs7 cifrati no, ma comunque risultavano visibili... quindi anzichè disabilitàre del tutto il supporto al pkcs7 (in tutte le sue salse) si potrebbe fare in modo di far riconoscere e trattare un pkcs7 come un generico octet-stream: l'esperimento con gli allegati cifrati mostra un comportamento analogo a quanto ottenuto con l'estensione che disabilità il supporto a smime, mentre la prova con il pdf con estensione cambiata suggerisce la possibilità di leggerne il contenuto, non sia mai che trattando un p7m contenente un documento firmato come un generico octet-stream si riesca ad aggirare il problema e rendere non solo il p7m, ma il suo contenuto visibile attraverso tb...

[guia78]

Quindi come si dovrebbe procedere?