Richiesta chiarimento su Avviso nr. 29 – Versione 2.0

Buonasera a tutti,

volevo chiedere un parere relativo all’avviso in oggetto, in particolare sulla struttura dei certificati elettronici dei Service Provider.

A pagina 1 si afferma quanto segue:

Nel campo SubjectDN:
a. commonName (OID 2.5.4.3) — EntityID del SP, così come riportato nell’attributo entityID del tag XML del metadata del SP.

Considerando però quanto riportato nell’Avviso nr. 6 è possibile che nel medesimo file di metadati siano indicati più nodi di erogazione dei servizi, e potenzialmente ciascuno con un proprio certificato di firma delle asserzioni.

Fino ad oggi, in situazioni analoghe a quella descritta, abbiamo valorizzato il commonName del certificato con un identificativo che consentisse di risalire al nodo di erogazione dei servizi a cui faceva riferimento. Seguendo le indicazioni riportate nell’avviso nr. 29 sembra che ciò non sia più possibile e che quindi non sia più possibile a posteriori risalire al nodo di erogazione a cui fa riferimento il certificato.

L’alternativa sarebbe quella di utilizzare un solo certificato di firma per tutti i nodi di erogazione dei servizi, cosa che in alcuni casi potrebbe essere problematica, visto che sarebbe necessario utilizzare la medesima parte privata per tutti i nodi di erogazione dei servizi.

Saluti.

Salve @damikael,
mi ricollego alla richiesta di @Angelo_Rossini estendendone il raggio di azione con i seguenti quesiti su quanto scritto nel documento:

Struttura dei certificati elettronici del SP

  • ho dei dubbi sulle modalità con cui sia possibile procedere alla valorizzazione dei campi organizationIdentifier e policyIdentifier. Hai qualche suggerimento circa il tool da utilizzare per la generazione del certificato e che permetta di valorizzare tali campi?

Struttura dei metadata dei Service Provider

  • una volta valorizzato il campo ContactPerson e correttamente firmato il metadata con i certificati di cui al punto precedente, è necessario effettuare modifiche sul software del SP per includere il campo all’interno della sessione SAML? E se si, avete in previsione un aggiornamento della libreria SPID-PHP, che includa tale funzionalità?

Grazie mille

Aggiornamento
Struttura dei certificati elettronici del SP
Abbiamo ricreato il certificato con il campo organizationIdentifier correttamente valorizzato.
Tuttavia riscontriamo difficoltà ad interpretare come valorizzare il campo policyIdentifier. In particolare abbiamo inserito nel file di configurazione della CA
[polsect]
policyIdentifier = 1.3.76.16.4.2.1

è sufficiente o è necessario inserire spid-publicsector-SP ?

Buongiorno.
Lo scenario da lei delineato è invero abbastanza comune: un singolo Service Provider (SP) che ha più servizi gestiti a loro volta da fornitori tecnologici diversi. La soluzione di ciascuno di questi fornitori è dotata di una chiave privata differente (non necessariamente diversa da SP a SP) con cui il fornitore sigilla le request per il/i servizio/i fornito/i per conto del SP.

Seguendo la normativa europea di riferimento relativa ai certificati elettronici (ETSI EN319-412, in 5 parti), che a sua volta richiama lo standard internazionale ITU-T X.520, l’estensione commonName non è adatta allo scopo da lei indicato. La normativa prevede, infatti, che tale estensione identifichi, nell’ambito d’uso del certificato o del directory service, il soggetto del certificato: cioè il SP o l’Aggregatore. In SAML e, perciò, anche nell’ambito SPID, l’EntityID è l’identificativo di riferimento di tali soggetti, proprio perché è il nome con cui ciascun ente della federazione si presenta, “tecnicamente,” verso gli altri.

L’Avviso SPID №29 per i SP (così come, mutatis mutandis, l’Avviso SPID №19 per gli Aggregatori) non vieta l’utilizzo di altre estensioni “X.509,” purchè queste non siano in antitesti con la normativa SPID.

Bisogna anche considerare che non deve esserci alcuna presunzione di corrispondenza uno-a-uno tra i servizi nel metadatada SAML (<AttributeConsumingService>) e i certificati di sigillo delle request (<KeyDescriptor> con uso signing), perciò l’associazione dei certificati ai servizi, non essendo in generale monodroma, non andrebbe etichettata in maniera così rigida sui certificati: cosa succederebbe se, a un certo punto, il medesimo certificato venisse usato per più servizi/nodi diversi?
Come già segnalato, gli Aggregatori full (ex Avviso SPID №19) e, più in generale, vari fornitori tecnologici, riusano il proprio certificato per più soggetti (Aggregati o SP) diversi.

Tutto ciò premesso, per distinguere fra loro eventuali certificati multipli utilizzati dallo stesso soggetto (SP, Aggregatore full o Aggregato light che sia), inclusa la possibilità di associarli a nodi/servizi diversi, consigliamo di adottare diverse strategie alternative ― tutte, peraltro, già previste in tal senso dagli standard tecnici:

  • uno o più tra i tag <KeyName> o <X509SubjectName> nel metadata SAML stesso (discendenti del tag <KeyDescriptor>) — come previsto da standard XML-DSIG, l’associazione avverrebbe così nel metadata anziché nel certificato.
  • estensione uniqueIdentifier nel SubjectDN — da norma X.520, disambigua “oggetti” diversi (i servizi SPID) nell’ambito del medesimo soggetto del certificato (un SP o Aggregato);
  • estensione dnQualifier nel SubjectDN — da norma X.520, serve a disambiguare lo stesso soggetto del certificato (SP o Aggregato) in contesti con directory service diversi (assimilabili ai diversi nodi SAML o a partner tecnologici multipli);
  • SKI (Subject Key Identifier) — l’identificativo unico della chiave del soggetto;
  • estensione serialNumber del certificato (non quella nel SubjectDN) — il “numero seriale” vero e proprio del certificato;
  • hash del certificato — il modo naturale di identificare e distinguere biunivocamente più evidenze informatiche, anche al di fuori dell’ambito di riferimento.

Di tutte queste soluzioni, quella che adotterei nel suo caso è la prima in quanto, volendo associare un certificato ad un servizio (AsCS), l’associazione è fatta nel metadata stesso e consente anche di ripetere più volte lo stesso identificativo qualora questo sia associato a diversi nodi/servizi.

Per quanto riguarda la valorizzazione delle estensioni organizationIdentifier e policyIdentifier, si tratta di estensioni specifiche previste dallo standard X.509 (RFC-5280) e seguenti (in particolare l’ITU-T X.520), perciò andrà bene qualunque tool che supporti lo standard nella sua interezza (e non vincoli i certificati creati solamente ad un ristretto numero di estensioni predeterminate dal software).

È fondamentale conoscere gli ᴏɪᴅ di riferimento delle estensioni (che indichiamo sempre esplicitamente negli Avvisi). Questi permettono, infatti, di inserirle nel certificato anche nei seguenti casi:

  • il tool adottato non riconosca già, in automatico (cioè mediante il solo nome) un’estensione “standard” (come organizationIdentifier − ᴏɪᴅ 2.5.4.97),
  • va adottata un’estensione “custom” di AgID, il cuo nome non può essere già noto ai tool (come spid-*sector-* − radice dell’ᴏɪᴅ 1.3.76.16.4.*).

Buonasera @walter-arrighetti,

ci servirebbe un chiarimento relativo alla Versione 3.0 dell’Avviso nr. 29.

relativamente ai metadati, è specificato quanto segue:

entityID (1 occorrenza) — Attributo valorizzato con l’EntityID, così come riportato nell’estensione commonName del certificato elettronico del SP. In caso il SP svolga più attività – come ad esempio quella di SP pubblico e di SP privato – si dota di metadata SAML differenti, ciascuno con un diverso EntityID.

Mentre relativamente al certificato è richiesto quanto segue:

commonName (OID 2.5.4.3) — La denominazione che valorizza l’estensione organizationName, eventualmente senza esplicitazione degli acronimi, come riportata nel tag XML del metadata del SP (esempio: “AgID”).

Se così fosse nel caso indicato, ad esempio, entityID dovrebbe essere valorizzato a “AgID”.

Si tratta di un refuso relativo a quanto riportato nella versione 2.0 dell’avviso? In tal caso la versione corretta dell’indicazione relativa ai metadati dovrebbe essere questa?

entityID (1 occorrenza) — Attributo valorizzato con l’EntityID, così come riportato nell’estensione uri del certificato elettronico del SP. In caso il SP svolga più attività – come ad esempio quella di SP pubblico e di SP privato – si dota di metadata SAML differenti, ciascuno con un diverso EntityID.

Grazie,

Angelo Rossini.