Topic: Allegati firmati digitalmente .P7M

[klades]

@ xeal: potresti mandarmi al mio indirizzo i messaggi con cui stai facendo queste prove, almeno i più significativi? (sempre che senza smartcard serva a qualcosa).

E inoltre: potresti fare tu degli esperimenti installando l'estensione per vedere che succede con i messaggi cifrati? Tieni conto che per eliminarne gli effetti, basta anche disabilitarla.

Comunque mi sembra - "a naso" - che le tue supposizioni possano essere esatte, soprattutto quando ipotizzi che TB non riesca a gestire le mail "miste".

Forse - e sottolineo "forse" - sarebbe possibile con molto sforzo costruire una specie di "plugin" ad hoc, ma purtroppo io non ho minimamente la possibilità di poter fare esperimenti con smartcard, messaggi cifrati e altre diavolerie del genere.

[guia78]

Io avrei la smart card e stà tesserina maledetta ma non sò nemmeno come configurare TB per cifrare i messaggi... Guide?

[xeal]

Scusate il ritardo, ieri ero un po' incasinato.

Dunque, ho installato nuovamente dike, ed effettivamente il mime-type dei p7m visto da tb è cambiato, però non sono riuscito a replicare (in maniera automatica) il test riuscito dell'altra volta...

In pratica, i p7m vengono visti da tb come degli "application/pkcs7" senza il "-mime" finale, e trattati come degli octet-stream (con la differenza che stavolta tb non analizza il file e non riconosce il pdf con estensione cambiata), quindi vengono visti e messi a disposizione per il download. Tuttavia, sono riuscito a simulare l'invio di pkcs7-mime. Premetto che per i test uso 3 email corrispondenti a 3 diversi profili: uno per inviare (con accesso ai certificati, ovviamente) e 2 per ricevere (uno con e l'altro senza certificati).

Inizialmente ho salvato in locale i 3 messaggi di prova (uno con allegato un pdf.p7m, uno con il vecchio smime, cifrato e firmato, contenente il semplice testo formattato "Come da soggetto, vediamo che succede stavolta...", e il terzo con smime, cifrato e firmato, contenente il pdf - con estensione regolare - del primo messaggio) come .eml, quindi li ho editati per correggere il content-type degli allegati e li ho aperti da tb con ciascuno dei profili e ho ottenuto il seguente risultato:

- il pdf con estensione fittizia non risulta presente da nessun profilo, come atteso (è lo stesso comportamento riscontrato nelle vostre prove);

- con il profilo privo di certificati non è possibile vedere nessun allegato;

- con i certificati installati la storia cambia... il testo del primo pkcs7 (vero) risulta inserito correttamente in calce al messaggio (avendo content-disposition: inline), mentre l'allegato pdf contenuto nel secondo viene riconosciuto come pdf e reso disponibile per il download...

Ad ogni modo, non sono riuscito a rilevare la firma incorporata nei messaggi cifrati. Ho effettuato una controprova importando le mail salvate (e corrette) e spedendole alle 2 caselle di prova (entrambe imap), con il seguente esito:

- il comportamento è invariato sia per il pdf.p7m fittizio, sia per il profilo privo di certificati;

- il testo è inserito correttamente in calce al messaggio, visto dal profilo con i certificati;

- il pdf cifrato e firmato, invece no... pur avendo a disposizione la chiave per la decodifica, tb non lo rileva.

A questo punto, ho modificato nuovamente l'header in modo da avere un content-disposition: attachment invece che inline, rispedito, ma niente. Curiosamente, quando tb si collega alla casella imap vede gli allegati (in particolare, il p7m cifrato contenente il pdf), ma non apppena apro il messaggio non solo non viene notificata la presenza di un allegato per il download, ma scompare anche la graffetta dall'elenco delle email: questo mi fa supporre che ci sia una qualche gestione basilare dell'errore (e infatti non viene notificato niente nella console degli errori), che tuttavia, purtroppo, risulta inefficace per i "nostri" scopi (sarebbe opportuno che venissero resi disponibili in ogni caso gli allegati come file generici da scaricare, eventualmente notificando l'errore avvenuto e avvisando di una possibile corruzione dei dati).

L'esito di questi test sembrerebbe confermare tutti i miei sospetti, in particolare che tb considera un pkcs7 sempre e solo come un file cifrato, contenente "preferibilmente" del semplice testo/html, cioè un messaggio, e quindi, in definitiva, applica all'interpretazione dell'email ricevuta algoritmi simmetrici, per così dire, a quelli usati in fase di costruzione di un messaggio da spedire, aspettandosi di ricevere qualcosa che sia il più possibile simile a ciò che produce: crea dei pkcs7 solo per spedire messaggi cifrati e solo se possiede la chiave pubblica del destinatario (applicando una sorta di tolleranza zero, ovvero la prima opzione dell'rfc2311), e riesce a gestire in maniera ottimale i pkcs7 ricevuti solo se sono cifrati e contenenti testo, e solo se possiede la chiave di lettura (altrimenti genera un errore e/o ignora - volutamente? - la presenza del messaggio). Almeno via imap.


@klades

Adesso ti invio le mail che mi hai chiesto, dovresti vederle con la tua estensione, ma non credo che potrai farci molto, visto che due degli allegati sono cifrati, tranne forse verificare se con un altra configurazione/sistema operativo (e relativa versione di tb), e/o con un altro servizio email (magari pop3) si riesce a vedere almeno la presenza di un allegato generico (le mie email, comunque, conterranno l'header corretto application/pkcs7-mime). Farò qualche prova anche con la tua estensione.


@guia78

Tu potresti rendere disponibili i certificati della tua smartcard (operi con una smartcard, giusto?) ad un profilo di tb usato per ricevere, disabilitando l'estensione di klades? In questo modo potresti testare l'eventuale riconoscimento del pkcs7 firmato (e non cifrato) grazie alla presenza dei certificati: se funziona (ma ho qualche dubbio), allora il problema è risolvibile anche senza disabilitare il supporto interno a smime, almeno per gli usi nelle PA, altrimenti l'unica è usare il plugin di klades finchè la gestione interna non sarà riscritta in una futura versione di tb (a mio avviso necessita di profonde modifiche). Quindi dovresti aggiungere un dispositivo di sicurezza in opzioni->avanzate->certificati (però non sò bene come creare un modello pkcs #11 relativo al lettore di smartcard, credo si possa fare con openssl - ti direi di spedirmi un file che ci provo io, ma non possiedo lettori), e spedirti un messaggio con allegato firmato, per vedere che succede; un'altra prova interessante potrebbe consistere nel modificare il content-type in modo tale che rispetti anche i parametri opzionali: "Content-type: application/pkcs7-mime; smime-type: signed-data; name: nome_allegato.qualcosa.p7m"; però, quand'anche funzionasse, sarebbe una magra consolazione, dato che difficilmente un client "normale" spedirà un allegato, per di più prodotto da un'applicazione esterna, come tale.

[xeal]

Io avrei la smart card e stà tesserina maledetta ma non sò nemmeno come configurare TB per cifrare i messaggi... Guide?

Dunque, per usare la smartcard con tb ti serve il modulo pkcs#11, che non devi produrre tu (prima ho scritto una sciocchezza). Dovrebbe essere compreso con il software del reader (o della tesserina se è dato a parte), probabilmente una dll (o un so) che contiene nel nome pkcs11, oppure cryptoki; altrimenti, c'è un helper facente parte del progetto opensc (al momento non riesco a raggiungere il sito in maniera diretta), però come file singolo probabilmente va compilato; sul sito ci sono dei bundle sia per win sia per mac che dovrebbero contenerlo (dovrebbe essere qualcosa del tipo opensc-pkcs11.so). Una volta individuato questo benedetto modulo, apri tb, vai su strumenti-> opzioni -> avanzate -> certificati -> dispositivi di sicurezza, qui credo che si debba selezionare "modulo radice predefinito", quindi premere "carica" e indicare il percorso del modulo; probabilmente chiederà di immettere la password e ti farà accedere alla scheda. A questo punto puoi caricare i certificati che ti servono (stesso percorso fino a certificati -> mostra certificati -> certificati personali -> importa), però forse li userai direttamente dalla smartcard, quindi potrebbe non essere necessario importarli. Devi anche procurarti il certificato con la lista dei certificatori validi e importarlo come autorità (da mostra certificati -> autorità -> importa). Se hai problemi ad usare qualche certificato, dopo averlo importato, vai su autorità, seleziona il certificatore (scegli una voce dell'elenco), premi modifica e quindi selezioni tutte le caselle di spunta (a causa di un bug di tb che si presenta, a volte, quando si importano certificati, il certificatore viene disabilitato). A questo punto sei pronto per firmare i messaggi (non gli allegati, ma l'intero messaggio): nella finestra di composizione vai su Opzioni -> Sicurezza -> apponi firma digitale; per cifrare un messaggio sempre su opzioni - sicurezza -> cifra questo messaggio, però devi avere un certificato per la cifratura (contenente la chiave pubblica, è di tipo pkcs12) del destinatario, legato al suo indirizzo email. Io ho effettuato i miei test producendo dei certificati con openssl, una guida veloce la trovi qui (può essere necessario installare perl ed eseguire ca.pl al posto di ca.sh, aggiustare i nomi di file e cartelle - qualcuno - e dare un'occhiata all'help dei comandi di openssl per estrarre il certificato "pubblico" - con le procedure indicate si crea un certificato x509, quindi un pkcs12, che però contiene sia la chiave pubblica, sia quella privata, ma per far cifrare le proprie email da qualcuno bisogna comunicargli la sola chiave pubbilca, quindi bisogna estrarla e farne un certificato a parte, il quale va importato nei certificati altrui).

[xeal]

Ho installato l'estensione: come ipotizzato, consente di produrre messaggi cifrati, ma ne impedisce l'apertura, così tb presenta un messaggio vuoto con l'allegato p7m disponibile per il download, che andrebbe decifrato e visualizzato all'esterno di tb (quindi salvato come p7m, decifrato con qualche programma - va bene anche openssl, basta saperlo usare, anche se un programma in linea di comando di questo tipo non è per tutti - rinominato in eml o qualsiasi altro suffisso leggibile da un mail client e aprirlo con il programma di posta preferito - a meno che non si voglia spulciare la struttura interna a mano con un editor di testo ). Date le circostanze, mi sembra il male minore, anche se devo dire che, benchè non mi piaccia l'implementazione parziale e problematica del supporto a smime in tb, l'idea che il protocollo di comunicazione tra le PA italiane preveda semplicemente l'apposizione di una firma digitale e non anche la cifratura (non vorrei sbagliare, ma la produzione di un p7e non è obbligatoria, tant'è che la versione base di dike non la prevede affatto), considerando che i dati potrebbero essere sensibili e, circolando in chiaro via smtp, sono facilmente intercettabili, non mi sembra proprio una genialata. E' sicuramente utile per autenticare il mittente, nonchè per dimostrare l'avvenuta comunicazione tra le parti (vantaggio della firma qualificata rispetto a una firma autoprodotta, se vogliamo - ma bisognerà vedere come la metterà il medico, ehm, l'ue, visto che forse l'intero ambaradan non è del tutto ortodosso), ma dal punto di vista della sicurezza non ci siamo. Sarò paranoico io...

[guia78]

Mizzega, proviamo anche questa lunga guida per cifrare un messaggio.
Di solito le PA per il momento usano la Pec (posta certificata - destinatario e mittenti certificati e dichiarati pubblicamente) e la firma digitale sugli allegati. Tutto questo gira in chiaro ma se un file p7m viene alterato durante il tragitto il destinatario aprendolo se ne accorge in quanto l'allegato non è più uguale.
Cifrare un messaggio per intero attualmente non viene fatto anche se penso dovrebbe essere usato nel caso di comunicazioni delicate e riservate. Ma già avere tutti i dipendenti che usano la mail normale sarebbe buono (te lo dico per esperienza!).
Proverò quindi ad inserire i certificati.
Ah per l'invio dei miei certificati al pubblico direi che non è proprio il massimo (non so le conseguenze) ma non penso che si debbano sperperare per la rete ---> devo capire ancora bene a che mi servono e poi vedrò.

[xeal]

Eh, ma non devi mica distribuire il certificato intero! Sarebbe come pubblicare l'annuncio "cercasi ladro per custodire villa"

In buona sostanza, un certificato x509 contiene due token (chiave pubblica e chiave privata) legati alle tue credenziali personali (ad esempio, la tua email) e un certificato di firma dell'autorità certificatrice (in breve, CA) che li ha emessi, per avallare le tue credenziali (è un po' come il timbro e la firma su una carta d'identità). Una CA può essere qualsiasi entità, una società privata, un'ente pubblico o anche tu stesso, e infatti un qualsiasi software per la gestione di ssl (come openssl) ti consente di creare una CA (fondamentalmente, delle cartelle contenenti dei certificati usati per firmare altri certificati) ed emettere le tue credenziali. Quando la CA è un ente ben definito e riconosciuto, in Italia ci siamo "inventati" il concetto di firma qualificata (per certi versi è utile, per altri è un po' in contrasto con la prassi di mercato - si tratta degli stessi certificati usati per i siti https, che non necessitano di una firma riconosciuta dallo Stato - e, forse, anche con la normativa europea - questo si chiarirà, prima o poi...).

La cosa da capire è il funzionamento dei due token: sono chiavi per la crittografia asimmetrica (detta anche a chiave pubblica, o a doppia chiave), e sono calcolate matematicamente in modo tale che se cifri un documento con una (non importa quale) puoi decifrarlo solo ed esclusivamente con l'altra, e conoscendone una non è possibile calcolare anche l'altra se non con un elaboratore potentissimo e impiegando tantissimi anni (con il progredire della tecnologia - es: arrivano processori più veloci - si aumenta il numero di bit delle chiavi, e si ristabilisce il livello di difficoltà). Se conosci PGP (o anche GPG), il principio è praticamente lo stesso, solo che c'è in più il "timbro" della CA (in particolare, di una CA "ufficiale"). L'idea di base è che tu estragga, dal certificato "completo", una specie di "sottocertificato" contenente la chiave pubblica e il "timbro", e che lo distribuisca alle persone con cui mantieni una corrispondenza via email (ma anche se lo spargi in giro per tutta internet non fai danni, l'importante e che tu mantieni per te la chiave privata - credo che il cnipa voglia che si tenga sempre dentro la "tesserina"; io personalmente preferisco l'idea di poterne fare un backup, sono sempre contrario ai dispositivi di sicurezza con dati inaccessibili). Quando qualcuno vorrà inviarti un messaggio cifrato, gli basterà usare la tua chiave pubblica per crittarlo, così saprà che solo tu potrai leggerlo (usando la chiave privata); se tu vorrai rispondergli con un altro messaggio cifrato, userai la sua chiave pubblica, così lui potrà leggerlo con la sua chiave privata. Il "timbro" della CA serve a dimostrare che la chiave pubblica è proprio la tua e non è stata sostituita da qualcuno che vuole intercettare le vostre comunicazioni (il cosiddetto attacco del man-in-the-middle).

La firma funziona in maniera analoga: usi la tua chiave privata (non quella pubblica, stavolta) per cifrare un pezzettino del messaggio (tipicamente, il valore hash di tutto il resto), così chiunque possiede la tua chiave pubblica (e il "timbro" della CA) può verificare che il messaggio è stato creato da te e non è stato alterato (se non sbaglio, il pkcs7 prevede la presenza, insieme alla firma, anche della chiave pubblica e del certificato di firma della CA, così e possibile scambiarsi documenti firmati in maniera veloce senza doversi prima scambiare i certificati pubblici - e preoccuparsi di ricordare chi possiede il certificato pubblico e chi no).

Non devi, però, confondere il meccanismo delle due chiavi con la presenza, nella tua "schedina maledetta", di due certificati diversi: ciascuno contiene la propria coppia di chiavi, però hanno funzioni diverse. Un certificato, infatti, serve per la firma digitale su documenti digitali con validità legale (ha la stessa validità legale di una firma "a mano" su un documento cartaceo), mentre l'altro è per la firma elettronica, che serve ad autenticarsi ma non è valido sui documenti! E' come se tu usassi uno pseudonimo per firmare, in maniera informale, un foglio di presenze: ufficiosamente, per convenzione, la firma è accettata, perchè comunque ad un esame calligrafico risulta tua (uscendo fuor di metafora, anche il certificato per la firma elettronica contiene le tue credenziali ed è avallato da una CA ufficialmente riconosciuta), però la stessa firma non sarebbe valida su un documento legale, perchè, per quei fini, sarebbe comunque un falso (cioè, se sbagli a usare il certificato di firma su un documento digitale, lo rendi nullo!). Questa è la parte più grossa del "pasticcio nostrano" sulla dematerializzazione dei documenti: per la fretta di essere i primi ad implementare la normativa europea, abbiamo scelto una strada complicata e non proprio aderente alle norme comunitarie, creando di fatto un protocollo "pericoloso" se adottato in massa (immagina quanti errori salterebbero fuori se tutti usassimo documenti digitali con firme digitali...), e buono solo a far vendere (e rinnovare alla scadenza) due certificati invece che uno solo.............

[guia78]

Sinceramente non ho letto tutto il post ma penso di aver capito il concetto. La questione delle doppie chiavi pubblica e privata sulla carta l'avevo studiata....
Il problema ti spiego qual'è:
io ho un certificato mio privato arrivato via e-mail poi ho la smart card con dentro i certificati per la firma. Con il software okgold! tramite un codice di accesso firmo gli allegati e vonde.
Per estrarre questo certificato della CA e quello pubblico come posso fare? OkGold (non lo conosco bene anche se ha 2 cavolate) non penso permetta di leggere la smart card e tirarci fuori qualcosa...
Devo mettermi con calma e fare ste cose. Purtroppo questa settimana sono full..

[klades]

@ xeal: solo ora sono libero da alcuni impegni e prometto che mi studierò bene tutto l'esito delle prove che gentilmente (e con competenza) hai fatto.
Vorrei chiederti un altro favore: potresti mandarmi la mail cifrata di cui hai parlato qui?

Ho installato l'estensione: come ipotizzato, consente di produrre messaggi cifrati, ma ne impedisce l'apertura, così tb presenta un messaggio vuoto con l'allegato p7m disponibile per il download, che andrebbe decifrato e visualizzato all'esterno di tb

Voglio vedere se si trova il modo di far distinguere a TB un messggio completamente cifrato da un allegato pkcs7-mime non cifrato (non credo, ma tentar...); mi piacerebbe quindi vedere che struttura ha un simile messaggio.

[guia78]

Io devo ancora capire come estrarre il certificato dalla smart card.
Ma per i test non si può usare i certificati rilasciati da Thawte come descritto in questa guida:
Mi sembra utile

[xeal]

I certificati thawte dovrebbero essere del tutto identici a quelli prodotti da openssl che ho usato nei miei test, quindi dovrebbero produrre risultati analoghi (cambieranno le informazioni interne, ma si tratta pur sempre di certificati x.509 racchiusi in un file pkcs#12, con estensione .p12 - l'unico tipo che TB consente di importare). Il problema casomai è che, non essendo scritti su una smartcard, non sono utilizzabili per produrre un p7m firmato, ma solo per cifrare un file già esistente (oppure cifrare/firmare interi messaggi direttamente attraverso tb).

@guia78

Qui ho trovato una guida su come utilizzare le applicazioni di postecom per creare un archivio di backup dei certificati, ma non sono sicuro che estraggano anche la chiave privata, nè che siano nel formato previsto dal pkcs#12. Se riesci a far vedere la card a tb, allora tutto diventa più semplice: basta importare i certificati tra i certificati personali, quindi farne un backup sul disco (ma anche stavolta non sono sicuro che la smartcard lasci importare l'intero certificato o solo la parte pubblica). Una volta creato il backup, la chiave pubblica (da distribuire all'occorrenza) si può estrarre tramite openssl con questo comando:

openssl pkcs12 -in nome_del_backup_a_piacere.p12 -nokeys | openssl pkcs12 -export -out nome_certificato_pubblico_a_piacere.p12

[opzionalmente aggiungi -name nome_a_piacere ----- serve a richiamare facilmente un certificato specifico: un p12 può essere un keystore e contenere più coppie di chiavi, cui si accede o tramite l'indice, oppure tramite il friendly name]

Se il pipelining da problemi, si può scindere in due comandi:

openssl pkcs12 -in nome_del_backup_a_piacere.p12 -out temp.pem -nokeys

openssl pkcs12 -export -in temp.pem -out nome_cert_pubblico_a_piacere.p12

Può essere necessario indicare la cartella di openssl con i binari (io ho aggiunto il path alle variabili d'ambiente). Se da errore, probabilmente vuol dire che il backup non contiene la chiave privata, quindi è già un certificato pronto per essere distribuito (ma per firmare bisogna sempre accedere alla smartcard).


@klades

Se hai già ricevuto le altre email, allora hai già tutto, l'unica differenza è che nel messaggio prodotto direttamente da tb non ci sono altre parti: ho creato i p7m firmati e cifrati sempre in questo modo, partendo da un messaggio cifrato e firmato di tb, scaricando il p7m e rispedendolo come allegato, quindi, per ricostruire il messaggio originario basta togliere tutto ciò che si trova tra il subject e il content type del p7m, aggiungendo "x-" prima di "pkcs7-mime", es:

Subject: Prova post dike ecc.
[parte da togliere, compreso il buondary dell'allegato]
Content-Type: application/x-pkcs7-mime; name=smime.p7m
Content-Transfer-encoding: base64
Content-Disposition:inline; filename=smime.p7m
[tutto il resto]

Ovviamente cambia anche l'indirizzo del destinatario, ma non credo faccia molta differenza. Senza la chiave privata, in ogni caso, non puoi decifrarlo, e inoltre non posso spedirti, con tb, un messaggio cifrato indirizzato a te se non possiedo un tuo certificato con la chiave pubblica: dovrei spedirti o solo l'allegato p7m, oppure l'intera email come allegato eml, quindi, in ogni caso, non potresti fare prove sul ricevimento di un messaggio cifrato. Altra cosa: come accennavo, questo è il modo in cui tb produce messaggi cifrati; altri client creano la struttura multipart attorno all'allegato, cioè aggiungono dopo il subject:

Content-Type: multipart/mixed;
 boundary="------------000208070808050800020406"
[eventuali altri header, ad esempio prodotti da un antivirus]

This is a multipart message in mime format.
[manca il primo boundary di tipo text/plane con il messaggio in chiaro, ovviamente]
------------000208070808050800020406
Content-Type: application/x-pkcs7-mime; name=smime.p7m
[oppure Content-Type: application/pkcs7-mime; name= smime.p7m]
[tutto il resto, cioè il file p7m convertito in base64]


Ho fatto qualche prova con openssl per produrre degli smime firmati (credo di aver pasticciato un po' con i certificati, ma per questa parte è irrilevante, influirebbe solo sulla verifica, che con un qualsiasi programma delle pa fallirebbe a prescindere, visto che non sono una CA ufficiale).

I file firmati prodotti sono di 3 tipi:

- SMIME, che contiene testo in chiaro, e può essere di due tipi:
--- un messaggio MIME che inizia con:
MIME Version: 1.0
Content-type: multipart/signed; protocol:protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----61E2544A821BEAFB7B538E65BA43B4CE"

e continua con la sezione con il messaggio/l'allegato (processa qualsiasi file come contenente testo, e questo può creare problemi, quindi conviene crearlo come binario e del tipo successivo) e la firma (application/x-pkcs7-signature). Sarebbe facile da distinguere: basterebbe decodificare le prime righe in base64 nel messaggio  "esterno" (che contiene l'allegato firmato e lo codifica in base64) e cercare la stringa "Content-Type"; tuttavia, sembra che dike non riconosca questo tipo di smime come una "busta pkcs7" (che però è tutt'altra cosa, quindi l'implementazione all'italiana ha fatto confusione anche qui);

--- un pkcs7 con firma incorporata: si ha un file in chiaro (che nell'email diverrà comunque un allegato con transfer encoding base64 - però non ho ancora verificato, ma credo proprio funzioni così), senza struttura multipart, ma solo con l'header del p7m "interno" (che conterrà il file e la firma a loro volta codificati in base64); anche stavolta si potrebbe procedere cercando la stringa "Content-Type", ma anche stavolta non piace a dike (non solo non trova e non verifica la firma, ma non riconosce e non estrae l'allegato/il testo del messaggio);

- come una struttura PEM: sono file di testo, che contengono il messaggio/il file più la firma codificati come base64 e delimitati dalle stringhe: ----------BEGIN PKCS7----- e -----END PKCS7----- come da rfc2315 (come formato generico di un pkcs7, ma l'rfc2311 relativo a smime consente i casi precedenti); in questo caso dike vede l'allegato, e lo estrae correttamente, sia che ci siano i delimitatori, sia che non ci siano affatto: in questo caso si potrebbe distinguere un p7m firmato da uno cifrato cercando innanzitutto il delimitatore di inizio pkcs7 (nella prima riga codificata in base64 nel messaggio "esterno"), quindi, se non si trova, verificare che la prima riga, decodificata da base64, contenga ancora una riga contenente i soli caratteri ammessi in base64 (dubito che un file cifrato cominci con i soli caratteri dell'alfabeto più i simboli "+" e "/");

-come un file in formato DER: anche questo viene letto senza problemi da dike; sfortunatamente è binario, quindi difficilmente sarà distinguibile da un p7m cifrato (anche perchè l'rfc2311 prevede diversi tipi di crittografia, e il der varia a seconda del contuenuto); oltretutto l'rfc2311 definisce il der per i pkcs10.

La cosa più semplice (e anche la più ovvia), ma forse la più difficile da fare con una estensione (più che altro per la documentazione mancante o incompleta) sarebbe intercettare l'errore nella gestione di smime da parte di tb e ordinare al client di trattare l'allegato come un generico octet-stream da mostrare all'utente, quindi forzarlo ad elaborare gli allegati successivi.


Probabilmente, qui c'è la soluzione al dilemma, o meglio, la conferma ai sospetti: nella "feature list" si può notare come le caratteristiche necessarie per il supporto ai pkcs7-mime con firma (in particolare, incorporata) attualmente siano mancanti o implementate parzialmente, in particolare mi riferisco ai punti 2 e 3

[klades]

Ho potuto fare una controprova diretta con messaggi cifrati e non posso che condividere l'analisi dettagliata di xael.
In pratica la situazione con l'attuale versione dell'estensione è questa:

- si vedono gli allegati p7m a un messaggio non cifrato
- non si possono decodificare i messaggi cifrati

Uscire da quest'impasse non è semplice, tuttavia credo di poter provare una strada: sto lavorando con un prototipo dell'estensione che consente l'abilitazione/disabilitazione manuale del supporto SMIME, cioè consente di passare facilmente da una configurazione all'altra con un semplice click.

In più credo che - forse - si può arrivare a un'implementazione "intelligente" di questo passaggio, cioè all'automatica attivazione del supporto SMIME quando il messaggio è cifrato (almeno secondo lo standard usato da TB) e una sua disattivazione quando non serve, anzi è dannoso.

Ovviamente questo significa che dovrete sobbarcarvi un po' di altre prove

[xeal]

Pensi di agire sul sorgente, facendo un parsing, oppure hai trovato il modo di interagire con le strutture dati di tb (che dovrebbero essere degli oggetti dom)? In quest'ultimo caso, si potrebbe pensare di fare qualcosa di ancora più "intelligente", ovvero verificare se una struttura multipart contiene un solo nodo foglia di tipo pkcs7 (che è il modo in cui altri client producono messaggi cifrati) e, in caso positivo, andare a togliere gli elementi che stanno attorno, in modo da far riconoscere a tb il messaggio come cifrato anche quando non ha la struttura prevista, e risolvere il bug relativo. Se ciò non fosse possibile si potrebbe tentare un altra strada: modificare direttamente il sorgente mime e darlo in pasto a tb, anche se questo richiederebbe il verificarsi di due condizioni: a) la possibilità di riscrivere il messaggio (memorizzandolo lato server e facendolo riaprire da tb, oppure modificandolo in locale e dandolo in pasto al parser del messaggio) e b) gli oggetti della struttura dati accessibile devono essere di tipo "live" (come gli element del dom) e consentire modifiche al volo.

Questo però potrebbe comportare un problema (e forse si verificherebbe anche nell'implementazione più semplice che forse stai pensando, cioè leggere il sorgente e attivare/disattivare il supporto a smime in base allo standard usato da tb): e se un client facesse la cosa opposta? Cioè, se una pa usasse un qualche client ipotetico, il quale, dovendo spedire un messaggio privo di testo con un solo allegato firmato, producesse una struttura mime identica a quelle che tb tratta come messaggi cifrati? Forse anche in questo caso c'è una soluzione: comunque si implementi la prima parte (attivazione/disattivazione supporto interno), si può sempre fare un controllo, successivamente, per verificare cosa è stato visualizzato: se con il supporto interno a smime non viene visualizzato nessun testo, allora le cose sono due, o il messaggio era cifrato (con o senza firma interna), ma non conteneva niente, oppure non si trattava di un messaggio cifrato, e siamo incappati nel bug. Il primo caso lo si verifica facilmente: tb mostrera delle informazioni sulla cifratura (ed eventualmente sulla firma), se questo non succede allora converrebbe disattivare smime e mostrare  l'allegato pkcs7.

Questo potrebbe essere valido anche in un altro caso: se il messaggio è effettivamente cifrato e "costruito" secondo le convenzioni di tb, ma tb non conosce le chiavi (che però l'utente potrebbe possedere e usare con dei software esterni), allora verrà trattato come un allegato non cifrato, quindi non visualizzato, per cui anche in questi casi servirà disabilitare il supporto a smime. Direi che l'algoritmo dovrebbe essere questo:

1. Applicare un criterio di scelta per l'attivazione/disattivazione del supporto interno a smime, in base alla presenza o meno di un unico allegato pkcs7;
1.1 se possibile, far vedere a tb come tali i messaggi cifrati da altri client (ma all'inizio dello sviluppo potremmo anche trascurare questo punto).

2. Verificare che il supporto interno, se attivato, abbia prodotto un risultato valido:
2.1 se il messaggio viene riconosciuto come cifrato (= viene prodotto il "lucchetto" con annesse informazioni sulla crittografia), allora abbiamo finito;
2.2 in caso contrario, o il messaggio non è cifrato, oppure è cifrato con chiavi ignote a tb, quindi bisogna disattivare il supporto a smime e lasciare che l'allegato venga presentato come tale.

Tuttavia, anche questo criterio presuppone un comportamento live delle strutture dati di tb (credo sia necessario anche nell'implementazione più semplice, senza controllo successivo: vuoi accedere al sorgente dopo che l'utente ha selezionato il messaggio e tb lo ha scaricato/ha fatto il parsing degli header via imap, giusto? oppure pensi di intercettare la richiesta al server?).

Darei una mano con il codice, ma non sono abbastanza dentro il meccanismo delle estensioni.

[xeal]

Suggerisco un paio di test preliminari, per verificare la fattibilità della cosa. Una prima versione basilare dell'estensione "intelligente" potrebbe semplicemente partire con il supporto interno abilitato (quindi, nessun allegato pkcs7 risulta visibile) per disabilitarlo dopo qualche secondo (una decina, per sicurezza): se funziona, gli allegati diverranno visibili. Un secondo test potrebbe indirizzarsi verso la possibilità di modificare gli header del messaggio: proverei, con il supporto interno attivo, a modificare il content-type dei pkcs7 in octet-stream, così da renderli visibili (naturalmente, solo se la modifica va a buon fine). Se funziona tutto come si vorrebbe, allora sarà possibile implementare un'estensione veramente smart, capace di riconoscere i messaggi cifrati provenienti da altri client. Aggiungerei anche, a questo punto, una correzzione di mime-type sbagliati (ad esempio, da "application/pkcs7" ad "application/pkcs7-mime").

[guia78]

Io mi sono perso nei meandri dei discorsi...