4.4. Extensions (Estensioni)
4.4. Extensions (Estensioni)
Questa sezione definisce alcune estensioni standard, basate sul modello di estensione impiegato nei certificati X.509 versione 3 (vedere [RFC5280]). Il supporto per tutte le estensioni è facoltativo sia per i client che per i responder. Per ogni estensione, la definizione indica la sua sintassi, l'elaborazione eseguita dal responder OCSP e qualsiasi estensione inclusa nella risposta corrispondente.
4.4.1. Nonce (Nonce)
Il nonce lega crittograficamente una richiesta e una risposta per prevenire attacchi di replay. Il nonce è incluso come una delle requestExtensions nelle richieste, mentre nelle risposte sarebbe incluso come una delle responseExtensions. Sia nella richiesta che nella risposta, il nonce sarà identificato dall'identificatore di oggetto id-pkix-ocsp-nonce, mentre extnValue è il valore del nonce.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Nonce ::= OCTET STRING
4.4.2. CRL References (Riferimenti CRL)
Può essere desiderabile per il responder OCSP indicare la CRL su cui si trova un certificato revocato o onHold (in sospeso). Ciò può essere utile dove OCSP viene utilizzato tra repository, e anche come meccanismo di auditing. La CRL può essere specificata da un URL (l'URL a cui la CRL è disponibile), un numero (numero CRL), o un orario (l'orario in cui è stata creata la CRL pertinente). Queste estensioni saranno specificate come singleExtensions. L'identificatore per questa estensione sarà id-pkix-ocsp-crl, mentre il valore sarà CrlID.
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
Per la scelta crlUrl, la IA5String specificherà l'URL a cui è disponibile la CRL. Per crlNum, l'INTEGER specificherà il valore dell'estensione del numero CRL della CRL pertinente. Per crlTime, il GeneralizedTime indicherà l'orario in cui la CRL pertinente è stata emessa.
4.4.3. Acceptable Response Types (Tipi di risposta accettabili)
Un client OCSP PUÒ (MAY) voler specificare i tipi di risposta che comprende. Per farlo, DOVREBBE (SHOULD) utilizzare un'estensione con l'OID id-pkix-ocsp-response e il valore AcceptableResponses. Questa estensione è inclusa come una delle requestExtensions nelle richieste. Gli OID inclusi in AcceptableResponses sono gli OID dei vari tipi di risposta che questo client può accettare (ad esempio, id-pkix-ocsp-basic).
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
Come indicato nella Sezione 4.2.1, i responder OCSP DEVONO (SHALL) essere in grado di rispondere con risposte del tipo di risposta id-pkix-ocsp-basic. Corrispondentemente, i client OCSP DEVONO (SHALL) essere in grado di ricevere ed elaborare risposte del tipo di risposta id-pkix-ocsp-basic.
4.4.4. Archive Cutoff (Taglio dell'archivio)
Un responder OCSP PUÒ (MAY) scegliere di conservare le informazioni di revoca oltre la scadenza di un certificato. La data ottenuta sottraendo questo valore dell'intervallo di conservazione dall'orario producedAt in una risposta è definita come la data di "archive cutoff" (taglio dell'archivio) del certificato.
Le applicazioni abilitate OCSP utilizzerebbero una data di archive cutoff OCSP per contribuire a provare che una firma digitale era (o non era) affidabile alla data in cui è stata prodotta anche se il certificato necessario per convalidare la firma è scaduto da tempo.
I server OCSP che forniscono supporto per tale riferimento storico DOVREBBERO (SHOULD) includere un'estensione della data di archive cutoff nelle risposte. Se incluso, questo valore DEVE (SHALL) essere fornito come estensione OCSP singleExtensions identificata da id-pkix-ocsp-archive-cutoff e di sintassi GeneralizedTime.
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}
ArchiveCutoff ::= GeneralizedTime
Per illustrare, se un server è gestito con una politica di intervallo di conservazione di 7 anni e lo stato è stato prodotto al tempo t1, allora il valore per ArchiveCutoff nella risposta sarebbe (t1 - 7 anni).
4.4.5. CRL Entry Extensions (Estensioni voce CRL)
Tutte le estensioni specificate come estensioni delle voci CRL -- nella Sezione 5.3 di [RFC5280] -- sono supportate anche come singleExtensions.
4.4.6. Service Locator (Localizzatore di servizi)
Un server OCSP può essere gestito in una modalità in cui il server riceve una richiesta e la instrada al server OCSP che è noto per essere autorevole per il certificato identificato. L'estensione della richiesta serviceLocator è definita a questo scopo. Questa estensione è inclusa come una delle singleRequestExtensions nelle richieste.
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL }
I valori per questi campi sono ottenuti dai campi corrispondenti nel certificato del soggetto.
4.4.7. Preferred Signature Algorithms (Algoritmi di firma preferiti)
Poiché sono consentiti algoritmi diversi dagli algoritmi obbligatori da implementare, e poiché un client attualmente non ha alcun meccanismo per indicare le sue preferenze di algoritmo, c'è sempre il rischio che un server che sceglie un algoritmo non obbligatorio generi una risposta che il client potrebbe non supportare.
Mentre un responder OCSP può applicare regole per la selezione dell'algoritmo, ad esempio, utilizzando l'algoritmo di firma impiegato dalla CA per firmare CRL e certificati, tali regole possono fallire in situazioni comuni:
-
L'algoritmo utilizzato per firmare le CRL e i certificati potrebbe non essere coerente con la coppia di chiavi utilizzata dal responder OCSP per firmare le risposte.
-
Una richiesta per un certificato sconosciuto non fornisce alcuna base per un responder per scegliere tra più opzioni di algoritmo.
L'ultimo criterio non può essere risolto attraverso le informazioni disponibili dalla segnalazione in banda utilizzando il protocollo RFC 2560 [RFC2560] senza modificare il protocollo.
Inoltre, un responder OCSP potrebbe voler impiegare algoritmi di firma diversi da quello utilizzato dalla CA per firmare certificati e CRL per due motivi:
-
Il responder può impiegare un algoritmo per la risposta dello stato del certificato che è meno impegnativo dal punto di vista computazionale rispetto alla firma del certificato stesso.
-
Un'implementazione potrebbe voler proteggersi dalla possibilità di una compromissione derivante da una compromissione dell'algoritmo di firma impiegando due algoritmi di firma separati.
Questa sezione descrive:
-
Un'estensione che consente a un client di indicare l'insieme di algoritmi di firma preferiti.
-
Regole per la selezione dell'algoritmo di firma che massimizzano la probabilità di successo dell'operazione nel caso in cui non siano specificati algoritmi preferiti supportati.
4.4.7.1. Extension Syntax (Sintassi dell'estensione)
Un client PUÒ (MAY) dichiarare un insieme preferito di algoritmi in una richiesta includendo un'estensione degli algoritmi di firma preferiti in requestExtensions della OCSPRequest.
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
La sintassi di AlgorithmIdentifier è definita nella Sezione 4.1.1.2 della RFC 5280 [RFC5280]. La sintassi di SMIMECapability è definita nella RFC 5751 [RFC5751].
sigIdentifier specifica l'algoritmo di firma che il client preferisce, ad esempio, algorithm=ecdsa-with-sha256. I parametri sono assenti per la maggior parte degli algoritmi di firma comuni.
pubKeyAlgIdentifier specifica l'identificatore dell'algoritmo della chiave pubblica del soggetto che il client preferisce nel certificato del server utilizzato per convalidare la risposta OCSP, ad esempio, algorithm=id-ecPublicKey e parameters= secp256r1.
pubKeyAlgIdentifier è FACOLTATIVO (OPTIONAL) e fornisce un mezzo per specificare i parametri necessari per distinguere tra diversi utilizzi di un particolare algoritmo, ad esempio, può essere utilizzato dal client per specificare quale curva supporta per un dato algoritmo a curva ellittica.
Il client DEVE (MUST) supportare ciascuno degli algoritmi di firma preferiti specificati, e il client DEVE (MUST) specificare gli algoritmi in ordine di preferenza, dal più preferito al meno preferito.
La Sezione 4.4.7.2 di questo documento descrive come un server seleziona un algoritmo per firmare le risposte OCSP al client richiedente.
4.4.7.2. Responder Signature Algorithm Selection (Selezione dell'algoritmo di firma del responder)
La RFC 2560 [RFC2560] non specificava un meccanismo per decidere l'algoritmo di firma da utilizzare in una risposta OCSP. Ciò non fornisce un grado sufficiente di certezza sull'algoritmo selezionato per facilitare l'interoperabilità.
4.4.7.2.1. Dynamic Response (Risposta dinamica)
Un responder PUÒ (MAY) massimizzare il potenziale per garantire l'interoperabilità selezionando un algoritmo di firma supportato utilizzando il seguente ordine di precedenza, purché l'algoritmo selezionato soddisfi tutti i requisiti di sicurezza del responder OCSP, dove il primo meccanismo di selezione ha la precedenza più alta:
-
Selezionare un algoritmo specificato come algoritmo di firma preferito nella richiesta del client.
-
Selezionare l'algoritmo di firma utilizzato per firmare una lista di revoca dei certificati (CRL) emessa dall'emittente del certificato che fornisce informazioni sullo stato per il certificato specificato da CertID.
-
Selezionare l'algoritmo di firma utilizzato per firmare la OCSPRequest.
-
Selezionare un algoritmo di firma che è stato pubblicizzato come algoritmo di firma predefinito per il servizio di firma utilizzando un meccanismo fuori banda.
-
Selezionare un algoritmo di firma obbligatorio o raccomandato specificato per la versione di OCSP in uso.
Un responder DOVREBBE (SHOULD) sempre applicare il meccanismo di selezione con il numero più basso che risulta nella selezione di un algoritmo noto e supportato che soddisfa i criteri del responder per la forza dell'algoritmo crittografico.
4.4.7.2.2. Static Response (Risposta statica)
A fini di efficienza, un responder OCSP è autorizzato a generare risposte statiche prima di una richiesta. Il caso potrebbe non consentire al responder di utilizzare i dati della richiesta del client durante la generazione della risposta; tuttavia, il responder DOVREBBE (SHOULD) comunque utilizzare i dati della richiesta del client durante la selezione della risposta pre-generata da restituire. I responder POSSONO (MAY) utilizzare le richieste storiche dei client come parte dell'input per le decisioni su quali diversi algoritmi dovrebbero essere utilizzati per firmare le risposte pre-generate.
4.4.8. Extended Revoked Definition (Definizione estesa di revocato)
Questa estensione indica che il responder supporta la definizione estesa dello stato "revoked" (revocato) per includere anche i certificati non emessi secondo la Sezione 2.2. Uno dei suoi scopi principali è consentire agli audit di determinare il tipo di operazione del responder. I client non devono analizzare questa estensione per determinare lo stato dei certificati nelle risposte.
Questa estensione DEVE (MUST) essere inclusa nella risposta OCSP quando tale risposta contiene uno stato "revoked" per un certificato non emesso. Questa estensione PUÒ (MAY) essere presente in altre risposte per segnalare che il responder implementa la definizione estesa di revocato. Quando inclusa, questa estensione DEVE (MUST) essere inserita in responseExtensions, e NON DEVE (MUST NOT) apparire in singleExtensions.
Questa estensione è identificata dall'identificatore di oggetto id-pkix-ocsp-extended-revoke.
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}
Il valore dell'estensione DEVE (SHALL) essere NULL. Questa estensione NON DEVE (MUST NOT) essere contrassegnata come critica.