I vincoli di nome devono essere presenti su una CA subordinata emessa da un'organizzazione?

4

Stavo guardando Autorità Internet G2 di Google . È una CA subordinata (critica, CA: TRUE, pathlen: 0) certificata da GeoTrust. La discarica è sotto.

Presumibilmente, GeoTrust ha certificato tale CA per Google in modo che Google possa gestire le sue proprietà web (correzioni, per favore). Tuttavia, al subordinato manca un vincolo di nome in modo che Google possa coniare i certificati per qualsiasi proprietà web, e non solo per quelli che possiede.

Sia i forum IETF che CA / B hanno vincoli di nome che potrebbero essere utilizzati per applicare la politica (piuttosto che consentire a un'organizzazione di coniare certificati per qualsiasi proprietà web). I documenti pertinenti sono RFC 5280, 4.2.1.10 Vincoli di nome e Requisiti di base, 9.7 Vincoli tecnici nei certificati CA subordinati tramite vincoli di nome .

Spesso, la mancanza di un vincolo del nome in una CA subordinata è una preoccupazione minima perché c'è un rivenditore indipendente di terze parti che funge da auditor che sta valutando la validità della richiesta di firma. Ma in questo caso, non esiste un rivenditore indipendente che agisca come revisore dei conti e non vi è alcuna separazione dei dubbi.

GeoTrust è di proprietà di Symantec e Symantec è membro del CA / forum del browser .

Perché alla CA subordinata mancano i vincoli del nome? In questo caso i vincoli dei nomi dovrebbero essere presenti sulla CA subordinata?

$ openssl x509 -in google-g2.pem -inform PEM -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 146038 (0x23a76)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
        Validity
            Not Before: Apr  5 15:15:55 2013 GMT
            Not After : Dec 31 23:59:59 2016 GMT
        Subject: C=US, O=Google Inc, CN=Google Internet Authority G2
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9c:2a:04:77:5c:d8:50:91:3a:06:a3:82:e0:d8:
                    50:48:bc:89:3f:f1:19:70:1a:88:46:7e:e0:8f:c5:
                    f1:89:ce:21:ee:5a:fe:61:0d:b7:32:44:89:a0:74:
                    0b:53:4f:55:a4:ce:82:62:95:ee:eb:59:5f:c6:e1:
                    05:80:12:c4:5e:94:3f:bc:5b:48:38:f4:53:f7:24:
                    e6:fb:91:e9:15:c4:cf:f4:53:0d:f4:4a:fc:9f:54:
                    de:7d:be:a0:6b:6f:87:c0:d0:50:1f:28:30:03:40:
                    da:08:73:51:6c:7f:ff:3a:3c:a7:37:06:8e:bd:4b:
                    11:04:eb:7d:24:de:e6:f9:fc:31:71:fb:94:d5:60:
                    f3:2e:4a:af:42:d2:cb:ea:c4:6a:1a:b2:cc:53:dd:
                    15:4b:8b:1f:c8:19:61:1f:cd:9d:a8:3e:63:2b:84:
                    35:69:65:84:c8:19:c5:46:22:f8:53:95:be:e3:80:
                    4a:10:c6:2a:ec:ba:97:20:11:c7:39:99:10:04:a0:
                    f0:61:7a:95:25:8c:4e:52:75:e2:b6:ed:08:ca:14:
                    fc:ce:22:6a:b3:4e:cf:46:03:97:97:03:7e:c0:b1:
                    de:7b:af:45:33:cf:ba:3e:71:b7:de:f4:25:25:c2:
                    0d:35:89:9d:9d:fb:0e:11:79:89:1e:37:c5:af:8e:
                    72:69
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E

            X509v3 Subject Key Identifier: 
                4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://g.symcb.com/crls/gtglobal.crl

            Authority Information Access: 
                OCSP - URI:http://g.symcd.com

            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.11129.2.5.1

    Signature Algorithm: sha1WithRSAEncryption
         27:8c:cf:e9:c7:3b:be:c0:6f:e8:96:84:fb:9c:5c:5d:90:e4:
         77:db:8b:32:60:9b:65:d8:85:26:b5:ba:9f:1e:de:64:4e:1f:
         c6:c8:20:5b:09:9f:ab:a9:e0:09:34:45:a2:65:25:37:3d:7f:
         5a:6f:20:cc:f9:fa:f1:1d:8f:10:0c:02:3a:c4:c9:01:76:96:
         be:9b:f9:15:d8:39:d1:c5:03:47:76:b8:8a:8c:31:d6:60:d5:
         e4:8f:db:fa:3c:c6:d5:98:28:f8:1c:8f:17:91:34:cb:cb:52:
         7a:d1:fb:3a:20:e4:e1:86:b1:d8:18:0f:be:d6:87:64:8d:c5:
         0a:25:42:51:ef:b2:38:b8:e0:1d:d0:e1:fc:e6:f4:af:46:ba:
         ef:c0:bf:c5:b4:05:f5:94:75:0c:fe:a2:be:02:ba:ea:86:5b:
         f9:35:b3:66:f5:c5:8d:85:a1:1a:23:77:1a:19:17:54:13:60:
         9f:0b:e1:b4:9c:28:2a:f9:ae:02:34:6d:25:93:9c:82:a8:17:
         7b:f1:85:b0:d3:0f:58:e1:fb:b1:fe:9c:a1:a3:e8:fd:c9:3f:
         f4:d7:71:dc:bd:8c:a4:19:e0:21:23:23:55:13:8f:a4:16:02:
         09:7e:b9:af:ee:db:53:64:bd:71:2f:b9:39:ce:30:b7:b4:bc:
         54:e0:47:07
    
posta jww 05.04.2015 - 05:34
fonte

4 risposte

3

La struttura è completamente sbagliata.

Se Google utilizza questo certificato intermedio solo per la firma di domini di proprietà di Google (che credo sia il caso), non possono farlo con un certificato di percorso limitato, perché devono firmare google.com e google.co.uk e gmail.com e anche com.google ora che possiedono quel TLD.

A mio parere, il PKI era progettato male per cominciare, e non c'è modo di aggiustarlo senza ricominciare da zero con qualcosa di un po 'più ristretto e gerarchico come dnssec.

    
risposta data 06.04.2015 - 00:16
fonte
1

È possibile che questo certificato CA sia collegato al certificato di origine di GeoTrust tramite il servizio "GeoRoot" di Geotrust, che "consente alle organizzazioni con la loro autorità di certificazione (CA) di concatenare l'Ubiquitous Public Root di GeoTrust". Vedi link .

    
risposta data 05.04.2015 - 22:57
fonte
0

Why does the subordinate CA lack the name constraints?

Perché i browser ignorerebbero comunque queste impostazioni. Al momento non esiste un modo tecnico per limitare i certificati che le sotto-CA possono rilasciare.

    
risposta data 05.04.2015 - 10:18
fonte
0

Penso che tu stia presupponendo che Google non sia attendibile o che si tratti di una svista nel modello di attendibilità dell'autorità di certificazione.

Non penso che ci sia un problema con Google che esegue un'autorità di certificazione. Forse possono scegliere di vincolarlo ai propri domini, ma nulla impedisce loro di stipulare un accordo con una CA Root stabilita (o di acquistare su!) E di essere una CA pubblica.

Se dimostrano sicurezza e processo appropriati, dovrebbero essere liberi di rilasciare qualsiasi certificato su un'identità convalidata.

    
risposta data 19.04.2015 - 19:44
fonte

Leggi altre domande sui tag