IL CERTIFICATO DI ATTRIBUTI

Un certificato di attributo ( Attribute Certificate o AC ) è un certificato simile ad un PKC. La differenza sostanziale sta nel fatto che un AC non riporta la chiave pubblica del titolare, ma solo uno o più attributi che specificano gruppo di appartenenza, ruoli, funzioni, etc...

Sintassi e specifica dei campi

La sintassi per gli AC è definita nello Standard X.509 come segue:

 
AttributeCertificate ::= SEQUENCE {
 acinfo  AttributeCertificateInfo,
 signatureAlgorithm AlgorithmIdentifier, 
 signatureValue BIT STRING
}
 
AttributeCertificateInfo ::= SEQUENCE {
 version AttCertVersion -- version is v2,
 holder Holder, 
 issuer AttCertIssuer,
 signature AlgorithmIdentifier,
 serialNumber CertificateSerialNumber,
 attrCertValidityPeriod AttCertValidityPeriod,
 attributes SEQUENCE OF Attribute,
 issuerUniqueID UniqueIdentifier OPTIONAL,
 extensions Extensions OPTIONAL
}
 
AttCertVersion ::= INTEGER { v2 (1) }
 
Holder ::= SEQUENCE {
 baseCertificateID [0] IssuerSerial OPTIONAL,
 -- the issuer and serial number of 
 -- the holder's Public Key Certificate
 entityName [1] GeneralNames OPTIONAL,
 -- the name of the claimant or role
 objectDigestInfo [2] ObjectDigestInfo OPTIONAL
 -- used to directly authenticate the holder,
 -- for example, an executable
}
 
ObjectDigestInfo ::= SEQUENCE {
 digestedObjectType ENUMERATED {
 publicKey (0),
 publicKeyCert (1),
 otherObjectTypes (2) },
 -- otherObjectTypes MUST NOT 
 -- be used in this profile
 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
  digestAlgorithm AlgorithmIdentifier,
 objectDigest BIT STRING
}
 
AttCertIssuer ::= CHOICE {
 v1Form GeneralNames, -- MUST NOT be used in this
    -- profile
 v2Form [0] V2Form  -- v2 only
}
 
V2Form ::= SEQUENCE {
 issuerName GeneralNames OPTIONAL,
 baseCertificateID [0] IssuerSerial OPTIONAL,
 objectDigestInfo [1] ObjectDigestInfo OPTIONAL
 -- issuerName MUST be present in this profile
 -- baseCertificateID and objectDigestInfo MUST NOT
 -- be present in this profile
}
 
IssuerSerial ::= SEQUENCE {
 issuer GeneralNames,
 serial CertificateSerialNumber,
 issuerUID UniqueIdentifier OPTIONAL
}
 
AttCertValidityPeriod ::= SEQUENCE {
 notBeforeTime GeneralizedTime,
 notAfterTime GeneralizedTime
}
 
Attribute ::= SEQUENCE {
 type AttributeType,
 values SET OF AttributeValue
 -- at least one value is required 
}
 
AttributeType ::= OBJECT IDENTIFIER
 
AttributeValue ::= ANY DEFINED BY AttributeType

I campi nel certificato di attributo includono:

Version: la versione del certificato;

Holder: l’identità del titolare del certificato, cioè l’identità dell’entità a cui gli attributi sono associati. Questo campo è una sequenza che permette tre differenti sintassi:

	baseCertificateID: dovrebbe essere usata negli ambienti in cui l’autenticazione è basata sull’uso di PKC X.509. Con questa opzione il numero seriale e l’emittente del PKC del titolare devono essere identici al campo holder dell’AC;
	entityName: potrebbe essere usata negli ambienti in cui l’autenticazione non avviene tramite il PKC del titolare, ma ad esempio tramite lo scambio sicuro di username e password. In questo caso, lo stesso username può essere usato come titolare dell’AC e dei privilegi o altre informazioni presenti negli attributi dell’AC;
	ObjectDigestInfo: consente di legare un AC direttamente ad un oggetto, calcolando il valore hash dell’oggetto stesso ed inserendolo nel campo. Finora sono definiti solo due tipi di classificazione: valore hash della chiave pubblica e valore hash del PKC, sebbene non sia vietato l’uso di altre classificazioni.

L’RFC 3281 raccomanda l’uso di una sola di queste opzioni per ogni AC, per evitare possibili confusioni.

Issuer: l’identità di chi ha emesso il certificato di attributo. La scelta “v2Form” deve contenere uno ed un solo GeneralName (DNSName, directoryName, uniformResourceIdentifier e IPAddress) nel campo issuerName;

Signature: l’identificatore dell’algoritmo (cioè l’ObjectIdentifier, o OID, più altri parametri associati) usato per calcolare la firma digitale sul certificato. Un OID è rappresentato come una sequenza di interi separati da punti e fornisce una rappresentazione unica per un dato oggetto. Ad esempio, il campo potrebbe includere il valore 1.2.840.113549.1.1.5 che è l’OID per SHA-1 con RSA e che indica che la firma digitale è un valore hash SHA-1, cifrato con l’RSA;

SerialNumber: un numero intero positivo unico, assegnato al certificato dal suo emittente;

AttrCertValidityPeriod: il periodo di validità del certificato di attributo sottoforma di due date che definiscono l’ intervallo di tempo entro cui gli attributi sono validi;

Attributes: informazioni sul titolare dell’AC, definito come una sequenza di attributi, ognuno dei quali è a sua volta una coppia contenente il tipo dell'attributo e il valore dell'attributo. Quindi lo Standard X.509 consente di specificare, tramite un solo AC, più attributi per lo stesso titolare. Ad esempio, una stessa persona potrebbe avere un AC che ne attesta la qualifica di membro di un circolo di golf, un altro che lo qualifica come amministratore delegato di una data società e così via;

IssuerUniqueID: informazioni addizionali per localizzare l’emittente dell’AC. Non deve essere usato a meno che non sia usato anche nel PKC dell’emittente stesso;

Extensions: informazioni aggiuntive sul certificato di attributo. Tra i possibili valori ci sono:

	Audit Identity: rende impossibile derivare l’identità del titolare dell’AC senza l’aiuto dell’emittente dell’AC stesso;
	Attribute Certificate Targeting: usata per identificare il numero di server e servizi che accettano l’AC;
	Authority Key Identifier: identificatore unico della chiave che dovrebbe essere usato per verificare la firma digitale dell’AC;
	Authority Information Access: usata per controllare lo stato di revoca di un certificato;
	CRL Distribution Points: indica la posizione della CRL dove trovare le informazioni di revoca dell’AC;
	No Revocation Available: permette all’emittente di un AC di indicare che nessuna informazione di revoca sarà resa disponibile per quell’AC.

Esempio di AC

Per chiarire meglio l’uso dei campi, mostriamo il seguente esempio di AC:

AttributeCertificateInfo ::= SEQUENCE
{
	version	v2
	owner	c=IT, O=Policlinico, CN=Rossi Mario
	issuer	c=IT, O=Policlinico, CN=Ufficio Ruoli
	signature	1.2.840.113549.1.1.5
	serialNumber	1234
	validity	01/01/2004 – 01/01/2005
	attributes	title=Radiologo
	issuerUniqueID	22431
	extensions	……
}

Come si vede, Mario Rossi è un radiologo del Policlinico e questa funzione gli è stata attribuita dall’Ufficio Ruoli.

Attribute Authority

Come un PKC, anche l'AC è emesso da una terza parte, detta Attribute Authority o AA. Quest'ultima, come la CA, assegna gli attributi, emette gli AC e li rende disponibili ad utenti ed applicazioni attraverso un apposito sistema online. Oltre ad emettere gli AC, un AA ha anche il compito di sospenderli, revocarli e rimuoverli alla scadenza, se possibile.

La AA non è propriamente una “trusted third party”, in quanto non necessariamente è “third” nè “trusted”. Infatti, essa non svolge il suo compito in virtù del fatto di essere un ente affidabile, ma piuttosto perché ha l’autorità di assegnare e modificare gli attributi dei suoi utenti. In altre parole, il fatto di essere un’autorità per creare un privilegio è esso stesso un privilegio e, come tale, è soggetto a cambiamenti. Inoltre, solo un ente che abbia una conoscenza “intima” degli attributi degli utenti può svolgere il ruolo di AA. Ad esempio, per i dipendenti di un’azienda la AA non può essere che l’azienda stessa; per i clienti di un servizio la AA non può essere che l’erogatore del servizio; per gli appartenenti ad un ordine professionale la AA non può essere che l’ordine professionale stesso.

Durata degli attributi

La durata degli attributi è stata classificata in relazione al periodo di validità del PKC di riferimento:

attributi “a vita”, la cui validità segue il titolare per tutta la sua vita, salvo revoche in casi eccezionali;

attributi “a lunga durata” , la cui validità supera quella del PKC di riferimento;

attributi “di breve durata”, la cui validità è inferiore a quella del PKC di riferimento.

Revoca di attributi e Attribute Certificate Revocation List

Un AC può essere revocato anche prima della sua scadenza naturale, su richiesta del titolare o autonomamente dall’emittente. La revoca può avvenire in due modi a seconda della politica scelta: implicitamente, con brevi periodi di validità, o allo stesso modo dei PKC, usando Attribute Certificate Revocation List (ACRL), che sono emesse periodicamente dall’emittente degli AC in accordo alla politica locale e contengono i numeri seriali dei certificati revocati. Poiché le ACRL possono diventare molto grandi e quindi onerose da scaricare e da esaminare, si possono adottare diverse soluzioni:

eliminare la revoca dopo la prima ACRL successiva alla scadenza del certificato;

pubblicare ACRL complete (Base ACRL) e poi solo differenze (Delta ACRL);

partizionare le ACRL in gruppi (ad esempio per ogni mille certificati emessi).

Sono definiti due schemi di revoca degli AC:

never revoke, che non fornisce informazioni sullo stato di revoca;

pointer in AC, che rende disponibile nell’AC stesso un puntatore a sorgenti di informazione sullo stato della revoca.

Modelli di distribuzione di AC

Esistono due modelli per la distribuzione di certificati di attributi: il modello “pull” ed il modello “push”. Nel modello push è il client che presenta il suo AC al server, mentre nel modello pull è il server che recupera da una directory l’AC del client. La scelta di uno dei due modelli dipende dalle esigenze del sistema. In generale il modello push è più efficiente dal momento che non c’è bisogno di una richiesta aggiuntiva da parte del server per recuperare l’AC dalla repository. La figura successiva mostra come vengono scambiati gli AC.

Privilege Management Infrastructure

Simile al bisogno di un’infrastruttura per l’uso e la gestione dei certificati di chiave pubblica, è il bisogno di un’infrastruttura per l’uso e la gestione dei certificati di attributi. Sebbene gli AC furono definiti per la prima volta nella terza edizione dello standard X.509, pubblicata nel 1997, è solo nel 2001, nella quarta edizione dello standard, che fu definita un’infrastruttura completa per il loro uso. Tale infrastruttura prende il nome di Privilege Management Infrastructure (PMI). La radice di fiducia di una PMI è detta Source of Authority (SOA). Quest’ultima può delegare i suoi poteri ad AA subordinate. Lo scopo principale di una PMI è fornire una funzione di autorizzazione dopo che è avvenuta l’autenticazione fornita dalla PKI. Questo significa che i certificati di chiave pubblica ed i certificati di attributi devono essere legati in qualche modo. Una possibile opzione è che il campo holder dell’AC contenga il numero seriale e l’identificativo della CA che ha emesso il PKC. Questo legame è mostrato nella figura successiva.

AC		PKC
Version		Version
Holder		SerialNumber
Issuer		Signature
Signature		Issuer
Serial Number		Subject
AttCertValidityPeriod		SubjectPublicKeyInfo
Attributes		IssuerUniqueID
IssuerUniqueID		SubjectUniqueID
Extensions		Extensions

Anche se CA ed AA svolgono funzioni simili, devono essere considerate enti distinti perché attestano caratteristiche complementari degli utenti. Spesso si è portati a confondere PKC e AC, ma un’analogia può chiarire le idee. Mentre un PKC può essere paragonato ad una carta d’identità (identifica il possessore, dura per molto tempo e non dovrebbe essere banale da ottenere), un AC può essere assimilato ad una carta di credito (rilasciata da un’autorità diversa e di durata minore) e, ottenere una carta di credito, tipicamente richiede di presentare una carta di identità.

Cifratura di AC

Se un AC deve essere trasmesso all’interno di un protocollo applicativo o contiene informazioni importanti, come un’applicazione username/password, allora può essere necessario cifrare gli attributi in esso contenuti. In tal caso, gli attributi sono cifrati prima che l’AC venga firmato. In particolare, i dati cifrati contengono, oltre agli attributi, il numero seriale dell’AC ed il nome del suo emittente. Questi valori devono essere uguali ai corrispondenti valori nel corpo dell’AC. Gli attributi sono cifrati usando la struttura EnvelopedData, specificata nell’RFC 2630 “Cryptographic Message Syntax”. In questa struttura, è possibile il seguente schema: per ogni messaggio è generata una chiave simmetrica e quest’ultima è poi cifrata con la chiave pubblica disponibile di ogni destinatario ed è inclusa nell’EnvelopedData.

Processo autorizzativo basato sugli AC

Nel processo autorizzativo basato sugli AC, il destinatario riceve tutte le informazioni di cui ha bisogno per verificare sia l'identità che gli attributi del firmatario del documento. Una volta superato il processo di identificazione, il destinatario deve controllare che l'AC del mittente sia stato emesso da un AA fidata, estrarne gli attributi, analizzarli e verificare se sono quelli richiesti e necessari per prendere in considerazione il messaggio ricevuto. Tale processo è mostrato nella figura successiva.