Passa al contenuto principale

4. Details of the Protocol (Dettagli del protocollo)

4. Details of the Protocol (Dettagli del protocollo)​

La sintassi ASN.1 importa i termini definiti in [RFC5280]. Per il calcolo della firma, i dati da firmare sono codificati utilizzando le regole di codifica distinte (DER - Distinguished Encoding Rules) ASN.1 [X.690].

Il tagging ASN.1 EXPLICIT viene utilizzato come impostazione predefinita se non diversamente specificato.

I termini importati da altrove sono Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier e CRLReason.

4.1. Request Syntax (Sintassi della richiesta)​

Questa sezione specifica la specifica ASN.1 per una richiesta di conferma. La formattazione effettiva del messaggio potrebbe variare a seconda del meccanismo di trasporto utilizzato (HTTP, SMTP, LDAP, ecc.).

4.1.1. ASN.1 Specification of the OCSP Request (Specifica ASN.1 della richiesta OCSP)​

La struttura ASN.1 corrispondente a OCSPRequest è:

OCSPRequest     ::=     SEQUENCE {
    tbsRequest                  TBSRequest,
    optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {
    version             [0]     EXPLICIT Version DEFAULT v1,
    requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
    requestList                 SEQUENCE OF Request,
    requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

Signature       ::=     SEQUENCE {
    signatureAlgorithm      AlgorithmIdentifier,
    signature               BIT STRING,
    certs               [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}

Version         ::=             INTEGER  {  v1(0) }

Request         ::=     SEQUENCE {
    reqCert                     CertID,
    singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

CertID          ::=     SEQUENCE {
    hashAlgorithm       AlgorithmIdentifier,
    issuerNameHash      OCTET STRING, -- Hash of issuer's DN
    issuerKeyHash       OCTET STRING, -- Hash of issuer's public key
    serialNumber        CertificateSerialNumber }

I campi in OCSPRequest hanno i seguenti significati:

  • tbsRequest è la richiesta OCSP facoltativamente firmata.

  • optionalSignature contiene l'identificatore dell'algoritmo ed eventuali parametri dell'algoritmo associati in signatureAlgorithm; il valore della firma in signature; e, facoltativamente, i certificati di cui il server ha bisogno per verificare la risposta firmata (normalmente fino a, ma escluso, il certificato radice del client).

Il contenuto di TBSRequest include i seguenti campi:

  • version indica la versione del protocollo, che per questo documento è v1(0).

  • requestorName è FACOLTATIVO (OPTIONAL) e indica il nome del richiedente OCSP.

  • requestList contiene una o più richieste di stato del certificato singolo.

  • requestExtensions è FACOLTATIVO (OPTIONAL) e include estensioni applicabili alle richieste trovate in reqCert. Vedere la Sezione 4.4.

Il contenuto di Request include i seguenti campi:

  • reqCert contiene l'identificatore di un certificato di destinazione.

  • singleRequestExtensions è FACOLTATIVO (OPTIONAL) e include estensioni applicabili a questa singola richiesta di stato del certificato. Vedere la Sezione 4.4.

Il contenuto di CertID include i seguenti campi:

  • hashAlgorithm è l'algoritmo di hash utilizzato per generare i valori issuerNameHash e issuerKeyHash.

  • issuerNameHash è l'hash del nome distinto (DN) dell'emittente. L'hash deve essere calcolato sulla codifica DER del campo nome dell'emittente nel certificato oggetto di controllo.

  • issuerKeyHash è l'hash della chiave pubblica dell'emittente. L'hash deve essere calcolato sul valore (esclusi tag e lunghezza) del campo chiave pubblica del soggetto nel certificato dell'emittente.

  • serialNumber è il numero di serie del certificato per il quale viene richiesto lo stato.

4.1.2. Notes on OCSP Requests (Note sulle richieste OCSP)​

Il motivo principale per utilizzare l'hash della chiave pubblica della CA in aggiunta all'hash del nome della CA per identificare l'emittente è che è possibile che due CA scelgano di utilizzare lo stesso Nome (l'unicità nel Nome è una raccomandazione che non può essere imposta). Due CA non avranno mai, tuttavia, la stessa chiave pubblica a meno che le CA non abbiano deciso esplicitamente di condividere la loro chiave privata o che la chiave di una delle CA sia stata compromessa.

Il supporto per qualsiasi estensione specifica è FACOLTATIVO (OPTIONAL). Il flag critical NON DOVREBBE (SHOULD NOT) essere impostato per nessuna di esse. La Sezione 4.4 suggerisce diverse estensioni utili. Estensioni aggiuntive POSSONO (MAY) essere definite in RFC aggiuntive. Le estensioni non riconosciute DEVONO (MUST) essere ignorate (a meno che non abbiano il flag critical impostato e non siano comprese).

Il richiedente PUÒ (MAY) scegliere di firmare la richiesta OCSP. In tal caso, la firma viene calcolata sulla struttura tbsRequest. Se la richiesta è firmata, il richiedente DEVE (SHALL) specificare il proprio nome nel campo requestorName. Inoltre, per le richieste firmate, il richiedente PUÒ (MAY) includere certificati che aiutano il responder OCSP a verificare la firma del richiedente nel campo certs di Signature.

4.2. Response Syntax (Sintassi della risposta)​

Questa sezione specifica la specifica ASN.1 per una risposta di conferma. La formattazione effettiva del messaggio potrebbe variare a seconda del meccanismo di trasporto utilizzato (HTTP, SMTP, LDAP, ecc.).

4.2.1. ASN.1 Specification of the OCSP Response (Specifica ASN.1 della risposta OCSP)​

Una risposta OCSP consiste come minimo in un campo responseStatus che indica lo stato di elaborazione della richiesta precedente. Se il valore di responseStatus è una delle condizioni di errore, il campo responseBytes non è impostato.

OCSPResponse ::= SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful            (0),  -- Response has valid confirmations
    malformedRequest      (1),  -- Illegal confirmation request
    internalError         (2),  -- Internal error in issuer
    tryLater              (3),  -- Try again later
                                -- (4) is not used
    sigRequired           (5),  -- Must sign the request
    unauthorized          (6)   -- Request unauthorized
}

Il valore per responseBytes consiste in un OBJECT IDENTIFIER e una sintassi di risposta identificata da quell'OID codificata come OCTET STRING.

ResponseBytes ::=       SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

Per un responder OCSP di base, responseType sarà id-pkix-ocsp-basic.

id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

I responder OCSP DEVONO (SHALL) essere in grado di produrre 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.

Il valore per response DEVE (SHALL) essere la codifica DER di BasicOCSPResponse.

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Il valore per signature DEVE (SHALL) essere calcolato sull'hash della codifica DER di ResponseData. Il responder PUÒ (MAY) includere certificati nel campo certs di BasicOCSPResponse che aiutano il client OCSP a verificare la firma del responder. Se non sono inclusi certificati, allora certs DOVREBBE (SHOULD) essere assente.

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   responderID              ResponderID,
   producedAt               GeneralizedTime,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName               [1] Name,
   byKey                [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)

SingleResponse ::= SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,
   nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    good        [0]     IMPLICIT NULL,
    revoked     [1]     IMPLICIT RevokedInfo,
    unknown     [2]     IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime              GeneralizedTime,
    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL

4.2.2. Notes on OCSP Responses (Note sulle risposte OCSP)​

4.2.2.1. Time (Orario)​

Le risposte possono contenere quattro orari -- thisUpdate, nextUpdate, producedAt e revocationTime. La semantica di questi campi è definita nella Sezione 2.4. Il formato per GeneralizedTime è come specificato nella Sezione 4.1.2.5.2 di [RFC5280].

I campi thisUpdate e nextUpdate definiscono un intervallo di validità raccomandato. Questo intervallo corrisponde all'intervallo {thisUpdate, nextUpdate} nelle CRL. Le risposte il cui valore nextUpdate è precedente al valore dell'orario di sistema locale DOVREBBERO (SHOULD) essere considerate inaffidabili. Le risposte il cui orario thisUpdate è successivo all'orario di sistema locale DOVREBBERO (SHOULD) essere considerate inaffidabili.

Se nextUpdate non è impostato, il responder indica che informazioni di revoca più recenti sono disponibili tutto il tempo.

4.2.2.2. Authorized Responders (Responder Autorizzati)​

La chiave che firma le informazioni sullo stato di un certificato non deve necessariamente essere la stessa chiave che ha firmato il certificato. È necessario, tuttavia, garantire che l'entità che firma queste informazioni sia autorizzata a farlo. Pertanto, l'emittente di un certificato DEVE (MUST) fare una delle seguenti cose:

  • firmare le risposte OCSP stesso, o

  • designare esplicitamente questa autorità a un'altra entità

La delega della firma OCSP DEVE (SHALL) essere designata dall'inclusione di id-kp-OCSPSigning in un'estensione del certificato di uso esteso della chiave inclusa nel certificato del firmatario della risposta OCSP. Questo certificato DEVE (MUST) essere emesso direttamente dalla CA che è identificata nella richiesta.

La CA DOVREBBE (SHOULD) usare la stessa chiave di emissione per emettere un certificato di delega di quella usata per firmare il certificato che viene controllato per la revoca. I sistemi che si affidano alle risposte OCSP DEVONO (MUST) riconoscere un certificato di delega come emesso dalla CA che ha emesso il certificato in questione solo se il certificato di delega e il certificato che viene controllato per la revoca sono stati firmati dalla stessa chiave.

Nota: Per retrocompatibilità con la RFC 2560 [RFC2560], non è vietato emettere un certificato per un Authorized Responder utilizzando una chiave di emissione diversa dalla chiave usata per emettere il certificato che viene controllato per la revoca. Tuttavia, tale pratica è fortemente sconsigliata, poiché i client non sono tenuti a riconoscere un responder con tale certificato come un Authorized Responder.

id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

I sistemi o le applicazioni che si affidano alle risposte OCSP DEVONO (MUST) essere in grado di rilevare e imporre l'uso del valore id-kp-OCSPSigning come descritto sopra. Essi POSSONO (MAY) fornire un mezzo per configurare localmente una o più autorità di firma OCSP e specificare l'insieme di CA per le quali ogni autorità di firma è attendibile. DEVONO (MUST) rifiutare la risposta se il certificato richiesto per convalidare la firma sulla risposta non soddisfa almeno uno dei seguenti criteri:

  1. Corrisponde a una configurazione locale dell'autorità di firma OCSP per il certificato in questione, o

  2. È il certificato della CA che ha emesso il certificato in questione, o

  3. Include un valore di id-kp-OCSPSigning in un'estensione di uso esteso della chiave ed è emesso dalla CA che ha emesso il certificato in questione come indicato sopra.

Criteri di accettazione o rifiuto aggiuntivi possono applicarsi sia alla risposta stessa che al certificato utilizzato per convalidare la firma sulla risposta.

4.2.2.2.1. Revocation Checking of an Authorized Responder (Controllo della revoca di un Responder Autorizzato)​

Poiché un responder OCSP autorizzato fornisce informazioni di stato per una o più CA, i client OCSP devono sapere come verificare che il certificato di un Authorized Responder non sia stato revocato. Le CA possono scegliere di affrontare questo problema in uno dei tre modi seguenti:

  • Una CA può specificare che un client OCSP può fidarsi di un responder per la durata del certificato del responder. La CA lo fa includendo l'estensione id-pkix-ocsp-nocheck. Questa DOVREBBE (SHOULD) essere un'estensione non critica. Il valore dell'estensione DEVE (SHALL) essere NULL. Le CA che emettono tale certificato dovrebbero rendersi conto che una compromissione della chiave del responder è grave quanto la compromissione di una chiave CA utilizzata per firmare le CRL, almeno per il periodo di validità di questo certificato. Le CA possono scegliere di emettere questo tipo di certificato con una durata molto breve e rinnovarlo frequentemente.
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

  • Una CA può specificare come il certificato del responder deve essere controllato per la revoca. Ciò può essere fatto utilizzando i punti di distribuzione CRL se il controllo deve essere fatto utilizzando le CRL, o utilizzando l'Accesso alle Informazioni dell'Autorità se il controllo deve essere fatto in qualche altro modo. I dettagli per specificare uno di questi due meccanismi sono disponibili in [RFC5280].

  • Una CA può scegliere di non specificare alcun metodo di controllo della revoca per il certificato del responder, nel qual caso spetterebbe alla politica di sicurezza locale del client OCSP decidere se tale certificato debba essere controllato per la revoca o meno.

4.2.2.3. Basic Response (Risposta di base)​

Il tipo di risposta base contiene:

  • la versione della sintassi della risposta, che DEVE (MUST) essere v1 (il valore è 0) per questa versione della sintassi della risposta base;

  • o il nome del responder o un hash della chiave pubblica del responder come ResponderID;

  • l'orario in cui la risposta è stata generata;

  • risposte per ciascuno dei certificati in una richiesta;

  • estensioni opzionali;

  • una firma calcolata su un hash della risposta; e

  • l'OID dell'algoritmo di firma.

Lo scopo delle informazioni ResponderID è consentire ai client di trovare il certificato utilizzato per firmare una risposta OCSP firmata. Pertanto, le informazioni DEVONO (MUST) corrispondere al certificato che è stato utilizzato per firmare la risposta.

Il responder PUÒ (MAY) includere certificati nel campo certs di BasicOCSPResponse che aiutano il client OCSP a verificare la firma del responder.

La risposta per ciascuno dei certificati in una richiesta è costituita da:

  • un identificatore del certificato per il quale vengono fornite informazioni sullo stato di revoca (cioè, il certificato di destinazione);

  • lo stato di revoca del certificato (good, revoked, o unknown); se revocato, indica l'orario in cui il certificato è stato revocato e, facoltativamente, il motivo per cui è stato revocato;

  • l'intervallo di validità della risposta; e

  • estensioni opzionali.

La risposta DEVE (MUST) includere una SingleResponse per ogni certificato nella richiesta. La risposta NON DOVREBBE (SHOULD NOT) includere elementi SingleResponse aggiuntivi, ma, ad esempio, i responder OCSP che pre-generano risposte di stato potrebbero includere elementi SingleResponse aggiuntivi se necessario per migliorare le prestazioni di pre-generazione della risposta o l'efficienza della cache (secondo [RFC5019], Sezione 2.2.1).

4.3. Mandatory and Optional Cryptographic Algorithms (Algoritmi crittografici obbligatori e facoltativi)​

I client che richiedono servizi OCSP DEVONO (SHALL) essere in grado di elaborare risposte firmate utilizzando RSA con SHA-256 (identificato dall'OID sha256WithRSAEncryption specificato in [RFC4055]). I client DOVREBBERO (SHOULD) anche essere in grado di elaborare risposte firmate utilizzando RSA con SHA-1 (identificato dall'OID sha1WithRSAEncryption specificato in [RFC3279]) e il Digital Signature Algorithm (DSA) con SHA-1 (identificato dall'OID id-dsa-with-sha1 specificato in [RFC3279]). I client POSSONO (MAY) supportare altri algoritmi.

Ultimo aggiornamento il