1. Introduction (Introduzione)

1. Introduction (Introduzione)

Questo documento specifica un protocollo utile per determinare lo stato corrente di un certificato digitale senza richiedere CRLs. Meccanismi aggiuntivi che affrontano i requisiti operativi PKIX sono specificati in documenti separati.

Questa specifica rende obsoleti [RFC2560] e [RFC6277]. Il motivo principale per la pubblicazione di questo documento è affrontare le ambiguità che sono state riscontrate dalla pubblicazione della RFC 2560. Questo documento differisce dalla RFC 2560 solo in poche aree:

• La Sezione 2.2 estende l'uso della risposta "revoked (revocato)" per consentire questo stato di risposta per certificati che non sono mai stati emessi.

• La Sezione 2.3 estende l'uso della risposta di errore "unauthorized (non autorizzato)", come specificato in [RFC5019].

• Le Sezioni 4.2.1 e 4.2.2.3 affermano che una risposta può includere informazioni sullo stato di revoca per certificati che non erano inclusi nella richiesta, come consentito in [RFC5019].

• La Sezione 4.2.2.2 chiarisce quando un responder è considerato un Authorized Responder (Responder Autorizzato).

• La Sezione 4.2.2.3 chiarisce che il campo ResponderID corrisponde al certificato del firmatario del responder OCSP.

• La Sezione 4.3 modifica l'insieme di algoritmi crittografici che i client devono supportare e l'insieme di algoritmi crittografici che i client dovrebbero supportare come specificato in [RFC6277].

• La Sezione 4.4.1 specifica, per l'estensione nonce, la sintassi ASN.1 che mancava nella RFC 2560.

• La Sezione 4.4.7 specifica una nuova estensione che può essere inclusa in un messaggio di richiesta per specificare gli algoritmi di firma che il client preferirebbe che il server utilizzasse per firmare la risposta come specificato in [RFC6277].

• La Sezione 4.4.8 specifica una nuova estensione che indica che il responder supporta l'uso esteso della risposta "revoked" per certificati non emessi definiti nella Sezione 2.2.

• L'Appendice B.2 fornisce un modulo ASN.1 utilizzando la sintassi 2008 di ASN.1, che aggiorna [RFC5912].

Una panoramica del protocollo è fornita nella Sezione 2. I requisiti funzionali sono specificati nella Sezione 3. I dettagli del protocollo sono discussi nella Sezione 4. Copriamo i problemi di sicurezza con il protocollo nella Sezione 5. L'Appendice A definisce OCSP su HTTP, l'Appendice B fornisce elementi sintattici ASN.1 e l'Appendice C specifica i tipi MIME per i messaggi.

1.1. Requirements Language (Linguaggio dei requisiti)

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nella RFC 2119 [RFC2119].