Requisiti di accettazione della risposta OCSP ambigui

Naviga le tue risposte
1

Ci sono 6 requisiti menzionati nella RFC 2560 per una risposta OCSP da considerare come una risposta OCSP valida:

  1. Il certificato identificato in una risposta ricevuta corrisponde a quello identificato nella richiesta corrispondente;
  2. La firma sulla risposta è valida;
  3. L'identità del firmatario corrisponde al destinatario della richiesta.
  4. Il firmatario è attualmente autorizzato a firmare la risposta.
  5. L'ora in cui lo stato indicato è corretto (questo aggiornamento) è sufficientemente recente.
  6. Se disponibile, l'ora o prima di quali informazioni più recenti saranno disponibili sullo stato del certificato (nextUpdate) è maggiore dell'ora corrente.

L'ambiguità in questi requisiti è la seguente:

  1. Perché dobbiamo controllare il numero 3? È possibile che io invii una richiesta OCSP a Comodo CA, e quindi ricevo una risposta da Trust Iden CA ad esempio ?! Voglio dire, non è sufficiente controllare se la risposta è firmata da una delle CA di fiducia nei miei computer?
  2. Perché dobbiamo controllare il numero 4? C'è qualche caso che in quel caso un risponditore OSCP di CA divenga non autorizzato dopo un po '? Se è così, perché? (Intendo quali casi)?
posta Abraham 02.09.2017 - 13:26
fonte

1 risposta

4

La risposta OCSP non deve necessariamente essere firmata dalla stessa entità che ha firmato il certificato originale, in quanto questa responsabilità può essere delegata esplicitamente.

Questo è discusso nella sezione 4.2.2.2 di RFC 2560:

4.2.2.2 Authorized Responders

The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST either sign the OCSP responses itself or it MUST explicitly designate this authority to another entity. OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that issued the certificate in question.

Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-ad-ocspSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs for which each signing authority is trusted. They MUST reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria:

  1. Matches a local configuration of OCSP signing authority for the certificate in question; or

  2. Is the certificate of the CA that issued the certificate in question; or

  3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question.

Riguardo a questa parte della tua domanda:

I mean, isn't it enough to check if the response is signed by one of the trusted CAs in my computers?

È fondamentale che non sia così, altrimenti qualsiasi CA compromessa potrebbe falsificare una risposta OCSP per qualsiasi certificato, piuttosto che solo certificati emessi da esso (o delegati ad esso). Questo non è limitato alle CA pubbliche; immagina il caso in cui la CA interna di un'azienda (ad esempio per l'uso con la sua intranet) è compromessa e utilizzata per falsificare le risposte OCSP quando gli utenti visitano siti Web esterni, evitando così HPKP e altre operazioni di pinzatura.

la sottosezione 4.2.2.2.1 spiega il controllo 4; anche il risponditore OCSP deve essere controllato per la revoca per evitare che una CA revocata sia in grado di falsificare le risposte OCSP.

    
risposta data 02.09.2017 - 14:34
fonte

Leggi altre domande sui tag

Come pericolo installare APk da fuori Google Play? [duplicare] Posso generare e memorizzare chiavi sul mio Yubico?