Subject: [dbound] Another use case to consider....

From: Jeffrey Walton <[email-masked]>
Date: Tue, 7 Apr 2015 22:33:20 -0400

Hi Everyone,

I know its a little late in the game, but the following use case might
be helpful (if its not already covered).

The use case is verifying the end-entity certificate issued by an
organizational subordinate CA *without* constraints.

In the case of organization subordinate CA *without* constraints, the
independent 3rd party auditor (the RA) was removed *and* a name
constraint was not used to enforce policy. Lack of name constraints
means we don't know what domains the organization is authorized to
issue for.

It seems like DBOUND would be a good place to look for an answer to
the question: what domains is an organizational subordinate CA
authorized to issue for?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 08 Apr 2015 09:25:34 -0400

> the question: what domains is an organizational subordinate CA

The implication here is that the organizational subordinate CA doesn't
have name constraints, but *does* have some DNS label embedded in it
somehow.  is that right?

Take a look at the "Google Internet Authority G2" intermediate
organizational certificate below (with parsed output from GnuTLS's
certtool -i).

The only DNS labels included in this certificate are AIA and CRL
distribution points.

How would you apply dbound to limit the scope of this organizational
intermediate certificate?

I tend to think that explicit name constraints are the way to go, since
they are already pretty clearly specified; we just need to actually get
tools to respect them (and CAs to issue intermediate certs with them)!

    --dkg

X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 023a76
	Issuer: C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA
	Validity:
		Not Before: Fri Apr 05 15:15:55 UTC 2013
		Not After: Sat Dec 31 23:59:59 UTC 2016
	Subject: C=US,O=Google Inc,CN=Google Internet Authority G2
	Subject Public Key Algorithm: RSA
	Algorithm Security Level: Medium (2048 bits)
		Modulus (bits 2048):
			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 (bits 24):
			01:00:01
	Extensions:
		Authority Key Identifier (not critical):
			c07a98688d89fbab05640c117daa7d65b8cacc4e
		Subject Key Identifier (not critical):
			4add06161bbcf668b576f581b6bb621aba5a812f
		Basic Constraints (critical):
			Certificate Authority (CA): TRUE
			Path Length Constraint: 0
		Key Usage (critical):
			Certificate signing.
			CRL signing.
		CRL Distribution points (not critical):
			URI: http://g.symcb.com/crls/gtglobal.crl
		Authority Information Access (not critical):
			Access Method: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp)
			Access Location URI: http://g.symcd.com
		Certificate Policies (not critical):
			1.3.6.1.4.1.11129.2.5.1
	Signature Algorithm: RSA-SHA1
	Signature:
		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
Other Information:
	SHA1 fingerprint:
		bbdce13e9d537a5229915cb123c7aab0a855e798
	SHA256 fingerprint:
		c3f697a92a293d86f9a3ee7ccb970e20e0050b8728cc83ed1b996ce9005d4c36
	Public Key ID:
		43dad630ee53f8a980ca6efd85f46aa37990e0ea
	Public key's random art:
		+--[ RSA 2048]----+
		|                 |
		|                 |
		|        +        |
		|  .    = =       |
		| . . .o S o      |
		|  . oo = + .     |
		| . ...o = o      |
		|......++ o       |
		|.E+ o=o..        |
		+-----------------+

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 11 Apr 2015 17:45:53 -0400

> intermediate certificate?

I'm trying to get that cleared up now at
https://www.ietf.org/mail-archive/web/pkix/current/msg33275.html. The
first step in handling them correctly is identifying them.

But I suspect all of this is fundamentally broken. Unconstrained
subordinates issued to an organization is just a bad idea...

Jeff

On Wed, Apr 8, 2015 at 9:25 AM, Daniel Kahn Gillmor
<[email-masked]> wrote:
> MIID8DCCAtigAwIBAgIDAjp2MA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
> MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
> YWwgQ0EwHhcNMTMwNDA1MTUxNTU1WhcNMTYxMjMxMjM1OTU5WjBJMQswCQYDVQQG
> EwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzElMCMGA1UEAxMcR29vZ2xlIEludGVy
> bmV0IEF1dGhvcml0eSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
> AJwqBHdc2FCROgajguDYUEi8iT/xGXAaiEZ+4I/F8YnOIe5a/mENtzJEiaB0C1NP
> VaTOgmKV7utZX8bhBYASxF6UP7xbSDj0U/ck5vuR6RXEz/RTDfRK/J9U3n2+oGtv
> h8DQUB8oMANA2ghzUWx//zo8pzcGjr1LEQTrfSTe5vn8MXH7lNVg8y5Kr0LSy+rE
> ahqyzFPdFUuLH8gZYR/Nnag+YyuENWllhMgZxUYi+FOVvuOAShDGKuy6lyARxzmZ
> EASg8GF6lSWMTlJ14rbtCMoU/M4iarNOz0YDl5cDfsCx3nuvRTPPuj5xt970JSXC
> DTWJnZ37DhF5iR43xa+OcmkCAwEAAaOB5zCB5DAfBgNVHSMEGDAWgBTAephojYn7
> qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUSt0GFhu89mi1dvWBtrtiGrpagS8wEgYD
> VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig
> JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF
> BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMBcGA1UdIAQQ
> MA4wDAYKKwYBBAHWeQIFATANBgkqhkiG9w0BAQUFAAOCAQEAJ4zP6cc7vsBv6JaE
> +5xcXZDkd9uLMmCbZdiFJrW6nx7eZE4fxsggWwmfq6ngCTRFomUlNz1/Wm8gzPn6
> 8R2PEAwCOsTJAXaWvpv5Fdg50cUDR3a4iowx1mDV5I/b+jzG1Zgo+ByPF5E0y8tS
> etH7OiDk4Yax2BgPvtaHZI3FCiVCUe+yOLjgHdDh/Ob0r0a678C/xbQF9ZR1DP6i
> vgK66oZb+TWzZvXFjYWhGiN3GhkXVBNgnwvhtJwoKvmuAjRtJZOcgqgXe/GFsNMP
> WOH7sf6coaPo/ck/9Ndx3L2MpBngISMjVROPpBYCCX65r+7bU2S9cS+5Oc4wt7S8
> VOBHBw==