È possibile creare un PKI solo SMIME che * non può * essere utilizzato per SSL?

Question

È possibile creare un PKI solo SMIME che * non può * essere utilizzato per SSL?

#1 da (1 voti)

0

Supponiamo di avere una CA radice che voglio condividere con terze parti non fidate ostili.

Quindi vincola questa radice usando specifici EKU nella root.

 OID=1.3.6.1.5.5.7.3.4        ; Secure Email

Successivamente, creare una CA politica (controllata dalla radice) per limitare le autorizzazioni concesse alle CA non attendibili utilizzando Path = 1 e Vincoli di nome (vedi anche questo ).

Risultato ideale

Vorrei rilasciare certificati SMIME che sono solo per la firma e un altro per la crittografia (capisco che il supporto varia su questo)

Domanda

È possibile limitare il nome, l'uso avanzato delle chiavi e l'utilizzo delle chiavi in modo che una CA ostile a cui è delegato il potere non possa creare certificati HTTPS e non possa creare certificati SMIME per altri domini?

Se quanto sopra è vero; Penso che sia possibile creare un solo PKI SMIME (correggimi se ho torto)

Sono particolarmente preoccupato per l'abilità (o la sua mancanza) di vincola il campo di utilizzo della chiave nella CA, in modo che qualsiasi client correttamente (o ampiamente distribuito) vedrà che la catena CA non è consentita emettere certificati HTTPS e ne rifiuterne uno se offerto.

L'estensione Uso chiave è descritta nella sezione 4.2.1.3 di X.509, con i seguenti possibili contrassegni:

KeyUsage ::= BIT STRING {
   digitalSignature        (0), -- Needed for SMIME and (EC)DHE TLS implementations
   nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
                                -- Accepted in some TLS implementations if (0) is missing
   keyEncipherment         (2),  Used in RSA based TLS
   dataEncipherment        (3),  Accepted in some TLS implementations if (2) is missing
   keyAgreement            (4),  Accepted in some TLS implementations if (2) is missing
   keyCertSign             (5),
   cRLSign                 (6),
   encipherOnly            (7),
   decipherOnly            (8) }

public-key-infrastructure tls certificates certificate-authority

posta random65537 18.06.2014 - 18:35

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure tls certificates certificate-authority

TrueCrypt alternative (cripta partizione) La crittografia e successivamente l'invio di una stringa clearext nota dopo un cattivo design di Diffie-Hellman?

score 1 · Answer 1

È possibile creare una CA radice che non può essere utilizzata per SSL con ... non usando per SSL!

Quando una CA rilascia un certificato per una CA secondaria, lo fa nel contesto di un determinato contratto di fiducia. La sub-CA accetta di emettere certificati solo in conformità con un numero di regole che sono esplicitate nella Politica di certificazione e nella Dichiarazione di pratica dei certificati - questi sono documenti legali destinati al consumo umano. Se si desidera una CA radice che può essere utilizzata per S / MIME ma non per SSL, la CA principale deve indicare nel proprio CP e CPS che i certificati relativi alla CA principale non devono essere utilizzati per SSL. In particolare, la sub-CA presta il giuramento formale di non rilasciare certificati in grado di SSL (cioè non metterà i nomi delle macchine nell'estensione del nome dell'estensione del soggetto o nella parte Common Name del SubjectDN e metteranno un uso chiave esteso esteso estensione che dice "solo per S / MIME").

In X.509 ci sono due categorie di tali "regole PKI":

Regole che vengono applicate dall'algoritmo di validazione. I vincoli di nome, ad esempio, possono (teoricamente) essere utilizzati per impedire la convalida dei certificati in modo che il nome del certificato dell'entità finale non faccia parte di uno spazio dei nomi dei nomi consentiti debitamente specificato in uno dei certificati CA intermedi.
Regole che non sono applicate dall'algoritmo di validazione. La regola "no SSL" sarebbe una regola del genere.

Nella pura teoria di X.509, non c'è bisogno di applicare le regole nell'algoritmo di validazione; la revoca viene utilizzata per mantenere l'ordine e punire le entità che si comportano male. Tuttavia, in pratica, la revoca è asincrona e troppo lenta per reagire agli "attacchi flash". Un utente malintenzionato che desidera eseguire un server falso ha bisogno solo di una decina di minuti per mettere in atto un notevole danno; vedere il suo certificato revocato due giorni dopo non lo scoraggerà. Questo è il motivo per cui un certo numero di regole PKI sono ora applicate a livello di validazione, prima di tutto incarnato dall'estensione dei vincoli di base: al proprietario del certificato non è concesso il potere della CA.

Esiste (attualmente) alcuna applicazione automatica delle regole relative all'utilizzo delle chiavi estese. Se una CA desidera applicare una regola no-SSL, non deve emettere certificati che possono essere utilizzati per SSL e deve fare in modo che CA sub-AC rispetti la stessa regola. La mancanza di tale applicazione è un problema solo se un sub-CA si comporta male, e il certificato ottenuto può essere utilizzato come certificato server SSL per perpetrare qualche crimine odioso prima che la giusta revoca colpisca la sub-CA incriminata.

(Si noti che l'estensione Uso chiave copre solo una manciata di casi d'uso generici, come "crittografia" o "firma", e questo non è correlato all'utilizzo di chiavi estese.Inoltre, l'estensione Uso chiave non è più ereditata lungo un percorso del certificato rispetto all'estensione dell'uso della chiave estesa.)

C'è un altro punto in cui le regole possono essere incise: nei clienti . I client si fidano della CA radice (questo è ciò che li rende "root CA"), ma possono fidarsi di loro solo per ruoli specifici. Vedi ad esempio questo screenshot dal visualizzatore di certificati nelle preferenze di Firefox:

L'elencodi"usi" è configurabile e consente al client di limitare una determinata CA a determinate situazioni.

Questo meccanismo:

non è supportato da informazioni scritte nel certificato CA radice stesso, ma da metadati che devono essere mantenuti da un meccanismo fuori banda;
non è standardizzato (ogni sistema ha la propria nozione di "ruoli");
è specifico per root CA (trust anchors) e non può essere collegato a una CA intermedia;
vale qualcosa solo nella misura in cui le applicazioni pertinenti si occupano delle restrizioni e le applicano.

Eppure funziona. Se si desidera una CA radice solo S / MIME, quindi distribuirla e installarla nei client con il tag "solo per S / MIME". Questa è valida come estensione EKU automatica a percorso completo (se esiste una cosa del genere).