[SSL Observatory] Name constraints: a reasonable idea that hasn't panned out in practice

[=JeffH]

 >> * why couldn't a Swedish CA be able to deliver a certificate to
 >> *.google.com?

well, I think what Chris was really imagining is mis-issuance of certs, for
(well-known) entities that already have certs, to bad actors who then want to
MITM users of said entities.

 > Perhaps because Google is a US company. Similarly, perhaps we should expect
 > certificates for names in google.se to be signed by a Swedish CA.

that's all layer 9 (ie political/bidniz) stuff, and a quagmire because such
"expectations" don't necessarily map to layer 9 realities.


 > I don't know what a good policy for name constraints would be.

My gut feeling is that "name constraints" as specified in X.509 & PKIX are
pretty much unworkable in the real world (see my prior post).


 > So ideas younger than name constraints have been widely and well implemented
 > already. Maybe nobody really wants name constraints, or maybe there is some
 > technical or other limitation in the idea as currently specified. Maybe we
 > could rectify that.

there were a couple of longish threads wrt Name Constraints (and related cert 
naming issues) recently (in IETF-time) on the certid@ list that may be 
illustrative of the mess of issues involved here...

Re: [certid] Need to define "most specific RDN"
     * From: Nelson B Bolyard <nelson at bolyard.me>
     * To: certid at ietf.org
     * Date: Wed, 14 Jul 2010 08:47:36 -0700
http://www.ietf.org/mail-archive/web/certid/current/msg00248.html


[certid] CN-ID and name constraints

     * From: Matt McCutchen <matt at mattmccutchen.net>
     * To: certid at ietf.org
     * Date: Thu, 23 Sep 2010 21:10:22 -0400
http://www.ietf.org/mail-archive/web/certid/current/msg00381.html


fyi/fwiw, the spec that came out of all the discussions on certid@ (and tls@, 
apps-discuss@, etc) is...

Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS)
(aka "tls server id check")
http://tools.ietf.org/html/rfc6125

..whose length and complexity should inform the reader about how 
gnarly/unwieldy all this PKIX/X.509 stuff is.

=JeffH