[cabfpub] Ballot 92 - Subject Alternative Names

Ryan Sleevi sleevi at google.com
Fri Nov 16 20:16:49 UTC 2012

Steve, members,

Let me first say categorically that Google does not support this motion and
will vote No. As discussed previously, we believe there are several flaws
in the reasoning for this motion, and do not believe this meaningfully
improves security on the Internet.

* On the matter of forbidding internal names or IPs in the CN, but
permitting them in SANs.

The entire purpose of permitting the CN to contain duplicated information
from the SAN is to support legacy clients that only support or examine the
CN for information about the assured server identity. Forbidding it in the
CN, but not in the SAN, in our view does absolutely nothing to improve the
quality of validated information within the certificate. As all member
browsers in this Forum are examining the SAN for the assured server
identity, and thus ignoring the CN, this only serves to actively break
these legacy clients, for reasons that remain unclear. While we support
measures to outright forbid internal names and internal IPs (for the many
reasons shared previously), we don't think this proposal is consistent with
the security concerns involved, nor do we think it's reasonable to
arbitrarily break such legacy clients.

* On the matter of requiring OV validation for distinct domain names within
a cert

We believe DV certs have played and will continue to play a vital part in
improving web security, and thus oppose measures that seek to deprecate or
prevent their usage. DV certs allow a domain holder, with minimal cost and
effort, to establish a secure presence on the Internet, protecting their
visitors from passive eavesdropping, fingerprinting, and, to some degree,
from a variety of active attacks. As we have promoted in numerous forums,
the wider deployment of TLS is something we strongly support, and we think
DV offers a reasonable and compelling solution to permit opportunistic
encryption with a domain.

As has been repeatedly explained to members advocating for this, the
security properties of one certificate with ten names vs ten certificates
with one name, are in the real world indistinguishable. This is because we
view DV certificates as a means of asserting domain authorization - and
not, as some member CAs may view - as a way of establishing identity or
trustworthiness. Because the technical value of one certificate with ten
names is still significantly greater than ten certificates with one name,
preventing them seems both misguided and hostile towards DV, and thus also
hostile to actually improving and encouraging the deployment of TLS on the

It is regrettable that a number of TLS clients still do not support SNI,
but that ship has sailed and that deployment is our reality. Making SNI a
requirement, or making it more difficult and complicated to obtain
certificates that are functionally equivalent to SNI, is something that is
only going to hinder TLS deployment, which is why we do not support this

* On the matter of requiring OV for internal names

It should come as no surprise that, as a browser and as a member deeply
concerned about security on the web, we strongly dislike the issuance of
internal names in publicly trusted certificates, in all forms. We do not
believe that a publicly trusted CA can or should be asserting ownership of
a particular internal name - which is why we support their deprecation in
October 2016, and would welcome it much sooner if member CAs felt it was

The proposal to require OV for these names is alluring at first, if only
because it makes it more difficult to obtain these names, ergo it will
further discourage CAs from issuing them and subscribers from obtaining
them. However, coupled with the proposal has been the suggestion that
somehow OV addresses the security concerns of internal names, which is a
position which we actively disagree with and we think may be harmful to the
future deprecation of such names.

Thus, while we support this effort, it should be clear our motivations, and
that we'd not support measures to further encourage, permit, or undeprecate
internal names, regardless of any additional validation checks that may be
proposed in the future.

On Fri, Nov 16, 2012 at 12:35 AM, Steve Roylance <
steve.roylance at globalsign.com> wrote:

> Morning Ryan,
> So what you are saying below, is that because there are a few clients out
> there that can only support CN  (CN = mail or CN = for example)
> then it's acceptable (until Nov 2015) for CAs to offer single dimensional
> 'intranet' certificates with no other verified content? (This is what Rich
> was first eluding to in his initial post)
> Does this not mean an attacker could very easily build up a portfolio of
> attack certs with various internal names and IPs and pretty much zero
> traceability?
> Or are you saying (unlike Rich) that other details should be added?
>  That's what we are saying with ballot 92.  We are simply saying that to
> deter hackers we need to know the details of the entity to add to the
> Subject O field and not that they simply have control/access to an FQDN
> which also may be untraceable when it comes to investigation/crunch time.
> See lines 14/15/16 and 34/35/36 on my spreadsheet with the examples I
> created to illustrate the situations we wish to prevent.
> I hope it's clear that this is both from a security perspective and as
> Jeremy already answered last night, relying party understanding perspective.
> Have a great weekend and no doubt speak to you on Monday's call ;-)
> Steve
> From: Ryan Sleevi <sleevi at google.com>
> Date: Thursday, 15 November 2012 22:26
> To: Eddy Nigg <eddy_nigg at startcom.org>
> Cc: <public at cabforum.org>
> Subject: Re: [cabfpub] Ballot 92 - Subject Alternative Names
> 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.
> _______________________________________________ Public mailing list
> Public at cabforum.orghttps://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121116/c1078391/attachment-0004.html>

More information about the Public mailing list