Perché RFC 4158 (Path Building) limita le ancore di Trust ai certificati autofirmati?

Naviga le tue risposte
7

Ho problemi con l'utilizzo di Wget per scaricare un file su HTTPS da ftp.gnu.org utilizzando la radice Let's Encrypt X3 . Il Let's Encrypt X3 è sottoposto a certificazione incrociata, il che significa che ha un emittente e non è autofirmato. Quando utilizzi Let's Encrypt X3 , Wget non riesce con l'errore non riesce a trovare il certificato emittente anche se sto cercando di radicare la fiducia nel certificato Let's Encrypt.

Ho visitato RFC 4158, infrastruttura a chiave pubblica Internet X.509: percorso del percorso di certificazione per vedere quale dovrebbe essere il comportamento . Il documento discute in dettaglio i percorsi di costruzione da certificati di entità finale o di sottoscrizione a root di root e ancore di fiducia. È quello che ci si aspetterebbe.

Tuttavia, Sezione 1.3 fornisce una terminologia e definisce i trust ancore:

  • Elenco di attendibilità : un elenco di trust ancore.

  • Trust anchor : la combinazione di una chiave pubblica attendibile e il nome dell'entità a cui appartiene la corrispondente chiave privata.

  • Certificato di ancoraggio attendibile : un certificato autofirmato per un'ancora di attendibilità utilizzata nell'elaborazione del percorso di certificazione.

  • "Certificato di ancoraggio attendibile" e la definizione che richiede "autofirmato" significa che non possiamo radicare la fiducia in un certificato subordinato, come Let's Encrypt X3 root che è stato sottoposto a certificazione incrociata.

La mia domanda è, perché l'RFC lo ha fatto? Perché siamo costretti a utilizzare un certificato autofirmato come ancoraggio e includere porzioni non necessarie della PKI che servono solo a complicare la creazione di percorsi e ad aumentare la superficie di attacco?

    
posta jww 15.10.2017 - 05:00
fonte

2 risposte

1

Questa è una di quelle sottili e sottili parole. Il significato completo della RFC potrebbe non essere ovvio in prima lettura. Dalla tua domanda ( emphasis mine ):

Trust Anchor: The combination of a trusted public key and the name of the entity to which the corresponding private key belongs. Trust Anchor Certificate: A self-signed certificate for a trust anchor that is used in certification path processing.

Un archivio fidato ha due scopi:

  1. Stabilisci che tutte le firme generate da questa chiave pubblica dovrebbero essere attendibili e
  2. Associare la chiave pubblica a un nome (in genere un DN (Distinguished Name) LDAP definito in RFC2253 )

Alcuni corollari di questo sono:

  • Tutta la firma eseguita da quella chiave sarà considerata attendibile, incluse le emissioni di certificati.
  • Poiché lo contrassegni come attendibile in modo esplicito, questa chiave non può essere revocata tramite i metodi normali: l'unico modo è rimuoverlo manualmente dal tuo archivio di fiducia.

La sottigliezza qui è che RFC ti permette di appuntare o un certificato, o una chiave pubblica direttamente, tuttavia se tu pin un certificato quindi deve essere un certificato di origine. La RFC fornisce alcune giustificazioni qui:

1.5.1. Hierarchical Structures

A hierarchical PKI, depicted in Figure 1, is one in which all of the end entities and relying parties use a single "Root CA" as their trust anchor.

Dal punto di vista della CA, potrebbero non voler bloccare la CA intermedia perché rimuove la loro capacità di revocarla se viene compromessa: anche se pubblicano una revoca per questo, il client la ignorerà.

Nel caso in cui una CA voglia essere in grado di utilizzare una CA intermedia come ancoraggio affidabile, ho visto che danno un trust entrambi un certificato emesso, e un certificato autofirmato per la stessa chiave pubblica e DN. Suppongo che Let's Encrypt non lo faccia per le sue CA intermedie.

Per quanto riguarda la tua domanda attuale su wget , ftp.gnu.org e Let's Encrypt X3 CA intermedio, penso che tu abbia due opzioni:

  • Trova il certificato di base autofirmato che ha emesso Let's Encrypt X3 e aggiungilo al tuo trust store.
  • Scopri come aggiungere direttamente una chiave pubblica. Questo dipenderà dal software / stack del sistema operativo in uso e dal fatto che supporti la parte arcaica e non comune della RFC che consente a un'ancora di trust di essere una chiave e non un certificato.
risposta data 25.12.2017 - 00:42
fonte
0

Come presupposto generale: se non è autofirmato; stai facendo affidamento su qualche altra entità per infondere fiducia; quell'altra entità per definizione diventa l'ancora.

Sebbene molte implementazioni possano fidarsi di qualcosa di più lungo la catena, questa non è una funzione di PKI / x509 - è un trust fuori banda; quindi fuori campo per la RFC.

Solleva una domanda: perché dovresti infondere fiducia implicita in un'ancora, che di per sé non ha fiducia implicita dal suo emittente (potrebbe essere revocato)

    
risposta data 24.11.2017 - 23:56
fonte

Leggi altre domande sui tag

Come memorizzare nonce e chiave quando si lavora con libsodium secretbox? Esistono servizi VPN di livello consumer che supportano l'autenticazione a due fattori, come SecurID?