Newsgroup: it.diritto.internet
Titolo: PEC come raccomandata

Dove fare la richiesta per un rimborso ad un comune.
Normalmente scriverei la lettera la firmerei e la invierei per 
raccomandata con ricevuta di ritorno.
Se invece volessi usare una PEC come dovrei fare?
Basta fare la scansione della lettera firmata, allegarla ed inviarla?
Il solo documento in word senza firma vale lo stesso, essendo firmato 
dalla pec, oppure bisogna comunque firmarlo manualmente e scansionarlo?

 dalla pec, oppure bisogna comunque firmarlo manualmente e scansionarlo?
La PEC certifica anche il contenuto, quindi dovrebbe essere sufficiente
inviare la mail, a prescindere da quel che contiene. Certamente da evitare
il word; o solo testo o PDF.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Certamente da evitare il word; o solo testo o PDF.
Ma se evito il pdf come posso allegare la lettera firmata che "In linea 
teorica dovrebbe essere sufficiente"?
E se evito il solo testo inviare il contenuto che "la PEC certifica"?

 Grazie per la risposta, che però mi ha lasciato dei dubbi.
In effetti rileggendola mi sono accorto che era tutto fuorché chiara.
Ti riassumo quel che posso. Per la legge italiana la firma digitale equivale
in tutto e per tutto la firma autografa, quindi se invii un documento
firmato digitalmente questo ha valore legale (D.Lgs.82/2005) (ovviamente
deve rispettare certi criteri, ma questo immagino lo sappia già)
Il documento così firmato ha valore di per sè, ovvero vale se lo invii via
mail, con la PEC, masterizzato su un CD e inviato per posta, ecc.ecc.
Inoltre la firma digitale offre garanzia di autenticità e di integrità,
ovvero un documento firmato digitalmente non può essere "ripudiato" (salvo
prova contraria a carico del firmatario) e si può verificarne eventuali
manomissioni.
Un documento cartaceo firmato e poi scansionato invece non da analoghe
garanzie; normalmente è accettato e comunque ha una certa validità, ma è
innegabile che tale documento sia facilissimamente falsificabile e quindi
chi lo riceve potrebbe non accettarlo.
La PEC sostituisce la raccomandata. Come la raccomandata fornisce una
ricevuta di ritorno che ha valore legale, ma a differenza della raccomandata
la PEC certifica anche che quel che è stato ricevuto è esattamente quel che
è stato inviato, "firmando" il contenuto della mail.
Inoltre la casella PEC che ha inviato la mail è identificabile con certezza
e così teoricamente anche il mittente che deve essere stato identificato per
il rilascio della PEC (quindi non puoi mandare raccomandate conto terzi :-) ).
Quindi riassumendo:
Se mandi il messaggio via PEC è come se avessi mandato una raccomandata, ma
in più il ricevente non può negare che il contenuto del messaggio sia quello
inviato. Se hai scritto qualcosa nella mail il ricevente non può negare che
ciò vi è stato scritto, e il fatto che sia stato tu a scriverlo è provabile
per l'identificazione certa del soggetto per la fornitura del servizio PEC.
Alla fine equivale ad un invio via FAX.
Se alleghi la scansione di un documento firmato, questo ha praticamente lo
stesso valore di cui sopra, quindi normalmente è sufficiente. Essendo la
firma scansionata facilmente falsificabile, non aggiunge praticamente nulla
all'invio del solo testo nella mail.
Se invii via PEC un documento firmato digitalmente invece sei in una botte
di ferro perché hai la ricevuta di invio, hai la certificazione che il
documento sia quello che tu hai inviato, e la firma del documento garantisce
sia la tua identità che la sua integrità.



Grazie, chiaro come uno specchio :)


X-Tiporicevuta: completa
MIME-Version: 1.0
...
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="----XXXXXXXXXXXXXXXXXXXXXXXXX"
This is an S/MIME signed message
------XXXXXXXXXXXXXXXXXXXXXXXXX
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_XXXXXXXXXXXXXXXXXXXXXXXXX"
This is a multi-part message in MIME format...
------------=_XXXXXXXXXXXXXXXXXXXXXXXXX
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
--Questo e' un Messaggio di Posta Certificata--
Il giorno 12/04/2010 alle ore XX:XX:XX (+0200) il messaggio con Oggetto
...
e indirizzato a:
flavio.visentin@XXXXXXXXXXXXXXXXXXXXXXXXX "posta ordinaria"
Il messaggio originale e' incluso in allegato, per aprirlo cliccare sul fil=
e "postacert.eml" (nella webmail o in alcuni client di posta l'allegato pot=
rebbe avere come nome l'oggetto del messaggio originale).
L'allegato daticert.xml contiene informazioni di servizio sulla trasmissione
L'identificativo univoco di questo messaggio e':
XXXXXXXXXXXX...@pec.aruba.it
------------=_XXXXXXXXXXXXXXXXXXXXXXXXX
Content-Type: application/xml; name="daticert.xml"
Content-Disposition: inline; filename="daticert.xml"
Content-Transfer-Encoding: base64
...
------------=_XXXXXXXXXXXXXXXXXXXXXXXXX
Content-Type: message/rfc822; name="postacert.eml"
Content-Disposition: inline; filename="postacert.eml"
Content-Transfer-Encoding: 7bit
...
------------=_XXXXXXXXXXXXXXXXXXXXXXXXX--
------XXXXXXXXXXXXXXXXXXXXXXXXX
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
...
------XXXXXXXXXXXXXXXXXXXXXXXXX--
Pensa che quello stupido di thunderbird addirittura mi dice:
"This message includes a valid digital signature. The message has not been
altered since it was sent". Sarà utile che tu glielo dica al client di posta
che evidentemente sta sbagliando, perché «la pec non certifica il contenuto»


 veritiera.
Corretto. Aggiungo che la PEC dimostra "soltanto" che quell'e-mail è stata
inviata e ricevuta, ma non CHI l'ha inviata.
Più precisamente, in rekaizone al contenuto, la PEC (rectius il gestore
della PEC) certifica solo che quel determinato contenuto è esattramente
quello inviato\ricevuto, ma NON la paternità dello stesso.
Ora, mentre per il destinatario subentra l'articolo 1335 (presunzione di
conoscenza) nulla ci consente di dimostrare (in caso di contestazone
dell'origine), che il mittente sia effettivamente il titolare dell'account
PEC.
Anche questo è un aspetto molto poco noto.
-- 
 Non hai veramente capito qualcosa finché non sei in grado di spiegarlo a
tua nonna. (Albert Einstein)

 stata inviata e ricevuta, ma non CHI l'ha inviata.
Non lo fa anche meglio della raccomandata?
Se io mando una raccomandata c'è solo una firma in calce, che
potrebbe essere falsa.
Se mando una PEC ho usato una coppia user/pass che - ok - può
essere stata trafugata, ma comunque è un'operazione più difficile
che non falsificare la mia firma.
In più nei log del gestore PEC ci sarà l'ip da cui mi sono connesso,
che mi rende ancor più rintracciabile.
Poi il mio pensiero sulla PEC è PG-13 rated, ma vabbé.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 Poi il mio pensiero sulla PEC è PG-13 rated, ma vabbé.
ROTFL
-- 
 Il vecchio scosse il capo: — Che gioventù — gridò indignato. — Non sono
ancora nati e già accampano dei diritti ! (G.Guareschi)

 garantirne la corrispondenza tra identit� e account PEC.
Ecco, questo � interessante e chiarisce il punto.


 Se chi mi ha fornito la PEC, NON mi ha identificato...
Ni, nel senso che comunque la PEC non è idonea a garantire l'identità del
mittente. Neppure la mia, che è foirnita dall'Ordine, è, se priva di firma
digitale o elettronica q. idonea allo scopo.
Posso sempre dimostrarlo in dibattimento, ma fino a quel momento ha la
stessa efficia probatoria, in termini di paternità, di un fax o di un'email
semplice.
-- 
 "i consigli sono doni pericolosi, anche se scambiati fra saggi, e tutte le
strade possono finire in un precipizio". (J.R.R. Tolkien)


Esempio pratico...
Fa conto che io sia la tua banca, tu mi mandi via PEC un ordine di 
bonifico ad un tizio residente in Cile, io eseguo diligentemente 
l'ordine svuotandoti il conto..
Ora, se l'ordine l'hai effettivamente inoltrato tu è tutto ok, ma se 
disgraziatamente l'ha inoltrato qualcun'altro entrato in possesso delle 
tue credenziali? Ci vado io o ci vai tu in Cile a sperare di recupere il 
malloppo?
Dato che io "banca" non ho modo di verificare in real-time n'è l'IP da 
cui viene inviata che sarebbe peraltro inutile per un utente in mobilità 
nè il reale mittente non resta che ricorre alla firma qualificata.

 verso i cittadini italiani.
Vero, ma considera che per permettere ai notai di utilizzare la macchina da
scrivere anziché la penna c'è voluta una legge apposita, quindi non ci
stupiamo che la cosa vada avanti a rilento.
-- 
 La mente è come un paracadute. Funziona solo se si apre. (Albert Einstein)

 l'ordine svuotandoti il conto..
Non credo calzi: la banca accetta ordini di bonifico via raccomandata?


 In via teorica dovrebbe.
Se la mia banca lo facesse la abbandonerei di corsa :-)


:-)
Mh.  Bisognerebbe chiedere sul gruppo delle banche, ma immagino che un
conto di corrispondenza prevedea qualche forma di autenticazione del
mittente, perlomeno con una firma, e magari anche con una telefonata.
Se la PEC non certifica il mittente, non può autenticare.

Non credo calzi: la banca accetta ordini di bonifico via raccomandata?
In ogni caso neppure tramite raccomandata postale il mittente viene
identificato...
Chiunque può tranquillamente recarsi all'ufficio postale e compilare
la ricevuta della raccomandata e l'avviso di ritorno con il nome del
mittente che gli pare e "ad abundantiam" magari falsificare anche la
firma del documento inviato tramite ufficio postale.
A me pare quindi che mai in ogni caso una raccomandata possa garantire
che il mittente sia effettivamente quello dichiarato nelle ricevute di
invio e di ritorno: nella PEC mi pare che invece ci siano maggiori
probabilità che il mittente sia quello dichiarato, visto che ad
esempio la banca già intratteneva un rapporto "ad personam" tramite lo
specimen firma, l'ordine professionale si relazionava già in
precedenza con la persona a cui rilascia la PEC ed in genere era già
preesistente un rapporto diretto con la persona a cui la PEC viene
rilasciata.

 persona.
Infatti, è pur sempre prevista la "raccomandata a mano".
Però il problema mi sembra affrontato a rovescio.
La raccomandata ha lo scopo e le metodologie di funzionamento per
"garantire" la dimostrabilità della ricezione da parte del destinatario.
È uno strumento a tutela del mittente, non del destinatario.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 È uno strumento a tutela del mittente, non del destinatario.
Fino ad un certo punto però. Con l'invio di raccomandata in busta chiusa il
ricevente può sempre dire di aver ricevuto una busta vuota o un documento
diverso da quello effettivamente contenuto. Sta al mittende dimostrare quel
che ha effettivamente inviato, ed è per questo infatti che le raccomandate
"importanti" andrebbero sempre fatte con cartolina o comunque senza busta.
La PEC in questo caso invece tutela effettivamente il mittente garantendo
che quel che è stato spedito sia effettivamente quel che si sostiene aver
spedito e che sia esattamente quel che è stato ricevuto.
Peraltro pensavo anche che è possibile sfruttare la PEC come marca temporale
con valore legale a costo praticamente nullo.
Mando un hash di quel che voglio marcare ad un indirizzo di posta PEC e
salvo la ricevuta.


 Infatti, è pur sempre prevista la "raccomandata a mano".
Che però comunque IMHO non certifica il mittente...



E come faccio a provare di NON aver ricevuto qualcosa?
Io vedo che molti spediscono in azienda il foglio direttamente senza busta.
La raccomandata certifica l'invio e (eventualmente) la ricezione, non certo 
il contenuto
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 
Vero, a parte quelle consegnate ad un notaio o un ufficiale di stato
civile.
E traslando il concetto, in realtà lo potrebbe anche certificare, se
il mittente rilascia copia firmata della ricevuta.


 Del resto l'impostazione "sociale" della comunicazione, č quella.
Infatti, era il senso del mio intervento.
La PEC nasce con l'idea di sostituire con mezzi moderni e con alcune
caratteristiche ulteriori (firma digitale applicabile, marca temporale
e altre quisquilie del genere) la raccomandata, senza, a mio avviso,
cercare di snaturarne la filosofia di base.


 Cosa c'entra l'ufficile di stato civile?
Può certificare il mittente, tanto quanto un notaio.


 Se parli di atto notorio, mica *lo consegni*.
No, parlo sempre della "certificazione" del mittente.
Nel caso di raccomandata a mano, deve essere il mittente a consegnarla,
altrimenti c'è sempre un terzo di mezzo, come con le poste, e le cose
si ricomplicano.
Pertanto, al momento della consegna brevi manu, ci sono i due attori:
il mittente e il destinatario.
Per certificare l'identità del mittente, al momento della consegna, ci
vuole un notaio o un ufficiale di stato civile, che possono identificare
(anche a fini legali) il mittente e pertanto "certificarlo".
La prossima volta ci metto lo stesso la faccina, anche se il discorso
era sì contorto, (io salgo le scale a chiocciola senza girarmi) ma al
100% rispondente all'obiezione di valeryo.


 Qualcuno certifica il _mittente_ al momento della *consegna*?
No, infatti la raccomandata a mano non risolve il problema:
il mittente non è certificabile.
Una delle pochissime cose positive della PEC poteva essere
la certificazione del mittente, ma pare non serva neppure a quello.


 Nel caso di raccomandata a mano, deve essere il mittente a consegnarla,
Perciò si stava parlando (be', io ero convinto che stessimo parlando) di
quel caso particolare di corrispondenza in cui al momento della consegna
sono presenti entrambi gli attori.
PS: l'ufficiale di stato civile, potendo autenticare firme, atti notori,
ecc.ecc. è deputato all'identificazione del cittadino, e col suo titolo
lo può fare in qualunque luogo.
Gli impiegati d'anagrafe, comandati allo sportello per l'autentica, non
lo possono fare se non allo sportello a fronte di incarico temporaneo.


 "certificarlo".
Fornisci esempio di USC che certifichi l'identità del mittente. 

Sparrow® ha scritto:

Signori, è assodato: o io non so scrivere, o voi non sapete leggere.
Io, dopo questa, rinuncio, e ammetto tranquillamente che sia vera la
prima ipotesi: non so scrivere.
Riassunto delle puntate precedenti:
Dopo varie peripezie sulla filosofia della comunicazione cartacea,
siamo arrivati alla raccomandata a mano, come esempio in cui anche
il mittente ha *possibilità* di essere identificato visto che è lì
che sta consegnando la raccomandata al destinatario, nel caso che
ho preso ad esempio, escludendo la consegna a mano da parte di terzi,
che torna ad essere come l'affidamento alle poste o corriere.
Ci siamo? Siamo arrivati a casa di $destinatario nel momento in cui
c'è $mittente che gli porge la busta, esige una ricevuta, e potrebbe
lasciarne copia a $destinatario.
A questo punto, valerYo ha parlato di "certificare" il mittente.
Io ho giocato lessicalmente sul termine, e ho detto che solo se
il destinatario è un notaio o un ufficiale di stato civile il mittente
(ricordate? il mittente è lì che sta porgendo la busta al notaio) può
essere certificato, visto che quei due soggetti sono quelli demandati
al riconoscimento *certo* di chi sta apponendo firme su atti.
Perciò, NESSUN NOTAIO CERTIFICA IL MITTENTE IN QUANTO TALE.
Contenti?


 forza esserci il mittente.
Eh, temo di sě (a parte che poteva essere un sottoinsieme dei casi
possibili).
Perň non ho trovato traccia (velocemente) di normativa specifica.


 suo titolo lo può fare in qualunque luogo.
Confondi USC con funzionario (o dipendente) incaricato dal sindaco.
L'USC delegato dal sindaco (il sindaco è USC in quanto ufficiale del 
governo) non è *necessariamente* un dipendente comunale. Può infatti 
essere anche il presidente della circoscrizione o un consigliere 
comunale.
Quindi un USC che non sia *anche* dipendente comunale *non* è titolato a 
autenticare firme, atti notori (o, esattamente, dichiarazioni 
sostitutive dell'atto di notorietà).
Ma anche se lo fosse (dipendente comunale), per organizzazione interna 
raramente gli sono assegnate anche queste incombenze. Che sono invece 
svolte dagli impiegati dei servizi demografici (anagrafe).
In ogni caso, vorrei proprio vedere un USC (seppur titolato alle 
autenticazioni ex DPR 445/2000) che vada a "identificare" un "mittente" 
di una missiva. 

È uno strumento a tutela del mittente, non del destinatario.
Soprattutto, sì.  Da quando è tracciabile, dà anche una certa tutela
al destinatario, perché è più difficile che si perda.


Allora è meglio che non ti dico in che modo gli uffici ragioneria dei 
comuni inviano gli ordini di pagamento alle banche.. potrebbe guastarti 
il sonno.

 guastarti il sonno.
Non vedo cosa c'entri...


 
ammettiamo:
l'emittente della firma e' anche la controparte in una causa
chi mi garantisce dalla controparte che non firmi digitalmente
altri documenti con quella che dovrebbe essere la mia firma
tradotto
non mi fido del certificatore chi mi garantisce da lui ?

 quanta ignoranza...
Sì, trasudi parecchia ignoranza, ma non ti abbattere. Forse leggendo quel
che linki in futuro imparerai anche ad evitare certe figure del ca$$o ...
-- 
Flavio Visentin
2006: l'onestà  2007: la storia  2008: la leggenda  2009: il mito epico
Solo vincendo sul campo, senza rubare, si replica il grande Torino.

 non mi fido del certificatore chi mi garantisce da lui ?
Lo Stato italiano!
I certificatori accreditati CNIPA sono sottoposti a rigidissimi 
controlli, nonchï¿œ il fatto che l'unico possessore della chiave privata 
"dovrebbe" essere l'utente finale che ha richiesto e ritirato 
personalmente il token, ergo l'unico che puï¿œ apporre la tua firma 
digitale su un documento sei tu.
Ammenochï¿œ... ma questa ï¿œ un altra storia..

 personalmente il token
Senza il ï¿œdovrebbeï¿œ. La chiave privata ï¿œ generata internamente al token e
non puï¿œ esserne estratta in alcun modo lecito (ed ï¿œ comunque difficile anche
con metodi illeciti dato che sono richieste apparecchiature presenti solo in
universitï¿œ o in centri di ricerca che non sono certo appannaggio del primo
che passa).
Il certificatore ï¿œ solo in possesso della chiave pubblica che provvede a
firmare, indicizzare ed eventualmente a revocare.
-- 
Flavio Visentin
2006: l'onestï¿œ  2007: la storia  2008: la leggenda  2009: il mito epico


 hai ragione, avevo letto male.
Capita a tutti :-)
Ma è certamente cosa rara ed apprezzabile trovare ancora in qualcuno la
maturità di ammettere i propri errori.
Stefano Bartezzaghi lo riteneva ormai un tabù tutto italiano :-)


 Capita a tutti :-)
Flavio... mi aggancio qui visto che stavo leggendo il thread;
tutto corretto, per carit�; incapsulamento e tutto il resto, solo
che... il protocollo SMTP � un "best effort" nel senso che il
server mittente tenta di fare del suo meglio per recapitare
un dato messaggio ma non garantisce la riuscita di tale
recapito ora; se da un lato la PEC ha affrontato i problemi
relativi all'identificazione del mittente ed alla segnalazione
dell'avvenuto recapito, dall'altro non ha affrontato quello
visto sopra e, se permetti, a questo punto non � possibile
parlare di comunicazione *affidabile*
Poi ok, ci sarebbe anche da parlare dei problemi inerenti
ad eventuali "furti di identit�" ma credo che finiremmo OT

 parlare di comunicazione *affidabile*
IMHO non ï¿œ corretto.
Una comunicazione ï¿œ da considerarsi affidabile nel momento in cui:
- se essa ï¿œ avvenuta con successo il mittente lo sappia e il destinatario
possa avere garanzia che il dato sia integro.
- se essa non ï¿œ avvenuta o i dati non siano giunti integri, almeno il
mittente ne sia informato.
Nel caso del SMTP ovviamente ciï¿œ non ï¿œ vero, ma nel caso della PEC il
sistema delle ricevute garantisce l'affidabilitï¿œ della trasmissione (ed ï¿œ il
motivo per cui ï¿œ stata creata). Si tratta di un protocollo affidabile
costruito sopra un protocollo inaffidabile, un po' come avviene per il TFTP
o per NFS che pur utilizzando come trasporto un protocollo inaffidabile come
UDP garantiscono comunicazioni affidabili.
-- 
Flavio Visentin
2006: l'onestï¿œ  2007: la storia  2008: la leggenda  2009: il mito epico


 mittente ne sia informato.
E sin qui, ci sta tutto... il problema � ... se al sig. Rossi inviano
una
cartella esattoriale a mezzo raccomandata ed il portalettere non
trova il sig. Rossi a casa, quest'ultimo si trover� un avviso di
giacenza nella buca delle lettere... ma nel caso in cui, per un
qualsivoglia motivo (es. sovraccarico dei servers) lo stesso
avviso, trasmesso tramite PEC non venga recapitato ?
Io sospetto che potremmo assistere a "penali" ed altre simpatiche
cosette simili... per� magari sono io ad essere prevenuto :)

 avviso, trasmesso tramite PEC non venga recapitato ?
Se non viene recapitato, il destinatario non e' in grado di prenderne 
conoscenza.
Quindi l'atto non raggiunge il suo scopo. 



A rigor di logica si; quello che pavento � che, dati altri precedenti il
destinatario finisca per doversi far carico di dimostrare di non aver
(es.) pagato un qualsiasi sospeso a causa del mancato ricevimento
della relativa comunicazione il che, invece di "snellire gli iter" non
farebbe altro che complicare ulteriormente tutto quanto... oh, poi
magari mi sbaglio


La ricevuta della PEC garantisce la consegna al server di destinazione.
Dovrebbe essere quindi il gestore del destinatario a prendersi carico di 
eventuali problematiche
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 cosette simili... perï¿œ magari sono io ad essere prevenuto :)
Se la legge ï¿œ scritta con il culo purtroppo non ci si puï¿œ far nulla. Anche
il fatto stesso che la PEC non sia completamente RFC compliant ï¿œ una
porcheria, ma non ï¿œ che ci si possa attendere altro dall'Italia.


del portinaio.
Non � una porcheria � connaturato al sistema ed ha la sua logica.
Il problema � che � una condanna, quando ti fai la PEC e la comunichi
allo stato devi continuare a controllare la casella, perch� che sia
una multa o una cartella esattoriale � sempre un problema tuo.
Peccato che da Vespa non l'abbia detto il furbone del ministro e tutti
i partecipanti troppo accondiscendenti.
Non � un problema di politica � un problema di usare uno strumento
professionale per le masse.
Vedremo quando un giudice dovr� giudicare su un ricorso di un utente
che non sapeva che facendosi la PEC diventa un suo problema
controllare sempre la posta.
Un altra cosa che non hanno detto � che senza firma elettronica da
parte dell'utente non si pu� fare poi molto come inoltro di documenti
validi legalmente.
AndreA

 della relativa comunicazione
Ma no, neanche che per sogno. Il mittente dovrebbe provare l'invio e
l'avvenuta ricezione. Il destinatario non pu� essere chiamato a provare
una cosa che NON � successa.
-- 
 Candido

 avviso, trasmesso tramite PEC non venga recapitato ?
Se il postino lascia l'avviso, compiuta la giacenza la lettera si ha per
consegnata. Con la PEC non c'� la compiuta giacenza, perch� c'� maggiore
sicurezza sul destinatario.
-- 
 Candido

 validi legalmente.
Questo � vero, senza una firma elettronica documenti o servizi ne 
funzioneranno pochini dato che la PA in un modo o nell'altro tratta al 
90% dati sensibili che devono rimanere riservati, mica si possono 
mettere a rilasciare certificati al primo pinco pallo con la PEC!


Vedo che sei attento ai dettagli, ma non abbastanza preparato...
Vediamo se sei in grado di notare il dettaglio che trasforma il "deve" 
in "dovrebbe", ti do un aiutino...
[root@localhost ~]# pkcs11-tool
Usage: pkcs11-tool [OPTIONS]
Options:
   --show-info, -I               Show global token information
   --list-slots, -L              List available slots
   --list-token-slots, -T        List slots with tokens
   --list-mechanisms, -M         List mechanisms supported by the token
   --list-objects, -O            Show objects on token
   --sign, -s                    Sign some data
   --hash, -h                    Hash some data
   --mechanism, -m <arg>         Specify mechanism (use -M for a list of 
supported mechanisms)
   --login, -l                   Log into the token first (not needed 
when using --pin)
   --pin, -p <arg>               Supply User PIN on the command line (if 
used in scripts: careful!)
   --so-pin <arg>                Supply SO PIN on the command line (if 
used in scripts: careful!)
   --init-token                  Initialize the token, its label and its 
SO PIN (use with --label and --so-pin)
   --init-pin                    Initialize the User PIN (use with --pin)
   --change-pin, -c              Change your User PIN
   --keypairgen, -k              Key pair generation
   --key-type <arg>              Specify the type and length of the key 
to create, for example rsa:1024
   --write-object, -w <arg>      Write an object (key, cert, data) to 
the card
   --read-object, -r             Get object's CKA_VALUE attribute (use 
with --type)
   --delete-object, -b           Delete an object
   --application-label <arg>     Specify the application label of the 
data object (use with --type data)
   --application-id <arg>        Specify the application id of the data 
object (use with --type data)
   --type, -y <arg>              Specify the type of object (e.g. cert, 
privkey, pubkey, data)
   --id, -d <arg>                Specify the id of the object
   --label, -a <arg>             Specify the label of the object
   --slot <arg>                  Specify number of the slot to use
   --slot-label <arg>            Specify label of the slot to use
   --set-id, -e <arg>            Set the CKA_ID of an object, <args>= 
the (new) CKA_ID
   --attr-from <arg>             Use <arg> to create some attributes 
when writing an object
   --input-file, -i <arg>        Specify the input file
   --output-file, -o <arg>       Specify the output file
   --module <arg>                Specify the module to load
   --test, -t                    Test (best used with the --login or 
--pin option)
   --moz-cert, -z <arg>          Test Mozilla-like keypair gen and cert 
req, <arg>=certfile
   --verbose, -v                 Verbose operation. Use several times to 
enable debug output.
   --private                     Set the CKA_PRIVATE attribute (object 
is only viewable after a login)
l'hai visto anche tu? ti si sono drizzati i capelli?

sicurezza sul destinatario.
Con una PEC che funziona bene ci sono molti vantaggi, intanto la mia
prova di ieri tra legalmail e postacertificata di un amico non mi
sembra poi cos� buona come risultati ...
---------------
Avviso di mancata consegna
Il giorno 01/05/2010 alle ore 04:49:50 (+0200) il messaggio "test"
proveniente da xyz ( at) 
legalmail.it
 e destinato all'utente 123 (at)
postacertificata.gov.it
 non � stato consegnato nelle prime dodici ore
dal suo invio.
Non escludendo che questo possa avvenire in seguito, si ritiene utile
considerare che l'invio del messaggio potrebbe non andare a buon fine.
--------------
Boh, speriamo che migliori.
AndreA

 l'hai visto anche tu? ti si sono drizzati i capelli?
Non c'ï¿œ nulla di rilevante.
Sulle smartcard ï¿œ possibile *anche* caricare delle chiavi extra oltre che
utilizzare quella generata internamente, e le chiavi caricate dall'esterno
ovviamente possono essere anche scaricabili previa conoscenza del codice
pin. IIRC ï¿œ anche possibile generare delle chiavi che ï¿œ poi possibile estrarre.
Ma quelle caricate non sono le chiavi che vengono usate nel caso della firma
digitale con valore legale (almeno secondo quanto riportato nelle linee
guida) che invece *devono* esser state generate *internamente* al token e
*non possono* esserne estratte.
Sarebbe d'altronde anche ridicolo che non fosse cosï¿œ, non trovi?


 Sarebbe d'altronde anche ridicolo che non fosse cosï¿œ, non trovi?
N'zomma... il fatto che la RA sia in grado di generare la mia chiave 
privata al di fuori del token e poi caricarcela non ï¿œ che sia il massimo 
della libidine.

 sicurezza sul destinatario.
In che senso maggior sicurezza?
-- 
Flavio Visentin
2006: l'onest�  2007: la storia  2008: la leggenda  2009: il mito epico


 sembra poi cos� buona come risultati ...
Boh, io non ho mai avuto problemi, e ormai la uso da un paio di anni.
-- 
 Candido

 In che senso maggior sicurezza?
Nel senso che - in linea di massima - dovrebbe essere meno sentito il
problema del cambio di sede o di residenza, perch� l'indirizzo PEC,
sempre in linea di massima, non dovrebbe cambiare.
-- 
 Candido

On Sat, 1 May 2010 13:17:50 +0200, 
cand...@gmail.com
 (Candido)
wrote:

Intendevo il nuovo servizio gratuito statale...
Anche a me legalmail non ha dato un errore in vari anni di utilizzo.
Comunque mi � arrivata un'altra notifica "...non � stato consegnato
nelle ventiquattro ore successive al suo invio.
Si ritiene che la spedizione debba considerarsi non andata a buon
fine."
Consiglio vivamente un servizio a pagamento e con un SLA certo, per
una clientela consapevole.
AndreA

 
per generare le chiavi occorre una cpu quindi il token dovrebbe avere
una cpu e anche DECENTE e storarle in 2 memorie una laggibile e una
interna, e la generazione dovrebbe avvenire "a casa dell'utente"
e non dalla RA

> della libidine.
Un conto ï¿œ quel che si ï¿œ in grado di fare e un conto ï¿œ quel che si fa.
D'altronde non possiamo partire dal presupposto che le RA certificate siano
disoneste, altrimenti lo dovremmo mettere come presupposto per tutto, quindi
anche per il notaio che certificasse come tua autografa una firma solo
imitata...


 imitata...
Quindi secondo il tuo punto di vista, una PKI che consenta a chiunque di 
gestire una RA (previa sottoscrizione di un contratto ovviamente) ï¿œ da 
ritenersi totalmente affidabile pur sapendo che esiste la possibilitï¿œ 
che una RA disonesta mantenga per se una coppia "chiave 
privata/certificato" rilasciata ad un utente finale?
D'altra parte ï¿œ vero che qualunque impiegato in un anagrafe puï¿œ 
incollare la foto del cuggino su una carta d'identitï¿œ inserendo dati 
anagrafici totalmente inventati.
Il mio dubbio ï¿œ in caso di contestazione/querela in cui venga tirata in 
ballo la PKI.

 anagrafici totalmente inventati.
E' questo il punto. Ci sono delle regole, ci sono dei controlli, ci sono
delle leggi. Il nostro potere di verifica e di controllo ad un certo punto
necessariamente viene a mancare e da lï¿œ in avanti bisogna fidarsi.
In questo caso personalmente ho fiducia nel fatto che le aziende abilitate a
rilasciare SC per la firma seguano le direttive e facciano generare la
chiave al token.


 validi legalmente.
E mica solo quello; l'accesso all'account PEC � subordinato all'utilizzo
di *credenziali* ora, essendo queste ultime "intangibili" (non essendo
un legale al momento non mi sovviene il termine corretto)  � possibile
ed anche facile che in caso di furto di identit� (credenziali in questo
caso) il legittimo proprietario NON si accorga del furto in questione
la cosa sarebbe diversa se l'accesso avvenisse tramite smartcard
in tal caso in caso di furto o smarrimento della stessa il legittimo
proprietario riuscirebbe ad accorgersene (anche perch� dovrebbe
controllare regolarmente la propria casella PEC) e potrebbe in tal
caso procedere a regolare denuncia
Immagina un delinquente che voglia "far del male a qualcuno";
il tizio potrebbe fare in modo da infettare il computer della vittima
con un malware, rubare in tal modo le credenziali PEC e quindi
mettere in piedi un meccanismo automatico che controlli quasi
continuamente il contenuto della casella PEC *SVUOTANDOLA*
a quel punto, la povera vittima, avrebbe mooolto da fare per
riuscire a dimostrare di essere estranea alla cosa e di non aver
effettivamente ricevuto n� tantomeno letto le comunicazioni
inviate alla sua casella PEC
Per dirla tutta, imHo la PEC non serve assolutamente a nulla se
non a permettere a chi fornisce servizi PEC di far soldi

 con un malware, rubare in tal modo le credenziali PEC e quindi
E mettiamoci pure un'altra cosetta; immagina un tot di PC sui quali
sono contenute *credenziali* PEC che vengano infettate dall'ennesimo
worm; a quel punto tali worms sarebbero in grado di pompare tonnellate
di "immondizia" (leggasi "spam") tramite PEC e, siccome non � pensabile
filtrare tale casella, ci si troverebbe in breve intasati di porcheria e
senza
la possibilit� di fare nulla; mi rendo conto che il problema �
"secondario"
ma non per questo credo sia trascurabile; ovviamente nel caso in cui la
PEC fosse utilizzabile soltanto previo inserimento di smartcard tale
tipo
di problematica sarebbe molto pi� limitato

 
Perchï¿œ tu non hai mai visto le smart card inserite perpetuamente
nel lettore, cosï¿œ quando serve ï¿œ giï¿œ a posto.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 il word; o solo testo o PDF.
Mi son letto un po' del thread, e faccio una domanda netta: certifica
SOLO il fatto che il contenuto non e' stato alterato lungo il percorso
fino alla consegna, o potrebbe invece certificare PROPRIO il contenuto?
Insomma, il meccanismo col quale il gestore PEC mittente firma il
messaggio col proprio certificato e' assimilabile a quello con cui
firmerei digitalmente il messaggio col un mio certificato di firma
digitale?
Cioe', con un esempio: se io non ho firma digitale, e spedisco un
messaggio PEC non firmato col mio certificato, e il destinatario per
ipotesi fa il "gioco" del famoso foglio bianco, se vado in giudizio con
una copia del mio messaggio, il magistrato puo' invocare il mio gestore
PEC mittente perche' certifichi il contenuto della mia email e si possa
cosi' dimostrare che ho spedito... quel che dichiaro di aver spedito?
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 cosi' dimostrare che ho spedito... quel che dichiaro di aver spedito?
Sï¿œ, se tu hai la ricevuta di quel che hai spedito, il destinatario non puï¿œ
affermare di aver ricevuto qualcosa di diverso da quanto da te asserito,
cosï¿œ come non puï¿œ negare di averlo avuto nella propria casella di PEC.
C'ï¿œ da dire che ovviamente una mail di PEC senza firma digitale non
garantisce che chi ha inviato il documento sia effettivamente chi dice di
essere, quindi ci si potrebbe trovare nella situazione in cui chi ha
ricevuto la mail non puï¿œ negare di averla ricevuta (perchï¿œ hai la ricevuta)
e non puï¿œ nemmeno negare che il suo contenuto sia quello effettivamente
inviato (perchï¿œ ï¿œ firmato dal gestore di PEC che ï¿œ riconosciuto come parte
affidabile), MA puï¿œ sempre dire di non aver intrapreso le azioni richieste
in quanto non aveva garanzia che tale mail fosse stata inviata realmente
dalla persona titolata a farlo.
In questo caso penso 
p.es
. alla lettera di dismissione di un servizio o di
recesso da qualche cosa, ecc.ecc.


 mail fosse stata inviata realmente dalla persona titolata a farlo.
Perfetto. Chiaro che il gestore PEC mittente si fa garante unicamente
dell'integrita' del messaggio, e non certo dell'identita' del mittente
e/o la certificazione di un determinato contenuto (la firma e' la sua
e uguale per tutti, mica e' quella del mittente, eh). Il "lavoro extra"
del gestore a cui facevo ipoteticamente riferimento e' solo in caso
venga chiamato in causa dal gestore per rifirmare il messaggio
pre-imbustatura e ottenere la stessa impronta, per cui a quel punto e'
assai improbabile che il messaggio contenesse qualcosa di diverso da
quanto asserito dal mittente. (e senno', diobono, a che cassio serviva
sta PEC? Solo a certificare l'avvenuta consegna e dire che la carta non
si e'  alluvionata lungo il percorso? Bah...)
Che e' certamente qualcosa in piu' della posta ordinaria: in giudizio,
li' e' tutto a discrezione del magistrato sentenziare la veridicita' del
contenuto...
Pero', il discorso "l'ho ignorata perche' nessuno mi garantiva che fosse
veramente chi diceva di essere" rischia IMHO in sede giudiziale di fare
acqua da tutte le parti e far sorridere il magistrato: quali sono i casi
in cui uno ha interesse a spedire una raccomandata AR fingendosi
un'altro?


 un'altro?
Quello no, ma 
p.es
. un caso concreto mi ï¿œ capitato l'altro giorno quando ho
dovuto inviare dei documenti firmati e non hanno accettato il fax o la PEC
ma hanno richiesto esplicitamente una raccomandata con i documenti firmati
(e c'era scritto nelle istruzioni).
In quel caso se io avessi fatto una scansione dei documenti e li avessi
inviati via PEC loro avrebbero potuto non accettarli ed ignorarli, ma
ovviamente qui si entra nel merito del contenuto, non del mezzo.


 un'altro?
Lunedï¿œ mattina.. il Sig. Rossi si presenta in azienda ma viene bloccato 
in portineria perchï¿œ risulta licenziato.
Salta fuori che la settimana precedente aveva inviato lettera di 
dimissioni via PEC, PECcato che lui non ne sapesse nulla!

jj wrote:


Dimissioni addirittura senza preavviso? :-)
Denuncia alla polizia postale, per almeno un reato: sostituzione di
persona.


 dimissioni via PEC, PECcato che lui non ne sapesse nulla!
Dovresti mostrarmi l'azienda che accetta le dimissioni senza un documento
autografo... o anche solo che accetti un documento firmato digitalmente.


 questa
A quanto ho capito, non certifica l'identita' del mittente, e ok. Non
certifica il contenuto, e ok. Ma quest'utlimo e' un "pro-forma" giacche'
si capisce che la firma del provider non ha quello scopo, ma di fatto
chiamando in causa il provider affinche' convalidi l'impronta si
stabilisce che quel che gli ha passato "un" utente pec... e' proprio
quello. :-)


 bella chiavetta per firmare.
Si', lungi da me dire che se ne possa fare a meno. :-)


 Se invece volessi usare una PEC come dovrei fare?
Piï¿œ che una raccomandata, l'art. 48 c.2 del Codice dell'Amm. digitale
(DLgs 82/05) dice che "La trasmissione del documento informatico per
via telematica, effettuata mediante la posta elettronica certificata,
equivale, nei casi consentiti dalla legge, alla notificazione per mezzo
della posta"
Spulciando nel cpc non ho perï¿œ trovato un definizione di
"notificazione"
Vorrei sapere: quali sono gli elementi certi che caratterizzano la
notifica postale? Contenuto, mittente, destinatario, data, ... ?
-- 
 pietro.b
 
http://pib.netsons.org