>> **  But talking about TLS/SNI to SSL suppliers is like talking about the
>> lifeboats on the Titanic ... we don't need it because SSL is unsinkable.

Apache support for this came out 12 months ago.  Does any one know of 
statistics that show what percentage of installed Apache servers out there are 
running 2.2.12 or greater?  How many of the top 10 Linux distributions are past 
2.2.12?  

A CDN might be able to push SNI forward for its own platform, but mass adoption 
isn't coming until we also have broad compatibility among the client browsers.  
SSL certs as they are currently being used are not good for much if they cause 
a bunch of browser warnings, so I can't see how you could really expect SSL 
suppliers to blast holes in their own "Titanic."  New standards are wonderful, 
but who can use them until they're well supported?

This page says iPhone IOS4 supports SNI.  That just came out.

http://en.wikipedia.org/wiki/Server_Name_Indication

> ... or talking to PKI standards groups about adding a CRL reason code for
> "certificate issued in error" (e.g. to an imposter).  This was turned down
> because CA's never make mistakes, so there's no need to have such a reason
> code.

I wasn't around when this happened, but maybe revoking for "Key compromise" was 
considered just as good.  And maybe it's rare enough not to need its own 
special if() statement in all the browsers.  The browsers don't really do 
different things based on the reason code anyway (to my knowledge) 

Paul Tiemann
(DigiCert)
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to