Domanda di mappatura dei criteri del certificato X.509

Question

Domanda di mappatura dei criteri del certificato X.509

#1 da (5 voti)

3

Quindi sono un po 'confuso su come funzionano i mapping delle policy dei certificati X.509 . Diciamo che quanto segue descrive la mia catena di certificati:

root CA ---> intermediary CA ---> client cert

La CA radice avrebbe una mappatura dei criteri? In tal caso, come potrebbe esserci un soggettoDomainPolicy? Se subjectDomainPolicy deve corrispondere ai certificati padre issuerDomainPolicy e il certificato in questione è il certificato di livello superiore nella gerarchia, in che modo subjectDomainPolicy può corrispondere a qualcosa? E se non può corrispondere a nulla, cosa dovrebbe essere?

Da RFC X.509:

   In general, certificate policies that appear in the
   issuerDomainPolicy field of the policy mappings extension are not
   considered acceptable policies for inclusion in subsequent
   certificates in the certification path.

Come potrebbe essere? Se la CA radice, nel diagramma sopra, ha una issuerDomainPolicy, ciò equivale a dire che la politica della CA dell'intermediario dovrebbe essere la stessa, non è vero?

cryptography public-key-infrastructure tls certificates x.509

posta compcert 10.03.2012 - 21:45

fonte

1 risposta

Leggi altre domande sui tag cryptography public-key-infrastructure tls certificates x.509

Certificati SSL spuri durante l'accesso ai siti attraverso la rete aziendale Che cos'è chrome.googleechotest.com?

score 5 · Answer 1

L'idea alla base delle politiche dei certificati è che una politica si applica al processo di certificazione completo, dalla radice all'entità finale e questo si riflette nel certificato includendo l'OID della politica in tutti certificati nella catena. Le politiche sono "verticali". Un validatore (qualcuno che convalida la catena di certificati) dovrebbe avere nel proprio archivio fiduciato la definizione di politiche accettabili, in base alla radice. Per immaginarlo in parole semplici: una tipica voce del negozio di fiducia dovrebbe essere qualcosa del tipo "Mi fido questa CA principale (nome + chiave pubblica) per verificare i certificati conformi alla politica 1.2.3.4". Se la politica 1.2.3.4 non appare in tutti i certificati nella catena, il validatore rifiuterà la catena.

Tuttavia, nella PKI gerarchica come quella supportata da X.509, è comune l'isolamento orizzontale: entità che controllano CA e CA subordinate operano a livelli distinti e ogni livello ha i propri requisiti e convenzioni. Pertanto, è stato incluso un meccanismo per gestire tali modifiche basate sul livello, e questo è il mapping dei certificati . Quando una mappatura "1.2.3.4 - 1.5.6.7" appare in un certificato CA da qualche parte nella catena, significa "ciò che era noto come politica 1.2.3.4 nei livelli superiori, è chiamato 1.5.6.7 da questo punto verso il basso". Il nostro validatore, che inizialmente richiede la politica 1.2.3.4, prende atto che ciò che ora dovrebbe cercare nei certificati successivi è 1.5.6.7.

Questo processo è reso più complesso dalle seguenti caratteristiche:

Puoi mappare un OID a diversi OID.
C'è un OID speciale chiamato "anyPolicy" che è un jolly: corrisponde a tutte le politiche.
Ogni certificato nella catena può vietare anyPolicy o richiedere una politica esplicita da qualche punto nel percorso.
Un gran numero di CA ampiamente implementate si sbaglia completamente e utilizza le policy come tipo di commento (in particolare, attribuiscono a ciascuna CA un OID della politica specifico della CA, che la CA include nel certificato, senza alcuna mappatura).

Quindi il triste stato di cose è che le politiche dei certificati, come attualmente implementate, non funzionano come previsto. Gli archivi attendibili contengono solo CA radice senza alcun insieme di criteri (vale a dire che tutti i criteri sono accettati per i percorsi che iniziano con queste radici e non è richiesta alcuna politica esplicita - la "struttura dei criteri" può essere vuota).

CA root di per sé non contengono mapping di criteri. Non sono certificati reali. Una CA radice, nota nello standard come trust anchor , è a conoscenza priori di un nome e di una chiave pubblica associata. Una tradizione pervasiva consiste nel codificare CA radice come certificati, spesso autofirmati (poiché in un certificato esiste un campo "firma" non opzionale). Il formato del certificato è solo conveniente per quello. Tuttavia, i certificati possono contenere molte funzionalità (in particolare molte estensioni) che non hanno senso per CA principale; le mappature dei criteri sono tali caratteristiche.