[cabfpub] Ballot 92 reviewed

[kirk_hall at trendmicro.com]

Jeremy, I know Ballot 92 has been withdrawn, but I expect it will be reintroduced - so we may as well continue the conversation.

Concerning your proposed changes to Sec. 9.2.1 outlawing DV SANs certs, I am still puzzled about what security threat is being addressed.  In your email below, you listed a hypothetical 12 names that could be included in the SANs field of a single DV cert (so long as the customer has demonstrated domain control for each of the 12 names).

Are you saying this single DV SANs cert with 12 names inside (all of which have passed the domain control test with the customer) represents a greater security threat than if the same customer had ordered 12 separate DV certs, each with only one name inside, and had proved domain control for each of the 12 names?  In what way does the DV SANs cert with 12 names inside represent a greater security threat than 12 individual DV certs issued to the same customer?  (I don't believe it does.)  We have to consider the convenience of the customer, and not put artificial barriers or unnecessary extra expense in the way.

You also talk about the need for one of the 12 names to go through the OV vetting process so there is an identified "responsible party" inside the cert (does that make it an OV cert then?  The CA issuer knows that 11 names have not been OV vetted...).  But I think that would be very misleading to Relying Parties - If they look inside the cert with 12 names in the SANs field, and they see an OV-vetted entity's identity listed in the cert, they will probably assume that ALL 12 NAMES in the cert have been OV vetted, and that all 12 names belong to the one entity that is listed in the cert.  But only one domain name was OV vetted, and the remaining 11 were only DV vetted.  That would be terribly misleading to the public, and a bad idea.

We don't issue DV certs, and have no plans to do so, but we strongly oppose any new effort to deprecate DV certs using the Forum's powers to set requirements for CAs.  I hope you will drop this from Ballot 92, or else the other provisions of the ballot (some of which we support) will possibly fail as well.

********************************************************

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Thursday, October 25, 2012 2:08 PM
To: public at cabforum.org
Subject: [cabfpub] Ballot 92 reviewed

Hi everyone,

Ballot 92 addresses the concerns listed below.  These issues have been discussed since at least February of 2012 through various email exchanges.  Kirk Hall asked for a summary explanation of why we consider these changes necessary.  This summary is intended only to explain the purpose of the ballot and is not intended to modify the ballot in any manner.

Section 9.2.1 - Subject Information
Section 9.2.1was modified to require subject information in a certificate containing multiple root domain names.  DV certs are still permitted if the certificate will contain multiple subdomains off the same root domain.  Subject information is also required for certificates that contain a reserved server name or IP address.

This change is necessary because, in certain cases, certificates with multiple domains (SANs) owned by unrelated parties present security problems when no identifying information has been obtained.  Take for instance a DV certificate with multiple SANs as follows:

OBJECT IDENTIFIER : subjectAltName [2.5.29.17]
CONTEXT SPECIFIC (2) : 'xyx.whoami.com'
CONTEXT SPECIFIC (2) : 'www.microswift.com'
CONTEXT SPECIFIC (2) : 'xyz'
CONTEXT SPECIFIC (2) : 'students.fullerton.edu'
CONTEXT SPECIFIC (2) : 'www.paypal.local'
CONTEXT SPECIFIC (2) : '10.0.0.101'
CONTEXT SPECIFIC (2) : 'shareholder.gecapital.com'
CONTEXT SPECIFIC (2) : 'amazon.ez-seller.com'
CONTEXT SPECIFIC (2) : 'www.google.dom'
CONTEXT SPECIFIC (2) : 'fasthost.com'
CONTEXT SPECIFIC (2) : 'authentic.bad-girl.com'
CONTEXT SPECIFIC (2) : 'score.nuthinbut.net'

It's hard to tell who the responsible party is.  (By way of analogy, under traditional limited partnership law, there is always at least one General Partner when the rest of the partners are Limited Partners.)

So even assuming that we're sunsetting certificates with private IP addresses or internal server names, there has never been a decision to not make other related improvements to the security of certificates where necessary.  Certain information should be prohibited in the CN field and that certificates containing internal server names should have additional restrictions, and possibly full Organizational Vetting (regardless of whether such information is contained in the certificate) for the following reasons:

Prior to v1.0 of the baseline requirements, the CN field could contain information other than an FQDN, but allowing a private IP or non-FQDN might result in an incorrect interpretation of the information in this field and create a potential attack. The CN field's multi-purpose use is one of the reasons the field was deprecated, and the Forum shouldn't permit uses of this field that resemble an organization name instead of an FQDN.

A certificate with a non-FQDN or private IP address is essentially non-verified if the certificate lacks organization details.  Providing a certificate without verified information might enable an attacker to perform a MITM attack.  Conversely, if a verified O field were included, that would provide a way to distinguish between various mail.server certificates held by different organizations.

As illustrated above, a certificates containing multiple registered domains must be tied to at least one specified entity.  Including multiple unrelated domains in a single certificate just amplifies the potential damage caused by a single mis-issued certificate.  Multiple domains are now a central part of virtualization, and certificates with multiple domain names should be additionally protected.   Requiring the listing of an organization in certificates with multiple root domains ties the certificate to a verified owner, which is a protection against fraud.  Requiring OV (for at least one entity) helps monitor and/or communicate with all of the other entities receiving and using such certificates.  A certificate with a lot of high profile domains is worrisome if contextual organizational contact information is missing.  When that information is absent, then relying parties are at the mercy of the issuing CA, who may be unwilling to share that contact information because the relying party is not "the customer" in the minds of some CAs.

***

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121027/86e62027/attachment-0004.html>