[cabfpub] Ballot 92 - Subject Alternative Names

Steve Roylance steve.roylance at globalsign.com
Sun Nov 18 17:51:32 UTC 2012

Thanks Ryan for the detailed feedback.

All we are trying to do here is bring clarity to the use of the SAN field.
I have one question below that I need your feedback on prior to the
discussions tomorrow ­ Intranet certificates.  My feedback is in purple and
in line. [SJR]



From:  Ryan Sleevi <sleevi at google.com>
Date:  Friday, 16 November 2012 20:16
To:  Steve Roylance <steve.roylance at globalsign.com>
Cc:  <public at cabforum.org>
Subject:  Re: [cabfpub] Ballot 92 - Subject Alternative Names

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.

> [SJR] - The issue this portion of the Ballot addresses is that from a relying
> party point of view legacy certificate viewers with a CN=nonunique will show
> two certificates as effectively being the same thing when clearly they are
> not.  As we can't change what is used in the installed base we could remove
> the possibility of CN=nonunique as a possible option but still allow it in the
> SAN.    As you seem to want to keep it as an option in the CN, then for the
> record can you clarify if you are happy for CN=nonunique, SAN=nonunique (i.e.
> Intranet certs) to be allowed as viable product options.  If not then could
> you please propose how you would like to word the ballot to disallow them and
> we can consider this prior to the start of voting.   If you do wish to allow
> them then unfortunately I have nothing to add.

* 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.

> [SJR] - As do we all.

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

> [SJR] - We all hope SNI will eventually make this point moot, however in the
> mean time there IS a difference between 10 Domains in 1 cert and 10 domains in
> 10 certs.  In the former you can ONLY have one key.  In the latter you can
> have one to 10 keys, so there is a security difference if you are one of the
> domain owners and it's not you who has the key.   10 apartments in a flat with
> one shared front door is a wholly different situation to 10 apartments with 10
> keys.   Yes they are the same when all 10 keys to all 10 apartments are the
> same.   In a shared hosting environments there are many places where it's not
> 100% clear who has access to the private keys.  The owner(s), the host(s) or
> someone else.  
> Google is both a browser and a SubCA.   In the case of your country specific
> certificates they all seem to share the same key so I can see why you see
> there's no difference between the two types.  (Left hand side is a OV SAN with
> several hundred domains and the right examples are from the UK and NL and
> indeed they share the same key.  All three attached to this mail so others can
> look as necessary.
> For the SAN example, would you be happy if this were a DV ­ Yes if all sites
> belonged to Google which is what is still allowed with this ballot?   Would
> you be happy if you shared the keys for this with several other entities where
> you only knew their domain names?   I doubt you would. - of course this is
> hypothetical as that would not happen at Google.
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

> [SJR] - Standard DV certificates are not hindered.   DV certificates with the
> same owner are likewise not hindered.   The only thing that is hindered is
> mixed/unclear ownership certificates or those with non unique content.

* 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

> [SJR] - If you welcome a much sooner date for the deprecation of these
> certificates then please vote positively for this ballot as we hope to
> persuade some users to move away from internal names sooner rather than later
> by making it harder.

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.

     [SJR] - As above, I think the reverse is true.  Less people using over
time will mean less need for CAs to start coming back to the forum with
excuses as to why the date should be pushed out, very much like many did
with 1024bit or signing from the root.

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/20121118/fab82de7/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1AF3BAC3-7259-4867-ACC5-A4CB61D18C28.png
Type: image/png
Size: 160262 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121118/fab82de7/attachment-0004.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: google.nl.cer.txt
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121118/fab82de7/attachment-0012.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Google OV SAN.cer.txt
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121118/fab82de7/attachment-0013.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: google.co.uk.cer.txt
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121118/fab82de7/attachment-0014.txt>

More information about the Public mailing list