颁发给组织的从属 CA 上是否应该存在名称约束?

信息安全 公钥基础设施 证书颁发机构
2021-08-17 04:57:53

我正在查看 Google 的Internet Authority G2它是一个通过 GeoTrust 认证的从属 CA(关键,CA:TRUE,pathlen:0)。转储在下面。

据推测,GeoTrust 为 Google 认证了 CA,因此 Google 可以管理其网络资产(请更正)。但是,该下属没有名称限制,因此 Google 可以为任何网络资产创建证书,而不仅仅是它拥有的那些。

IETF 和 CA/B 论坛都有名称限制,可用于执行策略(而不是允许组织为任何网络资产铸造证书)。相关文档是RFC 5280、4.2.1.10 名称约束基线要求、9.7 通过名称约束在从属 CA 证书中的技术约束

通常,从属 CA 中缺少名称约束是最小的问题,因为有一个独立的第三方经销商充当审计员,正在评估签名请求的有效性。但在这种情况下,没有独立的经销商担任审计员,也没有关注点分离。

GeoTrust归赛门铁克所有,赛门铁克是CA/浏览器论坛的成员。

为什么从属 CA 缺少名称约束?在这种情况下,从属 CA 上是否应该存在名称约束?


$ 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
4个回答

结构全错。

如果 Google 仅使用此中间证书来签署 Google 拥有的域(我认为是这种情况),他们无法使用受限路径证书来执行此操作,因为他们需要签署 google.com 和 google.co.uk 以及 gmail。 com 甚至 com.google 现在他们拥有该 TLD。

在我看来,PKI 一开始就设计得很糟糕,如果不从头开始使用像 dnssec 这样更受限制和分层的东西,就无法修复它。

此 CA 证书可能通过 Geotrust 的“GeoRoot”服务链接到 GeoTrust 的根证书,该服务“允许拥有自己的证书颁发机构 (CA) 的组织链接到 GeoTrust 的无处不在的公共根”。请参阅http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root -54048807.html

为什么从属 CA 缺少名称约束?

因为浏览器无论如何都会忽略这些设置。目前没有技术方法来限制子 CA 可以颁发哪些证书。

我认为您假设 Google 不受信任,或者这是证书颁发机构信任模型中的疏忽。

我认为 Google 运行证书颁发机构没有问题。也许他们可以选择将其限制在自己的域中,但没有什么能阻止他们与已建立的根 CA 签订协议(或购买!)并成为公共签名 CA。

如果他们展示了适当的安全性和流程,他们应该可以自由地向经过验证的身份颁发任何证书。