[Openpec-users] Certificati "tarocchi", nuova feauture e sito per documentazione

[Alberto Z. <al...@in...>]

Salve a tutti, non sar=C3=B2 breve ;-)
Con un collega abbiamo messo in piedi un paio di server con OpenPEC e stiam=
o=20
compiendo una serie di test di interoperabilit=C3=A0. A parte il problemino=
 dei=20
destinatari multipli che pare abbiamo risolto, personalmente ho qualche=20
dubbio su come funzionino i certificati.
In questo momento abbiamo utilizzato la procedura di creazione dei certific=
ati=20
descritta nel file di installazione e ne risultano, ovviamente, dei=20
certificati "tarocchi". Cosa vuol dire questo: vuol dire che sia per quanto=
=20
riguarda la connessione al server, sia per la firma di ogni messaggio, il=20
client di posta (ho provato sia outlook express su windows, sia ximian=20
evolution su linux) restituisce un warning di inattendibilit=C3=A0 del=20
certificato.
Per ci=C3=B2 che si legge dalle faq sul sito del CNIPA pare che questo non =
vada=20
bene, ma prima di acqistarne uno volevo un parere da parte Vostra (magari c=
on=20
un consiglio su l'ente da cui comprarlo).
Tra l'altro abbiamo avuto non poche difficolt=C3=A0 ad includere il certifi=
cato=20
nella directory LDAP in quanto openpec utilizza il formato pem, mentre ldap=
=20
necessita della conversione in ASN.1 (grazie a Fabio Ferrari).

Inoltre, in tutta sincerit=C3=A0, ho qualche dubbio sulla qualit=C3=A0 del =
sistema=20
concepito dal CNIPA; mi riferisco principalmente al fatto che il messaggio=
=20
viene firmato dai server, ma non da mittente e destinatario. Questo, second=
o=20
me, comporta due problemi:
=2D non ho la certezza sul mittente (se conoscessi l'abbinata username-pass=
word=20
di un utente potrei spedire mail certificate a nome di qualcun altro e in u=
n=20
ufficio non =C3=A8 una cosa cos=C3=AC impossibile);
=2D non ho la certezza che il destinatario abbia effettivamente letto la po=
sta=20
(la ricevuta di consegna arriva, ma se il destinatario non va a leggersi la=
=20
posta...).
Spero che nella nuova versione del capitolato tecnico vengano presi in esam=
e=20
anche questi punti, cos=C3=AC come il dubbio gi=C3=A0 emerso riguardo a sis=
temi=20
antispam o antivirus.

In qualsiasi caso si legge chiaramente tra le faq:
=2D-----------
D: Come =C3=A8 possibile inserire nei messaggi generati dal sistema, dati n=
on=20
previsti nel DTD che descrive i dati di certificazione (es. l=E2=80=99ident=
ificativo=20
originale del messaggio originale)?
R: Dati aggiuntivi possono essere inseriti nel corpo del messaggio rispetta=
ndo=20
i modelli descritti nell=E2=80=99allegato tecnico. Inoltre, in tutti i mess=
aggi=20
generati dal sistema di posta certificata (ricevute, messaggi di trasporto,=
=20
errori) =C3=A8 possibile inserire ulteriori allegati per specifiche funzion=
alit=C3=A0=20
offerte dal gestore. =C3=88 importante che questi allegati (inseriti come p=
arti=20
MIME all=E2=80=99interno del messaggio) rispettino la codifica specificata =
al=20
paragrafo 7.3 e abbiano un nome che non vada in conflitto con quelli defini=
ti=20
dall=E2=80=99allegato tecnico.
=2D-----------

Per cui qualche possibilit=C3=A0 di creare una sorta di ibrido ci sarebbe. =
Avrei=20
qualche idea in proposito, per=C3=B2 prima vorrei capire se secondo voi ci =
pu=C3=B2=20
essere spazio di manovra e casomai potremmo lavorarci assieme.

Infine, riguardo al discorso del manuale di installazione affrontato un pai=
o=20
di mesi orsono, pensavo di mettere in piedi qui da me un server Plone: lo u=
so=20
in altre situazioni e si sta dimostrando davvero efficace. Vorrei un parere=
=20
anche su questo punto.

Ciao,
Alberto