Predisposizione alla sottoscrizione (presso il SP)¶

Il processo prevede che il SP conosca il codice fiscale del firmatario; il SP quindi:

Consenso alla sottoscrizione (presso l’IdP)¶

L’IdP:

Al termine del processo qui descritto, salvo che l’utente non abbia scelto di avvalersi dei servizi di conservazione dei documenti firmati (cfr. §9), l’IdP rimuove dai propri sistemi il documento oggetto della sottoscrizione, nel pieno rispetto di quanto disposto dal Regolamento GDPR.

Formato del documento¶

Il documento predisposto dal SP per il processo di firma rispetta le specifiche PDF versione 1.7 o successive, profilo PDF/A-2a, secondo lo standard ISO/IEC 32000-1. Inoltre rispetta le seguenti caratteristiche tecniche:

1. il documento non richiede alcun controllo di accesso per essere aperto o modificato;
2. è consentita la modifica del documento esclusivamente per quanto concerne l’apposizione dei previsti sigilli elettronici PAdES;
3. né il contenuto del documento né i suoi metadati sono cifrati.

Convenzioni di nomenclatura dei documenti¶

Il nome del documento predisposto per la firma, di cui al §3.1 punto 2 è costituito da tre parti obbligatorie variabili, una parte facoltativa (indicata tra parentesi quadre “[” e “]”), più alcune parti fisse (in tondo):

usID_dataTora[_001].tmp.pdf

Il nome del documento firmato con SPID, di cui al §3.2 punto 11, è derivato dal precedente nome, senza il suffisso .tmp:

usID_dataTora[_001].pdf

In particolare:

• usID — Indivdua chi ha predisposto il documento per la firma. È una stringa costituita da un minimo di 3 a un massimo di 10 caratteri ASCII a scelta tra “01234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_”.
• data — È la data di creazione del documento predisposto per la firma (rispetto al fuso orario italiano), rappresentata da una stringa di 8 caratteri numerici così ripartiti:
  • quattro cifre per l’anno solare (da “2019” in poi),
  • due cifre per il mese dell’anno (da “01” per gennaio a “12” per dicmebre),
  • due cifre per il giorno del mese (da “01” a “31”);
• ora — È l’ora di creazione del documento predisposto per la firma, rispetto all’orario di sistema del SP, riportato al fuso orario italiano. È una stringa di 6 caratteri numerici così ripartiti:
  • due cifre per l’ora nell’arco delle ventiquattrore (da “00” per la mezzanotte alle “23”),
  • due cifre per il minuto primo (da “01” a “59”),
  • due cifre per il minuto secondo (da “01” a “59”);
• num — È un numero incrementale di 3 cifre che può essere facoltativamente utilizzato dal SP per differenziare più documenti che sono predisposti nell’arco del medesimo minuto secondo È facoltà del SP scegliere se usare sempre il campo aggiuntivo “_001” ovvero solo a partire dal secondo documento predisposto nel medesimo minuto secondo.

A titolo di esempio, il documento predisposto per la firma dall’Agenzia per l’Italia Digitale (abbreviativo unico: “AgID”), il 21 marzo 2019 all’ora locale 08:34:10, è “AgID_20190321T083410.tmp.pdf”. Il nome del corrispondente documento firmato con SPID (da una persona fisica presso il proprio IDP), sarà “AgID_20190321T083410.pdf”.

Apposizione del QSeal del Service Provider¶

Il SP appone il proprio QSeal mediante firma elettronica di tipo PAdES, non visibile (senza alcuna componente grafica), nei formati previsti dal Regolamento eIDAS e dalle conseguenti Decisioni di Esecuzione (UE).

Prima di apporre il proprio QSeal, il SP predispone il documento prevedendo adeguato spazio per contenere la componente grafica (o più componenti se richiede più firme) del QSeal che verrà apposto dall’IdP, il cui testo (cfr. §4.5) deve essere agevolmente leggibile, almeno fino a 256 caretteri ASCII di lunghezza.

Apposizione del QSeal dell’Identity Provider¶

A completamento del processo di firma, l’IdP appone il proprio QSeal nel documento che è, per ciascuna firma, graficamente localizzato nello spazio previsto dal SP e indicato nella richiesta di autenticazione (cfr. §5). La componente visibile del sigillo contiene il seguente testo:

Il %data% alle %ora%, %firmatario% ha confermato la volonta' di apporre qui la propria sottoscrizione ai sensi dell'art. 20, comma 1-bis del CAD.

Dove:

• La parte variabile %firmatario% è così costituita in base alla seguente alternativa (cfr. LL.GG. identità digitali uso professionale):
  • nel caso si utilizzi un’identità digitale non ad uso professionale, ovvero ad uso professionale per la persona fisica: il nome e cognome del firmatario (separati fra loro da uno spazio – esadecimale 0x20), seguiti da uno slash ascendente ‘/’ (esadecimale 0x2F), seguito dalla stringa ‘TINIT-’, seguito dal codice fiscale del firmatario; ad esempio: “Mario Rossi/TINIT-RSSMR064T30H501H”;
  • nel caso si utilizzi un’identità digitale per uso professionale della persona giuridica: il nome e il cognome del firmatario (fra di loro separati da uno spazio) seguiti da uno slash ascendente ‘/’, seguiti dalla denominazione dell’organizzazione, seguita da un altro slash ascendente ‘/’, seguito da un identificativo unico dell’organizzazione (privo di spazi in testa e in coda), valorizzato seguendo le alternative proposte nel §4.5, punto 1.a. Ad esempio, nel caso di Mario Rossi che utilizza l’identità digitale uso professionale della persona giuridica ‘Agenzia per l’Italia Digitale’: “Mario Rossi/Agenzia per l'Italia Digitale/TINIT-97735020584”.
• La parte variabile %data% contiene la data di sottoscrizione, espressa come una stringa di 8 caratteri numerici separati in tre gruppi da uno slash ascendente ‘/’ e ripartiti come:
  • due cifre per giorno del mese (da “01” a “31”),
  • due cifre per il mese dell’anno (da “01” per gennaio a “12” per dicembre),
  • quattro cifre per l’anno solare (da “2019” in poi).
• La parte variabile %ore% contiene l’ora di sottoscrizione (sempre riportata al fuso orario italiano), espressa come una stringa di 8 caratteri numerici separati in tre gruppi da due-punti ‘:’ e ripartiti come:
  • due cifre per l’ora nell’arco delle ventiquattrore (da “00” per la mezzanotte a “23”),
  • due cifre per il minuto primo (da “00” a “59”),
  • due cifre per il minuto secondo (da “00” a “59”).

Il documento può contenere già una o più firme elettroniche qualificate o sigilli elettronici qualificati, o può già essere stato oggetto di altri processi di sottoscrizione come previsti dalle presenti Linee guida.

La richiesta del SP può prevedere più firme dello stesso soggetto sul documento; in tal caso l’IdP appone altrettanti sigilli.

Certificati qualificati di sigillo elettronico¶

SP e IdP si dotano, presso un QTSP, di un certificato elettronico qualificato per la creazione di sigilli elettronici.

Detti certificati qualificati sono conformi alle raccomandazioni emanate con le LL.GG. sui certificati elettronici (cit.), allo standard X.509 versione 3, e contengono le seguenti informazioni aggiuntive:

1. Il campo SubjectDN, contenente i seguenti attributi:
   1. serialNumber (ᴏɪᴅ 2.5.4.5) — contiene per gli IdP e i SP, alternativamente, secondo il seguente ordine:
      • la partita IVA indicata con il prefisso ‘VAT’, come prescritto dal §5.1.4 punto 1 della norma ETSI EN 319-412-1 (es. “VATIT-12345678901”);
      • il codice fiscale indicato con il prefisso ‘CF:’, come prescritto dal §5.1.4 punto 3 della suddetta norma (es. “CF:IT-01234567890”);
      • il numero assegnato dal Registro Imprese, indicato con il prefisso ‘NTR’, come prescritto dal §5.1.4 punto 2 della suddetta norma (es. “NTRIT-1234567890”);
      • per gli SP pubblici, il codice IPA, così come risulta nel campo ipaEntityCode del registro SPID, preceduto dal prefisso ‘PA:’, come prescritto dal §5.1.4 punto 3 della suddetta norma (es. “PA:IT-agid”).
   2. commonName (ᴏɪᴅ 2.5.4.3) — contenente, mediante un elemento di tipo dNSName, il nome di dominio – privo di qualsiasi carattere wildcard – di cui al punto 5.
2. Il campo CertificatePolicies (ᴏɪᴅ 2.5.29.32), contenente i seguenti attributi:
   1. PolicyIdentifier — valorizzato come:
      • spidSignature (ᴏɪᴅ 1.3.76.16.4.11);
   2. una limitazione d’uso indicata mediante la presenza di un campo userNotice (ᴏɪᴅ 2.5.29.49), di tipo explicitText, valorizzato con la seguente stringa bilingue: “Certificato usabile solo per il processo di sottoscrizione di cui all'art.20 del CAD/This certificate may be used only for elecrronic signing pursuant to the Italian Digital Administration Code, art.20.”.
3. keyUsage (ᴏɪᴅ 2.5.29.15) — contenente i valori digitalSignature e keyEncipherment, cioè i bit #0 e #2, valorizzati a 1, come da specifica RFC 5280.
4. extendedKeyUsage (ᴏɪᴅ 2.5.29.16) — contenente sia l’elemento id-kp-serverAuth (ᴏɪᴅ 1.3.6.1.5.5.7.3.1) che l’elemento id-kp-clientAuth (ᴏɪᴅ 1.3.6.1.5.5.7.3.2).
5. subjectAltName (ᴏɪᴅ 2.5.29.17) — valorizzata con elemento unico di tipo dNSName e contenente il dominio dell’URL completo (così come riportato nel registro SPID) presso il quale l’ente federato rende disponibile, agli enti federati della tipologia opposta, il servizio di trasferimento sicuro di cui al §5.2.

Metadata nel registro SPID¶

Qualora un IdP, un SP ovvero un soggetto aggregatore offra il servizio in oggetto, il relativo metadata pubblicato nel registro SPID contiene l’estensione <SignatureArt20> (namespace spid) come figlio dell’elemento <Extensions> (namespace samlp), al cui interno è specificata la modalità tecnica tramite la quale l’ente federato espone tale servizio.

La suddetta modalità è costituita da:

• l’elemento <FileTransferService> (namespace spid), dotato del seguente attributo:

  • Location — URL completo (comprensivo del relativo schema HTTPS) ove l’ente rende disponibile il sistema di trasferimento sicuro dei documenti di cui al §5.2.

Si veda a tale scopo il seguente esempio:

<md:EntityDescriptor>
    <ds:Signature>...</ds:Signature>
    ...
    <samlp:Extensions
          xmlns:spid="https://spid.gov.it/saml-extensions">
        <spid:SignatureArt20>
            <spid:FileTransferService
                  Location="https://indirizzo/al/DataIO/" />
        </spid:SignatureArt20>
    </samlp:Extensions>
    <md:Organization>...</md:Organization>
    ...
</md:EntityDescriptor>

Qualora l’elemento <SignatureArt20> non sia presente nel metadata, è da intendersi che l’ente federato non offre tale servizio.

Il metadata dei SP che offrono il servizio in oggetto contiene, all’interno dell’<EntityDescriptor> (namespace md):

• Un Attribute Consuming Service specifico:
  1. il cui attributo index è valorizzato con il valore “77”;
  2. privo di alcun attributo nel servizio (nessun elemento <RequestedAttribute>);
  3. contenente almeno un elemento figlio <ServiceName> (namespace md), valorizzato con il nome del servizio in lingua italiana: “Sottoscrizione elettronica ex art.20 CAD”.

Il metadata del SP comprende dunque la seguente struttura:

<md:EntityDescriptor>
    ...
    <md:SPSSODescriptor>
        <md:AttributeConsumingService index="77">
            <md:ServiceName xml:lang="it">
                Sottoscrizione elettronica ex art.20 CAD
            </md:ServiceName>
        </md:AttributeConsumingService>
    ...
    </md:SPSSODescriptor>
</md:EntityDescriptor>

Tutte le evidenze informatiche SAML che si riferiscono al servizio in oggetto (descritte sia qui che al §5.1) indicano il riferimento URN https://spid.gov.it/saml-extensions al namespace XML dell’Agenzia riservato a SPID — nel proprio elemento radice, ovvero in tutti i singoli elementi interessati (qui genericamente indicati come <Element> di namespace ns), come riportato nell’esempio sotto:

<ns:Element xmlns:spid="https://spid.gov.it/saml-extensions">
    ...
</ns:Element>

SAML¶

La richiesta di autenticazione SAML si riferisce, nell’elemento <AuthnRequest> (namespace samlp), all’attributo AttributeConsumingServiceIndex corrispondente all’Attribute Consuming Service specifico, di indice “77”, introdotto al §4.6.

Le richieste e risposte di autenticazione SAML impiegano session ID, nei loro rispettivi attributi ID, valorizzati come stringhe uniche che cominciano con sig-. Le richieste e risposte di autenticazione contengono entrambe un’estensione <Signature> (namespace spid) contenuta nella sezione prevista dallo standard per le estentioni SAML. I metadati sopra elencati sono realizzati mediante i seguenti elementi:

• punti a. e d. tramite elemento <Filename> (namespace spid), contenente il nome del file del documento, comprensivo della corretta estensione, composto come descritto in §4.2;
• punti b. e f. tramite elemento <DigestValue> (namespace ds), contenente un’impronta rappresentata applicandole la trasformazione Base64 (cfr. RFC 4648);
• punti c. e g. tramite elemento <DigestMethod> (namespace ds), contenente la codifica W3C della funzione di hash utilizzata per il calcolo dell’impronta del documento;
• l’identificativo univoco di sessione è indicato nell’attributo ID dell’elemento <AuthnRequest> per la richiesta di autenticazione, il cui valore combacia con quello dell’attributo InResponseTo dell’elemento <Response> per la corrispondete risposta di autenticazione.

Qui sotto è riportato un esempio di richiesta di autenticazione SAML, comprensiva dell’Attribute Consuming Service specifica e dell’elemento <Signature> (namespace spid) per la richiesta di autenticazione relativa a un documento in formato PDF predisposto dal SP e successivamente inviato all’IdP per la sottoscrizione.

<samlp:AuthnRequest
      AttributeConsumingService="77"
      Destination="https://url-IdP-destinatario"
      ID="sig-SessionID"
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
      xmlns:spid="https://spid.gov.it/saml-extensions"
      xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
    <saml:Issuer>https://url-SP-inviante</saml:Issuer>
    ...
    <samlp:Extensions>
        <spid:Signature>
            <spid:Filename>AgID_YYYYMMDDThhmmss.tmp.pdf</spid:Filename>
            <ds:DigestMethod Algorithm="http://funzione_hash" />
            <ds:DigestValue>ImprontaDocumento1</ds:DigestValue>
        </spid:Signature>
        <spid:Signer>
            <saml:Attribute
                  xmlns:xs="http://www.w3.org/2001/XMLSchema"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                  Name="fiscalNumber">
               <saml:AttributeValue xsi:type="xs:string">
                   CodiceFiscaleFirmatario
               </saml:AttributeValue>
           </saml:Attribute>
        </spid:Signer>
    </samlp:Extensions>
</samlp:AuthnRequest>

Qui sotto è riportato un esempio di elemento <Signature> per la risposta di autenticazione SAML relativa alla richiesta di autenticazione di cui al precedente esempio, ove l’IdP comunica al SP i metadati del documento firmato con SPID.

<samlp:Response
      xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
      Destination="https://url-SP-destinatario"
      ID="_ResponseID"
      InResponseTo="sig-SessionID">
    <saml:Issuer>https://url-IdP-inviante</saml:Issuer>
    ...
    <samlp:Extensions
          xmlns:spid="https://spid.gov.it/saml-extensions">
        <spid:Signature>
            <spid:Filename>AgID_YYYYMMDDThhmmss.pdf</spid:Filename>
            <ds:DigestMethod Algorithm="http://funzione_hash" />
            <ds:DigestValue>ImprontaDocumento2</ds:DigestValue>
        </spid:Signature>
    </samlp:Extensions>
</samlp:Response>

Sistema di trasferimento sicuro dei documenti¶

Ogni ente federato si dota di un sistema di trasferimento dedicato ai documenti oggetto delle presenti Linee guida, costituito da uno storage dedicato, un protocollo di comunicazione sicura che garantisce un adeguato livello di confidenzialità, integrità e disponibilità, e da un sistema di gestione dei file ricevuti.

L’interfaccia applicativa fornita dal protocollo di comunicazione per il trasferimento di documenti dall’esterno è resa nota da ciascun ente federato verso tutti gli enti federati, mediante l’URL che l’ente medesimo pubblica nel metadata SPID e il cui dominio è contestualmente riportato nei campi commonName e subjectAltName del proprio certificato qualificato di sigillo elettronico, di cui al §4.5, punti 1.b e 5. Tale URL indica esplicitamente il protocollo di comunicazione sicuro, i cui dettagli sono dati in §5.2.1.

Il sistema di trasferimento è, nella sua interezza, protetto da misure di sicurezza logica, fisica e amministrativa conformi almeno alle LL.GG. sulle misure minime di sicurezza. Esso è inoltre adeguatamente protetto logicamente affinché solamente gli enti federati possano trasferire file mediante uno dei seguenti due flussi:

1. il sistema dell’IdP è configurato per la sola ricezione di evidenze informatiche provenienti dagli SP in modalità push (cioè con trasferimenti iniziati in upstream dal SP);

2. il sistema del SP è configurato per la sola ricezione di evidenze informatiche provenienti dagli IdP in modalità push (cioè con trasferimenti iniziati in upstream dall’IdP).

Il sistema di trasferimento possiede, inoltre, le seguenti caratteristiche:

1. SP e IdP controllano che ogni file creato presso il proprio storage soddisfi quanto prescritto nel §4.2.
2. L’IdP rimuove dallo storage i file ricevuti per i quali non sia pervenuta, entro un tempo limite di 10 secondi, una richiesta di autenticazione proveniente dal SP.
3. IdP e SP verificano l’integrità dei documenti ricevuti ricalcolandone l’impronta e confrontandola con quella contenuta, rispettivamente, nella richiesta e nella risposta di autenticazione che le accompagnano.
4. IdP e SP verificano l’autenticità dei QSeal della controparte e l’integrità del documento ricevuto.

{
    "typ" : "JOSE",
    "alg" : "ES256",
    "x5c" : "Certificato/codificato+Base64",
    "crit": ["x5c"]
}

{
    "jti" : "uuid1",
    "iss" : "https://entityId-SP-inviante",
    "aud" : "https://entityId-IdP-ricevente",
    "iat" : 1563235200,
    "sessionID": "sig-sessionID",
    "filename" : "AgID_20190321T083410.tmp.pdf",
    "cty" : "pdf",
    "digest" : {
        "method" : "schema://funzione_hash",
        "value" : "ImprontaDocumento1"
    },
    "signatures" : [
        {
            "id"  : "sig1",
            "pag" : 3,
            "pos" : {
                "llx":89.9446,
                "lly":719.976,
                "urx":239.978,
                "ury":751.299
            },
            "req" : true
        },
        {
            "id"  : "sig2",
            "pag" : 7,
            "pos" : {
                "llx":240.734,
                "lly":686.297,
                "urx":390.768,
                "ury":718.421
            },
            "req" : false
        }
    ],
    "payload" : "BlobDocumento1 + [...] + codificatoBase64"
}

{
    "jti" : "uuid2",
    "iss" : "https://entityId-IdP-inviante",
    "aud" : "https://entityId-SP-ricevente",
    "sub" : "Mario Rossi/CF:IT-RSSMR064T30H501H",
    "iat" : 1563235220,
    "sessionID": "sig-sessionID",
    "filename" : "AgID_20190321T083410.pdf",
    "cty" : "pdf",
    "digest" : {
        "method" : "http://funzione_hash",
        "value" : "ImprontaDocumento2"
    },
    "ref" : [
        {
            "id"  : "sig1",
            "signed" : true
        },
        {
            "id"  : "sig2",
            "signed" : false
        }
    ],
    "payload" : "BlobDocumento2 + [...] + codificatoBase64"
}

Obblighi in capo agli Identity Provider¶

Gli IDP che offrono servizi di sottoscrizione di cui alle presenti Linee guida, si impegnano:

• a rendere disponibile ai SP il proprio servizio e garantirne tutte le caratteristiche di confidenzialità, integrità e disponibilità;
• salvo quanto previsto al §9, a non conservare i documenti oggetto della firma con SPID che sono depositati presso i propri sistemi, rimuovendoli in modo sicuro al termine del trattamento.

Obblighi in capo ai Service Provider¶

I SP che intendono far utilizzare la funzione di firma oggetto del presente provvedimento, hanno l’obbligo improrogabile di consentire agli utenti la sottoscrizione con firma elettronica qualificata.