Quali elementi chiave avanzati sono necessari per le attività dell'infrastruttura PKI? (OID per la firma OSPF e CRL, ecc.)

Question

Quali elementi chiave avanzati sono necessari per le attività dell'infrastruttura PKI? (OID per la firma OSPF e CRL, ecc.)

#1 da (6 voti)

3

Sto costruendo una PKI vincolata che specifica EKU per l'intera gerarchia e voglio documentare gli OID richiesti per le attività di manutenzione dell'albero PKI.

Comprendo che i client potrebbero non convalidare l'intero albero EKU, proprio come alcuni client potrebbero non controllare nemmeno i CRL o gli URL OCSP. Il mio intento è quello di creare una linea di base dell'infrastruttura che possa essere utilizzata per testare l'interoperabilità e documentare in che modo le terze parti convalidano (o non convalidano) i certificati utilizzati dalle CA.

Domanda

Quindi, supponendo che un client convalidi un CRL, OSPF o qualsiasi altro certificato relativo alla manutenzione dell'infrastruttura PKI, quali OID devo includere nel mio EKU di root per abilitare una linea di base di supporto + SMIME?

Ad esempio, alcuni OID che possono riguardare l'infrastruttura PKI possono includere la firma di una CA secondaria (se tale OID esiste) e anche la Subordinazione qualificata. Tuttavia il problema è che tutti gli OID che posso trovare rientrano nello spazio dei nomi Microsoft di 1.3.6.1.4.1.311 o sono semplicemente elencati su questa pagina web . Poiché Microsoft non ha inventato PKI, non voglio creare problemi di interoperabilità includendo solo i loro OID ... Vorrei includere l'implementazione di IBM o Oracle (Java) sulla convalida della CA.

Risposta campione

La risposta ideale dovrebbe includere un elenco di OID (in qualsiasi formato) e una descrizione di ciò per cui è utilizzato nel modo più dettagliato possibile. Quanto segue è nel formato "Capolicy.inf" per il server dei certificati Microsoft, ma tutto quello che mi interessa sono le informazioni ...

 ;OID = 1.3.6.1.4.1.311.20.2.1; Certificate Request Enrollment
 OID = 1.3.6.1.5.5.7.3.9;  OCSP Signing (Required for OCSP)
 ;OID = 1.3.6.1.5.5.7.48.1.5; OCSP signing (SHOWS AS UNKNOWN in some software)
 OID = 1.3.6.1.5.5.7.3.4 ; SMIME
 ; OID = 1.2.840.113549.1.9.15 ; On MSFT.com... Safari reports SMIME
 ; Should I include timestamping OIDs?

Inoltre, se ci sono determinati OID che non dovrei includere, includi anche loro. Ad esempio, i seguenti sembrano essere controversi e potrebbero invalidare i diritti dei certificati inutilmente

;OID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER
;OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_SIGNING

smime public-key-infrastructure certificates certificate-authority certificate-revocation

posta random65537 08.01.2013 - 01:08

fonte

1 risposta

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

È possibile utilizzare un carattere di regex di spazi bianchi per eseguire un'iniezione di javascript? La compressione TLS può essere abilitata su siti CDN di terze parti privi di autenticazione?

score 6 · Answer 1

EKU è Utilizzo chiave esteso ; questa è un'estensione del certificato descritta in X.509 (RFC 5280) , sezione 4.2.1.12. Come dice la RFC:

In general, this extension will appear only in end entity certificates.

perché, contrario a "Criteri certificati", non esiste alcuna nozione di ereditarietà e propagazione di EKU lungo un percorso del certificato. L'estensione EKU parla di possibili usi per la chiave pubblica nel certificato che presenta l'estensione e solo quella chiave pubblica. In quanto tale, la tua idea di "Root EKU" non sembra avere molto senso per me.

Come regola generale, la mancanza di EKU non impedisce l'esecuzione di alcune operazioni, tranne in alcuni casi:

Il certificato per un risponditore OCSP delegato (ovvero quando una risposta OCSP non è firmata dalla stessa CA) DEVE possedere un EKU con OID 1.3.6.1.5.5.7.3.9 (vedere RFC 2560 , sezione 4.2.2.2).
Il certificato per un'Autorità di timestamp DEVE avere un EKU con OID 1.3.6.1.5.6.7.3.8 (vedi RFC 3161 , sezione 2.3, che insiste anche sulla presenza di solo quell'OID nell'estensione EKU, escluso qualsiasi altro OID).

Per altri ruoli, la presenza dell'estensione EKU non è obbligatoria, ma deve essere onorato se presente. Vedi ad esempio Gestione certificati S / MIME , sezione 4.4.4: se l'estensione è presente a tutti, quindi il certificato dovrebbe essere considerato adatto all'utilizzo S / MIME solo se l'OID 1.3.6.1.5.5.7.3.4 è presente, oppure è presente lo speciale OID 2.5.29.37.0 (questo è il "qualsiasi utilizzo chiave "). Ma la mancanza dell'estensione è considerata equivalente a un EKU con l'OID "qualsiasi utilizzo esteso della chiave".

Non esiste "l'uso della chiave estesa" per la firma CA o CRL (per questi, l'estensione "Utilizzo chiave" di base è considerata sufficiente).

Alcuni sistemi possono avere requisiti aggiuntivi specifici del sistema. Ad esempio, per l'accesso con smart card in un contesto di Active Directory, i certificati sulla smart card e i certificati rilasciati allo stesso controller di dominio devono entrambi presentare la versione 1.3.6.1.4.1.311.20.2.2 specifica di Microsoft. . Microsoft è fan totale di EKU; hanno persino escogitato la propria estensione ("criteri applicativi", apparentemente non documentati) che duplica le informazioni dall'estensione EKU.