SSL's identity problem
One of the many problems of SSL, especially on the web, is that it gets its idea of identity wrong (in practice, in actual implementations). SSL's version of identity is all tied to abstruse X.509 things, all CN and O and OU and so on, but on the real Internet, users don't think of identity that way; they think of identity as websites, or more exactly of some personal label that they have for the entity that stands behind a website.
This matters because a great deal of SSL's claimed security is based on users understanding the identity of what they're talking to. If they don't, SSL cannot possibly create trust or protect against even moderately clever impersonation attacks, and indeed that is what we see all the time.
(For example, consider the various IDNA homograph attacks. If users actually used the SSL/X.509 idea of identity they would not be fooled in the least, but they don't; they look at the domain name, and the IDNA homograph attacks created lookalike domain names through Unicode tricks.)
Fortunately this is mostly a matter of how applications present SSL identity information, so it can be mostly solved in applications. Roughly speaking, we want to be able to tell users 'this website is the same people as www.microsoft.com' in some useful way. Given IDNA homograph attacks we can't tell the user literally this, but we can get around that by letting the user create tags for organizations and showing those tags as the 'this is part of' identity. (This is more useful for the user anyways.)
(Mechanically we can use the SSL certificate identity information to compare a new certificate's X.509 organizational information to a known certificate for the organization captured when the user made the tag.)
Note that you cannot let organizations assert tags for themselves in certificates, however convenient it would be, because then you are back to both IDNA homograph attacks and the 'we issued a certificate to Microsoft, but it wasn't the right Microsoft' problem.