[cabfpub] Ballot 92 - Subject Alternative Names

[Ryan Sleevi]

On Thu, Nov 15, 2012 at 2:10 PM, Eddy Nigg (StartCom Ltd.) <
eddy_nigg at startcom.org> wrote:

>
> On 11/15/2012 11:52 PM, From Rich Smith:
>
>  Since many clients and servers will still choke on a cert with no Common
> Name.
>
>
> Rich, can you please give me real examples of commonly used browsers and
> servers that wouldn't work? Much appreciated.
>
>   Regards      Signer:  Eddy Nigg, COO/CTO    StartCom Ltd.<http://www.startcom.org>
> XMPP:  startcom at startcom.org  Blog:  Join the Revolution!<http://blog.startcom.org>
> Twitter:  Follow Me <http://twitter.com/eddy_nigg>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
I don't know if the volume is many, but I have seen a variety of
vendor-proprietary implementations that behave as Rich describes.

However, I don't think think the volume of affected clients matter - the
whole point of permitting entries in the CN (in addition to the SAN) is to
support such clients.

For any *new* client, which supports SAN, what benefits does this provide /
security threats does this address?
 - I would suggest none, since any SAN-supporting client will ignore the CN

For any *old* client, which does not support SAN, what benefits does this
provide / security threats does this address?
  - Given that internal IPs / hostnames are still permissible in the SAN, I
would suggest none.


I'm certainly sympathetic to the argument "The UI [might be] ambiguous",
but I think that's a different problem, and arguably address[ed/able] today
by requiring the value of the CN match one of the values of the SANs, so it
remains unclear to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121115/2c8cb1bf/attachment-0004.html>