¿Deben existir restricciones de nombre en una CA subordinada emitida a una organización?

4

Estaba mirando Autoridad de Internet G2 de Google. Es una CA subordinada (crítica, CA: VERDADERO, pathlen: 0) certificada por GeoTrust. El volcado está debajo.

Presumiblemente, GeoTrust certificó que CA para Google para que Google pueda administrar sus propiedades web (correcciones, por favor). Sin embargo, el subordinado carece de una restricción de nombre para que Google pueda acuñar certificados para cualquier propiedad web, y no solo para los que posee.

Tanto el IETF como el CA / B Forums tienen restricciones de nombre que podrían usarse para hacer cumplir la política (en lugar de permitir que una organización acuñe certificados para cualquier propiedad web). Los documentos relevantes son RFC 5280, 4.2.1.10 Restricciones de nombre y Requisitos básicos, 9.7 Restricciones técnicas en certificados de CA subordinados mediante restricciones de nombre .

A menudo, la falta de una restricción de nombre en una CA subordinada es una preocupación mínima porque hay un revendedor externo independiente que actúa como un auditor que evalúa la validez de la solicitud de firma. Pero en este caso, no hay un revendedor independiente que actúe como auditor y no hay separación de inquietudes.

GeoTrust es propiedad de Symantec, y Symantec es miembro de CA / Browser Forums .

¿Por qué la CA subordinada carece de restricciones de nombre? ¿Deben existir restricciones de nombre en la CA subordinada en este caso?

$ 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
    
pregunta jww 05.04.2015 - 05:34
fuente

4 respuestas

3

La estructura está mal.

Si Google usa este certificado intermedio solo para firmar dominios que son propiedad de Google (lo cual creo que es el caso) no pueden hacerlo con un certificado de ruta restringida, porque necesitan firmar google.com y google.co.uk y gmail.com e incluso com.google ahora que poseen ese TLD.

En mi opinión, la PKI estaba mal diseñada para comenzar, y no se puede arreglar sin comenzar desde cero con algo un poco más restringido y jerárquico como dnssec.

    
respondido por el tylerl 06.04.2015 - 00:16
fuente
1

Es posible que este certificado de CA esté vinculado al certificado raíz de GeoTrust a través del servicio 'GeoRoot' de Geotrust, que "permite a las organizaciones con su propia autoridad de certificación (CA) encadenarse a la raíz pública ubicua de GeoTrust". Consulte enlace .

    
respondido por el mti2935 05.04.2015 - 22:57
fuente
0
  

¿Por qué la CA subordinada carece de restricciones de nombre?

Porque los navegadores ignorarían estas configuraciones de todos modos. Actualmente no hay una forma técnica de restringir qué certificados pueden emitir las sub-CA.

    
respondido por el Steffen Ullrich 05.04.2015 - 10:18
fuente
0

Creo que está asumiendo que Google no es confiable o que esto es una supervisión en el modelo de confianza de la Autoridad de Certificación.

No creo que haya un problema con Google al ejecutar una autoridad de certificación. Tal vez puedan elegir restringirlo a sus propios dominios, pero nada les impide celebrar un acuerdo con una CA raíz establecida (o comprar en) y ser una CA pública firmante.

Si demuestran la seguridad y el proceso adecuados, deberían tener la libertad de emitir cualquier certificado a una identidad validada.

    
respondido por el Gabe 19.04.2015 - 19:44
fuente

Lea otras preguntas en las etiquetas