[cabfpub] Ballot 92 reviewed

[Jeremy Rowley]

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. 

 

Section 9.2.2 - Internal Server Name Use

Under v1.0, section 9.2.2 of the baseline requirements permitted an internal
server name or reserved IP address within the CN field of a certificate. The
change prohibits this practice in an attempt to ensure that each certificate
is associated with an identifiable entity. A certificate containing only a
single internal server name could be used to MITM anyone else with the same
single internal server name.

 

Section 9.2.7 - Internationalized Names

The changes in section 9.2.7 restrict use of mixed characters and certain
confusing characters in certificates to prevent confusable domains.
Allowing internationalized domain names can lead to the inclusion of
visually similar (so-called "confusable") characters in certificates.
Restricting this practice will prevent phishing attacks on domains using
certificates with characters that may be poorly interpreted by a browser.

 

Section 10.3 - Information Requirements

This change is to clarify that at least one subjectAltName extension entry
is required.  CN was deprecated in v1.0.  This change furthers the
deprecation by shifting domain name entries into the subjectAltName
extension.

 

Section 11.1.3 - Wildcard Validation

The current requirements permit  an essentially unrestricted use of the
wildcard character in a domain name. The argument against unrestricted
wildcard characters is set forth in RFC6125:

 

"Wildcard certificates automatically vouch for any and all host names within
their domain.  This can be convenient for administrators but also poses the
risk of vouching for rogue or buggy hosts.
 
   o  Specifications for existing application technologies are not clear
      or consistent about the allowable location of the wildcard
      character, such as whether it can be:
 
      *  only the complete left-most label (e.g., *.example.com)
 
      *  some fragment of the left-most label (e.g., fo*.example.com,
         f*o.example.com, or *oo.example.com)
 
      *  all or part of a label other than the left-most label (e.g.,
         www.*.example.com or www.foo*.example.com)
 
      *  all or part of a label that identifies a so-called "public
         suffix" (e.g., *.co.uk or *.com)
 
      *  included more than once in a given label (e.g.,
         f*b*r.example.com
 
      *  included as all or part of more than one label (e.g.,
         *.*.example.com)
 
These ambiguities might introduce exploitable differences in identity
checking behavior among client implementations and necessitate overly
complex and inefficient identity checking algorithms."
 
By requiring wildcard characters in only the complete left-most label, the
forum's practices will conform to the various RFCs already created and
prevent a possible attack.
 
Section 11.1.4 - New gTLD Domains
ICANN will begin the process of issuing new generic Top Level Domains
(gTLDs) beginning in 2012, therefore certain Certificates for non-public
names will need to be revoked on an accelerated schedule. A failure to
revoke certificates issued to internal server name containing the new gTLDs
will result in collisions throughout the Internet and mis-represent the
actual owner of the (now) publicly registered domain. As Brad Hill said "If
customers feel there is a property right relative to the name that has been
infringed, they need to take that up with ICANN, not the CA.  There is a
dispute process in place for this kind of issue.  CAs issuing publicly
trusted certificates with a DNS-ID type have an obligation to conform to the
public registration of names, not to second-guess the registries. (as was so
often pointed out with regard to my suggestions on IDNA restrictions)"
 
Please, don't hesitate to ask any additional questions about the ballot or
proposed changes.  I will respond as soon as I am able.
 
Thanks,
Jeremy

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cabforum.org/pipermail/public/attachments/20121025/94d4aa47/attachment-0001.html