[DOC_OP_02] 1. Introduzione

Consultazioni pubbliche LG interoperabilità tecnica delle PA
1

I pattern di sicurezza definiscono le modalità per assicurare che le interazioni tra fruitore ed erogatore siano realizzate nel rispetto delle specifiche esigenze di sicurezza determinate dalla natura delle transazioni realizzate e dalle prescrizioni normative che hanno determinato le stesse…

…continua a leggere su docs.italia.it

2

Come si qualifica la direct trust? Probabilmente sarebbe opportuno dare delle indicazioni più operative sul tipo di ‘fiducia’ e le modalità di scambio di chiavi/certificati e quando usare o meno certificati self signed.

3

Il tema della costruzione dei trust sarà oggetto delle LG Sicurezza in fase di redazione.

1 Mi Piace
4

Benfatto! Grazi per l’ottimo lavoro!

5

Sempre sul trust dei certificati, ma spero come indicato le LG Sicurezza possano chiarire, come si consiglia di procedere, oppure quali delle seguenti possibilità è da ritenere non consigliabile?

• In fase di abilitazione all’interoperabilità viene comunicato da parte dell’utilizzatore il certificato che verrà utilizzato
• In fase di abilitazione all’interoperabilità l’erogatore consegna al fruitore il certificato che dovrà utilizzare
• Nessun trust di certificati, ma l’erogatore validerà la CA del certificato utilizzato (ad esempio verificando se questa è riconosciuta AgID)

6

Ciao @fenzad,
in merito alle tue gli schemi previsti sono due:
a. costruire trust su certificati emessi da CAQ (Certification Autority qualificate AgID ai sensi del Regolamento CE eIDAS)
b. costruzione trust tra erogatore e fruitore con garanzie di gestione di processi (i) generazione dei certificati, (ii) revoca dei certificati e (iii) deployment dei certificati

In breve:

  • la tua ipotesi 1 risulta troppo riduttiva, in quanto non si preoccupa di gestire il ciclo di vita dei certificati ed in particolare il problema della revoca
  • la tua ipotesi 2, se intendi che l’erogatore genera le chiavi pubbliche e private per formare il certificato, direi di no in quanto non assicura le due parti (l’erogatore conosce la chiave private del fruitore e potrebbe maliziosamente impersonare lo stesso)
  • la tua ipotesi 3 corrisponde alla precedente a)
7

Grazie mille della tua super celere risposta @vintraAgID!
E’ evidente che la mia ipotesi 3 (corrispondente al caso a) è a sto punto quella più facilmente percorribile, perchè (a meno che non sei un CA) il caso b si fa arduo.
Questo comunque comporterebbe sempre ad ogni request la valorizzazione nel jwt header del parametro x5c, che comporterebbe un po’ di overhead, in quanto poi andrebbe validata la CA. Sbaglio qualcosa?

8

@fenzad la scelta tra le due possibilità è, in breve, determinata dal trade -off tra il numero di soggetti coinvolti e i costi per l’acquisto dei certificati.

In relazione alla tua osservazione sull’overhead non è possibile negarlo, ma mi preme evidenziarti che nelle LG è stato immaginato un meccanismo di continua evoluzione delle stesse (vedi quanto indicato in https://docs.italia.it/italia/piano-triennale-ict/lg-modellointeroperabilita-docs/it/bozza/doc/00_Linee%20guida%20interoperabilità%20tecnica/07_pattern-e-profili-di-interoperabilità.html) che a partire dalle esigenze delle PA - gli stakeholder delle LG - permette di declinare, fatta salva la necessità di assicurare gli opportuni livelli di sicurezza (integrità, certezza della fonte, non ripudiabilità, … ) delle comunicazioni, ulteriori pattern per questo ti invito a restare nella community per darci il tuo contributo

Grazie